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>
12 KiB
Post-Market-Surveillance-Plan (PMS) — Rebreak · v0 (Entwurf)
Dok 09 der DiGA-Technischen-Akte. Norm-Bezug: **MDR (EU) 2017/745, Art. 83–86
- Anh. III** (System zur Überwachung nach dem Inverkehrbringen, PMS-Plan, PSUR/PMS-Report), ISO 14971 §10 (Informationen aus Produktion und Markt → Risikomanagement), IEC 62304 §6 (Software-Wartungsprozess). DiGA-spezifisch: BfArM-DiGA-Leitfaden (Anforderungen an positive Versorgungseffekte + laufende Sicherheits-/Qualitäts-Überwachung). Erstellt von Dr. Marlene Brandt (
diga-regulatory). Drafting / Erst-Entwurf — die Inkraftsetzung des PMS- Prozesses ist[Gründer-Entscheidung], die Konformität (Vollständigkeit nach Art. 84 + Anh. III, Berichtsrhythmus je Klasse) ist[Profi-Validierung].Ehrliche Grenze: Dieser Plan beschreibt PMS-Datenquellen, die real existieren (GlitchTip-Crash-Monitoring, Store-Reviews, In-App-Feedback, Support) und entwirft die Melde-/Reaktionswege. Er ist kein von einer benannten Stelle abgenommenes PMS-System. Der konkrete Berichts-Rhythmus (PMS-Report Klasse I vs. PSUR Klasse IIa) und die meldepflichtigen Schwellen sind klassenabhängig →
[Profi-Validierung]nach Dok 02.Andockpunkte: Dok 04 (Risiko-Akte — PMS speist die Risikoanalyse zurück, ISO 14971 §10), Dok 07 (Gebrauchsanweisung — Support-/Kontakt-Kanal), Dok 08 (Datenschutz — PMS-Daten sind selbst Art-9-nah), Dok 10 (QMS — CAPA- Andockpunkt).
1. Zweck & Geltungsbereich
Das PMS-System sammelt systematisch und aktiv Erfahrungen mit Rebreak nach der Bereitstellung, um:
- die Nutzen-Risiko-Bewertung (Dok 04, ISO 14971 §10) aktuell zu halten,
- Vorkommnisse und negative Trends früh zu erkennen und zu melden (Art. 87),
- Korrektur-/Vorbeugemaßnahmen (CAPA → Dok 10) auszulösen,
- die für die DiGA geforderten positiven Versorgungseffekte und die Anwendungssicherheit laufend zu belegen.
Geltungsbereich: die Rebreak-App (iOS, Android) und die begleitenden Desktop-
Schutz-Clients (macOS/Windows „Rebreak Magic"), soweit sie Teil des zertifizierten
Scopes sind. [Gründer-Entscheidung] Scope-Abgrenzung Desktop (vgl. Dok 01 §1,
Dok 03 §2-Kasten).
Reaktiv vs. proaktiv: MDR verlangt proaktives PMS (Art. 83). Die Crash-/Feedback-Quellen unten sind teils reaktiv (Nutzer meldet) — der proaktive Teil liegt im regelmäßigen Review dieser Quellen (§5) und in der Verzahnung mit der klinischen Nachbeobachtung (Dok 06, PMCF —
[Profi]+ Uni Bremen).
2. PMS-Datenquellen (real vorhanden)
| # | Quelle | Was sie liefert | Code-/Infra-Beleg | Typ |
|---|---|---|---|---|
| Q1 | GlitchTip (self-hosted) — Crash-/Error-Monitoring | App-/Backend-Crashes, Stacktraces, Fehlerraten, betroffene App-Versionen/OS | self-hosted (server-first, vgl. interne Notiz „Android16/Samsung VPN-FGS-Crash + GlitchTip") | technisch, proaktiv |
| Q2 | In-App-Feedback | strukturiertes Nutzer-Feedback, Bewertung/Status-Workflow | backend/server/api/feedback/index.get.ts, backend/server/api/feedback/[id].patch.ts |
Nutzer, reaktiv |
| Q3 | SOS-Feedback | Rückmeldung direkt nach einem SOS-/Druckmoment (Wirksamkeit der Begleitung) | apps/rebreak-native/components/urge/SosFeedbackModal.tsx; detectAndSaveFeedback() in backend/server/api/coach/message.post.ts |
Nutzer, fokussiert |
| Q4 | Store-Reviews | öffentliche Bewertungen/Beschwerden im App Store / Google Play | Apple App Store Connect, Google Play Console | Nutzer, öffentlich |
| Q5 | Support-Kanal | direkte Nutzeranfragen/-beschwerden, Eskalationen | Support-E-Mail / In-App-Kontakt ([Gründer] Adresse, vgl. Dok 07 §1) |
Nutzer, reaktiv |
| Q6 | DiGA-Auswertungsdaten | Streak/Urge-Logs, SOS-Sessions, Demografie (Wirksamkeits-/Nutzungssignale) | prisma Streak/UrgeLog/SosSession (Dok 03 §5/§6/§4) |
klinisch-nah |
| Q7 | Risiko-/Eval-Records | Crisis-Recall-Live-Runs, Mail-Klassifikations-Metriken (sobald archiviert) | docs/specs/diga/eval-records/, Dok 05c |
Verifikation |
Datenschutz-Hinweis (Owner Hans, Dok 08): PMS-Daten aus Q3/Q6 sind selbst Art-9-nah (Krisen, Suchtdruck). Ihre Verarbeitung für PMS braucht eine Rechtsgrundlage/Zweckbindung (Dok 08 §2.7). PMS darf nicht die Anonymitäts-/ Datenminimierungs-Prinzipien aufweichen — Auswertung pseudonymisiert/aggregiert.
[Profi-Validierung].
[Gründer-Entscheidung]Welche dieser Quellen formal als PMS-Eingang deklariert werden (und wer sie wann sichtet), ist festzulegen. GlitchTip-Zugang, Store-Console-Zugang und das Support-Postfach brauchen eine benannte verantwortliche Person (§6).
3. Vorkommnis- & meldepflichtige Ereignisse
Definition (MDR Art. 2 Nr. 64/65): Ein Vorkommnis ist eine Fehlfunktion oder Verschlechterung der Eigenschaften/Leistung, ein Anwendungsfehler oder eine Unzulänglichkeit der Kennzeichnung; ein schwerwiegendes Vorkommnis ist eines, das direkt/indirekt zum Tod, zu einer schwerwiegenden Verschlechterung des Gesundheitszustands oder einer schwerwiegenden Gefahr für die öffentliche Gesundheit führte oder führen könnte.
Produktspezifische Vorkommnis-Kategorien (abgeleitet aus Dok 04 — Top-Risiken):
| Kategorie | Beispiel-Ereignis | Verknüpftes Risiko (Dok 04) | Vorab-Einstufung |
|---|---|---|---|
| VK-1 Krise verpasst | Lyra erkennt eine akute Krise/Suizidalität nicht; Nutzer berichtet Selbstgefährdung | R-LYRA-01 (S4) | potenziell schwerwiegend |
| VK-2 Hotline-Fehler | falscher/fehlender Krisen-/Notruf-Verweis | R-LYRA-03 (S4) | potenziell schwerwiegend |
| VK-3 Selbstbindungs-Falle | legitimer Ausstieg nach Cooldown scheitert, Nutzer „eingesperrt" | R-BYP-03 (S3) | ernst — ethisch/haftungsrelevant |
| VK-4 falsche Sicherheit | Schutz inaktiv ohne Warnung → Rückfall trotz „aktiv"-Anzeige | R-FALSE-01 (S3) | ernst |
| VK-5 Datenleck / De-Anonymisierung | Klarname/E-Mail/Username leakt (vgl. 05d §2c GAP) | R-DATA-07 (S3) | ernst — meldepflicht prüfen |
| VK-6 irreversibler Mail-Verlust | legitime Mail dauerhaft gelöscht (False Positive) | R-MAIL-02 (S2) | zu bewerten |
[Profi-Validierung]— kritisch: Die Zuordnung „schwerwiegendes Vorkommnis" und die Meldefrist an die zuständige Behörde (Art. 87: i.d.R. unverzüglich, spätestens 15 Tage; bei ernster Gefahr für die öffentliche Gesundheit 2 Tage; bei Tod/ unerwarteter schwerer Verschlechterung 10 Tage) sind vom Profi zu bestätigen. Diese Fristen stehen hier als Orientierung aus dem MDR-Text, nicht als verbindlich validierte Festlegung. Die zuständige Behörde (BfArM) und der Meldeweg (MIR-Formular/EUDAMED) sind in Kraft zu setzen.
3.1 Meldeweg (Entwurf)
Eingang (Q1–Q5)
└─ Triage durch PMS-Verantwortliche (§6) — Vorkommnis ja/nein?
├─ KEIN Vorkommnis → in PMS-Trend-Log (§4) aufnehmen
└─ Vorkommnis → Schweregrad-Einstufung (gegen Dok 04)
├─ nicht schwerwiegend → Trendbeobachtung (§4) + ggf. CAPA (Dok 10)
└─ schwerwiegend → BEHÖRDENMELDUNG (Frist s.o.) + CAPA + Risiko-Akte-Update
└─ ggf. Sicherheitskorrekturmaßnahme im Feld (FSCA) + FSN an Nutzer
Die Verzahnung mit der Gebrauchsanweisung (Dok 07) ist beidseitig: ein wiederkehrender Anwendungsfehler kann eine Labeling-Anpassung (zusätzlicher Warnhinweis) auslösen (ISO 14971 §10 → §7.1(3)).
4. Trendberichterstattung (Art. 88)
Über die Einzel-Vorkommnisse hinaus werden Trends statistisch signifikanter Anstiege nicht-schwerwiegender Ereignisse beobachtet:
| Trend-Metrik | Quelle | Vorab-Schwelle (Entwurf) |
|---|---|---|
| Crash-Rate je App-Version | Q1 GlitchTip | Anstieg > X % ggü. Vorversion [Profi] |
| SOS-Abbruch-/Fehler-Quote (LLM-Ausfall) | Q3 + Backend-Logs | Schwelle [Profi] (R-LYRA-04) |
| False-Positive-Mail-Beschwerden | Q2/Q5 | Häufung [Profi] (R-MAIL-02) |
| „Schutz war aus"-Meldungen | Q2/Q5 + Q1 | Häufung [Profi] (R-FALSE-01) |
| Negative Store-Reviews mit Sicherheitsbezug | Q4 | manuelle Sichtung |
[Profi-Validierung]Die konkreten Trend-Schwellen sind statistisch zu definieren (Baseline aus den ersten Nutzungsmonaten). Solange keine Baseline existiert, gilt manuelle Sichtung im Review-Zyklus (§5).
5. Berichts-Rhythmus & Review-Zyklus
| Aktivität | Frequenz | Ergebnis-Artefakt | Verantwortlich |
|---|---|---|---|
| GlitchTip-Crash-Sichtung | laufend / wöchentlich | Crash-Triage-Notiz | PMS-Verantwortliche |
| Feedback-/Support-/Store-Review-Sichtung | wöchentlich | Eingangs-Log | PMS-Verantwortliche |
| PMS-Trend-Auswertung | monatlich/quartalsweise [Profi] |
Trend-Report | PMS-Verantwortliche + Profi |
| PMS-Report (Klasse I) oder PSUR (Klasse IIa) | klassenabhängig [Profi] |
PMS-Report / PSUR | Gründer + Profi |
| Rückfluss in Risiko-Akte (Dok 04) | mit jedem Report | aktualisierte Dok 04 | Marlene + Profi |
| Management-Review-Input (Dok 10 §6) | je Management-Review | PMS-Zusammenfassung | PMS-Verantwortliche |
[Profi-Validierung]— Berichts-Art hängt an der Klasse (Dok 02):
- Klasse I: PMS-Report (Art. 85), bei Bedarf aktualisiert.
- Klasse IIa: PSUR (Periodic Safety Update Report, Art. 86) — mindestens alle 2 Jahre zu aktualisieren, der zuständigen Stelle auf Anfrage zugänglich.
Welcher Bericht greift, steht erst nach der Klassifizierung fest. Bis dahin gilt der Platzhalter — kein Bericht-Typ ist hier verbindlich festgelegt.
6. Verantwortlichkeiten
| Rolle | Aufgabe | Wer |
|---|---|---|
| PMS-Verantwortliche/r | Quellen sichten, Triage, Trend-Log führen | [Gründer] benennen |
| Person verantwortlich für Regelkonformität (PRRC, Art. 15) | Vorkommnis-Meldungen, PMS-/PSUR-Freigabe | [Gründer] + [Profi] — PRRC-Pflicht/Eignung prüfen |
| Datenschutz (PMS-Daten) | Q3/Q6-Verarbeitung rechtskonform | Hans (Dok 08) |
| Klinische Nachbeobachtung (PMCF) | Wirksamkeit/Versorgungseffekt | [Profi] + Uni Bremen (Dok 06) |
| CAPA-Umsetzung | Korrektur-/Vorbeugemaßnahmen | Dev/Backend (Dok 10) |
[Profi-Validierung]Ob für die Unternehmensgröße eine PRRC nach Art. 15 verpflichtend ist (und ob extern beauftragbar), ist zu klären.
7. CAPA-Andockpunkt (→ Dok 10)
Jedes Vorkommnis und jeder bestätigte negative Trend, der eine Produktänderung erfordert, mündet in einen CAPA-Vorgang (Corrective And Preventive Action), der im QMS (Dok 10 §3, CAPA-Template) geführt wird. Der Schließungs-Nachweis einer CAPA (Codeänderung → Review → Deploy → Verifikation) läuft über den Änderungs-/Deploy-Flow aus Dok 10 §2 und wird in der Risiko-Akte (Dok 04) und ggf. der Traceability-Matrix (Dok 05d) reflektiert.
Beispiel-Kette (real, illustrativ): der Android16/Samsung-VPN-FGS-Crash (über Q1
GlitchTip erfasst, Fix 63fae25) ist ein Muster-CAPA: Crash erkannt → Ursache
(impliziter startForeground) → Fix + Guard → Deploy → Verify. So ein Vorgang würde
künftig als CAPA-Record dokumentiert (Dok 10).
8. Offene Punkte
| # | Punkt | Owner |
|---|---|---|
| PMS-1 | Berichts-Typ (PMS-Report vs. PSUR) + Rhythmus festlegen | [Profi] nach Dok 02 |
| PMS-2 | Vorkommnis-Schwellen + Meldefristen verbindlich bestätigen | [Profi] |
| PMS-3 | PMS-Verantwortliche/r + PRRC benennen | [Gründer] |
| PMS-4 | Trend-Schwellen statistisch definieren (Baseline) | [Profi] |
| PMS-5 | Rechtsgrundlage PMS-Datenverarbeitung (Q3/Q6) | Hans (Dok 08) |
| PMS-6 | EUDAMED-/Behörden-Meldeweg in Kraft setzen | [Gründer] + [Profi] |
| PMS-7 | PMCF-Plan mit Uni Bremen (Dok 06) verzahnen | [Profi] + klinisch |
v0-Entwurf. PMS-Datenquellen sind aus der realen Infrastruktur abgeleitet und belegt.
Berichts-Rhythmus, Meldefristen und Klassen-Abhängigkeiten sind [Profi-Validierung];
die Inkraftsetzung des Prozesses (Verantwortliche, Frequenzen) ist [Gründer-Entscheidung].