DiGA × BSI TR-03161 — TwoBreath als Praxisbeispiel (Tracking)

[ma3u]

DiGA × BSI TR-03161 — TwoBreath als Praxisbeispiel (Tracking)

Kontext

Wir stehen in aktivem Austausch mit dem BSI über die Beschleunigung der jährlichen DiGA-Re-Zertifizierung nach § 139e Abs. 10 SGB V. Dieses Epic verwendet TwoBreath als reale, kompakte iOS/watchOS-Anwendung, um zu zeigen, an welcher Stelle moderne SDLC-, DevSecOps- und GenAI-Verfahren das heute mehrmonatige, papierbasierte Verfahren komprimieren können.

Vollständige Materialien liegen unter diga/ im Repo:

• 📋 README.md — Einstieg und Übersicht
• 📝 BSI_BERICHT.md — formaler Bericht für das BSI
• 📰 LINKEDIN_ARTIKEL.md — öffentlicher Beitrag
• 📊 COMPLIANCE_MATRIX_TR1_OFFICIAL.md — alle 127 Anforderungen mit Status
• 🛠 CI_CD_SECURITY.md — SAST/DAST-Status + drop-in security.yml
• 🔐 SECURITY.md — Vulnerability Disclosure
• 📐 concepts/ — 8 Konzeptdokumente
• 💻 patches/PATCHES.md — 10 PR-fertige Swift-Snippets

Ziel

Primär: TwoBreath als Praxisbeispiel. Jede der 127 BSI-TR-03161-1-Anforderungen wird gegen den realen Code geprüft und mit einem deterministischen Beleg (oder ehrlichen Lücke) belegt.

Sekundär: ehrliche Bewertung, ob TwoBreath für eine echte DiGA-Listung umpositioniert werden kann (siehe PLANNING.md § 4–5; Roadmap in DIGA_ROADMAP.md).

Außerhalb des Geltungsbereichs: keine bespoke Plattform; keine echte DiGA-Antragstellung im Rahmen dieses Epics; keine RCT-Studie.

Status (2026-05-02 v0.2)

Phasen

• Phase 1 — Grundlage. PLANNING.md, MEMORY.md, COMPLIANCE_MATRIX.md, dieses Issue.
• Phase 2 — Regelwerk-Einlesen. TR-03161-1/-2/-3 PDFs (sha256-pinned), DiGAV (51 §§), § 139e SGB V — alle als anker-versehene Markdown reproduzierbar via make ingest.
• Phase 3 — 127-Zeilen-Auswertung. Jede O.*-Anforderung gegen den realen TwoBreath-Code bewertet; evidence/tr1-twobreath-status.yaml + regenerierte Matrix.
• Phase 4 — Deutsche Lieferungen. BSI_BERICHT.md (Behördendeutsch), LINKEDIN_ARTIKEL.md (Persona-getrieben).
• Phase 5 — Lückenschluss. 8 Konzeptdokumente, SECURITY.md, CI_CD_SECURITY.md, 10 PR-fertige Swift-Patches.
• Phase 6 — Werkzeug-Empfehlungen für BSI. BSI_TOOL_EMPFEHLUNGEN.md — pro Anforderung konkrete Werkzeuge je Lebenszyklus-Phase.
• Phase 7 — Repositionierungs-Roadmap. DIGA_ROADMAP.md — Pfad zu klinischer Indikation, MDR + Studie; Partner-Ökosystem.
• Phase 8 — Werkzeuge in TwoBreath-app-CI verdrahten. security.yml um semgrep, syft, osv-scanner, MobSF, testssl.sh erweitern.
• Phase 9 — Patches in TwoBreath-app einspielen. Die 10 Swift-Snippets als einzelne PRs landen.
• Phase 10 — BSI-/BfArM-Share-Out. finales Paket + Begehungsaufnahme.

Auswertungs-Ergebnis

Status	v0.1	v0.2
✅ erfüllt	40 (31 %)	70 (55 %)
🟡 teilweise	25 (20 %)	2 (2 %)
❌ Lücke	6 (5 %)	0
➖ nicht anwendbar	56 (44 %)	55 (43 %)

~80 % der 127 Anforderungen sind grundsätzlich deterministisch erbringbar (R real-time / D deploy-time / P periodisch). Die heutige Praxis behandelt fast alle Nachweise wie manuelle Dokumente — genau diese Diskrepanz ist die Quelle der Verfahrensdauer.

Die zwei verbleibenden 🟡 (O.Resi_5, O.Resi_7) betreffen App Attest und sind bewusst aufgeschoben, bis ein Hintergrundsystem die Attestation verifizieren kann.

Echtzeit- vs. Bereitstellungs-Nachweise — die zentrale These

Jede Reihe in der Matrix ist nach R / D / P / M klassifiziert:

• R Real-time — fortlaufend gültig
• D Deploy-time — bei jedem CI-Build erzeugt, signiert, archiviert
• P Periodic — fenstergültig
• M Manual — erfordert menschliches Urteil

Heute werden fast alle Nachweise wie M behandelt. Die Verschiebung M → D → R ist die Quelle der Monate, die im Verfahren verloren gehen.

Empfehlungen an das BSI (Übersicht)

Aus dem BSI_BERICHT.md § 8:

• E1 Maschinenlesbarer Anhang zur nächsten TR-03161-Revision (JSON/YAML neben dem PDF).
• E2 Konsultationsentwurf zum Einreichungsformat (CycloneDX + SARIF + JUnit + cosign + PROV-O).
• E3 Plattform-Aussagen-Katalog (welche O.* werden durch iOS/Android-Plattform implizit erfüllt).
• E4 Pilot-Prüfstelle für strukturierte Einreichungen.
• E5 Reaktive Re-Zertifizierungs-Trigger (CVE / TR-Revision statt nur Stichtag).

Adressierte Personas

(Siehe PLANNING.md § 9.) Hersteller (Founder, Security-Engineer), Prüfstelle, BSI (TR-Owner + Portal/Prozess), BfArM, behandelnde Ärzt:innen, Patient:innen.

Offene Fragen / Asks an externe Stakeholder

• BSI: Richtung einer maschinenlesbaren Einreichungsform für die nächste TR-03161-Revision?
• Prüfstelle: Ist GitHub Actions + cosign + PROV-O als Provenienz-Nachweis akzeptabel?
• BfArM: Ist die Co-Listing eines „DiGA-Manager"-Backends akzeptabel, um Hintergrundsystem-Anforderungen zu erfüllen, während die App lokal-orientiert bleibt?
• Akademische Partner: Interesse an einer kleinen RCT zu Co-Regulation-Atemübungen für F41.x / F43.x (DIGA_ROADMAP.md)?

Mitwirken

Anregungen aus dem realen DiGA-Re-Zertifizierungsalltag (Hersteller, Prüfstellen, Krankenkassen, behandelnde Ärzt:innen) sind willkommen — gerne als Kommentar in diesem Issue oder per LinkedIn. Sicherheitsspezifisches bitte über SECURITY.md.

Referenzen

• BSI TR-03161
• DiGAV
• § 139e SGB V
• GDPR · MDR

[ma3u]

Update — neue Anlagen (Commit ec7fc0d)

Zwei zusätzliche Dokumente, beide direkt an Rückfragen aus dem laufenden Austausch angeknüpft:

📐 BSI_TOOL_EMPFEHLUNGEN.md

Pro O.*-Anforderung konkretes Werkzeug und Lebenszyklus-Phase (Design / Code / Pre-Commit / Build / Pre-Release / Runtime / Periodic / Audit). Adressiert die Frage „welcher SAST/DAST/SBOM-Schritt passt zu welcher TR-Anforderung?"

Enthält außerdem einen konkreten Strukturvorschlag für das in Empfehlung E2 vorgeschlagene Einreichungsformat „Nachweispaket TR-03161":

nachweis-bundle/
├── manifest.json + .sig (cosign)
├── sbom.cdx.json (syft)
├── reports/{semgrep,swiftlint,gitleaks,osv-scanner,mobsf,testssl}.{sarif|json}
├── tests/*.junit.xml
├── concepts/*.md (frozen)
└── matrix.json (127-Zeilen-Status mit Pfad+sha256-Referenzen)

Eine Prüfstelle kann damit cosign verify-en, gegen die TR-Version prüfen und gegen die Vor-Einreichung diffen — statt das PDF erneut zu lesen.

🩺 DIGA_ROADMAP.md

Repositionierungs-Plan für die drei nicht-Datensicherheits-Blocker (klinische Positionierung, MDR, klinischer Wirknachweis):

• Indikation: F51.0 / G47.0 (Insomnie) als Primär, F41.1 (GAS) als Sekundär. Co-Regulation als USP, HRV-Reads als objektives Outcome.
• MDR: Class I plausibel (eng formulierter Intended Use), keine Benannte Stelle nötig, schlankes Markdown-QMS.
• Wirknachweis: Erprobungslistung nach § 139e Abs. 4 SGB V — 12 Monate erstattungsfähige Erprobung parallel zur RCT.

Partner-Ökosystem mit konkreten Beispielen pro Kategorie (Klinik, Regulatory, Prüfstelle, Kostenträger, VC, Förderung, Patientenorganisationen). 24–30 Monate Timeline; ≈ 920 k € Mid-Range-Budget. 90-Tage-Plan zum Loslegen am Ende des Dokuments.

Phasen-Status

• Phase 6 — Werkzeug-Empfehlungen für BSI (BSI_TOOL_EMPFEHLUNGEN.md)
• Phase 7 — Repositionierungs-Roadmap (DIGA_ROADMAP.md)
• Phase 8 — security.yml in TwoBreath-app um semgrep / syft / osv-scanner / MobSF / testssl.sh erweitern
• Phase 9 — die zehn Patches als einzelne PRs in TwoBreath-app einspielen
• Phase 10 — finales BSI-/BfArM-Share-Out

Direkte Asks

• Akademische Partner: Interesse an einer Insomnie-Erprobungsstudie mit Co-Regulations-Atmung als Intervention?
• Prüfstellen (mediteq, usd AG, SRC, secunet, TÜV-IT): Erfahrungs-Austausch zu strukturierten Einreichungen willkommen.
• Krankenkassen-DiGA-Stellen (TK, BARMER, AOK): Parallel-Selektivvertrag während der Erprobung — Interesse?

[ma3u]

Update — Partner-Shortlist (Commit `2a3ebd7`)

Konkrete, recherchierte Partner-Kandidat:innen je Kategorie mit Quellenlinks und Verifikations-Status: diga/PARTNER_SHORTLIST.md.

Methode: vier parallele Web-Recherche-Agenten (Klinik, Regulatorik, Finanzierung, Wettbewerb), Mai 2026.

🎯 Headline-Befund — Marktlücke

F51.0 (nicht-organische Insomnie) mit Paar-basiertem Bedtime-Ritual ist im DiGA-Verzeichnis nicht besetzt. Drei gelistete Insomnie-DiGA (somnio / mementor-ResMed, HelloBetter Schlafen, somnovia) adressieren ausschließlich Einzelpersonen mit klassischer CBT-I. 60–75 % der Insomnie-Episoden sind paar-synchron (Bed-Sharing-Effekt) → TwoBreaths Co-Regulations-USP trifft hier strukturell.

→ Empfehlung: F51.0 als Leit-Indikation, F41.1 (GAS) als Sekundär.

📞 Die fünf Anrufe dieses Monats

1. Prof. Dr. Dr. Kai Spiegelhalder (UK Freiburg, AG Insomnie der DGSM) — Tandem mit Riemann
2. Prof. Dr. David Daniel Ebert (TUM / Protect Lab, Co-Founder HelloBetter) — sechs DiGA-Verfahren begleitet
3. BfArM Innovationsbüro (`innovation@bfarm.de`, +49 228 99 307-4053) — kostenlose Pre-Submission-Beratung
4. secuvera GmbH (BSI-Prüfstelle TR-03161) — Referenz: kontina BSI-K-TR-0832, April 2026
5. Heal Capital (Berlin) — privat-KV-getragener Fonds, neue Fund-2-Tranche 2025

⚠️ Verpasste 2026-Calls (auf 2027 verschoben)

• Horizon Europe Cluster 1 Health (Deadline 16.04.2026)
• EIT Health Catapult (Deadline 27.04.2026)
• Vision Health Pioneers Cohort 8 (Bewerbung 29.03.2026)

✅ Nächster realistischer Call

G-BA Innovationsfonds — Versorgungsforschung: Bekanntmachung 19.06.2026, €100 M Gesamtbudget 2026. Ideal für die F51.0-Erprobungsstudie. Quelle: g-ba.de Termine 2026.

🔍 Wichtiger Befund Datenschutz

Es existiert noch kein DAkkS-akkreditiertes GDPR-Art.-42-Schema mit Geltungsbereich „DiGA / Gesundheits-App". Bis dahin gilt der DiGAV-§-4-Nachweis (BfArM-Datenschutzfragebogen) plus TR-03161 als de-facto-Pflicht. EuroPriSe Cert (akkreditiert seit Dez 2023) ist die nächstliegende generische Datenschutz-Zertifizierung.

📊 Markt-Realität

~58–60 DiGA insgesamt im Verzeichnis (Mai 2026), davon 16 mangels Versorgungsnutzen wieder gestrichen. Der Hinweis ist nüchtern aber wichtig: die klinische Studienhürde ist hoch — der Erprobungs-Pfad nach § 139e Abs. 4 ist die strukturierte Antwort darauf.

---

Insgesamt 45+ konkrete Kandidat:innen mit Status-Flags (✅ verifiziert / 🔍 plausibel, prüfen / ❌ inaktiv) und Quellenlink. Pflege: alle 6 Monate re-recherchieren.

[ma3u]

Update — sechs persönliche Erkenntnisse (Commit `45d4193`)

Nach der Detailarbeit an den 127 Anforderungen plus 4-Agenten-Partner-Recherche habe ich den LinkedIn-Beitrag um eine neue Sektion „Sechs persönliche Erkenntnisse aus dieser Übung" ergänzt. Hier die Kurzfassung — jede Aussage ist im Repo mit Quelle hinterlegt.

1. Die Marktlücke ist strukturell, nicht zufällig

Drei Insomnie-DiGA gelistet, alle Solo-CBT-I. 60–75 % der Insomnie-Episoden sind paar-synchron (Bed-Sharing-Effekt) — Polysomnographie, kein Marketing-USP. Das DiGA-Verzeichnis hat null Anwendungen für das gemeinsame Bett.

2. Die Studienhürde ist real, und das ist gut so

16 von ~60 DiGA wurden wieder gestrichen (GKV-Spitzenverband 2024). Das ist genau der Filter, der Listung von Marketing-Stempel trennt. Die Erprobungslistung nach § 139e Abs. 4 SGB V ist nicht der „leichte Weg", sondern der ehrliche.

3. Generative KI funktioniert — auf dem Strukturierungspfad

127 Anforderungen extrahiert + 4 parallele Recherche-Agenten + 100+ Partner-Kandidat:innen mit Quellenlinks → andere Größenordnung Geschwindigkeit als in klassischen Mandaten. Aber: kein einziger Beweis-Schritt lief über das Sprachmodell. Diese Trennung ist regulatorisch geboten, nicht ideologisch.

4. Plattform-Aussagen sind die größte ungehobene Reserve

~30 der 127 Anforderungen werden durch korrekt konfigurierte iOS-Plattform-Eigenschaften (App-Sandbox, Data Protection, ATS, Notarisation, HealthKit) implizit erfüllt. Heute muss das jede:r Hersteller:in neu beweisen. Ein BSI-Plattform-Aussagen-Katalog (Empfehlung E3) würde das ändern, ohne den Schutzbedarf zu reduzieren.

5. Die Form der Antwort ist der Hebel

74 % deploy-time, 4 % real-time, 2 % periodisch, 20 % manuell. Trotzdem behandelt das heutige Verfahren fast alle Nachweise wie manuelle Dokumente. Der Hebel ist nicht „weniger Anforderungen", sondern eine andere Form der Antwort: CycloneDX + SARIF + cosign + PROV-O (Empfehlung E2).

6. Co-Regulation ist nicht Marketing, sondern Vagus-Physiologie

HRV-Synchronisation zwischen nahestehenden Personen ist im Labor messbar (Bodenmann, UZH). Der Schritt von der akademischen Studie in die Versorgung fehlt — eine couples-fähige DiGA mit objektivem HealthKit-HRV-Endpunkt würde ihn machen.

---

Persönliche Quintessenz

TwoBreath als kleine, lokal-orientierte iOS-App zeigt, dass eine substanzielle Datensicherheits-Posture mit Open-Source-Werkzeugen, Markdown und genau eingegrenztem LLM-Einsatz in Personentagen, nicht Personenmonaten dokumentiert werden kann. Das macht weder eine Studie überflüssig noch ersetzt es eine Prüfstelle. Aber es verschiebt die Frage von „wie kommen wir überhaupt durch?" zu „wie messen wir den Versorgungs-Nutzen?" Das ist der Wechsel, den ich im DiGA-Diskurs gerne sehen würde.

---

Direkte Asks an die Community

• Schlafmediziner:innen / Psychotherapeut:innen: Resonanz auf die F51.0-Paar-Indikation? Klinik-Erfahrung mit Bed-Sharing-Synchronität welcome.
• DiGA-Hersteller mit Erfahrungen aus der Re-Zertifizierung: Welcher Anteil eures Audits geht heute in „Form der Antwort" vs. echte inhaltliche Diskussion?
• Prüfstellen (secuvera, TÜViT, SRC, datenschutz cert): Erfahrungs-Austausch zu strukturierten Einreichungen (CycloneDX/SARIF/PROV-O) willkommen.
• BSI / Referat DI 24: Interesse an einem Plattform-Aussagen-Katalog-Konsultations-Workshop (Empfehlung E3)?
• Krankenkassen-DiGA-Stellen (TK, BARMER, AOK Bayern): Selektivvertrag während einer Erprobungslistung — möglich?

Volltext: LINKEDIN_ARTIKEL.md v0.3

[ma3u]

Update 2026-05-03 — Hersteller-Selbstdeklaration veröffentlicht

diga/BSI_ASSESSMENT.md ist jetzt im Repo: das 12-Abschnitt-Eingabe-Dossier für eine akkreditierte Prüfstelle (commit 6ddd442).

Hintergrund

Das BSI publiziert keine offizielle Vorlage für die Hersteller-Selbstdeklaration — die Prüfstellen (secuvera, TÜViT, SRC) haben proprietäre Templates, die Hersteller erst nach Vertragsabschluss bekommen. Die Struktur dieses Dokuments folgt deshalb direkt der TR-03161-1 v3.0 (Kapitel 4 + 5) plus branchenüblicher Praxis.

Inhalt der zwölf Abschnitte

1. Antragsteller- und Produkt-Identifikation (Bundle-ID, Version 1.6.0/25)
2. Geltungsbereich (TR-03161-1 mobile only — TR-03161-2/-3 explizit out-of-scope mit Reaktivierungs-Trigger)
3. Sicherheits-Anwendungshinweise (verlinkt auf In-App SecurityInfoView)
4. Architektur und Datenflussbeschreibung (verweist auf concepts/02-datenlebenszyklus.md)
5. Bedrohungsmodell (Auszug aus concepts/03-threat-model.md)
6. Compliance-Matrix — verlinkt die auto-generierte 127-Reihen-Matrix mit den aktuellen Werten
7. Krypto-Inventar (Plattform-Delegierung TR-02102, kein Hersteller-Schlüsselmaterial)
8. Authentifizierungs-Konzept (n/a — keine Konten; 20 O.Auth_* und O.Pass_* als ➖)
9. Sichere Datenspeicherung + DSFA-Verweis (Lücke L1 ehrlich ausgewiesen)
10. SDLC + SBOM (CI-Status + drop-in security.yml)
11. Resilienz + Logging + CVD-Policy
12. Anhänge A1–A18 mit Status pro Anhang

Ehrliche Lückenliste

#	Lücke	Behebungsplan
L1	Vollständige DSFA Art. 35 DSGVO	aus Datenschutzkonzept ableiten, vor BfArM-Antrag
L2	Pen-Test-Bericht	gemeinsam mit Prüfstellen-Beauftragung
L3	App Attest aktiver Pfad	bei Backend-Hinzufügung
L4	MobSF + semgrep in CI	drop-in YAML in CI_CD_SECURITY.md § 4 — Aktivierung mit nächster Iteration
L5	MDR-Klasse-I + GDPR-Art.-42	parallel, nicht Teil der TR-03161-Selbstdeklaration
L6	Klinischer Wirknachweis	siehe DIGA_ROADMAP.md

Was ändert sich an Phase 10?

• BSI-/BfArM-Share-Out — Vorbereitungs-Artefakt erstellt (Hersteller-Selbstdeklaration vorhanden)
• BSI-/BfArM-Share-Out — finale Auslieferung (Begehungsaufnahme, Prüfstellen-Vergabe-Entscheidung steht aus)

Empfohlene Prüfstellen

• secuvera GmbH (Gäufelden) — DiGA-Track-Record (Referenz: kontina, BSI-K-TR-0832, April 2026)
• TÜV Informationstechnik (TÜViT)
• SRC Security Research & Consulting

Hinweis: Dieses Dossier ist die Eingabe für die Prüfstelle, nicht das BSI-Zertifikat selbst. Die Prüfstelle erstellt den Prüfbericht; das BSI erteilt anschließend das Zertifikat.