Die Frage „Wer prüft BfArM Unterlagen?“ klingt zunächst nach einer einfachen Zuständigkeit. In der Praxis sind mehrere Stellen beteiligt, allerdings mit klar voneinander getrennten Rollen. Wer diese Rollen früh versteht, vermeidet doppelte Dokumentation, falsche Erwartungen und einen Go-Live, der an einem fehlenden Nachweis hängen bleibt.
Für Hersteller von Digitalen Gesundheitsanwendungen ist das besonders relevant. Eine DiGA muss nicht nur sinnvoll gestaltet und technisch stabil sein. Sie muss als Medizinprodukt korrekt in Verkehr gebracht werden, sensible Gesundheitsdaten schützen und ihren Nutzen für die Versorgung nachvollziehbar belegen. Das BfArM-Verfahren verbindet diese Ebenen, ersetzt aber keine Vorarbeit.
Wer prüft BfArM-Unterlagen im DiGA-Verfahren?
Den Antrag auf Aufnahme in das DiGA-Verzeichnis prüft das Bundesinstitut für Arzneimittel und Medizinprodukte, kurz BfArM. Dort wird bewertet, ob eine Anwendung die gesetzlichen Anforderungen für eine DiGA erfüllt. Dazu gehören Sicherheit und Funktionstauglichkeit, Datenschutz, Informationssicherheit, Qualität sowie der positive Versorgungseffekt.
Das bedeutet jedoch nicht, dass das BfArM jedes Dokument isoliert oder jede Zeile des Quellcodes prüft. Die Behörde bewertet die eingereichten Nachweise als Gesamtbild: Passen technische Architektur, Risikoanalyse, Datenschutzkonzept, Qualitätsmanagement, Nutzungslogik und klinische Evidenz zusammen? Sind Aussagen belastbar belegt? Und kann die Anwendung unter realistischen Bedingungen sicher betrieben werden?
Je nach Prüffeld werden weitere Bundesstellen eingebunden. Beim Datenschutz erfolgt die Bewertung im vorgesehenen Abstimmungsverfahren mit der oder dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit. Bei der Informationssicherheit kann das Bundesamt für Sicherheit in der Informationstechnik beteiligt sein. Für Hersteller ist entscheidend: Diese Abstimmungen sind Teil des behördlichen Verfahrens. Sie ersetzen nicht die eigene technische und organisatorische Vorbereitung.
Die Rollen vor der BfArM-Prüfung
Bevor ein Antrag beim BfArM sinnvoll gestellt werden kann, müssen wesentliche Voraussetzungen bereits erfüllt sein. Die häufigste Verwechslung betrifft die CE-Kennzeichnung. Das BfArM erteilt keine CE-Kennzeichnung und übernimmt nicht die Rolle einer Benannten Stelle.
Die CE-Konformität wird im Rahmen der europäischen Medizinprodukteverordnung, der MDR, hergestellt. Abhängig von Risikoklasse und Produktkonstellation ist dabei eine Benannte Stelle eingebunden. Sie prüft im Konformitätsbewertungsverfahren unter anderem das Qualitätsmanagement, die technische Dokumentation und die Konformität mit den anwendbaren regulatorischen Anforderungen. Bei bestimmten Medizinprodukten der Klasse I gelten andere Wege als bei Produkten der Klasse IIa. Welche Route einschlägig ist, hängt vom konkreten Produkt und seiner Zweckbestimmung ab.
Das BfArM setzt für das DiGA-Verfahren auf diesem Fundament auf. Vereinfacht gesagt: Die CE-Kennzeichnung beantwortet, ob das Medizinprodukt rechtmäßig in Verkehr gebracht werden darf. Die DiGA-Prüfung beantwortet zusätzlich, ob es als erstattungsfähige digitale Gesundheitsanwendung in das Verzeichnis aufgenommen werden kann.
Auch Datenschutzbeauftragte, Informationssicherheitsverantwortliche, klinische Partner, externe Auditoren und spezialisierte Rechts- oder Regulatory-Berater können an der Vorbereitung mitwirken. Sie sind aber nicht „die Prüfstelle“. Ihre Aufgabe ist es, Lücken vor der Einreichung sichtbar zu machen und belastbare Nachweise aufzubauen.
Was bewertet das BfArM konkret?
Die Unterlagen müssen zeigen, dass die Anwendung nicht nur im Demo-Modus überzeugt, sondern dauerhaft und kontrolliert betrieben werden kann. Gerade bei gewachsenen Produktlandschaften wird das schnell anspruchsvoll: Die App kommuniziert mit einem Backend, dieses nutzt externe Dienste, Analysewerkzeuge, Identitätsanbieter oder Schnittstellen zu Versorgungspartnern. Jede dieser Verbindungen kann Auswirkungen auf Datenschutz, Sicherheit und Betrieb haben.
Bei Sicherheit und Funktionstauglichkeit geht es darum, ob die DiGA entsprechend ihrer medizinischen Zweckbestimmung funktioniert und Risiken angemessen beherrscht werden. Dazu gehören beispielsweise Risikomanagement, klinische Bewertung, Gebrauchstauglichkeit und Prozesse für Vorkommnisse oder Änderungen am Produkt.
Der Datenschutz betrachtet nicht nur eine Datenschutzerklärung. Entscheidend sind Datenflüsse, Rechtsgrundlagen, Rollen- und Berechtigungskonzepte, Löschfristen, Auftragsverarbeitungen und die Frage, ob Daten tatsächlich nur für zulässige Zwecke verarbeitet werden. Eine sauber formulierte Erklärung hilft wenig, wenn Testsysteme mit Echtdaten laufen oder Admin-Zugänge nicht nachvollziehbar eingeschränkt sind.
Informationssicherheit umfasst unter anderem Zugriffsschutz, Verschlüsselung, Protokollierung, Schwachstellenmanagement, Backup- und Wiederanlaufprozesse sowie den Umgang mit Sicherheitsvorfällen. Hier zeigt sich oft, ob ein Produkt als langfristig betreibbares System geplant wurde oder ob es nur bis zum ersten Launch gedacht war. Ein Sicherheitskonzept muss zum tatsächlichen Hosting, zu den eingesetzten Komponenten und zu den betrieblichen Verantwortlichkeiten passen.
Für die Aufnahme in das Verzeichnis braucht es außerdem einen positiven Versorgungseffekt. Dieser kann ein medizinischer Nutzen oder eine patientenrelevante Struktur- und Verfahrensverbesserung sein. Welche Evidenz erforderlich und angemessen ist, hängt von Zweckbestimmung, Zielgruppe, Interventionslogik und beantragtem Status ab. Bei einer dauerhaften Aufnahme muss der Effekt nachgewiesen sein. Für eine vorläufige Aufnahme kann ein plausibles Evaluationskonzept mit laufender Erprobung eine Option sein. Das ist kein leichterer Weg, sondern ein eng getakteter Weg mit klaren Nachweispflichten.
Unterlagen sind kein Schreibprojekt
Viele Teams behandeln die BfArM-Unterlagen zu spät als Dokumentationsaufgabe. Dann werden Architekturentscheidungen im Nachhinein erklärt, Datenflüsse aus verschiedenen Excel-Dateien zusammengesucht und Sicherheitsmaßnahmen beschrieben, die im Alltag niemand getestet hat. Das kostet Zeit und schafft Widersprüche.
Besser ist es, die regulatorischen Anforderungen in die Produktentwicklung einzubauen. Die Zweckbestimmung sollte die Produktfunktionen präzise begrenzen. Anforderungen müssen auf Risiken, Tests und technische Umsetzung zurückführbar sein. Änderungen an App, Backend oder Infrastruktur brauchen einen geregelten Prozess, damit nach einem Update nachvollziehbar bleibt, was sich verändert hat und ob neue Risiken entstehen.
Vor der Einreichung lohnt sich eine gemeinsame Prüfrunde von Produkt, Entwicklung, Datenschutz, Informationssicherheit und Regulatory Affairs. Nicht als formaler Termin kurz vor Abgabe, sondern anhand konkreter Fragen: Stimmen die Datenflussgrafik und die reale Infrastruktur überein? Sind Subunternehmer und Hosting-Dienste vollständig erfasst? Lassen sich die beschriebenen Sicherheitsmaßnahmen im Betrieb nachweisen? Ist die Evidenzstudie genau auf den beantragten Versorgungseffekt ausgerichtet?
Eine praxistaugliche Einreichung erkennt man meist an vier Punkten:
- Die technische Dokumentation beschreibt das tatsächlich ausgelieferte Produkt, nicht ein Wunschbild.
- Datenschutz- und Sicherheitskonzepte sind mit Architektur, Verträgen und Betriebsprozessen abgestimmt.
- Verantwortlichkeiten für Releases, Vorfälle, Support und Änderungen sind klar benannt.
- Studienplanung, Endpunkte und Produktlogik zahlen auf denselben Versorgungseffekt ein.
Typische Reibungspunkte in der Prüfung
Ein häufiger Stolperstein sind widersprüchliche Angaben. Die Zweckbestimmung spricht von einer therapeutischen Unterstützung, die Evidenzstudie untersucht aber lediglich Zufriedenheit. Oder das Sicherheitskonzept nennt eine Verschlüsselung, ohne zu erklären, wo Schlüssel verwaltet werden und wer Zugriff erhält. Solche Lücken wirken selten wie einzelne Flüchtigkeitsfehler. Sie werfen Fragen zur Reife des gesamten Qualitäts- und Betriebsmodells auf.
Auch Drittanbieter verdienen Aufmerksamkeit. Push-Dienste, Fehleranalyse, Videofunktionen, Cloud-Hosting oder KI-Komponenten können technisch sinnvoll sein. Sie müssen jedoch in Datenflüssen, Verträgen, Risikoanalysen und Sicherheitsprozessen konsistent auftauchen. Wer hier mit Insellösungen arbeitet, produziert schnell Doppelpflege und unklare Verantwortlichkeiten.
Ein weiterer Punkt ist die Wartung nach der Listung. Eine DiGA bleibt kein abgeschlossenes Projekt. Betriebssystem-Updates, Sicherheitslücken, neue Bibliotheken und geänderte Backend-Komponenten verlangen einen kontrollierten Änderungsprozess. Das BfArM-Verfahren endet daher nicht gedanklich mit der Einreichung. Hersteller müssen zeigen können, dass sie ihr Produkt auch nach dem Go-Live sicher weiterentwickeln.
So wird aus dem Antrag ein steuerbarer Prozess
Für mittelständische Anbieter ist ein klarer Projektzuschnitt oft wirksamer als ein großer Dokumentenendspurt. Zu Beginn sollten Produktgrenzen, Zweckbestimmung, Risikoklasse, Zielarchitektur und Evidenzstrategie gemeinsam festgelegt werden. Danach lassen sich regulatorische Anforderungen in Arbeitspakete übersetzen: Was muss entwickelt, getestet, dokumentiert und im Betrieb organisiert werden?
Inter Medien Networks begleitet DiGA-Projekte dort, wo sich UX, App-Entwicklung, Backend, Datenschutz und langfristiger Betrieb treffen. Der Vorteil eines integrierten Vorgehens liegt nicht in mehr Dokumenten, sondern in weniger Brüchen zwischen Konzept, Entwicklung und Realität. Wenn Datenflüsse, Rollen und Deployment-Prozesse von Anfang an mitgedacht werden, bleibt die Dokumentation nachvollziehbar und der Go-Live planbar.
Wer BfArM-Unterlagen vorbereitet, sollte die Behörde nicht als letzte Hürde behandeln. Sinnvoller ist ein Produktprozess, der jederzeit erklären kann, was die Anwendung tut, welche Daten sie verarbeitet, wie Risiken beherrscht werden und warum sie Patientinnen und Patienten konkret hilft. Dann wird aus regulatorischer Pflicht ein belastbares Fundament für einen sicheren Betrieb.