Eine DiGA scheitert selten daran, dass die App keine sinnvolle Idee hat. Kritisch wird es dort, wo medizinischer Nutzen, Produktentwicklung, Datenschutz und Nachweisdokumentation getrennt laufen. Die BfArM Anforderungen für die DiGA Listung machen aus einer Gesundheitsapp ein reguliertes Produkt. Wer diese Arbeit erst kurz vor dem Antrag beginnt, produziert meist Nachweise unter Zeitdruck - und unnötige Schleifen.
Für Organisationen, die digitale Therapie- oder Versorgungsangebote aufbauen, ist die Listung deshalb kein abschließender Verwaltungsschritt. Sie ist ein Projektpfad, der Architektur, UX, klinische Bewertung, Betrieb und Verantwortlichkeiten von Beginn an beeinflusst.
Was für die DiGA-Listung grundsätzlich gelten muss
Eine Digitale Gesundheitsanwendung wird in Deutschland in das DiGA-Verzeichnis des Bundesinstituts für Arzneimittel und Medizinprodukte, kurz BfArM, aufgenommen. Erst dann kann sie grundsätzlich von Ärztinnen, Ärzten und Psychotherapeutinnen oder Psychotherapeuten verordnet werden und für gesetzlich Versicherte erstattungsfähig sein.
Der Fast-Track ist jedoch nicht für jede Gesundheitssoftware gedacht. Eine DiGA muss ein Medizinprodukt sein, das überwiegend auf digitaler Technologie beruht. Sie muss zur Risikoklasse I oder IIa gehören, Patientinnen und Patienten unterstützen und einen medizinischen Zweck erfüllen. Reine Terminapps, allgemeine Fitnessangebote oder Plattformen, die primär Leistungen vermitteln, erfüllen diese Voraussetzungen in der Regel nicht.
Der Antragsteller trägt die Verantwortung für das Produkt. Das betrifft nicht nur den Antrag beim BfArM, sondern auch die belastbare Dokumentation hinter den Aussagen zur Anwendung, Sicherheit und Wirkung. Eine hübsche Oberfläche oder ein sauber entwickeltes Backend reichen nicht aus, wenn der regulatorische Unterbau fehlt.
BfArM Anforderungen für die DiGA Listung: Die fünf Arbeitsstränge
In der Praxis greifen fünf Themen ineinander: Medizinprodukterecht, Sicherheit und Datenschutz, Interoperabilität, positive Versorgungseffekte sowie die Antragsunterlagen. Sie lassen sich organisatorisch trennen, aber nicht sinnvoll nacheinander abarbeiten. Eine Änderung am Funktionsumfang kann beispielsweise die Risikoanalyse, Einwilligungstexte, Testfälle und Studiendesign zugleich berühren.
1. CE-Kennzeichnung und Medizinprodukte-Qualität
Vor der Aufnahme in das DiGA-Verzeichnis braucht das Produkt eine CE-Kennzeichnung nach der europäischen Medizinprodukteverordnung, MDR. Bei vielen DiGAs der Klasse I oder IIa ist eine saubere Zweckbestimmung der Ausgangspunkt. Sie legt fest, für wen die Anwendung gedacht ist, bei welcher Indikation sie eingesetzt wird und was sie nachweisbar leisten soll.
Diese Zweckbestimmung darf nicht größer sein als die Evidenz. Wer therapeutische Wirkungen verspricht, muss die entsprechenden Aussagen später auch belegen können. Zu weit gefasste Marketingtexte führen schnell zu Konflikten zwischen Produktkommunikation, klinischer Bewertung und regulatorischer Dokumentation.
Zum Qualitätsmanagement gehören unter anderem Risikomanagement, Software-Lebenszyklusprozesse, Usability Engineering, Fehlerbehandlung und nachvollziehbare Änderungen. Das klingt nach Formalismus, schützt aber vor einem bekannten Problem: Ein Update wird aus Produktperspektive als klein eingestuft, verändert aber medizinische Logik, Datenflüsse oder Risikoprofile. Ohne geregelten Change-Prozess wird der Betrieb zur Dauerbaustelle.
2. Datenschutz und Informationssicherheit als Produktfunktion
DiGAs verarbeiten häufig Gesundheitsdaten. Entsprechend hoch sind die Anforderungen an Datenschutz und Informationssicherheit. Maßgeblich sind die Anforderungen der DiGAV und die dazugehörigen BfArM-Vorgaben. Gefordert ist nicht nur eine Datenschutzerklärung, sondern ein schlüssiges Sicherheitskonzept, das im Alltag funktioniert.
Dazu gehören eine passende Rechtsgrundlage für die Verarbeitung, Datensparsamkeit, Rollen- und Berechtigungskonzepte, Verschlüsselung, Protokollierung sowie geregelte Lösch- und Aufbewahrungsfristen. Bei mobilen Anwendungen kommen Themen wie sichere Authentifizierung, Schutz lokaler Daten, Sitzungsmanagement und Umgang mit verlorenen Geräten hinzu.
Entscheidend ist die reale Systemlandschaft. Werden Analysewerkzeuge, Push-Dienste, Videoanbieter, Identitätsdienste oder Cloud-Komponenten eingebunden, müssen Datenflüsse, Auftragsverarbeitungen und technische Schutzmaßnahmen zusammenpassen. Excel-Listen mit Zugriffsrechten und unklare Zuständigkeiten für Sicherheitsvorfälle sind keine tragfähige Betriebsgrundlage.
Auch der Betrieb zählt. Sicherheitsupdates, Backups, Monitoring, Incident Response und Wiederherstellungstests müssen geplant und dokumentiert sein. Ein Go-Live ohne Schweißperlen entsteht nicht durch einen einzelnen Penetrationstest, sondern durch klar geregelte Abläufe nach dem Launch.
3. Interoperabilität ohne Alibi-Schnittstelle
DiGAs sollen sich in die Versorgung einfügen. Deshalb spielen Interoperabilitätsanforderungen eine Rolle. Welche Daten ausgetauscht werden müssen und in welchem Format, hängt vom Produkt und dem jeweiligen Stand der Vorgaben ab. Wichtig ist: Eine Schnittstelle, die technisch vorhanden, fachlich aber unbrauchbar ist, löst kein Versorgungsproblem.
Schon im Konzept sollte geklärt werden, welche Informationen Patienten, Behandelnde oder andere Systeme tatsächlich benötigen. Das können etwa Verlaufsdaten, Messwerte, Berichte oder Hinweise zum Therapiefortschritt sein. Dabei gilt der Grundsatz der Datenminimierung: Nicht jede verfügbare Information muss übertragen werden.
Für die technische Umsetzung braucht es eine belastbare Datenarchitektur, Versionierung und klare Verantwortlichkeiten. Gerade bei bestehenden Praxis-, Klinik- oder Backend-Systemen lohnt sich eine frühe Integrationsprüfung. Sonst wird aus einer DiGA mit guter Nutzerführung eine Insellösung, deren Daten niemand sinnvoll weiterverwenden kann.
4. Positive Versorgungseffekte belegen
Der fachlich anspruchsvollste Teil ist häufig der Nachweis positiver Versorgungseffekte. Das BfArM unterscheidet medizinischen Nutzen und patientenrelevante Struktur- und Verfahrensverbesserungen. Welche Kategorie passt, hängt von Zweckbestimmung, Indikation und Versorgungssituation ab.
Für eine dauerhafte Aufnahme muss der Effekt mit geeigneten Studien belegt werden. Eine plausible Produktidee oder positives Nutzerfeedback ersetzt diesen Nachweis nicht. Das Studiendesign sollte zur konkreten Behauptung passen: Wer eine Verbesserung klinischer Symptome beansprucht, braucht andere Endpunkte als ein Produkt, das etwa Therapieadhärenz oder den Zugang zu Versorgung verbessern soll.
Unter bestimmten Voraussetzungen kann zunächst eine vorläufige Aufnahme erfolgen, während die erforderliche Erprobung läuft. Das kann den Marktzugang beschleunigen, ist aber kein Freifahrtschein. Der Evaluationsplan muss überzeugend sein, die Studie operativ umsetzbar bleiben und die Finanzierung bis zum belastbaren Ergebnis gesichert sein.
Ein häufiger Fehler liegt in der falschen Reihenfolge: Erst wird die App weitgehend fertig gebaut, danach sucht das Team nach messbaren Endpunkten. Besser ist es, die Versorgungsannahme früh zu formulieren. Welches Problem wird für welche Patientengruppe verbessert? Woran ist diese Verbesserung messbar? Welche Funktion der Anwendung trägt kausal dazu bei? Diese Fragen steuern Produktumfang, UX und Datenerhebung.
5. Antragsunterlagen und nachvollziehbare Produktbeschreibung
Der BfArM-Antrag verlangt eine konsistente Gesamtdarstellung. Angaben zu Zweckbestimmung, Zielgruppe, Funktionen, Datenschutz, Sicherheit, Interoperabilität und Versorgungseffekten müssen zueinander passen. Widersprüche zwischen App Store, Website, Gebrauchsanweisung, klinischer Bewertung und Studienprotokoll kosten Zeit und Vertrauen.
Sinnvoll ist eine zentrale Dokumentationslogik statt einzelner Dateien in verschiedenen Abteilungen. Produktmanagement, Entwicklung, Datenschutz, Regulatory Affairs und klinische Partner sollten mit klaren Freigaben arbeiten. Jede wesentliche Änderung braucht eine Bewertung: Betrifft sie den medizinischen Zweck, Risiken, Evidenz, Datenverarbeitung oder die eingereichten Angaben?
Ein belastbarer Weg vom Konzept zur Aufnahme
Für mittelständische Anbieter funktioniert ein phasenweises Vorgehen meist besser als ein großer Entwicklungsblock mit später Compliance-Prüfung. Zu Beginn stehen Indikation, Zielgruppe, Zweckbestimmung und Versorgungsproblem. Danach folgen die regulatorische Einordnung, eine Gap-Analyse für Qualitätsmanagement und Datenschutz sowie die technische Zielarchitektur.
In der Produktentwicklung sollten Anforderungen direkt in Backlog, Design und Teststrategie übersetzt werden. Beispiel: Wenn ein Therapieplan als Medizinproduktfunktion gilt, müssen Fachlogik, Fehlerszenarien, verständliche Hinweise und Änderungsprotokolle mitentwickelt werden. Wenn Nutzerdaten für die Evidenz erhoben werden, müssen Einwilligung, Datenmodell und Auswertung von Anfang an sauber zusammenspielen.
Vor dem Antrag braucht es einen ehrlichen Readiness-Check. Nicht jede Lücke ist gleich kritisch, aber offene Fragen dürfen nicht zwischen Teams verschwinden. Besonders genau lohnt sich der Blick auf externe Dienstleister, administrative Zugänge, Sicherheitsupdates, Supportprozesse und die Nachvollziehbarkeit von Releases. Der Antrag ist eingereicht, die Verantwortung für den Betrieb bleibt.
Was Entscheider jetzt konkret klären sollten
Die erste Frage lautet nicht: „Wie schnell können wir eine App bauen?“ Sie lautet: „Welche überprüfbare Versorgungswirkung soll dieses Produkt für welche Menschen erzeugen?“ Daraus ergeben sich Zweckbestimmung, regulatorischer Pfad, Studienstrategie und technischer Umfang.
Danach braucht es eine realistische Entscheidung über das Betriebsmodell. Wer überwacht Sicherheitsmeldungen? Wer priorisiert Fehler mit möglichem Patienteneinfluss? Wo liegen Daten, und wie werden Zugriffe kontrolliert? Ein System statt zehn Insellösungen reduziert nicht nur Pflegeaufwand. Es macht auch die Nachweisführung gegenüber Prüfern und Partnern deutlich verlässlicher.
Eine DiGA-Listung ist kein Projekt, das man mit einem guten Pitch gewinnt. Sie entsteht aus einer durchdachten Produktentscheidung, sauberer Dokumentation und einem Betrieb, der auch nach dem Go-Live funktioniert. Wenn diese Grundlagen früh stehen, wird aus regulatorischer Komplexität ein planbarer Arbeitsweg - und aus einer App ein Versorgungsangebot, das dauerhaft tragfähig bleibt.