Disclaimer
Der nachfolgende Artikel ist ein Meinungsbeitrag und stellt als solcher keine andere Meinung als die meine dar.Weiterhin sind Meinungen keine Fakten, sondern entstehen aus Schlussfolgerungen aus diesen. Die Schlussfolgerungen können falsch, unvollständig, nicht zu Ende gedacht oder auf falscher Grundlage erfolgt sein. Meinungen sollten daher immer zur Diskussion stehen können — die im nachfolgenden Artikel darstellten tun es jedenfalls.
Die elektronische Patientenakte kommt
Am 15.01.2025 ist es so weit: die elektronische Patientenakte (ePA) kommt für alle. Paragraph 341 und 342 des fünften Sozialgesetzbuchs verpflichtet die gesetzlichen Krankenkassen dazu ihren Versicherten eine von der „Gesellschaft für Telematik“ (auch bekannt als „gematik“) zugelassene elektronische Patientenakte anzubieten. Bis zum 14.01.2025 zwar dies nur auf ausdrücklichen Wunsch des Versicherten möglich und notwendig. Ab dem 15.01.2025 erhält jeder Versicherte, der nicht widerspricht, automatisch eine Akte (das sogenannte „Opt-Out-Prinzip“).
Die Umstellung der Bereitstellung der ePA auf ein Opt-Out-Prinzip wurde im Rahmen des „Digital-Gesetzes“ (DigiG) durchgeführt, dass erst am 26.03.2024 verkündet wurde — das Datum der Umstellung wurde jedoch schon Ende des letzten Jahres durch das BMG kommuniziert. Die Abkehr vom Opt-In-Prinzip wurde praktisch das gesamte letzte Jahr von verschiedensten Akteuren hoch kontrovers diskutiert. Insbesondere Datenschützer sehen hier eine Gefährdung des Rechts auf informationelle Selbstbestimmung und von Privacy-By-Design-Prinzipien. Diese Bedenken wurden sicherlich auch dadurch verstärkt, dass zeitgleich eine Vereinfachung des Zugriffs auf Gesundheitsdaten für Forschungszwecke eingeführt wurde. Auch die zentrale Sammlung von Daten in einem System birgt inhärente Gefahren: sollte es einem Hacker gelingen, in eine elektronische Patientenakte einzubrechen, erhält er dadurch auf einen Schlag Zugriff auf hochsensible Daten von hunderttausenden von Patienten.
Aus diesen und anderen Gründen bleibt die Einführung der „ePA für alle“ eine kontroverse Angelegenheit. Praktisch täglich äußern sich namhafte Akteure aus den Bereichen Datenschutz und IT-Sicherheit auf sozialen Medien und in Interviews kritisch über den anstehenden Launch am 15.01. Jüngst hat sich die Diskussion erneut anhand einer kürzlich veröffentlichten „Sicherheitsanalyse“ der ePA für alle des Fraunhofer SIT neu entzündet. Nach Darstellung in einschlägigen Medien (z.B. heise) fanden die Forschenden des SIT „21 Schwachstellen“ von denen unter anderem „4 als hoch“ eingestuft wurden. Für ein zentrales IT-System des Gesundheitswesens, dass in wenigen Monaten für Millionen von Bürgern automatisch eingeführt werden soll, eigentlich ein fatales Ergebnis. Kein Wunder also, dass das Fazit des SIT („Die ePA für alle ist sicher.“) ignoriert wird und dieses Ergebnis von vielen zum Anlass genommen wurde, die Einführung der ePA für alle erneut zur kritisieren und teilweise auch grundsätzlich in Frage zu stellen.
Es gibt nur ein Problem: diese verkürzte Darstellung der Fraunhofer-Studie ist bestenfalls Unsinn und schlimmstenfalls fährlässige Panikmache. Schuld ist daran auch die Studie selbst: basierend auf einer zumindest fragwürdigen Methodik haben die Forschenden des SIT zahlreiche „Schwachstellen“ ermittelt, die keine Schwachstellen sind und auch durch ein positives Gesamtfazit nicht mehr relativiert werden können. Im Folgenden möchte ich erklären, warum das so ist und warum ich die „ePA für alle“ trotz aller Kritik für ausreichend sicher und sinnvoll halte.
Zuvor muss allerdings noch eine wichtige Frage beantwortet werden: warum sollte man mir glauben?
Warum sollte man mir glauben?
Die kurze Antwort: sollte man nicht.
Die gematik veröffentlicht die Spezifikationen aller Produkte des deutschen Gesundheitswesens, die in ihrer Hoheit liegen mitsamt Versionshistorie auf ihrer Webseite (https://gemspec.gematik.de). Zusätzlich pflegt die gematik für zahlreiche Produktarten ein Wiki (https://wiki.gematik.de), in dem viele Hintergrundinformationen, allgemeine Erklärungen, sowie Ablauf- und Systemdiagramme zu finden sind. Es ist also grundsätzlich jedem Interessierten und technisch Versierten möglich sich in die Spezifikationen einzulesen und die Findings des Fraunhofer-Berichts (oder auch andere Aussagen über die ePA) kritisch zu hinterfragen und/oder zu validieren.
Fakt ist aber auch: die ePA ist ein hochkomplexes System mit zahlreichen Abhängigkeiten zu anderen hochkomplexen Systemen, sodass es auch für IT-Experten mitunter schon schwierig ist nur die Systemarchitektur und Kommunikationsflüsse zu durchdringen, geschweige denn eine Einschätzung zur Sicherheit abzugeben.
Das dafür zwingend notwendige Auseinandersetzen mit dem System und der Spezifikation habe ich schon hinter mir. Alter Solutions Deutschland ist nämlich Rahmenvertragspartner der gematik für die Durchführung von Penetrationstests auf alle Arten von IT-Systemen der Telematikinfrastruktur — inklusive der elektronischen Patientenakte. Zusätzlich sind wir auch Partner der SRC für die Durchführung von Penetrationstests während Produktzulassungsverfahren. Die SRC ist einer der wichtigsten Produktgutachter für IT-Systeme, die einer Zulassung durch die gematik unterliegen. Ohne (positives) Produktgutachten keine Zulassung.
In diesen Rollen haben meine Kollegen und ich in den vergangenen Monaten und Jahren die elektronische Patientenakte aus verschiedensten Blickwinkeln analysiert und technisch auf Schwachstellen getestet. Die nachfolgenden Darstellungen speisen sich also nicht nur aus der Lektüre von Spezifikationsdokumenten, sondern auch aus der technischen Auseinandersetzung mit realen Systemen.
Eine Kurzeinführung in die elektronische Patientenakte
Um die nachfolgenden Überlegungen nachvollziehen zu können ist zumindest ein bisschen Hintergrundwissen über die Funktionsweise der ePA, sowie über darin vorhandene Sicherheitsmechanismen notwendig.Dazu zunächst eine Begriffsklärung: ePA ist nicht gleich ePA. Bereits jetzt steht es allen Versicherten frei, bei ihrer Krankenkasse eine elektronische Patientenakte zu beziehen. Die aktuelle ePA trägt die Versionsnummer "2.6" und funktioniert sowohl oberflächlich betrachtet als auch was ihre Kernsicherheitsmechanismen angeht grundlegend anders als die ePA für alle (mit Versionsnummer "3"), die zum 15.01.2025 eingeführt werden wird. Beide ePAs sind dabei als reine Backend-Systeme spezifiziert, also eine Ansammlung von Schnittstellen -- das sogenannte "Aktensystem" -- die durch ein passendes Frontend angesprochen werden können. Dieses sogenannte "Frontend des Versicherten" (FdV) kann allerdings nicht durch eine x-beliebige Applikation realisiert werden (zumindest für die Verwendung durch Versicherte), sondern ist selbst wiederum der Zulassung durch die gematik unterworfen und besitzt eigene Spezifikationsanforderungen. Sowohl aktuell als auch in Zukunft wird das FdV primär eine Mobilapplikation für Android- und iOS sein. Eine reine Browser-basierte Web-Applikation ist nicht vorgesehen.
Die ePA 2.6
Stark vereinfacht dargestellt erfolgt die Authentisierung an der ePA 2.6 zertifikatsbasiert über eine elektronische Gesundheitskarte (eGK). Dazu wird mittels der eGK eine Signatur einer Nonce in einem Challenge-Response-Protokoll erstellt. Durch diese Signatur kann das Aktensystem Versicherte eindeutig authentifizieren und einen Token ausstellen, mit dem weitere Interaktionen authorisiert werden können. Mit diesem Token allein lassen sich jedoch nur einige wenige unkritische Funktionen der ePA nutzen. Für die Interkation mit der Akte selbst (beispielsweise für den Zugriff auf oder die Ablage von Dokumenten) muss zusätzlich ein sogenannter "VAU-Kanal" aufgebaut werden -- VAU steht dabei für vertrauenswürdige Ausführungsumgebung. Um diesen Kanal aufzubauen wird über ECIES zwischen dem FdV und der ePA eine gemeinsame Ableitung eines symmetrischen Schlüssels durchgeführt über den anschließend alle weitere Kommunikation verschlüsselt wird -- wohlgemerkt zusätzlich zu der ohnehin bestehenden TLS-Verschlüsselung. Idee des VAU-Kanals ist es einen durchgehend verschlüsselten Kanal zu demjenigen System zu etablieren, das tatsächlich für die Verarbeitung von sensiblen Daten innerhalb einer Akte zuständig ist -- eben der "vertrauenswürdigen Ausführungsumgebung", für die es noch mal besondere Sicherheitsanforderungen gibt, die auch interne Angreifer (also den Hersteller selbst) berücksichtigen. Über den Sinn und Zweck dieser zusätzlichen Verschlüsselungsschicht lässt sich sicher streiten, sie kann aber einen zusätzlichen Schutz für sensible Informationen bieten, wenn beispielsweise TLS an der DMZ des Betreibers terminiert wird.
Ein zentraler Vorteil der aktuellen Variante der ePA ist aber die Ende-zu-Ende-Verschlüsselung aller Dokumente, die in einer Akte abgelegt werden: jedes Dokument wird mit einem durch das FdV generierten Schlüssel verschlüsselt, bevor es an die ePA übertagen wird. Der Dokumentenschlüssel wird wiederum mit einem "Aktenschlüssel" verschlüsselt neben dem Dokument in der ePA abgelegt. Dieser Aktenschlüssel wird allerdings nicht nur vom FdV generiert, sondern durch eine Art Secret-Sharing mit zwei sogenannten "Schlüsselgenerierungsdiensten" abgeleitet. Einer dieser Dienste wird vom Hersteller des Aktensystems betrieben, der andere von der gematik. Die Authentisierung an diesen Diensten erfolgt wieder über ein Challenge-Response-Protokoll mit der eGK. Hintergrund dieser Konstruktion ist, dass verhindert werden sollte, dass bei Verlust des FdV (also: des Handys) alle in der ePA abgelegten Dokumente unbrauchbar werden (weil die Schlüssel nur auf dem FdV liegen). Stattdessen kann der Schlüssel zur Entschlüsselung der individuellen Dokumentenschlüssel jederzeit durch die Kombination von Informationen von zwei unabhängig betriebenen Diensten abgeleitet werden. Dieser Prozess unterstützt auch das Teilen von Dokumenten mit Leistungserbringern. Wichtig für die Sicherheit des Gesamtsystems ist dabei allerdings die Annahme, dass die beiden Schlüsselgenerierungsdienste jeweils von zwei unabhängigen und nicht kollaborierenden Instanzen betrieben werden.
Experten und Kenner der ePA-Spezifikation werden an dieser Stelle vermutlich die Nase rümpfen und darauf hinweisen, dass es sich dann gar nicht um echte Ende-zu-Ende-Verschlüsselung handelt, da der Schlüssel nicht nur beim Nutzenden selbst vorliegt, sondern mit dessen Identität abgeleitet werden kann. Damit haben sie zwar grundsätzlich recht, allerdings wurde das primäre Schutzziel – nämlich, dass der Betreiber des Aktensystems keinen Zugriff auf die abgelegten Inhalte haben soll – schon sehr gut erfüllt.
Die ePA für alle
Die ePA für alle wirft die meisten der bisher dargestellten Mechanismen über Board. So erfolgt die Authentisierung nicht mehr zertifikatsbasiert an der ePA selbst, sondern über ein weiteres (gematik-reguliertes) System: dem sogenannten "sektoralen Identity Provider" (IdP). Jede Krankenkasse kann dabei ihren eigenen sektoralen IdP betreiben, die jeweils wiederum über eine OpenID-Connect-Föderation über den sogenannten "Federation Master" miteinander verbunden sind. Also einige Komplexitätsschichten mehr.Veränderungen gab es auch bei der Ende-zu-Ende-Verschlüsselung: diese wurde nämlich abgeschafft. Stattdessen sollen die Dokumente im Aktensystem erst beim Hersteller in einer "vertrauenswürdigen Ausführungsumgebung" unter Verwendung eines HSMs ver- und entschlüsselt werden. Für diese neue vertrauenswürdige Ausführungsumgebung gibt es auch neue Sicherheitsanforderungen, die insbesondere die Isolation der VAU von übrigen Systemkomponenten betreffen. Geblieben ist der VAU-Kanal, der eine durchgängige Verschlüsselung vom FdV in die VAU gewährleisten soll. Das Protokoll dazu hat sich allerdings komplett geändert, berücksichtigt jedoch erfreulicherweise durch den Einsatz von "Kyber" – als eines der ersten Systeme überhaupt – Verfahren der Post-Quanten-Kryptographie.
Auch wenn der Wegfall der Schlüsselgenerierungsdienste die Systemkomplexität reduziert, ist es offensichtlich, dass die Gesamtsicherheit durch die Aufgabe der Ende-zu-Ende-Verschlüsselung ebenfalls reduziert wurde. Als Begründung hierfür wurde vom BMG genannt, dass die dokumentenbasierte Verschlüsselung zu ineffizient sein, dass die Forschungsdatenfreigabe bzw. Forschungsdatenspende damit nicht möglich sein und dass es nicht möglich sei, innerhalb der Patientenakte zu suchen. Über alle diese Gründe lässt sich streiten -- dazu später mehr.
Klar wird an dieser Stelle hoffentlich, dass, obwohl der wesentliche gesetzliche Unterschied zwischen ePA 2.6 und ePA 3 "nur" die Umstellung von Opt-In auf Opt-Out ist, der technische Unterschied zwischen beiden Systemvarianten immens ist. In der Praxis bedeutet das, dass eine Neuimplementierung von großen Teilen des Systems erforderlich ist. Eine ambitionierte Aufgabe, wenn man bedenkt, dass die erste verbindliche Version der Spezifikation erst Anfang dieses Jahres veröffentlich wurde.
Der Zulassungsprozess
Für die Beurteilung der Gesamtsicherheit der elektronischen Patientenakte ist es wichtig, sich (erneut) vor Augen zu führen, dass die ePA ein Produkt ist, dass einem Zulassungsprozess durch die gematik unterliegt. Es ist also mitnichten so, dass Hinz und Kunz schlecht und unsicher implementierte Produkte auf den Markt werfen können. Zulassung durch die gematik bedeutet insbesondere, dass das Produkt durch einen zugelassenen Sicherheitsgutachter geprüft werden muss. Dieser muss ein Produktgutachten erstellen, das die Erfüllung der Spezifikationsanforderungen nachweist, sowie eine Aussage über die Gesamtsicherheit des Systems tätigt – nämlich, dass das begutachtete System für den sicheren Einsatz in der Telematikinfrastruktur geeignet ist. Diese Begutachtung erfolgt auf Basis des Quellcodes des geprüften Systems und erfordert die Durchführung von Penetrationstests, deren Umfang und Tiefe teilweise durch die gematik vorgegeben werden, größtenteils aber durch den Gutachter frei festgelegt werden – was sicherlich Raum für Kritik bietet. Auch dazu später mehr.Es müssen aber nicht nur Produkte zugelassen werden, sondern auch Anbieter. Für diese muss dann ein sogenanntes Sicherheitsgutachten erstellt werden, das, ähnlich zur ISO 27001, Prozessaspekte der IT-Sicherheit prüft. Insgesamt müssen IT-Systeme, die einer Zulassung durch die gematik unterliegen einen bedeutend umfassenderen Prüfprozess durchlaufen als praktisch alle anderen IT-Systeme, die wir tagtäglich verwenden. Aus diesem Grund hinken auch alle Vergleiche mit und Hinweise auf US-amerikanische Anbieter für Gesundheitssoftware, denen große Mengen Gesundheitsdaten gestohlen wurden, oder auf Krankenhausinformationssystemen (KIS) mit trivialen Sicherheitslücken, die jeweils keinem derartigen Zulassungsprozess unterliegen.
Die Fraunhofer-Studie
Kommen wir endlich zu dem "Abschlussbericht Sicherheitsanalyse des Gesamtsystems ePA für alle (Frauenhofer SIT)" (;))
Wichtig zu wissen: Das Fraunhofer SIT ist kein Anbieter für Produktgutachten von gematik-Systemen und die einzigen beiden Anbieter der ePA (Ist das nicht blöd, dass es nur zwei Anbieter gibt? Auch dazu später mehr.) sind bereits anderweitig mit Produktgutachten versorgt. Es stellt sich also unmittelbar die Frage welches ePA-Gesamtsystem hier analysiert wurde, wenn noch keines öffentlich verfügbar ist und ein Zugriff auf die Entwicklungssysteme unwahrscheinlich ist. Die Antwort ist denkbar einfach: gar keines.
Die Fraunhofer-Studie hat kein real existierendes ePA-System zur Grundlage, sondern fußt allein auf Spezifikationsvorgaben. Entsprechend sind alle entdeckten Schwachstellen keine Schwachstellen der ePA, sondern höchstens der ePA-Spezifikation.
Wenn also beispielsweise das Fehlen von "Sicheren Entwicklungsprozessen" als Schwachstelle mit "hoch" bewertet wird, geht es hier nicht darum, dass tatsächlich einer oder beide der Hersteller der ePA keine sicheren Entwicklungsprozesse haben, sondern nur darum, dass die Spezifikation das Vorhandensein von sicheren Entwicklungsprozessen nicht in der Form vorschreibt, wie die Fraunhofer-Kollegen das erwarten würde. Wohlgemerkt: das Vorhandensein eines solchen Prozesses ist bereits vorgeschrieben (Kapitel 2.2 gemSpec_DS_Hersteller). Das Delta, das das SIT hier bemängelt scheint sich nur auf fehlende Vorgaben zu Zulieferern von Software zu beziehen.
Sicher mag es sinnvoll sein, dazu mehr Vorgaben in der Spezifikation zu machen. Es handelt sich aber erst mal um ein hypothetisches Problem eines fiktiven Herstellers, aus dem keinesfalls die Aussage abgeleitet werden kann, es handle sich hier um eine Schwachstelle "der ePA für alle" mit Bewertung "hoch".
Wie bereits erwähnt ist es aber durch pure Lektüre und Analyse der Spezifikation, ohne die Möglichkeit mit einem realen System zu interagieren, äußerst schwierig ein belastbares Gesamtbild eines einzelnen Systems zu erhalten. Für die Interaktion eines Versicherten mit der ePA sind mehr als 10 umfangreiche Spezifikationsdokumente relevant, die sich an vielen Stellen gegenseitig referenzieren. In den zwei Monaten zwischen "Arbeiten Stufe 1" und "Draft-Version Gesamtbericht" erscheint es unwahrscheinlich, dass die Autoren der Studie alle relevanten Systeme so tief durchdrungen haben, um eine "umfassende Sicherheitsanalyse der ePA" zu erstellen.
Und tatsächlich: das SIT nimmt eine Abkürzung. Sie nehmen die Spezifikationsdokumente als Grundlage für die Erstellung eines LLM (Large Language Model) mit RAG (Retrieval Augmented Generation) – von dem Fraunhofer SIT auch „gematikGPT“ genannt – und stellen diesem Fragen in natürlicher Sprache zu Anforderungen aus den Spezifikationen. Den bei LLMs typischerweise vorgebrachten Bedenken, dass diese häufiger Inhalte völlig frei erfinden ("halluzinieren") begegnen sie mit dem Einwand, dass sie alle durch das LLM getätigten Aussagen über die Spezifikation manuell validieren. Aber: das LLM kann letztlich (bestenfalls) nur wiedergeben was schon irgendwo steht. Es kann kein inhärentes Verständnis über das System erlangen oder verstehen wie die verschiedenen Systeme und deren Sicherheitsmechanismen zusammenwirken. Auch kann es weitere gesetzliche oder regulatorische Rahmenbedingungen nicht kennen.
Die Aussagen von "gematikGPT" als Grundlage für eine Sicherheitsanalyse zu verwenden ist also methodisch fragwürdig und keine Grundlage für eine "umfassende Sicherheitsanalyse", die mich überzeugt. Basierend auf den Aussagen von "gematikGPT" erstellt das SIT anschließend sogenannte "Angriffsbäume" (Attack Trees), um mögliche Angriffspfade in unterschiedlichen Angreifermodellen abzubilden. Angriffsbäume sind zwar ein etabliertes Werkzeug zur Modellierung von Angriffspfaden, nicht jedoch zur Sicherheitsanalyse. Die Sicherheitsanalyse muss mit einer eigenen Methodik vorgenommen werden (Brainstorming, Erfahrung, STRIDE oder was auch immer). In den Ergebnissen der Studie zeigt sich leider, dass dieser Sicherheitsanalyse etwas mehr umfassendes Systemverständnis und weniger "gematikGPT" gutgetan hätte.
Alle 23 "Schwachstellen" zu besprechen, würde den (eh schon überstrapazierten) Rahmen dieses Artikels sprengen. Daher möchte ich einige ausgewählte besprechen, die mich besonders geärgert haben. Der Fairness halber muss auch gesagt werden, dass die Studie auch einige berechtigte Feststellungen erhält, denen ich uneingeschränkt zustimmen kann (auch dazu später noch mehr). Wohlgemerkt aber: in keinem Fall handelt es sich dabei um Schwachstellen "der ePA für alle", sondern immer um Probleme in Spezifikationsvorgaben.
Schwachstelle #1: Angriff auf Verfügbarkeit durch Innentäter
Das SIT stellt hier fest, dass es Innentätern möglich ist durch Angriffe auf kritische IT-Systeme die Verfügbarkeit der ePA einzuschränken. Sie empfehlen den Anbietern vorzuschreiben, "technisch Auszuschließen", dass ein einzelner Innentäter zentrale Komponenten zerstören kann. Das erscheint mir praktisch unmöglich umzusetzen. Ein einzelner Innentäter mit Vorschlaghammer kann immer zentrale Komponenten zerstören und dadurch die Verfügbarkeit der ePA einschränken. Selbst wenn man vorschreiben würde, dass der Zutritt zu Serverräumen nur zu zweit möglich ist, kann der einzelne Innentäter immer noch seine Flasche Wasser auf den Server kippen. Sicherlich kann man darüber diskutieren, ob man hier ergänzende Maßnahmen umsetzen kann, die dieses Szenario erschweren. Ausschließen wird man es aber nie können, weswegen mir eine Einstufung als "hoch" unpassend erscheint.
Schwachstelle #2: IDP/IPS für sektorale IDP
Das Fraunhofer stellt hier fest, dass die Spezifikation des sektoralen IdP keine Verpflichtung dazu enthält, ein IDS oder IPS zu implementieren. Das mögliche Fehlen dieser Systeme sollen bewirken, dass Brute-Force-Angriffe nicht erkannt oder gar automatisch verhindert werden, was zu einer Kompromittierung des gesamten Systems führen können soll.Wir erinnern uns: der sektorale IdP ist ein Dienst zur Authentifizierung von Versicherten. Selbst wenn es durch einen Brute-Force-Angriff gelingen sollte die Zugangsdaten eines Versicherten zu erhalten ist nicht klar, warum dadurch direkt das gesamte System kompromittiert werden sollte.
Wir erinnern uns weiterhin: standardmäßig erfolgt die Authentisierung am sektoralen IdP zertifikatsbasiert mit der eGK. Zertifikatsbasierte Authentisierung lässt sich nicht per Brute-Force angreifen. Zwar gibt es tatsächlich die Möglichkeit auf eine Authentisierung ohne eGK umzustellen, allerdings nur nach einer erfolgten Gerätebindung an ein Mobiltelefon über das FdV und auch diese Authentisierung ist anschließend Public-Key-basiert. Ein möglicher Angriff müsste also auch noch die Nonce für die Gerätebindung erraten. Brute-Force-Angriffe spielen für den sektoralen IdP in der Praxis also kaum eine Rolle.
Nicht zuletzt sind aber weder IDS noch IDP sinnvolle Maßnahmen zur Prävention von Brute-Force-Angriffen. Eine sinnvolle Maßnahme wäre zum Beispiel ein Rate-Limiting für die Authentisierungsschnittstellen einzuführen.
Schwachstelle #3: Verfahren zum Einreichen von Widersprüchen
Das SIT bemängelt hier, dass es keine verbindlichen Vorgaben dazu gibt in welcher Form die Krankenkassen das Widerspruchsverfahren umsetzen müssen. Ein Angreifer könnte daher im Namen eines Versicherten Widerspruch einlegen und so die Löschung seiner Patientenakte bewirken.Hier wurde noch nicht mal ein Problem mit der Spezifikation identifiziert, sondern höchstens ein Problem mit dem Digital-Gesetz. Die gematik hat keine Regelungshoheit über die Krankenkassen. Nur der Gesetzgeber kann hier Prozessvorgaben machen. Bei der ePA für alle sind aber nicht mal unbedingt die Krankenkassen selbst relevant, sondern die sogenannte "Ombudsstelle". Diese ist unter anderem gesetzlich dafür vorgesehen den Versicherten die Möglichkeit zum Widerspruch zu geben und diesen auch technisch durchzusetzen. Anforderungen müssten also eigentlich an die Ombudsstelle gestellt werden. Aber eigentlich erscheint es eher unwahrscheinlich, dass dieser zentrale Prozess vom Gesetzgeber übersehen wurde.
Ein Blick in §342a SGB V schafft Klarheit:
"(6) Zur Unterstützung der Ombudsstellen bei der Erfüllung ihrer Verpflichtungen nach den Absätzen 2 bis 5 legt der Spitzenverband Bund der Krankenkassen zur verbindlichen Nutzung jeweils geeignete einheitliche Verfahren fest. Der Spitzenverband Bund der Krankenkassen legt das Verfahren im Benehmen mit der oder dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit und dem Bundesamt für Sicherheit in der Informationstechnik fest."
Das Erstellen von Vorgaben zum Widerspruch wurde also mitnichten vergessen, sondern an den Spitzenverband Bund der Krankenkassen in Zusammenarbeit mit dem BSI delegiert.
Vielleicht kann man sich erneut beschweren, wenn das Verfahren veröffentlicht wurde.
Schwachstelle #4: Cache-Angriffe auf die VAU
Hier wird bemängelt, dass es keine Vorgaben zu Mitigationsmechanismen für CPU-Cache-Angriffe (á la Specter und Meltdown) gibt. Als Maßnahme wird empfohlen zufällige Speicherzugriffe auf Anwendungsebene und Address Space Layout Randomization (ASLR) vorzuschreiben. Abgesehen davon, dass ASLR keine wirksame Maßnahme gegen Cache-Angriffe ist, könnten zufällig Speicherzugriffe auf Applikationsebene aber vielleicht tatsächlich helfen. Das Problem ist allerdings, dass die Verhinderung von Cache-Angriffen Aufgabe des Prozessors und höchstens noch des Kernels ist und nicht an die Applikationsschicht ausgelagert werden sollte und auch häufig nicht ausgelagert werden kann (eine Einschätzung, mit der ich übrigens nicht alleine stehe¹). Wie sollte das beispielsweise in Java oder C# implementiert werden? Sprachen, die direkte Speicherzugriffe erlauben bringen ihre eigenen Risiken mit sich (Fehler bei der Implementierung des Speichermanagements beispielsweise).
¹ https://mail.openjdk.org/pipermail/vuln-announce/2019-July/000002.html
Schwachstelle #5: Keine Maßnahmen gegen Click-/Tap-Jacking im Frontend
Das SIT stellt hier fest, dass die Spezifikation für das FdV keine Anforderungen enthält, die Maßnahmen gegen Click-Jacking betreffen. Als Empfehlung wird ausgesprochen passende X-Frame-Options-Header oder eine Content-Security-Policy zu setzen.
Wir erinnern uns: das FdV ist eine Mobilapplikation, nicht eine Web-Anwendung. Click-Jacking ist ein Angriff auf Web-Applikationen, die in einem Browser laufen. Bei Mobilapplikationen gibt es ähnliche Angriffe zwar auch (z.B. eine bösartige App über eine legitime legen) die funktionieren technisch völlig anders und können weder durch Header noch durch eine CSP verhindert werden.
Theoretisch bestünde aber die Möglichkeit einen Click-Jacking-Angriff über den sektoralen IdP durchzuführen. Beispielsweise könnte ein Anmeldevorgang im Browser gestartet werden und dann im ePA-FdV abgeschlossen werden oder ein Anmeldefenster des sektoralen IdP direkt als WebView im ePA-FdV angezeigt werden.
In jedem Fall sind aber sowohl CSP als auch X-Frame-Options-Header Dinge, die das Backend setzen muss und daher in keinem Fall in die Spezifikation des FdV gehören, sondern – wenn überhaupt – in die Spezifikation des sektoralen IdP.
Hier wird also erneut eine Schwachstelle diagnostiziert, die nur in der Spezifikation existiert und in der Praxis vermutlich nicht auftreten kann.
Schwachstelle #6: Fehlende Erkennung von Jailbreak/Root im Frontend
Ah, Root Detection. Eines meiner Lieblingsthemen. Ungeachtet dessen, dass das SIT bereit selbst feststellt, dass die Verantwortung für die Gerätesicherheit beim Benutzenden liegt (oder: wer sein Telefon rootet ist selbst schuld), ist es nahezu unmöglich für eine App zuverlässig zu erkennen, ob ein Telefon gejailbreakt oder gerootet wurde. Der einzige halbwegs verlässliche Weg ist die Verwendung von herstellerspezifischen Funktionen wie Google Play Integrity oder SafteyNet, die aber jeweils eigene Nachteile mit sich bringen -- wie beispielsweise ein maximales Limit von 10.000 Anfragen pro Tag, die bei 30 Millionen Versicherten schnell erschöpft sind.
Häufig wird Root Detection daher dadurch implementiert, dass in Systemverzeichnissen nach einschlägigen Dateien gesucht wird, die mit Rooting-Lösungen in Verbindung stehen (bspw. "/sbin/su"). Dieses Vorgehen ist jedoch offensichtlich inhärent fehleranfällig und leicht zu umgehen, weswegen die Anforderung Root Detection zu implementieren sich nahezu immer als praktisch wirkungslos erweist.
Das bedeutet insbesondere auch, dass Root Detection überhaupt kein wirksamer Schutzmechanismus gegenüber Angriffen ist. Ein Angreifer, der durch einen Kernel- oder Framework-Exploit Root-Rechte auf einem Mobiltelefon bekommen hat, kann Manipulationen von Apps direkt in deren Prozessspeicher durchführen, ohne irgendwelche leicht zu erkennenden Dateien auf dem System ablegen zu müssen. Root Detection ist also bestenfalls ein Mechanismus, mit dem sich absichtlich gerootete Geräte identifizieren lassen, also ein Schutz vor dem Nutzer des Telefons selbst – häufig um zu verhindern, dass dieser in einer App gespeicherte Geheimnisse des Herstellers auslesen kann.
Letztlich existiert das identifizierte Problem auch hier wieder nur in der Theorie. In der Praxis ist für eine Zulassung des ePA-FdV (und auch des eRezept-FdVs) auch eine Bestätigung des BSI notwendig. Das BSI möchte wiederum, dass die "Prüfvorschrift für den Produktgutachter des ePA-Frontend des Versicherten und des E-Rezept-Frontend des Versicherten" berücksichtigt wird. Dort ist die Integritätsprüfung des Endgerätes als Anforderung bereits enthalten.
Was sollte man denn kritisieren?
Ein zentrales Problem an Veröffentlichungen wie der Fraunhofer-Studie ist meiner Meinung nach, dass sie von Problemen mit und im Umfeld der ePA ablenken, über die eigentlich diskutiert werden sollte. Einige davon wurden zwar auch schon in der Studie adressiert, viele weitere aber nicht.Abgeschaffte Ende-zu-Ende-Verschlüsselung
Dass die Ende-zu-Ende-Verschlüsselung in der ePA3 fehlt, ist wirklich schade. Dieser zusätzliche Sicherheitsmechanismus hätte dazu beitragen können die Akzeptanz für die Opt-Out-Lösung zu erhöhen und das Vertrauen in die Sicherheit des Systems zu stärken. Besonders ärgerlich ist, dass die öffentlich vorgetragenen Argumente für die Abschaffung der Ende-zu-Ende-Verschlüsselung größtenteils fadenscheinig erscheinen:- Performance: Unstrittig ist, dass die Anwendung von kryptographischen Verfahren rechenintensiv sind und eine Auswirkung auf die Performance einer Applikation haben kann. Fakt ist aber auch, dass Verschlüsselung im Rahmen von TLS bereits standardmäßig und flächendeckend für Übertragung von Daten aller Art und Größe von Webseiten wie Facebook oder Google eingesetzt wird, die Millionen von Benutzern gleichzeitig haben. Dass bei der ePA die Performanceanforderungen für eine Ende-zu-Ende-Verschlüsselung von Dokumenten (ein Anwendungsfall, der nur verhältnismäßig selten eintritt) nicht erfüllt werden können erscheint daher wenig glaubwürdig. Vor allem, wenn man bedenkt, dass es sich hier in Zukunft um das zentrale System des deutschen Gesundheitswesens handeln wird, sollte etwas zusätzliche Investition in Server-Hardware eigentlich problemlos möglich sein. Schlimmer noch: der Rechenaufwand für die Verschlüsselung fällt eigentlich beim FdV (also auf den mobilen Endgeräten) an und nicht beim Aktensystem. Dieses muss die Dokumente eigentlich nur noch speichern.
- Teilbarkeit von Daten: Ein zentrales Argument war, dass die Ende-zu-Ende-Verschlüsselung das Teilen von Gesundheitsdaten (etwa im Rahmen der Forschungsdatenspende) nicht erlaubt. Das ist technisch schlicht Unsinn. Das auf Dokumentenschlüssel basierende Verschlüsselungskonzept der ePA erlaubt es sogar auf sehr elegante Weise einzelne Dokumente mit Dritten zu teilen. Dazu muss nur der individuelle Dokumentenschlüssel im FdV entschlüsselt und mit einem öffentlichen Schlüssel des Empfängers verschlüsselt werden. Was natürlich nicht geht ist der Zugriff auf Daten *ohne* explizite Einwilligung des Betroffenen.
- Durchsuchbarkeit von Daten: Tatsache ist sicherlich, dass verschlüsselte Daten nicht ohne weiteres durchsucht werden können und, dass das möglicherweise die Benutzerbarkeit der ePA einschränkt. Allerdings sieht bereits die ePA 2.6 hier schon Ausweichmöglichkeiten vor. So besitzt jedes Dokument Metadaten, die nicht Ende-zu-Ende-Verschlüsselt werden und beispielsweise für eine Keyword-basierte Suche verwendet werden können. Eine Volltextsuche ist damit nicht möglich, allerdings ist das auch grundsätzlich nur bei Textdateien und sogenannten "Medizinischen Informationsobjekten" /MIOs) möglich, nicht jedoch bei PDFs und Bilddateien, die von der ePA ebenfalls unterstützt werden. Volltextsuche für diese beiden Anwendungsfälle zu verlieren, erscheint eigentlich wie ein akzeptabler Trade-Off, für eine deutliche Erhöhung der Gesamtsicherheit. „Searchable Encryption“ ist weiterhin seit Jahrzehnten ein aktives Forschungsfeld, das auch schon einige praxistaugliche Verfahren hervorgebracht hat. Hier hätte man sich eventuell auch inspirieren lassen können.
- Notfälle: Es kann Notfallsituationen geben, in denen der Versicherte nicht mehr in einen Zugriff auf seine Patientendaten einwilligen kann. In diesen Fällen muss ein Zugriff auf wichtige Informationen, wie beispielsweise den Medikationsplan oder bekannte Allergien und Unverträglichkeiten, aber trotzdem möglich sein.
- Integration mit anderen Diensten: Die ePA3 wird mit einer Integration mit dem eRezept-Fachdienst ausgeliefert werden (der man auch widersprechen kann). eRezepte, werden über diese Integration automatisch in die Medikationsliste in der ePA geschrieben, sodass Ärzte immer sehen können welche Medikamente potentiell eingenommen werden. Da das Erweitern der Medikationsliste in der ePA selbst erfolgt, ließe sich das ebenfalls nicht realisieren, wenn diese Ende-zu-Ende verschlüsselt wäre.
Überhastete Einführung
Die ePA für alle ist auf vielen Ebenen ein komplett anderes System als die ePA 2.6 und erfordert daher von den Herstellern eine Neuimplementierung von großen Teilen ihres Produktes. Der politische Beschluss einer Einführung zum 15.01.2025 wurde allerdings getroffen und verkündet, bevor es überhaupt eine veröffentlichte Spezifikation gab – diese kam erst Weihnachten 2023. Zugelassen sein muss die ePA für alle Mitte Dezember, unter anderem, um eine Migration von Bestandakten in die neue ePA rechtzeitig zu ermöglichen. Abzüglich der Zeit für den Zulassungsprozess und den umfangreichen Begutachtungsprozess (der teilweise auch entwicklungsbegleitend laufen kann) bleiben den Herstellern also nicht viel mehr als neun oder zehn Monate Zeit ein System von dieser Komplexität zu implementieren. Eine nahezu unmögliche Aufgabe.Die überhastete Einführung der ePA für alle auf Basis einer politischen Entscheidung und ohne die Berücksichtigung der technischen Komplexität der Umsetzung ist daher zu Recht zu kritisieren. Allerdings nicht, weil es zu einem weniger sicheren System führen wird – die Sicherheitsanforderungen müssen in jedem Fall erfüllt sein – sondern, weil sich die Versicherten mit ziemlicher Sicherheit auf zahlreiche Bugs, Abstürze und Ausfälle in den ersten Monaten einstellen müssen, die durch eine längere Entwicklungs- und vor allem Testphase hätten verhindert werden können.
Hohe Einstiegshürden für Anbieter
Zum aktuellen Zeitpunkt gibt es zwei Anbieter der elektronischen Patientenakte: RISE und IBM. Zwar kann grundsätzlich jedes Unternehmen eine elektronische Patientenakte auf Basis der öffentlich verfügbaren Spezifikation implementieren, begutachten und zulassen lassen. Allerdings ist nicht davon auszugehen, dass das auch passiert. Die ePA ist ein technisch hochkomplexes System, bei der allein die Entwicklungskosten vermutlich im zweistelligen Millionenbereich liegen werden. Dazu kommt dann noch ein Begutachtungsprozess, der auf Grund seiner Tiefe und Ausführlichkeit (Quellcode-Review und Penetrationstests) auch noch mal eine ordentliche Stange Geld kostet, sowie Zulassungsgebühren der gematik.Diese hohen initialen Investitionskosten sind für KMUs kaum zu stemmen und selbst große Unternehmen werden sich das zwei Mal überlegen müssen. Problematisch ist auch, dass zum aktuellen Zeitpunkt bereits alle gesetzlichen Krankenkassen eine Patientenakte bei einem der beiden Hersteller eingekauft haben – sie sind ja zur Einführung ab dem 15.01.25 verpflichtet. Der Markt ist also schon gesättigt. Was passiert aber, wenn einer der beiden Hersteller oder gar beide aus unternehmensstrategischen Gründen entscheiden die Weiterentwicklung der ePA einzustellen? Dann wäre es gut, wenn es mehr als zwei Anbieter auf dem Markt gäbe.
Für das Problem gibt es leider keine einfachen Lösungen. Insbesondere der umfassende Begutachtungsprozess existiert aus gutem Grund und sollte eher noch intensiviert und nicht vereinfach werden. Möglich wäre aber beispielsweise, dass durch die gematik selbst Open-Source Referenzimplementierungen von wichtigen Komponenten der ePA (wie etwa der VAU) bereitgestellt werden, sowie für den Betrieb notwendige Dienste (wie etwa den sektoralen IdP), um neuen Anbietern, die auf den Markt wollen, ein Prototyping eines funktionalen Aktensystems zu erleichtern.
Keine Vorgaben für Penetrationstests im Begutachtungsprozess
Penetrationstests im Begutachtungsprozess sind zwar für eine erfolgreiche Zulassung der ePA notwendig, allerdings macht die gematik kaum Vorgaben dazu, was genau in welcher Tiefe getestet werden soll. Schlimmer noch: die wenigen Vorgaben, die dazu in Spezifikationen existieren, sind oftmals unsinnig. So haben sich deren die Autoren in vielen Fällen dazu verleiten lassen eine "Prüfung auf OWASP Top 10" zu fordern. Die OWASP Top 10 sind jedoch eine Sammlung von typischen Schwachstellen von Web-Applikationen, die auf reine Backend-Systeme wie die ePA oder den sektoralen IdP nur teilweise anwendbar sind und dafür applikationsspezifische Fehlerklassen (wie bspw. die sichere Implementierung von OAuth-Flows), die in jedem Fall getestet werden sollte, nicht adressieren.Gleichzeitig ist die Durchführung von Penetrationstests auf Systeme der Telematikinfrastruktur im Allgemeinen und auf die ePA im Speziellen technisch hoch komplex. Wie bereits dargestellt muss für den Zugriff auf die Kernfunktionalität der ePA (Dokumentenverwaltung) ein komplexes, zertifikatsbasiertes Authentisierungsverfahren durchlaufen werden, anschließend ein VAU-Kanal aufgebaut werden, um dann über statusbehaftetes Protokoll die wichtigen Geschäftslogikfunktionalitäten benutzen zu können. Ein seriöser Penetrationstest der ePA macht es also eigentlich notwendig einen größtenteils vollständigen ePA-Client (sprich: ein FdV) zu verwenden, um auch tieferliegende Funktionen testen zu können. Öffentlich verfügbare Clients existieren aber nicht und auch die Hersteller können nur Mobilapplikationen liefern, die sich kaum für die Durchführung von Penetrationstests des Backend-Systems eignen. Im Prinzip ist es für die Durchführung eines ordentlichen Penetrationstest also notwendig eigene Test-Werkzeuge zu entwickeln, und große Teile der Funktionalität eines FdV nachzuimplementieren.
Auch beim Penetrationstest der FdVs gibt es Herausforderungen. So erfordern die hohen Sicherheitsanforderungen in der Regel die Nutzung von iOS-Plattformfeatures, die erst ab iOS 17 zur Verfügung stehen. Für iOS 17 gibt es aber keine funktionierende Jailbreaks, was ein dynamisches Testen der App (bspw. mittels Frida) schwierig oder gar unmöglich macht. Mobile Applikationen aber nur statisch zu testen, berücksichtigt eine ganze Reihe von praxisrelevanten Sicherheitsproblemen überhaupt nicht.
All das kann Pentester und Gutachter unter Umständen dazu verleiten Abkürzungen zu wählen und die Tests eben nicht in der angemessenen Tiefe durchzuführen, sondern stattdessen das durchzuführen, was mit Standardwerkzeugen aus dem Pentesting-Repertoire möglich ist. Also beispielsweise ein Scan der Außenschnittstellen der ePA oder ein Pentest des FdV, der nur eine obfuszierte App mit aktivierter Root Detection prüft, wodurch jeweils keinerlei Aussage über die Sicherheit des untersuchten Produktes getroffen werden kann. Hier sollte die gematik tatsächlich aktiv werden und produktspezifische, konkrete Vorgaben zu Testumfang und Testtiefe der Penetrationstests im Rahmen der Produktgutachten machen. Tester könnten unterstützt werden, in dem die gematik mehr Open-Source Referenzimplementierungen von Clients bereitstellt, die als Grundlage für die Entwicklung von Testwerkzeugen dienen können. Bei diesem Punkt stimme ich den Kollegen des Fraunhofer SIT also uneingeschränkt zu.
Keine Kontrolle über Primärsysteme
Die gematik hat keinen Durchgriff auf die sogenannten "Primärsysteme", also diejenigen Systeme, die in den Krankenhäusern und Arztpraxen laufen und unmittelbar mit der ePA und dem eRezept interagieren. Während die zentralen Systeme der Telematikinfrastruktur also rigorose Test- und Zulassungsprozesse anhand strenger Sicherheitskriterien durchlaufen müssen, gibt es für Primärsysteme maximal eine softe Empfehlung zu IT-Sicherheit von der kassenärztlichen Bundesvereinigung, sowie ein Leitfaden IT-Sicherheit, der durch die gematik veröffentlicht wird, deren Umsetzung aber jeweils nicht geprüft wird. Der schnellste Weg an Patientendaten zu kommen ist also vermutlich nicht ein Angriff auf die ePA, sondern ein Angriff auf Krankenhäuser und Arztpraxen und die dort laufenden Softwaresysteme.Hier sollte der Gesetzgeber eingreifen und auch für Primärsysteme und deren Software verbindliche Sicherheitsstandards und Prüfverfahren vorgeben.
Und jetzt?
Wer schon mal in der unschönen Situation war für die Einholung eines medizinischen Rats mehrere unterschiedliche Ärzte aufsuchen zu müssen, wird mit dem Prozess des manuellen Transportierens von ausgedruckten Arztbriefen und Untersuchungsbefunden auf CDs vertraut sein. Diese Arztbriefe enthalten nie alle relevanten Informationen, oder werden teilweise gar nicht genau gelesen, sodass man bei jedem Arzt die komplette Untersuchungsgeschichte von neuem Vortragen muss. Das entspricht nicht meiner Vorstellung einer effizienten Gesundheitsversorgung. Mit der elektronischen Patientenakte haben wir jetzt endlich die Möglichkeit einen Riesenschritt bei der Digitalisierung des Gesundheitswesens voranzukommen.Das wir in Deutschland Aufholbedarf bei der Digitalisierung haben ist eigentlich unstrittig. Gerade die Digitalisierung der Verwaltung muss seit Jahrzehnten Kritik einstecken – verständlich, wenn eine der größten Errungenschaften der Verwaltungsdigitalisierung in den letzten Jahren war, dass weiterhin schriftlich abzugebende Antragsformulare jetzt vorab als PDF-Dokument auf der Webseite des Amtes heruntergeladen werden können. Auf die fehlende Verwaltungsdigitalisierung zu schimpfen ist praktisch überall En Vogue, denn niemand möchte zum zehnten Mal seine Geburtsurkunde bei einem Sachbearbeiter vorlegen, der im gleichen Gebäude arbeitet, in dem die Urkunde ausgestellt wurde.
Aber was ist die Lösung? Die Lösung ist eben nicht das kleinteilige Entwickeln von Software zur Umsetzung von kommunenspezifischen Verwaltungsprozessen, sondern das Schaffen von einheitlichen Prozessen, Spezifikationen und Schnittstellen, sowie von zentralen Datenablagen, auf die alle Kommunen Zugriff haben. Genau das versucht die gematik mit der Telematikinfrastruktur und der elektronischen Patientenakte für das Gesundheitswesen zu erreichen.
Die elektronische Patientenakte ist sicher nicht perfekt. Insbesondere die überhastete Einführung, sowie der vollständige Verzicht auf Ende-zu-Ende-Verschlüsselung lassen sich berechtigterweise kritisieren. An einigen Stellen wurden Kompromisse zwischen Sicherheit und Benutzbarkeit getroffen, die auch hätten anders getroffen werden können und bei den Schnittstellen zwischen Prozess, Technik und Mensch können sicherlich auch Probleme auftreten, die von bestehenden Spezifikationen nicht abgedeckt sind und/oder im Rahmen eines Sicherheitsgutachtens nicht tief genug geprüft werden können (vgl. „Käsethekenangriff“). Ebenfalls ist es zu erwarten, dass es in den ersten Monaten nach Launch immer wieder zu Abstürzen und Ausfällen kommen wird. Zu kurz war die zur Verfügung stehende Entwicklungs- und Testzeit, um mit Überzeugung sagen zu können, dass das System fehlerfrei implementiert ist.
Die elektronische Patientenakte ist aber auch mit Abstand das sicherste Gesundheitssystem zur Verwaltung von Patientendaten, das ihr finden werdet – auch im internationalen Vergleich. Strenge Sicherheitsanforderungen und ein rigoroser Zulassungsprozess, der so bei kaum einer anderen Produktart durchgeführt werden muss, tragen dazu bei.
Es ist völlig normal und auch sinnvoll, dass man Bedenken hat, wenn die eigenen Daten bei komplexen IT-Systemen zentral gespeichert werden sollen. Diese Bedenken sollten aber auf Basis der Faktenlage analysiert und bestenfalls ausgeräumt werden. Das erfordert aber, auf Grund der hohen Komplexität des Systems, Sach- und Spezifikationskenntnis und nicht nur spekulative Mutmaßungen. Was unsere Medienlandschaft (allen voran im Moment "heise") aktuell dazu veröffentlicht wird ist praktisch ausschließlich sinnlose, faktenfreie Panikmache.
Studien, wie die des Fraunhofer SIT sind in dieser Situation nicht hilfreich, da sie inhaltlich keine Aussagen über die Sicherheit eines tatsächlichen Aktensystems treffen können, die einschlägigen Medien aber offenbar nicht in der Lage sind das zu differenzieren. Besonders ärgerlich ist dann auch noch, dass einige "Schwachstellen" bei genauer Betrachtung noch nicht mal theoretisch existent sind. Entsprechend helfen solche oberflächlichen Analysen auch kaum dabei irgendwas zu verbessern.
Also: Hört auf zu auf abstraktem Niveau zu meckern und tragt technisch und inhaltlich fundierte Verbesserungsvorschläge vor. Oder freut euch einfach darauf keine Dokumentenstapel mehr zwischen Ärzten hin und her tragen zu müssen. Und wenn ihr nichts von beidem machen wollt, bleibt euch immer noch der Opt-Out.