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>
209 lines
12 KiB
Markdown
209 lines
12 KiB
Markdown
# 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:
|
||
|
||
1. die **Nutzen-Risiko-Bewertung** (Dok 04, ISO 14971 §10) aktuell zu halten,
|
||
2. **Vorkommnisse** und negative Trends früh zu erkennen und zu melden (Art. 87),
|
||
3. **Korrektur-/Vorbeugemaßnahmen** (CAPA → Dok 10) auszulösen,
|
||
4. 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]`.*
|