DiGA entwickeln: Ablauf, Anforderungen und Dauer bis zur „App auf Rezept“

Eine digitale Gesundheitsanwendung (DiGA) ist eine App, die Ärztinnen und Ärzte in Deutschland verordnen können und die die gesetzlichen Krankenkassen erstatten. Voraussetzung ist die Aufnahme in das DiGA-Verzeichnis des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM). Für Hersteller ist das ein Markt mit klaren, aber anspruchsvollen Regeln.

Der Weg dorthin ist allerdings kein reines Softwareprojekt. Medizinprodukterecht, Datensicherheit, Studien und Preisverhandlung greifen ineinander. Dieser Beitrag zeigt, was eine DiGA ausmacht, in welcher Reihenfolge Sie vorgehen, welche Fristen und Gebühren gelten und was sich 2025 und 2026 geändert hat. Grundlage sind der aktuelle DiGA-Leitfaden des BfArM (Version 3.6 vom 10.12.2025) und § 139e SGB V.

Was eine DiGA ist – und was nicht

Viele Gesundheits-Apps sind keine DiGA und können auch keine werden. Der DiGA-Leitfaden nennt die Merkmale, die zusammen erfüllt sein müssen:

• Medizinprodukt der Klasse I, IIa oder IIb nach der EU-Medizinprodukteverordnung (MDR). Klasse IIb ist seit Inkrafttreten des Digital-Gesetzes (DigiG) am 26.03.2024 zugelassen. Muss ein Produkt in Klasse III eingestuft werden, ist es keine DiGA mehr.
• Die Hauptfunktion ist digital. Eine App, die nur ein Gerät ausliest oder steuert – etwa ein Reizstromgerät –, ist keine DiGA.
• Medizinischer Zweck: Erkennung, Überwachung, Behandlung oder Linderung von Krankheiten bzw. Verletzungen oder Behinderungen. Reine Primärprävention für Gesunde ist ausgeschlossen.
• Der Patient nutzt sie aktiv, allein oder gemeinsam mit der Ärztin oder dem Arzt. Anwendungen, die nur Praxen einsetzen – der Leitfaden nennt Videosprechstunden als Beispiel –, sind keine DiGA. Auch das passive Sammeln von Sensordaten genügt nicht.
• Individualisierte Rückmeldungen auf Basis der Eingaben der Patienten.
• Bereits veröffentlicht: Zum Zeitpunkt des Antrags muss die App in den App-Stores (oder als Webanwendung) verfügbar sein.

Eine allgemeine Fitness- oder Wellness-App fällt nicht darunter – was dort gilt, beschreiben wir im Ratgeber Gesundheits-App entwickeln lassen.

Der Ablauf in sieben Schritten

Die Reihenfolge ergibt sich aus den Voraussetzungen, die bei Antragstellung bereits erfüllt sein müssen. Wer hier abkürzt, scheitert an der Eingangsprüfung.

1. Zweckbestimmung, Risikoklasse und Weg festlegen

Zuerst steht fest, welche Erkrankung die Anwendung adressiert, für welche Patientengruppe, und welcher positive Versorgungseffekt gezeigt werden soll – entweder ein medizinischer Nutzen oder eine patientenrelevante Struktur- und Verfahrensverbesserung (§ 139e Abs. 2 SGB V). Daraus folgt die Risikoklasse und die Wahl zwischen dauerhafter und vorläufiger Aufnahme. Das BfArM bietet dazu Beratungen an, auch als Kick-off-Meeting in Bonn; für Klasse IIb empfiehlt es ausdrücklich eine frühe Beratung.

2. Entwicklung als Medizinprodukt

Die Software entsteht unter den Regeln der MDR. Hinzu kommen die Anforderungen der Verordnung über digitale Gesundheitsanwendungen (DiGAV), die weiter unten beschrieben sind – sie betreffen Architektur und Oberfläche direkt und gehören von Beginn an ins Konzept.

3. Konformitätsbewertung und CE-Kennzeichnung

Die Konformitätsbewertung muss bei Antragstellung vollständig abgeschlossen sein. Bei Klasse IIa und IIb muss eine Benannte Stelle einbezogen werden – das Verfahren ist dann deutlich umfangreicher als bei Klasse I. Die App muss außerdem regulär in Verkehr gebracht sein.

4. Datensicherheit zertifizieren

Seit dem 01.01.2025 weisen Hersteller die Datensicherheit über ein Zertifikat nach der Technischen Richtlinie BSI TR-03161 nach. Seit dem 01.07.2025 ist dieses Zertifikat Voraussetzung dafür, dass ein Antrag überhaupt als formal vollständig gilt. Ohne Zertifikat keine Aufnahme. Zusätzlich verlangt die DiGAV ein zertifiziertes Informationssicherheits-Managementsystem nach ISO 27001 (oder auf Basis von IT-Grundschutz).

5. In den Stores veröffentlichen

Die App muss vor dem Antrag im App Store und bei Google Play (bzw. als Webanwendung) verfügbar sein. Wie die Veröffentlichung abläuft und welche Gebühren Apple und Google verlangen, beschreibt unser Leitfaden App veröffentlichen bei Google Play und im App Store.

6. Antrag beim BfArM stellen

Der Antrag läuft ausschließlich elektronisch über das Antragsportal des BfArM. Die Eingangsprüfung beantwortet das BfArM innerhalb von 14 Tagen. Fehlt etwas, erhalten Sie ein Mängelschreiben mit einer Frist von bis zu drei Monaten. Ab Eingang der vollständigen Unterlagen hat das BfArM drei Monate Zeit für die Entscheidung; in begründeten Einzelfällen kann es die Frist um bis zu weitere drei Monate verlängern.

7. Nach der Aufnahme: Preis, Erprobung, Erfolgsmessung

Im ersten Jahr gilt der Preis, den der Hersteller selbst festlegt (begrenzt durch gegebenenfalls vereinbarte Höchstbeträge). Ab dem 13. Monat gilt der mit dem GKV-Spitzenverband verhandelte Vergütungsbetrag. Bei vorläufiger Aufnahme läuft parallel die Studie. Für dauerhaft gelistete DiGA mit nachgewiesenem medizinischem Nutzen kommen ab dem 01.07.2026 Berichtspflichten zur Nutzung hinzu (siehe unten).

Dauerhaft oder vorläufig aufnehmen lassen?

Die wichtigste strategische Entscheidung ist, ob der Nachweis des Versorgungseffekts schon vor dem Antrag vorliegt.

Zwei Details werden oft übersehen: Die Erprobung beginnt mit der Bekanntgabe des Bescheids – ein späterer Start lässt sich nicht vereinbaren. Wer weiß, dass die Studie noch nicht startbereit ist, stellt den Antrag besser später. Außerdem trägt der Hersteller die Studienkosten selbst, und für vorläufig gelistete DiGA kann ein niedrigerer Höchstpreis gelten als für dauerhaft aufgenommene.

Die Studie muss nach § 10 Abs. 5 DiGAV grundsätzlich in Deutschland durchgeführt werden. Studien aus anderen Ländern erkennt das BfArM nur im Einzelfall an, wenn Patientengruppe und Versorgungssituation nachweislich vergleichbar sind.

Anforderungen, die die Entwicklung prägen

Ein Teil der DiGAV-Anforderungen ist Dokumentation. Ein anderer Teil entscheidet direkt über Architektur, Hosting und Oberfläche – und genau diese Punkte sollten vor der ersten Zeile Code feststehen.

Datenschutz und Serverstandort

Gesundheitsdaten einer DiGA dürfen nur in Deutschland, der EU, dem EWR, der Schweiz oder in Staaten mit Angemessenheitsbeschluss nach Art. 45 DSGVO verarbeitet werden. Standardvertragsklauseln oder Binding Corporate Rules allein reichen – anders als bei vielen anderen Apps – nicht aus (§ 4 Abs. 3 DiGAV). US-Dienstleister kommen nur infrage, wenn sie dem EU-US-Datenschutzrahmen beigetreten sind, der seit dem 10.07.2023 gilt. Praktisch heißt das: Backend, Datenbank, Analyse- und Absturzberichtsdienste müssen bewusst ausgewählt werden. Ein eigenes, in der EU betriebenes Backend ist oft die einfachere Lösung als ein Bündel einzelner Cloud-Dienste. Mehr dazu in unserem Beitrag zur Backend-Entwicklung.

Das Gesetz sieht außerdem ein Datenschutz-Zertifikat nach Art. 42 DSGVO vor (§ 139e Abs. 11 SGB V). Laut Leitfaden gibt es dafür aber noch keine akkreditierten Zertifizierungsstellen; das BfArM will die Vorlage erst mit ausreichendem Vorlauf einfordern. Bis dahin gelten die Anforderungen aus § 4 und Anlage 1 DiGAV.

Datensicherheit

Die Technische Richtlinie BSI TR-03161 trägt den Titel „Anforderungen an Anwendungen im Gesundheitswesen“; geprüft wird bei einer der vom BSI gelisteten prüfberechtigten Stellen. Wichtig für die Planung: Für die Aufrechterhaltung des Zertifikats ist der Hersteller selbst verantwortlich und muss ein neues Zertifikat dem BfArM unaufgefordert vorlegen. Sicherheit ist bei einer DiGA also ein laufender Prozess, kein einmaliger Meilenstein.

Interoperabilität

Patienten müssen ihre Daten in einem interoperablen Format exportieren können, und seit dem 01.01.2024 gehört der Export in die elektronische Patientenakte (ePA) dazu. Ebenfalls seit diesem Datum müssen sich gesetzlich Versicherte über die sichere digitale Identität nach § 291 SGB V anmelden können. Beides betrifft das Datenmodell und den Anmeldeprozess.

Nutzerfreundlichkeit und Barrierefreiheit

Grundsätzlich gelten die Gestaltungsrichtlinien der jeweiligen Plattform. Die DiGA muss Bedienhilfen für Einschränkungen beim Sehen, Hören und in der Motorik bieten – entweder eigene oder die der Plattform, die sie dann aktiv unterstützen muss. Nutzertests mit Fokusgruppen sollen Menschen mit unterschiedlicher digitaler Vorerfahrung einschließen.

Keine Werbung

DiGA müssen frei von Werbung sein (§ 5 Abs. 4 DiGAV) – das gilt für Fremd- und Eigenwerbung. Das eigene Logo ist erlaubt, ebenso ein sachlicher Hinweis auf kostenpflichtige Erweiterungen, aber kein Anpreisen. Was für die Werbung außerhalb der App gilt, beschreiben wir in Gesundheits-App vermarkten.

Neu seit 2026: Anwendungsbegleitende Erfolgsmessung

Hersteller dauerhaft gelisteter DiGA, die einen medizinischen Nutzen nachgewiesen haben, müssen Nutzungsdaten erheben und halbjährlich an das BfArM übermitteln, das die Ergebnisse im Verzeichnis veröffentlicht. Laut Leitfaden (Stand 10.12.2025, vorbehaltlich der noch ausstehenden 2. Änderungsverordnung zur DiGAV) sind die Nutzungsdaten für Patienten mit Nutzungsbeginn ab dem 01.07.2026 zu erheben; die erste Übermittlung ist zum 15.04.2027 vorgesehen. Ab dem 01.07.2027 kommen Angaben zur Patientenzufriedenheit hinzu. Parallel müssen seit dem 01.01.2026 mindestens 20 Prozent des Vergütungsbetrags erfolgsabhängig sein (§ 134 SGB V); wie die Erfolgsmessung dort einfließt, legen die Vertragspartner noch fest. Wer heute eine DiGA plant, sollte Erhebung und Auswertung dieser Daten gleich mit einplanen, statt sie nachzurüsten.

Wie lange dauert es bis zur App auf Rezept?

Eine seriöse Gesamtdauer lässt sich pauschal nicht angeben, weil die größten Blöcke – Entwicklung, Konformitätsbewertung, BSI-Prüfung und Studie – vom Produkt abhängen. Fest stehen nur die Fristen des Verfahrens:

Für die Planung bedeutet das: Wer ohne fertige Studie startet, kommt über die vorläufige Aufnahme schneller in die Erstattung, trägt aber das Risiko einer Streichung nach der Erprobung. Wer zuerst die Studie durchführt, verschiebt den Markteintritt, hat danach aber eine stabile Listung. Wie lange die reine Softwareentwicklung typischerweise dauert, zeigt unser Beitrag zu Phasen und Dauer der App-Entwicklung – bei einer DiGA kommen Dokumentation und Prüfungen darüber hinaus hinzu.

Welche Kosten auf Sie zukommen

Belegbar sind die Gebühren des BfArM. Der Leitfaden nennt folgende Spannen (Antragsgebühren nach DiGAV, Stand 20.12.2022; Beratung nach § 27 DiGAV):

Die Gebühren fallen auch an, wenn ein Antrag abgelehnt wird. In der Summe sind sie aber der kleinste Posten. Größer sind Entwicklung und Dokumentation, die Benannte Stelle (ab Klasse IIa), die BSI-Prüfstelle, das ISMS, die Studie und der laufende Betrieb mit Sicherheitsupdates, Re-Zertifizierung und Erfolgsmessung. Unsere üblichen Preisspannen – etwa 7.000 bis 13.000 € für eine Business-App – gelten für Apps ohne Medizinprodukt-Anforderungen und sind auf eine DiGA nicht übertragbar. Wer zunächst einen Prototyp zur Validierung der Idee bauen möchte, kann den App-Kosten-Rechner als Orientierung nutzen.

Häufige Fehler bei der DiGA-Planung

• Cloud-Dienste ohne Prüfung des Standorts: Ein Analyse- oder Push-Dienst mit Verarbeitung außerhalb der zulässigen Länder kann die Zulassung blockieren.
• BSI-Prüfung und Studie als Schlusspunkt behandeln: Das Zertifikat ist Voraussetzung für einen vollständigen Antrag, und die Erprobung beginnt mit dem Bescheid – beides gehört an den Anfang der Planung.
• Rollen nicht klären: Der Antrag kommt vom Hersteller oder einer bevollmächtigten Person. Wer rechtlich Hersteller ist, trägt die Verantwortung für Konformität, Zertifikate und Studie – das lässt sich nicht an einen Entwicklungsdienstleister abgeben.

Was ein Entwicklungspartner übernehmen kann

Ein Softwarepartner baut die Anwendung, das Backend und die Schnittstellen und liefert die technische Dokumentation zu, die Hersteller, Benannte Stelle und Prüfstelle brauchen. Medizinische Zweckbestimmung, Qualitätsmanagement, klinische Bewertung und Studie liegen beim Hersteller und seinen Regulatorik- und Studienpartnern. Ein gutes Projekt bringt diese Rollen früh zusammen, damit Anforderungen wie Datenstandort, ePA-Export oder Bedienhilfen nicht erst in der Prüfung auffallen.

Wir bei SB-Techworks in Regensburg entwickeln Gesundheits-Apps mit Flutter für iOS und Android aus einer Codebasis, dazu Backends mit Betrieb in der EU. Eine eigene DiGA-Zulassung haben wir nicht – unsere Rolle ist die Softwareentwicklung im Team mit Ihren Regulatorik-Partnern, mit direktem Draht zur Entwicklung statt Vertriebs- und Projektmanagement-Ebenen. Mehr dazu auf unserer Seite zur Entwicklung von Gesundheits-Apps. Wenn Sie ein DiGA-Vorhaben besprechen möchten, schreiben Sie uns über das Kontaktformular; wir antworten werktags innerhalb von 24 Stunden.