# 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]`.*