- 05: Software-Lifecycle/Architektur/SOUP, code-belegt aus package.json-Manifesten + graphify-Graph; IEC-62304-Klassifizierungs-Vorschlag (B, ggf. C Krisen-Pfad) - 05d: Traceability Anforderung<->Risiko<->Code fuer Lyra- + Schutz/Selbstbindungs- Strang (27 graph-abgeleitete traceability-Kanten) - 00: 05 + 05d im Dossier-Plan registriert - 05b: Gap 'Fehlende Traceability-Matrix' verweist jetzt auf 05d Alle v0-Entwuerfe; Regulatory-/QM-Validierung ausstehend. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
58 lines
3.5 KiB
Markdown
58 lines
3.5 KiB
Markdown
# 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) | **v0 angelegt** (Architektur + SOUP code-belegt) |
|
||
| 05b | Software-Verifikation: Test-Nachweis | IEC 62304 §5.5–5.7 | Ahmed (Test-Agent) | **v0 angelegt** |
|
||
| 05d | Traceability-Matrix (Anf. ↔ Risiko ↔ Code ↔ Test) | IEC 62304 §5.1.1/§5.5.2/§7.4 | Claude (aus Graph) | **v0 angelegt** (Lyra-Strang) |
|
||
| 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)
|
||
|
||
1. **Zweckbestimmung v0** (Datei `01-...`) → deine Freigabe.
|
||
2. **Kostenlose BfArM-Hersteller-Beratung** mit der Zweckbestimmung → **Klasse I/IIa** + Lücken-Feedback. *(billigster, hebelstärkster Schritt)*
|
||
3. Je nach Klasse: Regulatory-Berater als Lotse holen.
|
||
4. 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).
|
||
5. 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.**
|