21c1e31877
- 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>
240 lines
11 KiB
Markdown
240 lines
11 KiB
Markdown
# QMS-Templates / ISO-13485-Gerüst — Rebreak · v0 (Entwurf)
|
||
|
||
> **Dok 10 der DiGA-Technischen-Akte.** Norm-Bezug: **ISO 13485** (QM-System für
|
||
> Medizinprodukte), MDR Art. 10 Abs. 9 (QMS-Pflicht des Herstellers), **IEC 62304 §5/§8**
|
||
> (Software-Entwicklung/-Konfigurationsmanagement). Erstellt von Dr. Marlene Brandt
|
||
> (`diga-regulatory`). **Drafting / Template-Gerüst** — kein zertifiziertes QMS.
|
||
>
|
||
> **Ehrliche Grenze — bitte zuerst lesen:** Dies ist ein **Gerüst aus Vorlagen**, das den
|
||
> **bereits gelebten** Entwicklungs-/Deploy-Prozess von Rebreak in ISO-13485-Sprache
|
||
> beschreibt (Git-Versionierung, Branch→Review→main→Deploy ist **real so**) und die noch
|
||
> fehlenden QMS-Bausteine als **ausfüllbare Templates** bereitstellt. Es ist **kein**
|
||
> abgenommenes, in Kraft gesetztes QMS und **keine** Konformitätsbewertung.
|
||
>
|
||
> - **Inkraftsetzung** der Prozesse (verbindlich machen, Verantwortliche, Freigabe) =
|
||
> `[Gründer-Entscheidung]`.
|
||
> - **Konformitätsbewertung** (ISO-13485-Konformität, Vollständigkeit, Audit-Fähigkeit,
|
||
> ob ein vollzertifiziertes ISO 13485 oder das schlankere DiGA-/MDR-konforme QMS für
|
||
> die Klasse genügt) = `[Profi-Validierung]`.
|
||
>
|
||
> **Andockpunkte:** Dok 04 (Risikomanagement-Prozess), Dok 05/05b (Software-Lifecycle/
|
||
> Verifikation), Dok 09 (PMS → CAPA-Eingang), Dok 08 (Datenschutz-Prozesse, Owner Hans).
|
||
|
||
---
|
||
|
||
## 0. QMS-Prozesslandkarte (Überblick)
|
||
|
||
| Prozess | ISO-13485-Bezug | Status bei Rebreak | Dokument hier |
|
||
|---|---|---|---|
|
||
| Dokumentenlenkung | §4.2.4/§4.2.5 | **gelebt** (Git) | §1 |
|
||
| Änderungsmanagement / Konfig. | §7.3.9, IEC 62304 §8 | **gelebt** (Branch/PR/Deploy) | §2 |
|
||
| CAPA | §8.5.2/§8.5.3 | Template (neu) | §3 |
|
||
| Schulung / Kompetenz | §6.2 | Template (neu) | §4 |
|
||
| Lieferantenbewertung | §7.4 | Template + reale Liste | §5 |
|
||
| Management-Review | §5.6 | Template (neu) | §6 |
|
||
| Risikomanagement | §7.1, ISO 14971 | → Dok 04 | (Verweis) |
|
||
| PMS / Vorkommnis | §8.2, MDR Art. 83 ff. | → Dok 09 | (Verweis) |
|
||
|
||
---
|
||
|
||
## 1. Dokumentenlenkung (ISO 13485 §4.2.4/§4.2.5)
|
||
|
||
**Real gelebt — über Git.** Die Lenkung gelenkter Dokumente (Code **und** Dossier)
|
||
erfolgt im Monorepo `rebreak-monorepo`:
|
||
|
||
| ISO-13485-Anforderung | Umsetzung bei Rebreak (real) |
|
||
|---|---|
|
||
| Genehmigung vor Freigabe | Merge in `main` nur über Review (Pull-Request / Branch-Review) |
|
||
| Kennzeichnung von Änderungen | Git-Commit-Diff + Commit-Message (Konvention `fix(scope): …`) |
|
||
| Aktueller Revisionsstand erkennbar | Git-Commit-Hash + Tag/Release; Dossier-Dokumente versioniert `-v0/-v1` + Status-Tabelle in `00-dossier-plan.md` |
|
||
| Lesbar & identifizierbar | Dateipfad + Header je Dok (Norm-Bezug, Status, Autor) |
|
||
| Verteilung gelenkt | zentrales Repo als Single Source of Truth |
|
||
| Veraltete Dokumente kenntlich | Git-Historie; alte Versionen nie überschrieben, sondern als neue `-vN` |
|
||
| Externe Dokumente gelenkt | `[Template]` Register externer Normen/Leitfäden (MDR, ISO 14971, BfArM-Leitfaden) |
|
||
|
||
**Dossier-Versionierung (real, fortzuführen):** jede Akte-Datei trägt `-vN`; die
|
||
Status-/Änderungstabelle in `00-dossier-plan.md` ist das Lenkungs-Register. Diese
|
||
Praxis wird hier als verbindlich erklärt.
|
||
|
||
> `[Gründer-Entscheidung]` Formalisierung: Wer gibt eine Dossier-Version **frei** (Status
|
||
> „freigegeben" statt „v0-Entwurf")? Bislang sind alle Akte-Dokumente **Entwürfe**.
|
||
> `[Profi-Validierung]` Ob Git-basierte Lenkung als ISO-13485-konformer Records-Nachweis
|
||
> genügt (Aufbewahrungsfristen, Unveränderbarkeit, Zugriffslenkung), ist zu bestätigen.
|
||
|
||
---
|
||
|
||
## 2. Änderungsmanagement & Software-Konfiguration (ISO 13485 §7.3.9 / IEC 62304 §8)
|
||
|
||
**Real gelebter Change-Flow:**
|
||
|
||
```
|
||
Änderungsbedarf (Feature / Bug / CAPA aus Dok 09)
|
||
└─ Branch (kein direkter Push auf main)
|
||
└─ Implementierung + Tests (Vitest / Maestro — Dok 05b)
|
||
└─ Review (PR / Branch-Review)
|
||
└─ Merge in main
|
||
└─ Deploy-Pipeline (GitHub Actions → Build-Artefakt → Server-Skript)
|
||
└─ Verifikation live (Build läuft aus Build-Output, nicht aus Quelle)
|
||
```
|
||
|
||
| Aspekt | Umsetzung (real) |
|
||
|---|---|
|
||
| Rückverfolgbarkeit Änderung→Auslöser | Commit-Message + ggf. CAPA-/Issue-Referenz |
|
||
| Auswirkungsanalyse vor Änderung | `[Template]` Change-Impact-Notiz bei sicherheitsrelevanten Änderungen (Dok 04-Risiko betroffen?) |
|
||
| Verifikation der Änderung | Tests (Dok 05b) + Live-Verify; Crash-Monitoring (Dok 09 Q1) |
|
||
| Release-Notes | `apps/rebreak-native/NEXT_RELEASE.md` (real gepflegt) → von Deploy in CHANGELOG archiviert |
|
||
| Konfigurations-Identifikation | App-Version/Build (iOS), versionCode/versionName (Android — `build.gradle`) |
|
||
| Rollback | Git-Revert + Re-Deploy |
|
||
|
||
> **Change-Impact-Template (auszufüllen bei sicherheitsrelevanten Änderungen):**
|
||
>
|
||
> | Feld | Inhalt |
|
||
> |---|---|
|
||
> | Änderung / Auslöser | … (Feature / Bug / CAPA-ID / Vorkommnis Dok 09) |
|
||
> | Betroffene REQ (Dok 03) | REQ-… |
|
||
> | Betroffene Risiken (Dok 04) | R-… — verschärft / unverändert / gemindert? |
|
||
> | Erforderliche (Re-)Verifikation | Test-ID(s) Dok 05b/05c |
|
||
> | Labeling-Auswirkung (Dok 07) | ja/nein |
|
||
> | Freigabe | Reviewer + Datum |
|
||
|
||
> `[Profi-Validierung]` Welche Änderungen eine **erneute Risikobewertung** oder gar
|
||
> Neubewertung der Konformität auslösen (wesentliche Änderung i.S. MDR), ist festzulegen.
|
||
|
||
---
|
||
|
||
## 3. CAPA — Corrective and Preventive Action (ISO 13485 §8.5.2/§8.5.3)
|
||
|
||
Eingang: Vorkommnisse/Trends aus **Dok 09 (PMS)**, interne Audits, Reklamationen,
|
||
fehlgeschlagene Verifikationen.
|
||
|
||
> **CAPA-Record-Template:**
|
||
>
|
||
> | Feld | Inhalt |
|
||
> |---|---|
|
||
> | CAPA-ID | CAPA-YYYY-NN |
|
||
> | Datum / Auslöser | … (Quelle: Dok 09 Q1–Q7 / Audit / Reklamation) |
|
||
> | Typ | Korrektur (reaktiv) / Vorbeugung (proaktiv) |
|
||
> | Beschreibung Problem | … |
|
||
> | Betroffenes Risiko (Dok 04) | R-… |
|
||
> | Sofortmaßnahme (Containment) | … |
|
||
> | Ursachenanalyse (Root Cause) | … |
|
||
> | Maßnahme (korrigierend/vorbeugend) | … (i.d.R. Code-Änderung → §2-Flow) |
|
||
> | Wirksamkeitsnachweis | Test-/Verifikations-Record (Dok 05b) + Monitoring (Dok 09 Q1) |
|
||
> | Risiko-Akte aktualisiert? | ja/nein (Dok 04) |
|
||
> | Labeling aktualisiert? | ja/nein (Dok 07) |
|
||
> | Status / Abschluss | offen / in Arbeit / geschlossen + Datum + Freigabe |
|
||
>
|
||
> **Beispiel (real, illustrativ — wie ein Vorgang aussähe):** Android16/Samsung-VPN-
|
||
> FGS-Crash → GlitchTip-Eingang → Root Cause „impliziter `startForeground`" → Maßnahme
|
||
> „expliziter FGS-Typ + Guard" (Commit `63fae25`) → Verify ab Folge-Release. Dieser
|
||
> reale Vorgang ist das Muster für einen sauber dokumentierten CAPA-Record.
|
||
|
||
> `[Gründer-Entscheidung]` CAPA-Register in Kraft setzen (wo geführt — Issue-Tracker /
|
||
> Datei). `[Profi-Validierung]` Schließungs-Kriterien + Wirksamkeitsnachweis-Standard.
|
||
|
||
---
|
||
|
||
## 4. Schulung & Kompetenz (ISO 13485 §6.2)
|
||
|
||
> **Kompetenz-/Schulungsnachweis-Template (je Person/Rolle):**
|
||
>
|
||
> | Feld | Inhalt |
|
||
> |---|---|
|
||
> | Person / Rolle | … |
|
||
> | Erforderliche Kompetenz | z.B. IEC 62304, ISO 14971, Datenschutz Art-9, Krisen-/Sucht-Kontext |
|
||
> | Nachweis | Ausbildung / Schulung / Erfahrung |
|
||
> | Schulungsdatum / -inhalt | … |
|
||
> | Wirksamkeit bewertet | ja/nein + durch wen |
|
||
> | Nächste Auffrischung | … |
|
||
|
||
**Rebreak-spezifischer Mindest-Kompetenzbedarf (Vorschlag):**
|
||
|
||
| Rolle | Kompetenz-Schwerpunkt |
|
||
|---|---|
|
||
| Entwicklung | sichere SaMD-Entwicklung, IEC 62304, Test/Verifikation |
|
||
| PMS-/Regulatory-Verantwortliche | MDR PMS/Vorkommnis, ISO 14971 |
|
||
| Lyra-/Krisen-Verantwortung | **Krisen-/Suizid-Sensibilität** (Indikation F63.0), Eskalations-Pfade |
|
||
| Datenschutz | Art-9-Daten, DSFA (Hans, Dok 08) |
|
||
|
||
> `[Gründer-Entscheidung]` Rollen benennen + Schulungsbedarf festlegen.
|
||
> `[Profi-Validierung]` Mindestkompetenzen je sicherheitsrelevanter Rolle.
|
||
|
||
---
|
||
|
||
## 5. Lieferanten-/Subprozessor-Bewertung (ISO 13485 §7.4)
|
||
|
||
Reale, kritische Zulieferer/Subprozessoren (abgeglichen mit Dok 08):
|
||
|
||
| Lieferant | Leistung | Kritikalität | Bewertungs-Hinweis |
|
||
|---|---|---|---|
|
||
| **Hetzner** (DE) | Hosting (Server, Supabase self-hosted) | hoch — Verfügbarkeit + DE-Datenhaltung | Standort DE = Vorteil (Dok 08 §2.5); SLA/AVV prüfen |
|
||
| **Groq** (USA) | LLM-Inferenz (Lyra) | **kritisch** — Art-9-Drittland | DPA/SCC/TIA + ZDR — Owner Hans, Dok 08 §2.2 |
|
||
| **Anthropic** | LLM (Legend-Coach, Haiku) | hoch — Art-9 | DPA/Drittland prüfen (analog Groq) |
|
||
| **Stripe** | Zahlungsabwicklung | mittel — Zahlungsdaten | PCI/DPA (Dok 08) |
|
||
| **Brevo** | Transaktions-/Mail-Versand | mittel | AVV + Datenminimierung |
|
||
| **Apple / Google** | App-Stores, Push, Store-Reviews (Dok 09 Q4) | hoch — Distributions-/Plattform-Abhängigkeit | Plattform-Bedingungen; eingeschränkt verhandelbar |
|
||
| **Cloudflare** | Netzwerk/Edge | mittel | Drittland (Dok 08 §2.3) |
|
||
|
||
> **Lieferantenbewertungs-Template (je Lieferant):**
|
||
>
|
||
> | Feld | Inhalt |
|
||
> |---|---|
|
||
> | Lieferant / Leistung | … |
|
||
> | Kritikalität (Patientensicherheit/Daten) | hoch/mittel/niedrig |
|
||
> | Auswahl-/Bewertungskriterien | Verfügbarkeit, Datenschutz (AVV/DPA), Standort, Zertifikate |
|
||
> | AVV / DPA vorhanden? | ja/nein (Owner Hans für datenführende) |
|
||
> | Re-Evaluation | Frequenz / Auslöser (Incident, SLA-Bruch) |
|
||
> | Freigabe | Datum + Wer |
|
||
|
||
> **Wichtige Klarstellung:** Die **datenschutzrechtliche** Bewertung der Subprozessoren
|
||
> (AVV/SCC/TIA) ist **Hans' Scope (Dok 08)**. Diese §5 ist die **QMS-seitige
|
||
> Lieferanten-Lenkung** (Auswahl, Kritikalität, Re-Evaluation) — sie verweist auf Dok 08,
|
||
> dupliziert es nicht. `[Profi-Validierung]` Bewertungskriterien + Frequenz.
|
||
|
||
---
|
||
|
||
## 6. Management-Review (ISO 13485 §5.6)
|
||
|
||
> **Management-Review-Template (je Review):**
|
||
>
|
||
> | Eingang (Input) | Quelle |
|
||
> |---|---|
|
||
> | PMS-/Trend-Ergebnisse | Dok 09 §5 |
|
||
> | Vorkommnisse / Reklamationen | Dok 09 §3 |
|
||
> | CAPA-Status | §3 (dieses Dok) |
|
||
> | Audit-Ergebnisse (intern/extern) | … |
|
||
> | Risiko-Akte-Änderungen | Dok 04 |
|
||
> | Verifikations-/Eval-Status (z.B. Crisis-Recall) | Dok 05b/05c |
|
||
> | Lieferanten-Performance | §5 |
|
||
> | Änderungen Regulatorik / Normen | extern |
|
||
>
|
||
> | Ergebnis (Output) | … |
|
||
> |---|---|
|
||
> | Verbesserungsmaßnahmen | … |
|
||
> | Ressourcen-/Schulungsbedarf | §4 |
|
||
> | Produktänderungen | → §2 / CAPA §3 |
|
||
> | Datum / Teilnehmer / Freigabe | … |
|
||
|
||
> `[Gründer-Entscheidung]` Frequenz festlegen (üblich jährlich; für ein Startup mit hoher
|
||
> Änderungsrate ggf. häufiger). `[Profi-Validierung]` Vollständigkeit der Inputs/Outputs.
|
||
|
||
---
|
||
|
||
## 7. Offene Punkte
|
||
|
||
| # | Punkt | Owner |
|
||
|---|---|---|
|
||
| QMS-1 | QMS-Umfang festlegen: voll-zertifiziertes ISO 13485 vs. schlankes MDR-/DiGA-konformes QMS (klassenabhängig) | `[Profi]` nach Dok 02 |
|
||
| QMS-2 | Prozesse formal **in Kraft setzen** + Verantwortliche benennen | `[Gründer]` |
|
||
| QMS-3 | Git-basierte Dokumentenlenkung auf ISO-13485-Records-Tauglichkeit prüfen | `[Profi]` |
|
||
| QMS-4 | Definition „wesentliche Änderung" (Re-Konformität) | `[Profi]` |
|
||
| QMS-5 | CAPA-/Schulungs-/Lieferanten-Register operativ anlegen | `[Gründer]` |
|
||
| QMS-6 | Internes Audit-Programm aufsetzen (ISO 13485 §8.2.4) | `[Gründer]` + `[Profi]` |
|
||
|
||
---
|
||
|
||
*v0-Template-Gerüst. Dokumentenlenkung und Änderungsmanagement beschreiben den real
|
||
gelebten Git-/Deploy-Prozess; CAPA, Schulung, Lieferantenbewertung und Management-Review
|
||
sind ausfüllbare Vorlagen. Inkraftsetzung = `[Gründer-Entscheidung]`, Konformitäts-
|
||
bewertung = `[Profi-Validierung]`.*
|