ac05e255da
DiGA-Dossier weiter aufgebaut (docs/specs/diga/): - 03 Requirements (57 REQ-IDs aus dem Code, Traceability-Anker) - 04 Risiko-Akte (ISO 14971 Erstliste; R-LYRA-01 = verpasste Krise als Top-Risiko) - 05b Test-Verifikation (Maestro/Vitest-Inventar, IEC-62304-Luecken) - 05c Lyra-Eval (Suite-Doku) - 08 Datenschutz-Audit (hans-mueller; Groq/Art.9, DSFA-Pflicht, Mail-Agent, Anonymitaet) - 00 Dossier-Plan Status aktualisiert Lyra-Eval-Suite: backend/tests/eval/ (30 Prompts, 5 Kategorien, Vitest-Runner, Mock-Modus ohne Key; Live-Run misst Crisis-Recall). Konvergenter Befund aller 3 Agents: Lyras Krisen-Pfad haengt zu sehr am LLM (R-LYRA-01 + fehlender SOS-Handler-Fallback) -> deterministisches Sicherheitsnetz noetig. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.3 KiB
3.3 KiB
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 |
| 02 | Klassifizierung (Rule 11 → I/IIa) | MDR Anh. VIII | Profi (BfArM-Beratung) | offen — Kostenhebel |
| 03 | Anforderungen / Requirements | IEC 62304 | Claude (aus App) | v0 angelegt (57 REQ-IDs) |
| 04 | Risikomanagement-Akte | ISO 14971 | Claude-Erstliste + du | v0 angelegt (Erstliste) |
| 05 | Software-Lifecycle + Architektur + SOUP | IEC 62304 | Claude (aus Code) | offen |
| 05b | Software-Verifikation: Test-Nachweis | IEC 62304 §5.5–5.7 | Ahmed (Test-Agent) | v0 angelegt |
| 06 | Klinische Bewertung (Plan + Report) | MDR Anh. XIV | Profi + Uni Bremen | offen |
| 07 | Gebrauchsanweisung / Labeling | MDR | Claude-Entwurf | offen |
| 08 | DSFA + IT-Sicherheit | BfArM-DiGA-Anf. | Claude-Struktur + Profi | v0 angelegt (hans-mueller) |
| 09 | Post-Market-Surveillance-Plan | MDR | Claude-Entwurf | offen |
| 10 | QMS (Prozesse, Doc-Control, CAPA) | ISO 13485 | Profi + Claude-Templates | offen |
Reihenfolge (was zuerst)
- Zweckbestimmung v0 (Datei
01-...) → deine Freigabe. - Kostenlose BfArM-Hersteller-Beratung mit der Zweckbestimmung → Klasse I/IIa + Lücken-Feedback. (billigster, hebelstärkster Schritt)
- Je nach Klasse: Regulatory-Berater als Lotse holen.
- Parallel von Claude:
Requirements (03)✅,Risiko-Erstliste (04)✅, SOUP/Architektur (05) aus dem bestehenden Code. 03 + 04 sind der Traceability-Anker für 05b (Ahmed). Nächster Claude-Schritt: Dok 05 (SOUP/Architektur). - 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.