rebreak-monorepo/docs/specs/diga/10-qms-templates-v0.md

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