Datenabfluss auf Rezept
Impotenz? Gibt’s eine App für!
Depression? Schau dir ein paar Videos an!
Sinnlose Apps, die unfassbar teuer sind? Frag deine Krankenkasse!
Ein Glück, dass wir im 21. Jahrhundert leben und es für jedes Krankheitsbild die passende App gibt. Seit Oktober 2020 gibt’s die auch auf Rezept, die Digitalen Gesundheits-Anwendungen, oder kurz: DiGAs. Vielen Dank dafür an Jens Spahn. *hust*
Seit rund 1,5 Jahren können Unternehmen damit Apps entwickeln, die Ärzt*innen dann ihren Patient*innen verschreiben. Doch wie bei so vielen anderen Vorhaben zeigt sich auch hier einmal wieder: Digitalisierung löst nicht alle Probleme – sie schafft viel mehr ganz neue.
Und da wir einen Text über DiGAs schreiben, könnt ihr euch denken, welche Sorte von Problemen wir meinen: Die wenigen Digitalen Gesundheits-Anwendungen, die wir angeschaut haben, hatten massiven Datenabfluss. Insgesamt haben sie Daten von mehr als 20.000 Patient*innen verloren.
Doch was machen diese DiGAs eigentlich?
Digitale Gesundheits-Anwendungen gibt es aktuell von etwa zwanzig verschiedenen Anbietern für die verschiedensten gesundheitlichen Probleme. Von Depression bis Erektionsstörung, von Tinnitus bis Krebs. Die Inhalte reichen von Tagebüchern zur Rauchentwöhnung über Videos zur Rückenvorsorge bis hin zu Chatberatung mit Ernährungsexpert*innen.
Die von der vorigen Regierung eingeführte Gesetzgebung macht es sehr einfach, solche Apps zu entwickeln. Daher werden es jeden Monat mehr. Das lohnt sich natürlich vor allem für die App-Hersteller. Immerhin bekommen diese für jede Verschreibung ihrer App gutes Geld: etwa 200 bis 700 Euro – pro Quartal.
Wird schon nichts passieren?
Doch was heißt, die Gesetzgebung macht es “sehr einfach” solche Apps zu entwickeln? Im Bereich der DiGA wird größtenteils den Herstellern vertraut: Es gibt zwar eine Checkliste, auf der viele gute Sachen stehen – aber ob die Selbsteinschätzung der Hersteller tatsächlich stimmt, wird nur in Ausnähmefällen kontrolliert.
Weitere Überprüfungen werden erst schrittweise eingeführt. Eine erste seit April 2022, der Rest kommt nächstes Jahr.1
Doch was ist, wenn die armen kleinen Apps krank sind? Dafür gibt’s Menschen wie uns, die sich das genauer anschauen. Und glaubt uns: Das ist kein schöner Job! Wir hatten in den vergangenen Monaten einiges zu tun. Denn die Genesungsprozesse von verrenkten Apps dauern außergewöhnlich lange. Wir geben exklusive Einblicke in die Diagnoseprotokolle.
Novego – Diagnoseprotokoll
Die DSGVO schreibt vor, dass alle Apps eine Exportfunktion für die persönlichen Daten haben müssen – also auch Digitale Gesundheitsanwendungen. Das steht auch in der DiGA-Richtlinie.
Daran hält sich auch das Exemplar “Novego” und bietet eine Möglichkeit an, die eigenen Daten herunterzuladen. Doch wirklich nur die eigenen? Nein! Natürlich nicht.
Wenn wir unsere eigenen Daten herunterzuladen, ruft die Website den Endpunkt https://www.novego.com/myaccount/participant/data-export/export/21378 auf. Als Antwort bekommen wir dann eine andere URL, von der wir dann nach ein paar Sekunden unser Daten-Archiv abrufen können.
Nun können sich die treuen Leser*innen schon denken, was als nächstes passiert: 21378 ist unsere Nutzer*innen-ID.
Also probieren wir, was passiert, wenn man eine etwas kleinere Zahl eingibt.
Und richtig: Wir bekommen das Archiv einer anderen Person.
Denn die ID ist eine laufende Nummer, die jedes mal um eins hochgezählt wird, wenn ein neuer Account angelegt wird.
Damit sind die IDs wahrlich nicht schwer zu erraten, verschaffen aber Zugang zu höchst kritischen Daten. Denn der Daten-Abruf über die frei zugängliche Schnittstelle enthielt alle Informationen, die über ein*e Nutzer*in bei Novego gespeichert sind, also
- E-Mail-Adresse
- Username: frei wählbar, aber häufig Vorname und Nachname
- Geschlecht
- welches “Programm” (wie z.B. Burn-Out, Depression, Angststörung) bei Novego absolviert wird
- Ergebnisse eines Self-Assessments: Ergebnis regelmäßiger Abfrage standardisierter psychologischer Fragebögen zum gesundheitlichen Zustand, die darüber Aufschluss geben sollen, ob bzw. wie depressiv ein*e Nutzer*in ist. Hier ein Beispiel-PDF.
Cankado – Diagnoseprotokoll 1
In der App Cankado können Brustkrebs-Patient*innen ihre Beschwerden selbst erfassen und so automatisch Empfehlungen bekommen, wie dringend diese mit Ärzt*innen abgeklärt werden sollten. Äußerst unpraktisch nur, dass sich jede*r als Ärzt*in ausgeben kann – in jeder Klinik – sogar wir.
Und das geht so:
Als erstes müssen wir uns als Ärzt*in registrieren.
Das geht, indem wir uns auf https://cankado.com/register/doctor über das Anmelde-Formular für Ärzt*innen einen Account anlegen.
Das alleine ist kein Problem. Aber das System muss später prüfen, dass wir nur Zugriff auf Datenbereiche haben, für die wir auch berechtigt sind. Es braucht also eine sinnvolle Zugriffskontrolle.
Und auf den ersten Blick hat Cankado das auch vorbildlich getan:
Der Server von Cankado stellt verschiedene Schnittstellen bereit, über die die Website mit ihm kommuniziert.
Hier gibt es /centers/ für die Behandlungszentren und Krankhäuser, /patients/ für die Patient*innen, /physicians/ für die Ärzt*innen und so weiter.
Hier konnten wir auf den ersten Blick nur die Daten abrufen, die auch für uns zugänglich sein sollten.
Aber dabei hat eine Schnittstelle gefehlt: Eine API, um die einzelnen Abteilungen eines centers abzufragen.
Also haben wir scharf nachgedacht, wie so eine Schnittstelle heißen könnte. Und was heißt Abteilung auf Englisch? Department!
Wir haben ins Blaue geraten und https://api.cankado.com/departments/ aufgerufen.
Und da waren plötzlich nicht mehr nur unsere eigenen Abteilungen – sondern ALLE.
Und als wir analog zu den anderen Endpunkten versucht haben, Daten über die Schnittstelle zu bearbeiten, funktionierte auch das. So konnten wir uns selbst in die Liste der Ärzt*innen, die in einer Abteilung arbeiten, eintragen.
Alles was es dazu brauchte, war die department_id, die wir ja aus der Liste aller Abteilungen kannten, und der Befehl:
curl 'https://api.cankado.com/departments/{department_id}/' \
-X 'PATCH' \
-H 'Content-Type: application/json;charset=UTF-8' \
-H 'authorization: Bearer {BEARER_TOKEN}' \
--data-raw '{"physicians": ["{USER_ID}"]}'
Sobald man den Ärzt*innen-Status erreicht hat, ist es möglich, alle Daten für die Patient*innen der eigenen Abteilung abzurufen. Dazu gehören:
- Name
- Adresse
- E-Mail-Adresse
- Passwort, im Klartext (Das war schon nicht mehr Stand der Technik, als Teile von zerforschung geboren wurden)
- Zugangstoken
- Diagnose
- Tagebuchdaten
- Arztberichte
- Messdaten
- Überweisungen
- sowie alle weiteren Daten, die von Ärzt*innen und Patient*innen erfasst wurden.
Insgesamt waren bei Cankado auf diesem Wege 12.500 Datensätze abrufbar – von Brustkrebs-Patient*innen, aber auch von anderen Nutzer*innen des Systems, die darüber zum Beispiel Medikamenten-Studien durchgeführt haben.
Wie kann das sein?
Die Entwickler*innen von Cankado haben die Schnittstelle zum Zugriff auf die Abteilungen wohl im Anfangsstadium der App entwickelt, über die Zeit dann nicht mehr verwendet – und irgendwann schließlich vergessen, diese Schnittstelle abzuschalten. Auch bei Sicherheitsüberprüfungen muss sie übersehen worden sein.
Cankado – Diagnoseprotokoll 2
Weil Cankado uns so große Sorgen bereitet hat, haben wir uns die App noch etwas weiter angeschaut, und dabei leider gleich noch mehr gefunden.
Normalerweise können Patient*innen ihren Ärzt*innen Einblicke in ihre persönlichen Daten in der App gewähren. Das funktioniert so: Ärzt*innen geben ihren Patient*innen einen Code (“promotion_code”), den diese dann in ihre App eintragen. Sobald das passiert ist, werden die Patient*innen ihren Ärzt*innen zugeordnet und diese können die Daten einsehen. Das funktioniert – natürlich – über einen Aufruf einer Schnittstelle der App.
Technisch funktioniert das dann so:
Die App des*r Patient*in ruft https://api.cankado.com/patient/{PATIENT_ID}/extensions/ mit der eigenen Patient*innen-ID auf und übergibt dabei den Code, den die Patient*innen von ihren Ärzt*innen bekommen haben.
Die ID ist hier sogar eine UUID4, die wir nicht einfach erraten können.
Doch durch die vorherige Lücke Diagnose kennen wir diese schon.
Und außerdem überprüft der Server mal wieder nicht, ob die Patient*innen-ID auch unsere eigene ist. Stattdessen können wir dort eine beliebige ID angeben und diese*r Patient*in wird dann der*m Ärzt*in zugeordnet.
So können wir jetzt gleichzeitig Patientin und Ärztin spielen: Zuerst generieren wir über den Ärzt*innen-Account einen Zuordnungs-Code. Dann suchen wir uns eine reale Patient*innen-ID, geben uns als diese*r Patient*in aus und lösen den Code ein. Damit ist der echte Patient*innen-Account mit unserem Ärzt*innen-Account verknüpft und wir konnten problemlos auf die Daten “unserer” Patient*innen zugreifen.
curl -H "Authorization: Bearer {TOKEN}" \
--data-raw '{"promotion_code":"0116d885"}' \
https://api.cankado.com/patient/{PATIENT_ID}/extensions/
Wie in Diagnoseprotokoll 1 beschrieben wurde, kennen wir ja mittlerweile die ID der Patient*innen – und haben damit auch Zugriff auf all ihre Daten. Neue Informationen über die Betroffenen bekommen wir also nicht. Trotzdem wird auch diese neu entdeckte Lücke ein Problem, sobald wir an die ID von Patient*innen kommen:
Wir können uns zum Beispiel vorstellen, dass ein*e Patient*in entscheidet, Ärzt*innen keinen Zugriff auf die eigenen Daten mehr zu erlauben. Mit dieser Lücke könnten sich die Ärzt*innen jedoch immer wieder Zugriff auf die Daten beschaffen, denn die ID ist ja schon bekannt.
Das darf nicht so bleiben
Wie immer haben wir die Sicherheitslücken schnell und vertraulich an die Hersteller gemeldet. Alle hier beschriebenen Lücken sind nach deren Aussage geschlossen.
Da muss etwas passieren
Es ist erschütternd wie egal Unternehmen die Sicherheit von Patient*innen-Daten zu sein scheint und mit welcher Leichtfertigkeit staatliche Stellen ihnen Zugang zu diesen Daten geben.
Patient*innendatensicherheit ist nicht optional. Nicht etwas, das man noch “nachziehen” kann, nachdem eine App schon ein Jahr lang von Patient*innen benutzt wurde. Wenn eine App marktreif genug ist, um Patient*innen-Daten zu verarbeiten muss sie auch reif genug sein, diese für sich zu behalten. Daher sehen wir momentan keinen anderen Weg, als alle Apps, die noch keine ausreichenden Sicherheitsvorkehrungen implementiert haben, vorerst vom Markt zu nehmen.
Appanbieter*innen sind auch heute bereits dazu verpflichtet, ihre Apps nach dem Stand der Technik umzusetzen. Aus unserer Sicht bedeutet das konkret: Die Anwendungen dürfen die Daten der Nutzer*innen nicht mit anderen teilen, sondern diese soweit irgendwie möglich nur auf deren Endgeräten verarbeiten. Und wenn doch Kommunikation nötig ist, zum Beispiel zwischen Patient*innen und Ärzt*innen, dann muss diese Ende-zu-Ende verschlüsselt sein.
Denn Ende-zu-Ende-Verschlüsselung ist heute schon der Standard in Messengern – von WhatsApp bis Signal. Somit ist aktuell die Familien-Chatgruppe besser geschützt als die Kommunikation zwischen Ärzt*innen und Patient*innen über diese Apps.
Um hier jeglichen Interpretationspielraum auszuschließen, der Patient*innen-Daten gefährden könnte, muss dies zwingende Anforderung für alle DiGA sein. Doch nur weitere Punkte in eine Checkliste aufzunehmen reicht nicht aus!
Denn die Erfüllung dieser Checklisten muss auch überprüft und sanktioniert werden – und zwar jetzt! Und nicht irgendwann 2023, vielleicht.
Daher muss das DiGA-Fast-Track-Programm in seiner jetzigen Form eingestellt werden. Dieses ermöglicht Apphersteller*innen heute eine App ohne hinreichende Sicherheits- oder Wirksamkeitsprüfung auf den Markt zu bringen. Ein Vorgehen das man sich in anderen Lebensbereichen garnicht vorstellen könnte. Wenn man ein Medikament vom Arzt verschrieben bekommt oder ein Auto kauft, erwartet man ja schließlich auch, dass dieses sicher ist und diese Sicherheit auch überprüft wird.
Statt dass das BfArM als zuständige Regulierungsbehörde hier genau hinschaut, wird aktuell in die Eigenverantwortung der Hersteller vertraut. Was dann passiert, habt ihr gerade gelesen.
Apps alleine machen auch nicht glücklich gesund
Außerdem schließen wir uns der Forderung verschiedener Ärzt*innen- und Patient*innenverbände an, das nur Apps mit einem nachgewiesenen Nutzen von Krankenversicherungen bezahlt werden sollten. Denn wenn man schon Patient*innendaten in die Hand einer App gibt, dann sollte das wenigstens einen Versorgungsnutzen haben.
Die gute Nachricht ist: Das Bundesamt für Sicherheit in der Informationstechnologie arbeitet gerade an neuen Sicherheitsstandards für DiGAs und wir hoffen, dass unsere Forderungen darin aufgenommen werden. Und zukünftig Unternehmen bei Verstößen gegen diese Regelungen konsequent sanktioniert werden.
In einigen Bereichen sind die Regulierungen allerdings auch schon sehr gut. So können Apps bei Datenabflüssen von dem Bundesinistitut für Arzneimittel und Medizinprodukte ausgeschlossen oder mit Strafen belegt werden. Und Datenminimierung ist auch heute bereits eine Vorgabe in den Richtlinien. Allerdings werden diese Regeln noch nicht ausreichend durchgesetzt und es wirkt geradezu so, als gehören Datenabflüsse für die BfArM zum Alltagsgeschäft. Ohne jede Folge für die betroffenen Apphersteller*innen.
Wir hoffen außerdem, dass Gesundheitsminister Lauterbach sich um die Versäumnisse seines Vorgängers kümmert und Digitale Gesundheitsapps sinnvoller reguliert und auch den Vollzug dieser Regelungen aktiv unterstützt. Denn die Digitalisierung des Gesundheitssektors kann viele Chancen bieten. Es ist aber gefährlich, sich das Vertrauen der Bürger*innen in die Digitale Gesundheitsversorgung durch mangelnde Sicherheitsstandards und Durchsetzung dieser zu verspielen.
-
Ab dem 1. April 2022 muss der Nachweis eines “Informationssicherheitsmanagementsystem (ISMS) gemäß ISO 27001 oder gemäß ISO 27001 auf der Basis von IT-Grundschutz (BSI-Standard 200-2: IT-Grundschutz-Methodik)” vorgelegt werden. Weitere Vorgaben kommen dann erst nächstes Jahr: Ab dem 1. Januar 2023 muss durch ein Zertifikat vom BSI nachgewiesen werden, dass die Anforderungen an die Datensicherheit erfüllt werden. Ab dem 1. April 2023 dann auch, dass die Anforderungen an den Datenschutz erfüllt werden. https://www.gesetze-im-internet.de/digav/__7.html ↩︎