Eine DiGA kann therapeutisch sinnvoll, gut gestaltet und technisch modern sein - und trotzdem kurz vor dem Go-Live ins Stocken geraten. Der häufigste Grund ist nicht ein einzelner Programmierfehler. Es sind offene Sicherheitsfragen, unklare Verantwortlichkeiten und Nachweise, die erst erstellt werden, wenn die Anwendung praktisch fertig ist. DiGA Sicherheit muss deshalb vom ersten Konzept bis in den laufenden Betrieb mitgeplant werden.
Für Organisationen, die digitale Gesundheitsanwendungen entwickeln, geht es dabei um mehr als eine formale BfArM-Anforderung. Sicherheit entscheidet darüber, ob sensible Gesundheitsdaten geschützt bleiben, ob Ärztinnen und Ärzte Vertrauen in die Anwendung fassen und ob das Produkt bei Wachstum oder einem Sicherheitsvorfall handlungsfähig bleibt. Wer sie als separates Arbeitspaket am Projektende behandelt, produziert Nacharbeit, Verzögerungen und im schlechtesten Fall ein unsicheres Go-Live.
DiGA Sicherheit beginnt bei der Produktentscheidung
Am Anfang steht eine nüchterne Frage: Welche Daten verarbeitet die Anwendung wirklich und warum? Eine App, die Symptome dokumentiert, Therapieübungen begleitet oder mit Leistungserbringern kommuniziert, hat andere Risiken als eine reine Informationsanwendung. Gesundheitsdaten gelten als besonders schützenswert. Auch scheinbar harmlose Angaben können in Kombination Rückschlüsse auf Diagnosen, Behandlungen oder Lebensumstände zulassen.
Daraus folgen technische und organisatorische Entscheidungen. Welche Daten müssen dauerhaft gespeichert werden? Was kann lokal auf dem Gerät bleiben? Welche Schnittstellen zu Backend, Analysewerkzeugen, Benachrichtigungsdiensten oder externen Plattformen sind erforderlich? Jede zusätzliche Datenübertragung und jeder weitere Dienst vergrößert die Angriffsfläche. Das bedeutet nicht, dass externe Komponenten grundsätzlich ausgeschlossen sind. Sie müssen aber fachlich begründet, datenschutzrechtlich bewertet und technisch kontrollierbar sein.
Ein typischer Fehler ist die unkritische Übernahme von Bausteinen aus anderen App-Projekten. Ein Tracking-SDK, das im E-Commerce für Conversion-Messung eingesetzt wird, passt nicht automatisch in eine Gesundheitsanwendung. Bei einer DiGA muss klar sein, welche Daten wohin fließen, wie sie verarbeitet werden und ob der Nutzen die Risiken rechtfertigt. Weniger Abhängigkeiten bedeuten oft weniger Prüfaufwand und weniger Überraschungen im Betrieb.
Anforderungen müssen prüfbar werden
Sicherheit bleibt vage, solange Anforderungen nur als Satz wie „Daten sind zu schützen“ dokumentiert sind. Für die Entwicklung braucht es überprüfbare Vorgaben: Wie erfolgt die Registrierung? Wann ist eine starke Authentisierung nötig? Welche Berechtigungen erhalten Patientinnen, Patienten, medizinisches Fachpersonal und Support? Wie lange sind Sitzungen gültig? Was passiert bei einem verlorenen Smartphone oder bei mehreren fehlgeschlagenen Login-Versuchen?
Diese Fragen gehören in ein Sicherheits- und Datenschutzkonzept, aber ebenso in User Stories, Architekturentscheidungen und Testfälle. Nur dann wird aus einer Anforderung ein nachvollziehbarer Teil des Produkts. Wenn ein Nutzerkonto gelöscht wird, muss beispielsweise nicht nur ein Button in der Oberfläche existieren. Es muss feststehen, welche Daten gelöscht, welche aus rechtlichen Gründen aufbewahrt und welche Backups nach welchem Verfahren bereinigt werden.
Auch die Risikobewertung darf nicht als einmaliges Dokument verstanden werden. Funktionen verändern sich. Eine neue Chat-Funktion, eine Anbindung an Wearables oder ein erweitertes Rollenmodell schaffen neue Bedrohungen. Deshalb sollte jede fachliche Erweiterung eine kurze Sicherheitsprüfung auslösen. Das ist kein Bremsklotz für agile Entwicklung, sondern schützt vor teuren Korrekturen, wenn Architektur und Datenmodell bereits festgefahren sind.
Sicherheit und Gebrauchstauglichkeit gehören zusammen
Eine besonders strenge Anmeldung kann sinnvoll sein, wenn sie zum Risiko passt. Sie kann aber auch dazu führen, dass Menschen eine Therapie-App nicht regelmäßig nutzen. Gerade bei DiGAs ist das ein relevanter Zielkonflikt: Schutz darf die Versorgung nicht unnötig erschweren.
Die richtige Lösung hängt vom Anwendungsszenario ab. Bei hochsensiblen Inhalten kann eine zusätzliche Absicherung beim Öffnen bestimmter Bereiche sinnvoll sein. Bei einer täglich genutzten Übungseinheit muss der Zugang zugleich verständlich und verlässlich bleiben. Gute UX und Informationssicherheit sind keine Gegensätze. Eine klare Sprache, nachvollziehbare Fehlermeldungen und sauber gestaltete Wiederherstellungsprozesse reduzieren sowohl Abbrüche als auch Sicherheitsrisiken.
Die technische Basis: Schutz ist kein einzelnes Feature
Verschlüsselung bei der Übertragung und Speicherung ist ein Grundbaustein, aber keine vollständige Sicherheitsstrategie. Ebenso entscheidend sind eine sauber getrennte Systemarchitektur, restriktive Rechtevergabe, sichere Schnittstellen und ein nachvollziehbarer Umgang mit Geheimnissen wie API-Schlüsseln oder Zertifikaten.
In der Praxis lohnt es sich, Entwicklungs-, Test- und Produktionsumgebungen strikt zu trennen. Testdaten gehören nicht in die Produktionsumgebung, und reale Gesundheitsdaten gehören nicht in frei zugängliche Testsysteme. Zugriffe auf administrative Bereiche sollten auf die notwendigen Personen begrenzt, protokolliert und regelmäßig überprüft werden. Ein gemeinsames Admin-Passwort im Team ist keine pragmatische Abkürzung, sondern ein unnötiges Betriebsrisiko.
Auch die Qualität der Software selbst zählt. Sichere Entwicklung umfasst Code-Reviews, automatisierte Tests, Abhängigkeitsprüfungen und einen geregelten Umgang mit Schwachstellen. Moderne Anwendungen bestehen aus vielen Bibliotheken und Diensten. Wird eine kritische Sicherheitslücke bekannt, muss klar sein, ob die eigene DiGA betroffen ist, wer entscheidet und wie schnell ein Update bereitgestellt werden kann.
Das verlangt eine belastbare technische Dokumentation. Nicht als Ordner für die Prüfung, sondern als Arbeitsgrundlage für Entwicklung und Betrieb. Ohne sie wird jede Wartung zum Rätselraten: Welche Komponente verarbeitet welche Daten? Welche Schnittstelle hängt an welchem Dienst? Welche Änderung könnte Auswirkungen auf die Risikobewertung haben? Schluss mit Wissensinseln bei einzelnen Personen - gerade im Gesundheitsbereich muss das System auch dann verständlich bleiben, wenn Teams wechseln.
Betriebssicherheit entscheidet nach dem Launch
Ein sicher entwickeltes Produkt kann durch einen ungeordneten Betrieb schnell an Qualität verlieren. Updates für Betriebssysteme, Frameworks und Serverkomponenten laufen weiter. Nutzerzahlen steigen, Supportfälle häufen sich, neue Angriffswege entstehen. DiGA Sicherheit ist daher eine dauerhafte Aufgabe und kein Meilenstein, den man mit dem Go-Live abhakt.
Ein praxistaugliches Betriebskonzept regelt mindestens Monitoring, Backups, Patch-Management, Incident Response und Verantwortlichkeiten. Monitoring soll nicht jedes Nutzerverhalten überwachen. Es soll technische Auffälligkeiten sichtbar machen: ungewöhnliche Fehlerraten, fehlgeschlagene Anmeldeversuche, Ausfälle von Schnittstellen oder unerwartete Lastspitzen. So lassen sich Probleme erkennen, bevor sie die Versorgung beeinträchtigen.
Backups brauchen ebenfalls mehr als einen Haken im Hosting-Paket. Entscheidend ist, ob eine Wiederherstellung getestet wurde, wie lange sie dauert und welche Daten dabei verloren gehen könnten. Ein Backup, das sich im Ernstfall nicht zurückspielen lässt, ist nur eine Beruhigung auf dem Papier.
Für Sicherheitsvorfälle braucht es klare Wege. Wer bewertet einen Verdacht? Wer informiert interne Verantwortliche, Dienstleister und gegebenenfalls betroffene Stellen? Welche Maßnahmen sind vorbereitet, wenn ein Zugang kompromittiert wurde oder eine Schnittstelle falsch konfiguriert ist? Unter Zeitdruck helfen keine allgemeinen Zuständigkeiten. Es helfen erreichbare Ansprechpartner, dokumentierte Abläufe und regelmäßige Übungen.
Nachweise schaffen Klarheit, nicht Bürokratie
Die Anforderungen rund um Datenschutz, Informationssicherheit und die BfArM-Listung wirken zunächst dokumentenlastig. Der Aufwand wird aber beherrschbar, wenn Dokumentation parallel zur Produktentwicklung entsteht. Architektur, Risikoanalyse, Testnachweise, Verarbeitungsübersichten und Betriebsprozesse sollten dieselbe Realität beschreiben wie die laufende Anwendung.
Das ist auch wirtschaftlich sinnvoll. Werden Nachweise erst kurz vor Einreichung zusammengestellt, entdecken Teams häufig Differenzen zwischen Konzept und Umsetzung. Dann müssen Funktionen, Berechtigungen oder Verträge unter hohem Zeitdruck angepasst werden. Eine frühe, regelmäßige Abstimmung reduziert solche Schleifen und macht Budgets planbarer.
Externe Dienstleister sollten dabei nicht als Black Box eingebunden werden. Für Hosting, Push-Benachrichtigungen, Analytik, Support oder Entwicklung muss transparent sein, welche Rolle sie übernehmen, welche Daten sie verarbeiten und wie Änderungen abgestimmt werden. Gerade bei gewachsenen Systemlandschaften entstehen Risiken oft an den Übergängen - nicht in der einzelnen App.
Ein sinnvoller Projektablauf für sichere DiGAs
Ein belastbarer Ablauf verbindet Fachkonzept, UX, Entwicklung und Betrieb von Beginn an. Zuerst werden Versorgungsziel, Nutzergruppen, Datenflüsse und regulatorische Rahmenbedingungen geklärt. Danach folgt eine Architektur, die Sicherheitsanforderungen nicht nachträglich um das Produkt legt, sondern technisch berücksichtigt. In kurzen Entwicklungszyklen werden Funktionen umgesetzt, getestet und dokumentiert.
Vor dem Launch braucht es neben fachlichen Abnahmen gezielte Sicherheitsprüfungen. Dazu gehören Berechtigungs- und Schnittstellentests, Prüfungen typischer Angriffsszenarien sowie ein Blick auf Konfigurationen und eingesetzte Abhängigkeiten. Je nach Risikolage und Reifegrad kann eine unabhängige Prüfung sinnvoll sein. Entscheidend ist nicht, möglichst viele Prüfungen einzukaufen, sondern die passenden Risiken nachvollziehbar abzudecken.
Inter Medien Networks begleitet solche Vorhaben mit Blick auf das Gesamtsystem: von UX und mobiler Entwicklung über Backend und Schnittstellen bis zu dokumentierten Betriebsprozessen. Denn eine DiGA ist nicht nur eine App. Sie ist ein Versorgungsprodukt, das über Jahre sicher, wartbar und verständlich bleiben muss.
Wer Sicherheit früh als Teil der Produktqualität behandelt, verhindert nicht jede Störung. Aber er schafft die Voraussetzungen, ruhig und geordnet zu handeln, wenn etwas passiert - und gibt Nutzerinnen und Nutzern einen guten Grund, der Anwendung ihre Daten und ihre Gesundheit anzuvertrauen.