# DiGA / MDR — Dossier-Plan & Arbeitsteilung

**Ziel:** Schritt für Schritt die Technische Akte + QMS-Basis aufbauen, damit Rebreak
den DiGA-/MDR-Weg gehen kann. **Strategie:** Basis selbst legen (spart Berater-Geld,
macht BfArM-Beratung + Regulatory-Berater produktiv) → dann Profi validieren lassen.

> **Ehrliche Grenze:** Diese Dokumente werden hier **strukturiert + entworfen**
> (Drafting). **Validieren** muss ein Regulatory-/QM-Profi. Diese Drafts sind dein
> Vorsprung + Gesprächsgrundlage, **nicht** das fertige, zugelassene Dossier.

---

## Arbeitsteilung

| Rolle | Macht |
|---|---|
| **Claude (Drafting — der größte Teil)** | Dokumente strukturieren + Erst-Entwürfe schreiben (Zweckbestimmung, Risiko-Akte, SOUP-Liste, Architektur, Requirements, IEC-62304-Struktur, Labeling, PMS-Plan, QMS-Templates) — auf Basis des bestehenden Produkts. |
| **Du (Entscheidungen + Inputs — nur du kannst)** | medizinische Claims / genaue Zweckbestimmung freigeben · Indikations-Umfang · Firmen-/Rechtsdetails · reale Risiko-Entscheidungen · klinische Richtung (mit Uni Bremen) · parallel FAGS/Fachstellen. |
| **Regulatory-/QM-Profi (Validierung)** | Klassen-Bestätigung (I/IIa) · QMS-Konformität (ISO 13485) · klinische Methodik · finale Technische Akte. |

---

## Dokumenten-Landkarte + Status

| # | Dokument | Norm/Bezug | Wer draftet | Status |
|---|---|---|---|---|
| 01 | **Zweckbestimmung / Intended Use** ⭐ | MDR | Claude (+ deine Freigabe) | **v0 angelegt** — Freigabe §2/§3 offen `[Gründer]` |
| 02 | Klassifizierung (Rule 11 → I/IIa) | MDR Anh. VIII | Profi (BfArM-Beratung) | offen — **Kostenhebel** |
| 03 | Anforderungen / Requirements | IEC 62304 | Claude (aus App) | **v0 angelegt** (64 REQ-IDs) |
| 04 | Risikomanagement-Akte | ISO 14971 | Claude-Erstliste + du | **v0 angelegt** (Erstliste, 29 Risiken) |
| 05 | Software-Lifecycle + Architektur + SOUP | IEC 62304 | Claude (aus Code) | **v0 angelegt** (Architektur + SOUP code-belegt) |
| 05b | Software-Verifikation: Test-Nachweis | IEC 62304 §5.5–5.7 | Ahmed (Test-Agent) | **v0 angelegt** |
| 05c | Lyra-LLM-Evaluierungssuite | IEC 62304 §5.3/§5.5/§5.7 | Ahmed (Test-Agent) | **v0 angelegt** — Suite implementiert, **Live-Run-Record offen** |
| 05d | Traceability-Matrix (Anf. ↔ Risiko ↔ Code ↔ Test) | IEC 62304 §5.1.1/§5.5.2/§7.4 | Claude (aus Graph) | **v0 erweitert: Mail + Anonymität** (Lyra, Schutz/Selbstbindung, Mail-Schutz, Anonymität — Anonymitäts-GAP `username` in Response markiert) |
| 06 | Klinische Bewertung (Plan + Report) | MDR Anh. XIV | Profi + Uni Bremen | offen |
| 07 | Gebrauchsanweisung / Labeling | MDR Anh. I §23 | Claude-Entwurf | **v0 angelegt** — Warnhinweise aus Dok 04 RM-6 überführt |
| 08 | DSFA + IT-Sicherheit | BfArM-DiGA-Anf. | Claude-Struktur + Profi | **v0 angelegt** (hans-mueller) |
| 09 | Post-Market-Surveillance-Plan | MDR Art. 83–86 + Anh. III | Claude-Entwurf | **v0 angelegt** — Datenquellen real (GlitchTip/Feedback/Store/Support); Berichtsrhythmus `[Profi]` je Klasse |
| 10 | QMS (Prozesse, Doc-Control, CAPA) | ISO 13485 | Profi + Claude-Templates | **v0 angelegt** — Doc-Control/Change real (Git); CAPA/Schulung/Lieferanten/Mgmt-Review als Template |

---

## Reihenfolge (was zuerst)

1. **Zweckbestimmung v0** (Datei `01-...`) → **deine Freigabe der Claims §2/§3** (noch offen — der eine Gründer-Block, der alles Weitere entriegelt).
2. **Kostenlose BfArM-Hersteller-Beratung** mit der freigegebenen Zweckbestimmung → **Klasse I/IIa** + Lücken-Feedback. *(billigster, hebelstärkster Schritt → Dok 02)*
3. Je nach Klasse: Regulatory-Berater als Lotse holen.
4. Parallel von Claude bereits erledigt: ~~Requirements (03)~~ ✅, ~~Risiko-Erstliste (04)~~ ✅, ~~SOUP/Architektur (05)~~ ✅, ~~Test-Inventar (05b, Ahmed)~~ ✅, ~~Lyra-Eval-Suite (05c, Ahmed)~~ ✅, ~~Traceability v0 Lyra+Schutz (05d)~~ ✅. **03 + 04 sind der Traceability-Anker; 05d verdrahtet bisher nur Lyra- + Schutz-/Selbstbindungs-Strang.**
5. **Nächste Claude-Schritte (ohne Gründer-Input draftbar):** ~~(a) **Dok 07 Gebrauchsanweisung/Labeling**~~ ✅ (v0 2026-06-10); ~~(b) **Dok 09 PMS-Plan**~~ ✅ (v0 2026-06-10); ~~(c) **05d-Erweiterung** um Mail-Schutz (REQ-MAIL) + Anonymitäts-Invariante (REQ-COMM-005)~~ ✅ (v0 2026-06-10, **mit markiertem Anonymitäts-GAP**); ~~(d) **Dok 10 QMS-Templates**~~ ✅ (v0 2026-06-10). **Damit sind alle ohne Gründer-Input draftbaren Doku-Schritte abgearbeitet.** Nächster hebelstärkster Schritt bleibt: **Zweckbestimmung (Dok 01 §2/§3) freigeben → kostenlose BfArM-Hersteller-Beratung** (Schritt 2).
6. **Nächste Ahmed-/Test-Schritte:** **Live-Run-Record der Lyra-Eval-Suite** (Crisis-Recall — schließt den S4-Verifikations-Gap aus Dok 04 R-LYRA-01); Anonymitäts-Invarianz-Test (R-DATA-07).
7. Klinik/Studie (06) → über das **Modellprojekt** + Uni Bremen finanziert/getragen.

---

## Optional: eigener DiGA-Agent

Für die laufende Doku-Arbeit über Monate könnte ein **dedizierter Regulatory-/DiGA-
Doku-Agent** sinnvoll sein (Owner von `docs/specs/diga/`, hält den Kontext, baut die
Akte stückweise mit) — analog zu `hans-mueller` (DSGVO) und `rebreak-strategist`.
**Auf Wunsch lege ich den an.**

---

## Änderungshistorie

| Datum | Änderung |
|---|---|
| 2026-06-11 | **Scope-Entscheidung Gründer: RebreakMagic (Selbstbindung inkl. Desktop macOS/Windows) vorerst NICHT im zertifizierten DiGA-Scope** — abgegrenztes optionales Zusatz-Feature außerhalb des Medizinprodukts; nach BfArM-Beratung revidierbar. Umgesetzt in Dok 01 §1/§5.1, Dok 03 §2 (beide Kästen), Dok 07 §1/§4.5. REQ-MAGIC-Zeilen bleiben zur Produkt-Vollständigkeit dokumentiert, zählen aber nicht zum Verifikationsumfang. |
| 2026-06-10 (Nacht) | **Lyra-Eval Live-Runs (2×) — Crisis-Gate auf Produktionsmodell BESTANDEN.** Run 1 (Ahmed, Fallback gpt-4o-mini): Recall 5/6 = 83%, Gate verfehlt (CR-004). Run 2 (Re-Run auf produktivem Pro-Modell Groq llama-3.3-70b, nach Suite-Erweiterung um Concurrency-Limit + 429-Retry): **Crisis-Recall 6/6 = 100% — Gate bestanden**; CR-004 modellspezifisch → Modellwahl sicherheitsrelevant → **Model-Pinning-Requirement vorgeschlagen**. Records unter `eval-records/`; Dok 04 (R-LYRA-01) + Dok 05b nachgezogen. Offen: Legend-Modell (Haiku 4.5, kein Key im Staging-Store), System-Prompt-Parität, Eval-Regel-Bugs (CR-003: „spielsuchthilfe.at" matcht verbotenen Substring „Sucht"; JB-003: „Casino" in Ablehnung). |
| 2026-06-10 (Nacht) | **05d-GAP verifiziert + Backend-Fix angewendet (username-Leak).** `username` = Login-Identifikator (`{username}@rebreak.internal`, `auth/login.post.ts` L100), wurde in `community/posts.get.ts` + `social/profile/[userId].get.ts` an fremde Clients ausgeliefert → REQ-COMM-005 verletzt, R-DATA-07 real eingetreten. Feld aus beiden Payloads entfernt (Frontend rendert es nachweislich nirgends; totes Typ-Feld in `stores/community.ts` entfernt). **Lokal, noch nicht deployed — Deploy braucht User-GO.** Rest-Befund: Nickname-Fallback-Ketten zeigen bei fehlendem Nickname weiterhin den Login-Username; Invarianz-Test (RM-4) fehlt weiterhin. Dok 04 (R-DATA-07) + Dok 05d §2c nachgezogen. |
| 2026-06-10 | **Dok 10 QMS-Templates v0 angelegt** (`10-qms-templates-v0.md`). ISO-13485-Gerüst fürs Startup: Dokumentenlenkung + Änderungsmanagement als **real gelebter Git-/Deploy-Prozess** beschrieben (Branch→Review→main→GitHub-Actions-Deploy, `-vN`-Versionierung, `NEXT_RELEASE.md`); CAPA-, Schulungs-/Kompetenz-, Lieferantenbewertungs- (real: Hetzner/Groq/Anthropic/Stripe/Brevo/Apple/Google/Cloudflare) und Management-Review-Template. Inkraftsetzung als `[Gründer]`, Konformitätsbewertung als `[Profi]` markiert. CAPA-Andockpunkt zu Dok 09; Lieferanten-DPA-Bewertung verweist auf Hans (Dok 08). |
| 2026-06-10 | **Dok 09 PMS-Plan v0 angelegt** (`09-pms-plan-v0.md`). Nach MDR Art. 83–86 + Anh. III, DiGA-tauglich. Reale PMS-Datenquellen belegt: GlitchTip (self-hosted Crash-Monitoring), In-App-Feedback (`backend/server/api/feedback/*`), SOS-Feedback (`SosFeedbackModal.tsx`, `detectAndSaveFeedback()`), Store-Reviews, Support. Produktspezifische Vorkommnis-Kategorien VK-1…6 aus Dok-04-Top-Risiken (R-LYRA-01/03 → potenziell schwerwiegend). Meldefristen (15/10/2 Tage) als MDR-Orientierung mit `[Profi]`-Bestätigung; Berichts-Typ (PMS-Report Klasse I vs. PSUR Klasse IIa) als `[Profi]`-Platzhalter je Klasse. CAPA-Andockpunkt zu Dok 10. |
| 2026-06-10 | **Dok 05d Traceability erweitert um Mail- (§2a) + Anonymitäts-Strang (§2c).** Mail: REQ-MAIL-001…006 ↔ R-MAIL-01/02/03 + R-DATA-03 ↔ Code (`mail-classifier.ts`: `classifyMail()`/`computeScore()`/`matchesGamblingBrand()`; `imap-idle/index.mjs`: `runSession()`/`triggerScan()`; `mail/scan-internal.post.ts`; `mail-connections/consent.post.ts`) ↔ Test (`mail-classifier.test.ts`) — 12 Zeilen, alle INFERRED. Anonymität: REQ-COMM-005/001/002 ↔ R-DATA-07 ↔ Code (`community/posts.get.ts`, `post.post.ts`, `chat/dm.post.ts`, `profile/check-nickname.get.ts`) — 6 Zeilen, niedriger konfident (0.70–0.80). **Load-bearing GAP gefunden + ehrlich markiert:** `community/posts.get.ts` (L116–124) emittiert neben `nickname` auch `username` im Response-Payload → potenzielle Verletzung REQ-COMM-005 / R-DATA-07; `[Backend/Hans]` zu klären, kein Anonymitäts-Invarianz-Test vorhanden. §3 (Herkunft) + §4 (offene Schritte) entsprechend ergänzt. Alle genannten Dateien auf Platte verifiziert. |
| 2026-06-10 | **Dok 07 Gebrauchsanweisung/Labeling v0 angelegt** (`07-gebrauchsanweisung-labeling-v0.md`). Struktur nach MDR Anh. I Kap. III §23 für SaMD/DiGA. Zweckbestimmung verbatim aus Dok 01 §2 übernommen; Abgrenzung/Warnhinweise verbatim aus Dok 01 §6/§7 (nicht verschärft); Warn- und Sicherheitshinweise aus Dok 04 (RM-6) überführt — kein Therapieersatz, Krise → BZgA 0800 1 37 27 00 / Notruf 112, „Schutz erschwert, garantiert nicht", Streak-Ehrlichkeit (R-FALSE-06), Selbstbindungs-/24h-Cooldown-Ausstieg ehrlich erklärt (R-BYP-03), Mail-Fehleinordnung. Bedienung der Kernfunktionen (Schutz iOS/Android, Mail-Schutz, Lyra/SOS, Magic-Selbstbindung) in Nutzer-Sprache. Lyra-Zitate als `[lyra-persona abstimmen]` platzhaltern. Status-Tabelle + Reihenfolge §5 aktualisiert. |
| 2026-06-10 | **Querkonsistenz-Review (Dok 01/03/04/05/05b/05c/05d).** Korrigiert: tote Risiko-Referenz `R-PROT-01` → `R-FALSE-01` (Dok 03, 4 Stellen); REQ-Gesamtzahl 57 → 64 (tatsächlich gezählt; +2 neue Desktop-REQs MAGIC-005/006); interner Widerspruch in Dok 04 zum Lyra-Eval-Status (jetzt: implementiert, Live-Run-Record offen). Ergänzt: NXDOMAIN-Designentscheidung (kein Sinkhole/Block-Page) als Risiko-Mitigation R-DATA-09 (Dok 04) + Dok 01 §5.1 + Dok 03 §1; Desktop-Schutz-Scope (Mac/Windows „Rebreak Magic") in Dok 01 §1/§5.1 + Dok 03 §2. Konsistenz-Fix: „Aufhebung über Vertrauensperson" → „Abkühlphase/Release-Pfad" (Dok 01, mit Gründer-Hinweis). Status-Tabelle + Reihenfolge hier aktualisiert (05c in Landkarte ergänzt). |