DiGA/DiPA-Sicherheit: BSI TR-03161 als Eintrittskarte ins BfArM-Verzeichnis

Problem in der Praxis

Viele DiGA-/DiPA-Teams behandeln Sicherheit lange als Dokumentationsaufgabe am Projektende. Erst kurz vor der Listung fällt auf, dass der formale Nachweis fehlt - dann wird die Zertifizierung zum kritischen Pfad: Die Prüfstelle hat Vorlauf, Befunde müssen behoben werden, und ohne bestätigtes Zertifikat bleibt die Listung aus.

Verschärft wird das durch Unklarheit über Zuständigkeiten und Geltungsbereich. Teams unterschätzen, dass TR-03161 nicht nur die mobile App betrifft, sondern auch Web-Anwendung und Hintergrundsysteme. Für Bestands-DiGA ohne gültiges Zertifikat droht die Streichung; die genauen Übergangsmodalitäten sind gesondert zu prüfen.

CISO-Einordnung

TR-03161 trägt den amtlichen Titel "Anforderungen an Anwendungen im Gesundheitswesen" und deckt mehr ab als nur DiGA. Sie ist nach Anwendungstyp gegliedert: mobile Anwendungen, Web-Anwendungen und Hintergrundsysteme; die gültigen Versionsstände der Teile sind beim BSI zu verifizieren. Inhaltlich adressiert sie Vertraulichkeit, Integrität und Verfügbarkeit medizinischer Daten, abgestuft je Anwendungstyp. Der Nachweis erfolgt über eine akkreditierte Prüfstelle mit anschließender BSI-Bestätigung.

Wichtig ist die Nähe zu bekannten Rahmenwerken, ohne sie gleichzusetzen:

• ISO/IEC 27001: Ein gelebtes ISMS liefert den organisatorischen Unterbau, ersetzt die TR-Prüfung aber nicht.
• BSI C5: Bei Cloud-betriebenen Hintergrundsystemen dienen C5-Nachweise des Anbieters als Bausteine für die Backend-Absicherung.
• Cyber Resilience Act (CRA): Horizontale EU-Sicherheitsanforderungen für Produkte mit digitalen Elementen, gleiche Security-by-Design-Logik; die Überschneidung mit Gesundheits-Regelwerken ist produktspezifisch zu klären.
• MDR: Ist die Anwendung zugleich Software als Medizinprodukt, kommt das Cybersecurity-Risikomanagement der MDR (Anhang I) samt MDCG-2019-16-Guidance hinzu.

Umsetzungsperspektive

Sinnvoll ist, die Produktarchitektur früh auf die drei TR-Teile abzubilden und je Komponente festzulegen, welche Anforderungen greifen. Sicherheit gehört in den Entwicklungsprozess: Bedrohungsmodellierung, sichere Entwicklung, Test und Nachweisführung laufen parallel zur fachlichen Arbeit.

Vorhandene Steuerungsstrukturen sollten genutzt statt dupliziert werden. Ein ISMS liefert Risikoprozesse und Nachweise, C5-Nachweise des Cloud-Betreibers entlasten die Backend-Argumentation, und bei Medizinprodukte-Eigenschaft wird der Sicherheitsprozess in den Lebenszyklus nach MDR integriert. Die Prüfstelle sollte früh eingebunden werden, damit sie nicht kurz vor der Listung zum Engpass wird.

Typische Fehler

1. Sicherheit als Dokumentation am Projektende statt als Produktanforderung von Beginn an.
2. Zertifizierung als einmaliges Audit statt als wiederkehrender Nachweis über den Lebenszyklus.
3. Nur die mobile App betrachtet, Web-Anwendung und Hintergrundsysteme übersehen.
4. ISO-27001- oder C5-Nachweis fälschlich als Ersatz für die TR-03161-Prüfung angenommen.
5. Zuständigkeiten vertauscht oder der Bundesnetzagentur zugeschrieben statt BfArM und BSI.
6. Bei Bestandsprodukten den Zertifikatsbedarf zu spät erkannt und die Listung gefährdet.

Risiken und Trade-offs

Der zentrale Trade-off ist Marktzugang gegen Aufwand und Zeit: ohne Zertifikat keine Listung, ohne Listung keine Erstattung; zugleich binden Prüfung und Nachweise Ressourcen und verlängern Time-to-Market.

Ein zu enger Scope übersieht Komponenten (typischerweise Hintergrundsysteme) und führt zu Befunden; ein zu breiter erzeugt unnötigen Aufwand. Produktänderungen können erneute Nachweise auslösen, was bei agiler Entwicklung gesteuert werden muss. Ist die Anwendung zugleich Medizinprodukt, entsteht ein Doppelregime aus TR-03161 und MDR, das koordiniert werden sollte; das Verhältnis zum CRA ist im Einzelfall zu klären.

Entscheidungspunkte

• Welche TR-03161-Teile (mobil, Web, Hintergrundsysteme) gelten für welche Komponente?
• Ist die Anwendung zugleich Software als Medizinprodukt, sodass MDR-Anforderungen koordiniert werden müssen?
• Welche vorhandenen Nachweise (ISMS, C5 des Cloud-Betreibers) lassen sich wiederverwenden?
• Wann binden wir die akkreditierte Prüfstelle ein, damit der Nachweis nicht zum Engpass wird?
• Wie steuern wir bei Bestandsprodukten den Übergang, um eine Streichung zu vermeiden?

Praktische Empfehlungen

1. Behandeln Sie den TR-03161-Nachweis als Marktzugangsbedingung und planen Sie ihn ab Konzeption ein.
2. Integrieren Sie Sicherheit in den Entwicklungsprozess und erzeugen Sie Nachweise im Regelbetrieb.
3. Bilden Sie alle drei Anwendungsebenen ab und nehmen Sie Hintergrundsysteme aktiv in den Scope.
4. Nutzen Sie ISMS- und C5-Nachweise als Bausteine, nicht als Ersatz für die TR-Prüfung.
5. Klären Sie Zuständigkeiten: Listung BfArM, Bestätigung BSI, Prüfung akkreditierte Prüfstelle.
6. Verifizieren Sie Versionsstände der TR-Teile und Übergangsregeln für Bestandsprodukte an der Originalquelle.

Relevante Normreferenzen

• BSI TR-03161 "Anforderungen an Anwendungen im Gesundheitswesen": Sicherheitsanforderungen für mobile Anwendungen, Web-Anwendungen und Hintergrundsysteme (Versionsstände beim BSI verifizieren).
• § 391 SGB V "IT-Sicherheit in Krankenhäusern": Nachbarregime für Krankenhäuser, löst den früheren § 75c SGB V ab.
• VO (EU) 2017/745 (MDR) und MDCG 2019-16: Cybersecurity-Bezug bei Software als Medizinprodukt.
• ISO/IEC 27001: ISMS-Unterbau (reference-only, keine Volltexte/Kontrolllisten).
• IEC 81001-5-1: Cybersecurity-Prozess im Software-Lebenszyklus (reference-only).
• BSI C5: Absicherung Cloud-betriebener Hintergrundsysteme.
• Cyber Resilience Act (CRA): horizontale EU-Sicherheitsanforderungen; Verhältnis zum Gesundheitssektor produktspezifisch zu klären.