Eine Therapie-App mit guten Ideen ist noch keine erstattungsfähige DiGA. Wer eine DiGA entwickeln und beim BfArM listen lassen möchte, muss medizinischen Nutzen, regulatorische Nachweise, sichere Technik und einen tragfähigen Betrieb gleichzeitig planen. Genau dort scheitern viele Vorhaben nicht an einer einzelnen Anforderung, sondern an Lücken zwischen Produkt, Studienplanung, Datenschutz und Qualitätsmanagement.
Der entscheidende Punkt: Die BfArM-Listung ist kein Abnahmetermin am Ende eines App-Projekts. Sie ist das Ergebnis eines durchgängigen Produktprozesses. Werden Anforderungen erst kurz vor dem Go-Live gesammelt, entstehen Nacharbeiten, die Zeit, Budget und oft auch die Studienplanung gefährden.
Was eine DiGA von einer Gesundheits-App unterscheidet
Digitale Gesundheitsanwendungen sind Medizinprodukte, die unter anderem Patientinnen und Patienten bei der Erkennung, Überwachung, Behandlung oder Linderung von Krankheiten unterstützen können. Für die Aufnahme in das DiGA-Verzeichnis gelten klare rechtliche und fachliche Voraussetzungen. Die Anwendung muss als Medizinprodukt CE-gekennzeichnet sein und in den vorgesehenen Risikoklassen liegen. Außerdem muss sie überwiegend auf digitalen Technologien beruhen und von Patientinnen und Patienten oder Leistungserbringenden nutzbar sein.
Für Unternehmen ist vor allem der Erstattungsweg relevant: Eine gelistete DiGA kann ärztlich oder psychotherapeutisch verordnet werden. Damit verschiebt sich die Frage von „Lässt sich die App bauen?“ zu „Lässt sich ein belastbarer Versorgungsnutzen belegen und dauerhaft betreiben?“
Das BfArM prüft nicht nur die Oberfläche oder die Funktionsliste. Im Mittelpunkt stehen Sicherheit, Funktionstauglichkeit, Datenschutz, Informationssicherheit, Qualität und positive Versorgungseffekte. Dazu zählen medizinische Nutzen oder patientenrelevante Verbesserungen von Strukturen und Prozessen. Eine hübsche Anwendung mit vielen Downloads reicht dafür nicht aus.
DiGA entwickeln: Der Produktkern muss klinisch sinnvoll sein
Am Anfang steht eine präzise Indikation, nicht ein allgemeines Versprechen wie „besseres Gesundheitsmanagement“. Welche Patientengruppe soll die Anwendung nutzen? Welches konkrete Versorgungsproblem besteht heute? Welche Intervention bietet die App, und wodurch unterscheidet sie sich von einem digitalen Tagebuch, einem Videokurs oder einer gewöhnlichen Coaching-Anwendung?
Diese Fragen beeinflussen Architektur, UX und Evidenzstrategie unmittelbar. Wenn die DiGA beispielsweise Symptome regelmäßig erfasst, Therapieinhalte personalisiert oder Behandelnde mit Daten versorgt, müssen Zweck, Datenflüsse und Verantwortlichkeiten sauber voneinander getrennt sein. Sonst entsteht schnell eine Mischung aus Funktionen, deren medizinische Relevanz später schwer zu begründen ist.
Eine gute Produktdefinition verbindet vier Perspektiven: den klinischen Bedarf, die tatsächliche Nutzung im Alltag, die regulatorische Einordnung und das Geschäftsmodell. Gerade bei etablierten Organisationen kommen bestehende Systeme hinzu - etwa Patientenportale, Identitätsdienste, CRM, Forschungsdatenbanken oder Abrechnungslösungen. Ein System statt zehn Insellösungen ist auch im Gesundheitsbereich ein Sicherheits- und Betriebsfaktor.
UX ist Teil der Wirksamkeit, nicht Dekoration
Eine DiGA wird häufig in belastenden Situationen genutzt: nach einer Diagnose, zwischen Therapieterminen, bei Schmerzen, Erschöpfung oder psychischer Belastung. Komplizierte Registrierungen, lange Fragebögen und unverständliche Hinweise senken die regelmäßige Nutzung. Das ist nicht nur ein Conversion-Problem. Es kann die Evidenz, die Patientensicherheit und den Versorgungseffekt beeinträchtigen.
Deshalb sollten Inhalte, Interaktionen und Erinnerungen früh mit der Zielgruppe getestet werden. Dabei gilt: Niedrige Nutzung ist nicht immer ein UX-Fehler. Manche Indikationen erfordern bewusst kurze, seltene Interventionen. Entscheidend ist, ob das Nutzungskonzept zur medizinischen Hypothese und zum Studienendpunkt passt.
Die Evidenzplanung beginnt vor der Entwicklung
Der Nachweis positiver Versorgungseffekte ist häufig der anspruchsvollste Teil des DiGA-Vorhabens. Wer erst nach Fertigstellung der App über eine Studie nachdenkt, riskiert, dass relevante Daten fehlen, Endpunkte nicht sauber erhoben werden oder die Produktversion während der Studie zu stark verändert werden muss.
Die Evidenzstrategie sollte deshalb parallel zum Fachkonzept entstehen. Dazu gehören eine nachvollziehbare Versorgungshypothese, passende Zielgrößen, Ein- und Ausschlusskriterien, ein Studienprotokoll sowie ein Plan für Datenerhebung und Auswertung. Welche Studie angemessen ist, hängt von Indikation, Risiko, Interventionsart und vorhandener Evidenz ab. Es gibt keinen Standard, der für jede DiGA passt.
Auch eine vorläufige Aufnahme kann unter bestimmten Voraussetzungen ein sinnvoller Weg sein. Sie ersetzt jedoch nicht den Evidenznachweis. Unternehmen brauchen dann einen realistischen Zeitplan für die Erprobung, ausreichende Ressourcen für Rekrutierung und Studienbetrieb sowie klare Regeln für Produktänderungen. Eine neue Funktion kann klinisch sinnvoll sein, aber Vergleichbarkeit und Dokumentation erschweren.
Qualität, Datenschutz und Informationssicherheit von Anfang an verzahnen
Im DiGA-Projekt sind Qualitätsmanagement, Datenschutz und Informationssicherheit keine Anhänge für die letzte Projektphase. Sie bestimmen, wie Anforderungen dokumentiert, Risiken bewertet, Releases freigegeben und Vorfälle behandelt werden.
Ein belastbares Vorgehen umfasst mindestens diese vier Arbeitsstränge:
- ein Qualitätsmanagementsystem mit klaren Rollen, Entwicklungsdokumentation, Risiko- und Änderungsmanagement,
- eine technische Sicherheitsarchitektur mit Rechtekonzept, Verschlüsselung, Protokollierung, Backup und Wiederherstellung,
- ein Datenschutzkonzept für Datenminimierung, Zweckbindung, Einwilligungen, Auftragsverarbeitung und Löschkonzepte,
- einen Betriebsprozess für Monitoring, Support, Sicherheitsupdates, Incident Response und nachvollziehbare Releases.
In der Praxis sind die Übergänge entscheidend. Ein Rechtekonzept betrifft Datenschutz und Informationssicherheit. Ein Fehlerbericht kann Produktqualität, Patientensicherheit und Support zugleich berühren. Ein Release braucht nicht nur die Freigabe aus der Entwicklung, sondern je nach Änderung auch eine regulatorische und klinische Bewertung.
Für mittelständische Organisationen ist das oft ungewohnt. Viele haben erfahrene Fachabteilungen und gute Produktideen, arbeiten aber mit getrennten Dokumenten, Ticketsystemen und Dienstleistern. Das führt zu Doppelpflege und offenen Zuständigkeiten. Besser ist ein Prozess, in dem Produktanforderung, Risikobewertung, technische Umsetzung, Testnachweis und Releaseentscheidung nachvollziehbar zusammenlaufen.
BfArM-Listung vorbereiten: Das Dossier ist Projektarbeit
Der Antrag für das DiGA-Verzeichnis verlangt strukturierte Nachweise. Dazu gehören je nach Vorhaben Unterlagen zum Medizinprodukt, zur Sicherheit und Funktionstauglichkeit, zum Datenschutz und zur Informationssicherheit sowie zum positiven Versorgungseffekt. Die konkrete Ausgestaltung richtet sich nach den jeweils geltenden Vorgaben und dem Produkt.
Die größte Gefahr liegt in Widersprüchen: Das Marketing beschreibt eine andere Zielgruppe als die klinische Bewertung. Die Datenschutzerklärung nennt Daten, die in der technischen Dokumentation nicht auftauchen. Die Studienunterlagen beziehen sich auf einen Funktionsstand, der längst verändert wurde. Solche Brüche lassen sich vermeiden, wenn Dossierarbeit nicht als Dokumenten-Sammelaktion behandelt wird.
Sinnvoll ist ein fester Nachweisplan mit Verantwortlichen, Versionen und Prüfterminen. Jede zentrale Produktentscheidung sollte eine Spur hinterlassen: Warum wurde sie getroffen, welches Risiko betrifft sie, wie wurde sie getestet und welche Unterlage muss aktualisiert werden? Das wirkt zunächst aufwendig. Gegenüber einer hektischen Nachdokumentation kurz vor Antragstellung ist es der planbarere Weg.
Go-Live ohne Schweißperlen braucht einen Betriebsplan
Mit der Listung beginnt der operative Teil erst richtig. Nutzerinnen und Nutzer erwarten funktionierende Zugänge, verständlichen Support und stabile Performance. Ärztliche oder psychotherapeutische Praxen brauchen klare Informationen zur Verordnung und Nutzung. Intern müssen Teams Sicherheitsmeldungen, Fehler, Rückfragen und Produktänderungen kontrolliert bearbeiten können.
Dafür braucht es Service-Level, Zuständigkeiten und einen Releasekalender. Besonders wichtig ist die Trennung zwischen Fehlerbehebung, Sicherheitsupdate und funktionaler Weiterentwicklung. Nicht jede Änderung ist regulatorisch gleich zu bewerten. Wer diese Entscheidungen dokumentiert und früh einordnet, vermeidet, dass notwendige Verbesserungen zum Risiko für die Produktdokumentation werden.
Auch Skalierung sollte von Beginn an mitgedacht werden. Was passiert bei steigenden Verordnungszahlen? Wie werden Supportanfragen priorisiert? Welche Daten müssen für Monitoring, Qualität und Forschung getrennt verarbeitet werden? Ein Backend, das nur für einen Pilotbetrieb ausgelegt ist, wird schnell zum Engpass.
Der realistische Weg zur erstattungsfähigen Anwendung
Eine DiGA ist kein klassisches App-Projekt mit einem finalen Übergabetermin. Sie ist ein reguliertes digitales Produkt, das sich klinisch, technisch und organisatorisch weiterentwickelt. Deshalb lohnt sich ein interdisziplinäres Kernteam aus Medizin, Produktmanagement, Datenschutz, Informationssicherheit, Qualitätsmanagement, UX, Entwicklung und Studienexpertise.
Inter Medien Networks begleitet solche Vorhaben von der Produkt- und Systemkonzeption über UX, mobile Entwicklung und sichere Backend-Architekturen bis zum langfristigen Betrieb. Entscheidend ist dabei nicht, möglichst viele Funktionen schnell zu liefern, sondern einen nachvollziehbaren Weg von der Versorgungsidee zur belastbaren Anwendung aufzubauen.
Wer früh klärt, welche Aussage die DiGA medizinisch tragen soll, welche Daten dafür wirklich nötig sind und wie Änderungen im Betrieb kontrolliert werden, schafft mehr als eine gute Grundlage für den Antrag. Es entsteht ein Produkt, das Patientinnen und Patienten auch nach der Listung verlässlich nutzen können.