Eine DiGA scheitert selten daran, dass sich eine Funktion nicht programmieren lässt. Kritisch wird es dort, wo Produktidee, klinische Anforderungen, Datenschutz, Betrieb und Nachweise getrennt geplant wurden. Die DiGA Plattform Bewertungskriterien betreffen deshalb nicht nur die App-Oberfläche. Sie reichen bis in Architekturentscheidungen, Rollenmodelle, Supportprozesse und die Frage, wie sich Wirksamkeit belastbar belegen lässt.
Für Produktverantwortliche ist das eine unbequeme, aber hilfreiche Erkenntnis: Eine gute Gesundheitsapp wird nicht erst kurz vor dem Antrag beim BfArM zu einer DiGA. Sie muss von Beginn an so konzipiert werden, dass Sicherheit, Qualität und positive Versorgungseffekte nachvollziehbar zusammenwirken. Wer diese Arbeit erst zum Go-Live beginnt, produziert meist Nacharbeit, Dokumentationslücken und vermeidbare Kosten.
Was bei einer DiGA-Plattform tatsächlich bewertet wird
Der Begriff Plattform kann in DiGA-Projekten vieles meinen: eine Patienten-App mit Backend, ein Webportal für Fachpersonal, ein Content-System, Schnittstellen zu Drittsystemen oder eine gemeinsame technische Basis für mehrere Indikationen. Für die Bewertung ist entscheidend, welche Bestandteile Teil des Medizinprodukts sind und welche Funktionen sie für Patientinnen und Patienten erfüllen.
Im Fast-Track-Verfahren steht nicht eine schöne technische Plattform im Mittelpunkt, sondern ein Medizinprodukt der Risikoklasse I oder IIa mit digitaler Hauptfunktion. Die Anwendung muss die gesetzlichen Voraussetzungen erfüllen und einen positiven Versorgungseffekt nachweisen oder diesen bei vorläufiger Aufnahme innerhalb der vorgesehenen Erprobung belegen. Dazu kommen Anforderungen an Sicherheit, Funktionstauglichkeit, Datenschutz, Informationssicherheit, Qualität und Interoperabilität.
Eine Plattformarchitektur kann diese Nachweise erheblich erleichtern oder erschweren. Ein zentraler Dienst für Authentifizierung, Protokollierung oder Inhaltsverwaltung ist sinnvoll, wenn Verantwortlichkeiten, Datenflüsse und Änderungen sauber beherrscht werden. Werden dagegen mehrere Anwendungen, Mandanten und Datenquellen ohne klare Trennung in einem Backend zusammengeführt, entstehen schnell Fragen: Welche Daten verarbeitet welcher Dienst? Welche Änderung betrifft welches Produkt? Wie wird ein Sicherheitsvorfall eingegrenzt? Und welche Version war bei einer klinischen Studie im Einsatz?
Die Bewertungskriterien früh in Produktentscheidungen übersetzen
Die größten Reibungsverluste entstehen, wenn regulatorische Anforderungen als Dokumentationsaufgabe am Projektende behandelt werden. Besser ist es, jedes Kriterium in konkrete Entscheidungen für Produkt, Technik und Betrieb zu übersetzen.
Sicherheit und Funktionstauglichkeit beginnen bei den Nutzungsszenarien
Eine DiGA muss für ihre vorgesehene medizinische Zweckbestimmung sicher funktionieren. Das betrifft nicht nur Abstürze oder Ladezeiten. Ebenso relevant sind unklare Hinweise, falsche Berechnungen, fehlende Warnungen und Bedienwege, die in belastenden Situationen missverstanden werden können.
Am Anfang stehen daher präzise Nutzungsszenarien: Wer nutzt die Anwendung, mit welchem Ziel, in welcher körperlichen oder psychischen Verfassung und auf welchem Endgerät? Daraus lassen sich Risiken ableiten. Ein Symptomtagebuch braucht beispielsweise andere Plausibilitätsprüfungen als ein digitales Therapieprogramm. Eine Erinnerung kann hilfreich sein, darf aber nicht den Eindruck einer akuten medizinischen Überwachung erzeugen, wenn diese nicht stattfindet.
Usability Engineering ist dabei kein Design-Extra. Es liefert den nachvollziehbaren Prozess, mit dem Nutzung, Risiken und Gestaltung zusammengeführt werden. Nutzerfeedback ist wichtig, ersetzt aber keine strukturierte Bewertung kritischer Bedienfehler. Gerade bei komplexen Zielgruppen sollte die Plattform auch mit eingeschränkter Konzentration, geringer digitaler Erfahrung oder schlechter Netzverbindung verständlich bleiben.
Datenschutz ist Datenfluss, nicht nur Einwilligungstext
Gesundheitsdaten gehören zu den besonders schutzwürdigen Daten. Entsprechend reicht es nicht, am Ende eine Datenschutzerklärung zu ergänzen. Entscheidend ist, welche Daten wirklich erforderlich sind, wo sie gespeichert werden, wer Zugriff erhält und wie lange sie benötigt werden.
Eine gute Datenarchitektur trennt Identitätsdaten, medizinische Inhalte, Analyseinformationen und Betriebsdaten dort, wo es fachlich geboten ist. Sie reduziert Berechtigungen auf das notwendige Maß und macht Zugriffe nachvollziehbar. Auch scheinbar harmlose Telemetriedaten verdienen Aufmerksamkeit: Werden Nutzungsverhalten, Geräteinformationen oder Ereignisse an externe Dienste übertragen, kann das datenschutzrechtlich und regulatorisch relevant werden.
Besonders häufig wird die Trennung zwischen Produktbetrieb und Marketing unterschätzt. Tracking, Retargeting oder frei eingebundene Analyse-SDKs mögen im klassischen App-Marketing üblich sein. Bei einer DiGA erhöhen sie jedoch Prüfaufwand und Risiko erheblich. Die pragmatische Frage lautet: Braucht die medizinische Funktion diesen Datenfluss wirklich? Wenn nein, gehört er nicht in das Produkt.
Informationssicherheit muss im Alltag funktionieren
Informationssicherheit zeigt sich nicht in einer einzelnen Verschlüsselungsangabe. Sie zeigt sich darin, ob ein Team Zugänge kontrolliert, Sicherheitsupdates priorisiert, Schwachstellen bewertet und auf Vorfälle vorbereitet ist.
Für die Plattform bedeutet das unter anderem: eindeutige Benutzer- und Rollenmodelle, Mehrfaktor-Authentifizierung für administrative Zugänge, abgesicherte Schnittstellen, verschlüsselte Datenübertragung und angemessene Verschlüsselung gespeicherter Daten. Ebenso wichtig sind Protokollierung, Monitoring, Backups und getestete Wiederherstellungsprozesse. Ein Backup, das nie zurückgespielt wurde, ist kein belastbarer Notfallplan.
Hier entscheidet sich oft, ob aus einem Pilotprojekt ein dauerhaft betreibbares Produkt wird. Cloud-Dienste können sinnvoll sein, sofern Verträge, technische Maßnahmen, Verantwortlichkeiten und Datenstandorte zur Anwendung passen. Pauschale Aussagen wie „Die Cloud ist zertifiziert“ beantworten keine produktbezogene Risikofrage. Es kommt auf die konkrete Konfiguration und den gelebten Betrieb an.
Positive Versorgungseffekte brauchen eine messbare Produktlogik
Die klinische Bewertung ist für viele Teams der anspruchsvollste Teil, weil sie Produktentwicklung und Evidenzstrategie verbindet. Ein positiver Versorgungseffekt kann entweder ein medizinischer Nutzen oder eine patientenrelevante Verfahrens- und Strukturverbesserung sein. Welche Evidenz angemessen ist, hängt von Indikation, Zweckbestimmung, Risiko, Zielgruppe und Studiendesign ab.
Der häufige Fehler: Erst wird eine umfangreiche App gebaut, danach sucht man nach einer passenden Endpunktlogik. Sinnvoller ist der umgekehrte Weg. Welche Veränderung soll bei den Nutzenden eintreten? Woran ist sie messbar? Welche Funktion soll diese Veränderung auslösen? Und welche Daten dürfen beziehungsweise müssen erhoben werden, um den Effekt nachzuweisen?
Wenn etwa ein Therapieprogramm die Adhärenz verbessern soll, reicht eine hohe Zahl an Logins nicht automatisch als Nachweis. Nutzung kann eine unterstützende Kennzahl sein, aber sie ist nicht zwingend patientenrelevant. Die Plattform sollte deshalb jene Prozesse zuverlässig abbilden, die für die Studie und die spätere Versorgung relevant sind: Einschlusskriterien, Intervention, Zeitpunkte, Fragebögen, Abbrüche, unerwünschte Ereignisse und Versionen des Inhalts.
Änderungen während der Erprobung verdienen besondere Sorgfalt. Ein neues Design, geänderte Algorithmen oder zusätzliche Inhalte können die Vergleichbarkeit der Evidenz beeinflussen. Ohne klares Release- und Change-Management wird aus agiler Entwicklung schnell ein Risiko für die Nachweisführung.
Interoperabilität und Schnittstellen: nur dort bauen, wo sie Versorgung verbessern
Interoperabilität ist kein Selbstzweck und auch kein Argument für möglichst viele Schnittstellen. Sie wird dann wertvoll, wenn sie Doppelpflege reduziert, Versorgungsschritte vereinfacht oder die Anwendung sinnvoll in bestehende Abläufe einbindet.
Vor einer Integration mit Praxissoftware, Patientenakte, Wearables oder Identitätsdiensten sollten Teams klären, wer Daten erzeugt, wer sie fachlich verantwortet und wie Fehler behandelt werden. Was passiert bei einer unvollständigen Übertragung? Darf ein Wert automatisch übernommen werden? Wird eine behandelnde Person informiert, oder ist die DiGA ausschließlich ein Selbstmanagement-Werkzeug?
Technisch lohnt sich eine klare Schnittstellenstrategie mit dokumentierten Datenmodellen, Versionierung und definierten Fehlerfällen. Für den Betrieb ist mindestens genauso wichtig, dass Support und Fachverantwortliche wissen, wie sie fehlerhafte Daten, verlorene Freischaltcodes oder nicht erreichbare Dienste behandeln. Sonst wird aus einer gut gemeinten Integration eine weitere Insellösung mit Supportaufwand.
Ein Bewertungsplan verhindert teure Nacharbeit
Ein belastbares Projekt braucht keinen Dokumentenberg am ersten Tag. Es braucht einen Plan, der Anforderungen, Nachweise und Verantwortlichkeiten früh zusammenführt. Bewährt hat sich eine Arbeitsstruktur mit Produkt- und Zweckbestimmung, Risikomanagement, Datenschutzkonzept, Sicherheitskonzept, Qualitätsprozessen, klinischer Strategie sowie Betriebs- und Supportkonzept.
Diese Bausteine dürfen nicht nebeneinander liegen wie Dateien in einem Projektordner. Jede Produktentscheidung sollte sich darin wiederfinden. Ändert sich etwa der Login-Prozess, betrifft das möglicherweise Risikoanalyse, Datenschutz, Sicherheitskonzept, Gebrauchstauglichkeit, technische Dokumentation und Support. Ein System statt zehn unverbundene Listen schafft hier Transparenz.
Auch die Rollen müssen klar sein. Medizinische Verantwortung, regulatorische Bewertung, Datenschutz, Informationssicherheit, Entwicklung und Betrieb benötigen feste Ansprechpartner und nachvollziehbare Freigaben. Ein externer Entwicklungspartner kann die technische Umsetzung und Dokumentation wirksam unterstützen. Die Verantwortung des Herstellers für das Produkt lässt sich jedoch nicht einfach auslagern.
DiGA Plattform Bewertungskriterien als Betriebsaufgabe verstehen
Die Aufnahme in das DiGA-Verzeichnis ist kein Schlusspunkt. Betrieb, Updates, Sicherheitsmeldungen, Nutzeranfragen und Weiterentwicklungen bleiben Teil der Produktverantwortung. Gerade nach dem Launch zeigt sich, ob die Plattform sauber aufgebaut ist oder ob jedes Update Schweißperlen auslöst.
Deshalb sollten Teams nicht nur den Antrag planen, sondern auch die Zeit danach: Wie werden Releases bewertet und freigegeben? Wer beobachtet Sicherheitsmeldungen? Wie werden Backups geprüft? Wie reagiert der Support auf medizinisch sensible Rückmeldungen? Und wie bleiben Studien-, Betriebs- und Produktdaten nachvollziehbar, wenn sich die Anwendung weiterentwickelt?
Wer die Bewertungskriterien als gemeinsame Leitplanke für Produkt und Betrieb nutzt, schafft mehr als eine bessere Ausgangslage für die BfArM-Listung. Es entsteht eine DiGA, die im Versorgungsalltag verständlich, sicher und langfristig beherrschbar bleibt.