chahine/rebreak-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity
rebreak-monorepo/docs/specs/diga/00-dossier-plan.md
chahinebrini 21c1e31877 docs(diga): Nacht-Session — Eval-Records, Akte 10/11, Magic-Scope-Entscheidung 
- Lyra-Eval Live-Runs (2x): Crisis-Recall-Gate auf Produktionsmodell
  (Groq llama-3.3-70b) BESTANDEN (6/6=100%); gpt-4o-mini-Fallback 83%
  -> Modellwahl sicherheitsrelevant -> Model-Pinning vorgeschlagen.
  Records unter docs/specs/diga/eval-records/.
- 05d: Mail- + Anonymitäts-Strang (+18 Zeilen); username-GAP verifiziert
  + Fix dokumentiert. 04 (R-LYRA-01, R-DATA-07) + 05b nachgezogen.
- Dok 07 Gebrauchsanweisung, Dok 09 PMS-Plan, Dok 10 QMS-Templates (v0).
- Scope-Entscheidung Gründer 2026-06-11: RebreakMagic (inkl. Desktop)
  vorerst NICHT im zertifizierten DiGA-Scope (01/03/07 umgesetzt).
- graphify-Artefakte (Hook-Rebuild) mitgenommen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-11 06:36:33 +02:00

11 KiB
Raw Permalink Blame History

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).