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