pflegefuchs/Feedbackfromtester.md

Tester-Feedback: Feature-Backlog

Quelle: Feedbackfromtester.txt (unstrukturierte Rohnotizen eines Testers). Diese Datei fasst die inhaltlichen Punkte zu thematischen Gruppen zusammen und ordnet sie nach geschätztem Umsetzungsaufwand. Betrifft ausschließlich pflegepilot_v3.

Status (2026-08-06): Alle Punkte T1–T25 sind umgesetzt und deployed (T25 seit 2026-07-31, siehe CLAUDE.md "Antragsstatus-Tracking + automatischer Widerspruchs-Vorschlag"). Zeile 31 (PLZ→Ort-Autofill) war bereits umgesetzt und kein eigener Punkt. Neu ergänzt (2026-08-01): T26–T37, aus den bis dahin noch nicht erfassten Zeilen 40–58 der Feedbackfromtester.txt. Davon umgesetzt: T26 (bereits durch Date-Wheel-Picker gelöst, kein Code geändert — später korrigiert, siehe eigener Abschnitt unten), T32 (Musterbrief "Pflege durch"), T27+T28 (Rubrik umbenannt in "Wegweiser für schwierige Momente" + fünfter Guide), T33 (Bestätigen-Button statt Auto-Advance in Interview Schritt 6), T29 (Duplikat-Schutz + Antrag-Lösch-Endpunkt), T30 (durchsuchbare Dokumenten-Scans + Volltextsuche, nach Klärung deutlich größer als "niedrig" ausgefallen). T31 weiterhin blockiert (braucht den echten MDK-Text von "Marcel"/Betreiber, kein Text erfunden). T35 + T36 seit 2026-08-05 umgesetzt (gemeinsam mit einem T34-Anschlusspunkt geklärt und gebaut, siehe CLAUDE.md "T34-Anschluss/T35/T36: Pflegegrad vermutet/bestätigt, ressourcenorientiertes Interview, 4-Wochen-Pflegetagebuch"). T37 seit 2026-08-06 umgesetzt und deployed (Notfall-Card, siehe CLAUDE.md "T37: Notfall-Card" — inkl. zweier nach dem ersten Deploy gefundener und behobener Bugs: falsch protokollierte IP im Zugriffs-Log, kaputter Patientenverfügungs-Link auf der NAS). Damit ist der gesamte T-nummerierte Backlog bis auf T31 (blockiert) und den offenen Teil von T34 (Berechnungsgrundlage selbst) abgeschlossen. Noch offen: T34 (die eigentliche Grundsatzfrage "Berechnungsgrundlage überarbeiten oder Pflegegrad-Einschätzung ganz weglassen" wurde nur in dem für T35/T36 nötigen Umfang mitentschieden — die Betreiber-Antwort war "nicht mehr anzeigen, nur noch als vermutet/bestätigt", das ist jetzt umgesetzt; eine tiefere Überarbeitung der Berechnungsgrundlage selbst stand nicht zur Debatte und bleibt offen, falls gewünscht) sowie der neue Punkt B1 (Umkreissuche "Nicht gefunden?"-Ergänzung, bewusst zurückgestellt, siehe Gruppe P weiter unten).

Legende

Feld	Bedeutung
Aufwand	niedrig / mittel / mittel-hoch / hoch — grobe Einschätzung, kein Story-Point-Wert
Abhängigkeit	andere Punkte in dieser Liste, die vorher (oder im selben Zug) erledigt sein sollten
Quelle	Zeilennummer im Original Feedbackfromtester.txt

Schnellübersicht (rein nach Aufwand sortiert)

1. ✅ niedrig — T9 Versichertennummer-Format-Validierung
2. ✅ niedrig — T4 Auto-Fill E-Mail des Users
3. ✅ mittel — T1 Checkliste vor Antragstellung
4. ✅ mittel — T2 Interview-Erweiterung: Leistungsauswahl
5. ✅ mittel — T6 Vollmacht 2: Unterschriftsfelder wechseln
6. ✅ mittel-hoch — T5 Vollmacht-Generator
7. ✅ mittel-hoch — T3 Eigene Rolle + Steuervorteil
8. ✅ niedrig-mittel — T18 Krisen-Checklisten/Guides
9. ✅ niedrig-mittel — T12 Umkreissuche erweitert um Wohnformen
10. ✅ niedrig-mittel — T13 Umkreissuche Therapie/Reha
11. ✅ mittel-hoch — T17 Budget-Tracker Entlastungsbetrag
12. ✅ hoch — T8 OCR-Kartenerfassung
13. ✅ hoch — T10 Umkreissuche Pflegedienste
14. ✅ hoch — T11 Umkreissuche Sanitätshäuser
15. ✅ mittel-hoch — T14 Benachrichtigung bei Leistungskatalog-Änderung
16. ✅ hoch — T16 E-Mail-Push-Einstellungen + Tagebuch-Check-in
17. ✅ hoch — T15 Benachrichtigung bei Umkreis-Änderung
18. ✅ niedrig — T22 Adresse-Autofill "wie mein Konto"
19. ✅ niedrig-mittel — T21 Kalender-Überfälligkeiten in der Sidebar
20. ✅ mittel — T20 Kalender-E-Mail-Erinnerungen (1/7 Tage vorher)
21. ✅ mittel — T19 Hilfsmittel-Wiederholungs-Reminder
22. ✅ hoch — T24 Onboarding / "Was tue ich als nächstes?"
23. ✅ hoch — T25 Antragsstatus-Tracking + Widerspruchs-Automatik

Neu ergänzt 2026-08-01 (Zeilen 40–58, bisher unbewertet)

24. ⛔ niedrig, blockiert — T31 MDK-Text auf Ergebnisseite ergänzen
25. ✅ niedrig — T32 Musterbrief: Feld "Pflege wird durchgeführt von"
26. ✅ mittel-hoch (Umfang nach Klärung größer als anfangs geschätzt) — T30 Dokumenten-Scan-OCR: durchsuchbare PDFs + Volltextsuche
27. ✅ niedrig-mittel — T26 Geburtsdatum-Eingabe: Format + Nummernblock
28. ✅ niedrig-mittel — T27 Krisen-Checkliste: Wortwahl + Umbenennung
29. ✅ niedrig-mittel — T28 Guide "Umzug ins Pflegeheim"
30. ✅ niedrig-mittel — T33 Interview Schritt 6: Bestätigung vor Auto-Weiterleitung
31. ✅ mittel — T29 Doppelte Anträge/Briefe: Root-Cause + Löschen
32. 🟡 mittel, teilweise umgesetzt — T34 Pflegegrad-Einschätzung: Berechnungsgrundlage / ggf. entfernen
33. ✅ hoch, Plan nötig — T35 4-Wochen-Pflegetagebuch vor Erstantrag
34. ✅ hoch, Plan nötig — T36 Interviews ressourcenorientiert umbauen
35. ✅ hoch, Plan nötig — T37 Notfall-Card: Wallet-QR-Code zur Patientenverfügung
36. 🕓 niedrig-mittel, bewusst zurückgestellt — B1 Umkreissuche: "Nicht gefunden?"-Ergänzung / OSM-Beitrag anregen

---

Gruppe A: Bevollmächtigung / Vollmacht

Zusammenhängender Themenblock: der eingeloggte User (Bevollmächtigter) handelt im Namen des Patienten. Reihenfolge ist eine sinnvolle Umsetzungskette — T4 liefert die Grundannahme, T5 baut den eigentlichen Generator, T6 ist reines Folgeverhalten von T5.

T4. Auto-Fill E-Mail des Users (niedrig) ✅

• Original (Zeile 4): "Auto Fill der App User Daten; der Patient hat meistens keine eigene E-Mail Adresse, hier müsste die E-Mail vom User verwendet werden da dieser bevollmächtigt ist."
• Interpretation: Wo aktuell die E-Mail des Patienten für Anschreiben/Kontaktzwecke erwartet wird, als Fallback die E-Mail des eingeloggten Users (nutzer.email) verwenden, sofern der Patient keine eigene hinterlegt hat.
• Abhängigkeit: keine harte, aber inhaltlich Grundlage für T5/T6.

T5. Vollmacht-Generator (mittel-hoch) ✅

• Original (Zeile 5): "Vollmachten; Vollmacht Generator erstellen für die Krankenkassen, die Vollmacht muss vom Patienten und vom User unterschrieben werden, Daten aus dem System verwenden."
• Interpretation: Neuer Dokumenttyp analog zu Musterbrief/Widerspruch/Ummeldung (bestehendes Muster: briefe_text.py + serverseitiges PDF via WeasyPrint + autorisierter Download). Unterschied: zwei Unterschriftsfelder (Patient + Bevollmächtigter) statt eines.
• Abhängigkeit: keine zwingende, nutzt aber ggf. T4 (Kontaktdaten).

T6. Vollmacht 2: Unterschriftsfelder wechseln (mittel, Abh. T5) ✅

• Original (Zeile 6): "sobald Vollmacht hinterlegt ist, werden die Unterschriften Felder vom Patienten zum Bevollmächtigten."
• Interpretation: Sobald eine hinterlegte Vollmacht für einen Patienten existiert, wechseln nachfolgende generierte Dokumente von "Unterschrift Patient" auf "Unterschrift Bevollmächtigter" (der User unterschreibt stellvertretend).
• Abhängigkeit: T5 muss zuerst existieren — ohne Vollmacht-Datensatz gibt es nichts, dessen Vorhandensein geprüft werden könnte.

T22. Adresse-Autofill "wie mein Konto" (niedrig) ✅

• Original (Zeile 32): "bau im Patienten Interview bei der Adressabfrage ein Kästchen ein, Adresse gleich wie 'Nutzer' - wenn angeklickt Nutzer Adresse automatisch einfügen."
• Interpretation: Genau dasselbe Muster wie T4 (Auto-Fill E-Mail des Users), nur für die Adresse statt der E-Mail.
• Umgesetzt: Checkbox "Adresse wie mein Konto verwenden" in Schritt 2 des "Neuer Patient"-Assistenten, nur sichtbar wenn das Konto tatsächlich eine vollständige Rechnungsanschrift hat. Bei Aktivierung werden Straße/PLZ/Ort aus rg_strasse/rg_plz/rg_ort übernommen und die Eingabefelder durch eine Zusammenfassungszeile ersetzt (gleiches Muster wie bei T4). Der bestehende usePlzSync-Hook wird währenddessen bewusst deaktiviert (aktiv={!adresseWieKonto}), damit sein eigener PLZ→Ort-Datenbank-Lookup die übernommene Konto-Adresse nicht durch einen abweichenden Datenbank-Treffer überschreibt.
• Abhängigkeit: keine, nutzt exakt das von T4 etablierte Muster.

---

Gruppe B: Interview & Leistungsauswahl

Zusammenhängender Themenblock: Erweiterung des bestehenden 6-Schritte-Interview-Wizards um eine Leistungsauswahl aus dem Leistungskatalog plus Rollenverteilung. T3 baut inhaltlich auf T2 auf.

T2. Interview-Erweiterung: Leistungsauswahl (mittel) ✅

• Original (Zeile 2): "Customer Journey; Ein Interview für die möglichen auswählbaren Bezüge. Siehe Leistungskatalog."
• Interpretation: Im Interview-Wizard einen Schritt ergänzen, der die laut Leistungskatalog für den Patienten in Frage kommenden Leistungen anzeigt und auswählen lässt.
• Abhängigkeit: keine.

T3. Eigene Rolle + Steuervorteil (mittel-hoch, Abh. T2) ✅

• Original (Zeile 3): "eigene Rolle vergeben (was kann ich leisten, was will ich leisten); Primärer User soll angeben, welche Leistungen er selbstständig übernehmen kann/möchte aus dem Leistungskatalog, übrige aus dem Interview gewonnenen Leistungen müssten im Anschluss separat beantragt werden; schreibe den Steuervorteil der Eigenleistung hinzu."
• Interpretation: Auf der in T2 ausgewählten Leistungsliste zusätzlich markieren, welche Leistungen der User selbst erbringt vs. welche extern beantragt werden müssen, plus Steuervorteil-Hinweis (Pflegepauschbetrag) bei Eigenleistung.
• Abhängigkeit: T2 muss zuerst existieren.

---

Gruppe C: Antragsprüfung

Eigenständig, keine Abhängigkeit zu den anderen Gruppen.

T1. Checkliste vor Antragstellung (mittel) ✅

• Original (Zeile 1): "Checkliste; beim Beantragen einmal prüfen ob alles Notwendige für den Antrag schon hochgeladen worden ist, damit dies im Falle der Prüfung direkt bereitliegt."
• Interpretation: Vor dem Absenden/Generieren eines Antrags eine Prüfung einbauen, ob die für diesen Antragstyp nötigen Dokumente bereits hochgeladen sind.

---

Gruppe D: Datenerfassung & Validierung Krankenversicherung

Beide Punkte betreffen die Krankenversicherungsdaten-Erfassung, liegen aber weit auseinander im Aufwand — keine Abhängigkeit zueinander.

T9. Versichertennummer-Format-Validierung (niedrig) ✅

• Original (Zeile 9): "korrekte Anzahl der Krankenversicherungs-Nummer Format und Längen beachten (wenn falsch: Fehler!)."
• Interpretation: Reine Format-/Längenvalidierung der Versichertennummer (DE/AT/CH) beim Erfassen — schneller Gewinn.

T8. OCR-Kartenerfassung (hoch) ✅

• Original (Zeile 8): "Abfotografieren der Krankenkassen Karte zur Datenübernahme (OCR müsste hier hinterlegt werden, sowie eine Python zur Auslesen der Bilddaten)."
• Interpretation: Foto der Krankenkassenkarte aufnehmen/hochladen lassen, per OCR Versichertennummer/Kassenname/Name auslesen und Formularfelder automatisch befüllen. Größter Einzelposten der Liste: neue Bildverarbeitungs-Pipeline, Fehlerbehandlung bei Fehlerkennung, Testaufwand über verschiedene Kartenlayouts/-anbieter hinweg.
• Umgesetzt: Tesseract OCR (offline, Betreiber-Entscheidung analog OSM statt Google Places), bewusst nur GKV/eGK (standardisiertes Layout, PKV ausgeschlossen). Alle fünf Felder (Vorname, Nachname, Geburtsdatum, Versichertennummer, Krankenkasse) werden übernommen, Scan-Button sitzt in Schritt 1 des "Neuer Patient"-Assistenten und zusätzlich im Bearbeiten-Formular. Details, inkl. eines beim Verifikationstest gefundenen und behobenen Fehltreffer-Bugs bei der Krankenkassen-Fuzzy-Erkennung, siehe CLAUDE.md-Abschnitt "eGK-Scan / OCR-Kartenerfassung". Noch ohne echte Testfotos verifiziert (nur synthetisches Testbild) — wie beim Dokumenten-Scan ist eine Nachbesserung anhand echter Nutzung wahrscheinlich nötig.
• Abhängigkeit: profitiert von T9, ist aber nicht davon blockiert.

---

Gruppe E: Umkreissuche (Pflegedienste, Sanitätshäuser, Wohnformen, Therapie)

Vier Punkte, alle auf derselben Grundmechanik aufbauend: PLZ eingeben → Umkreis → Ergebnisliste mit Kontaktdaten. T10 legt die Infrastruktur (externe Datenquelle, Geokoordinaten/Distanzberechnung, Ergebnisliste), T11/T12/T13 sind im Kern nur weitere Kategorie-Filter auf derselben Infrastruktur — deshalb nach T10 deutlich billiger als T10 selbst.

T10. Umkreissuche Pflegedienste (hoch) ✅

• Original (Zeile 14): "Umkreis Suche für Pflegedienste - Research aller Pflegedienste in DE, Umfeldsuche nach PLZ. Ausgabe Firmenname, Webseite, Telefon / E-Mail / WhatsApp"
• Interpretation: Anders als bei Krankenkassen (94 Einträge) oder Rentenversicherung (16 Einträge) gibt es in Deutschland mehrere Tausend Pflegedienste — eine handkuratierte, statische Liste ist hier nicht praktikabel. Braucht eine Produktentscheidung zur Datenquelle (z. B. Google Places API — kostenpflichtig pro Anfrage, oder OpenStreetMap/Overpass — kostenlos, aber lückenhafter) plus PLZ→Geokoordinaten-Auflösung und Umkreisberechnung. WhatsApp-Nummern sind über keine dieser Quellen zuverlässig abfragbar.
• Umgesetzt: OpenStreetMap (Betreiber-Entscheidung, siehe CLAUDE.md-Abschnitt "Umkreissuche für lokale Pflege-Dienstleister") statt Google Places — Nominatim (Geocoding) + Overpass API (Umkreissuche). WhatsApp wie erwartet über keine der beiden Quellen verfügbar, daher nicht ausgegeben.
• Abhängigkeit: keine, liefert aber die Infrastruktur für T11–T13.

T11. Umkreissuche Sanitätshäuser (hoch, Abh. T10) ✅

• Original (Zeile 15): "Umkreis Suche für Sanitätshäuser - Research aller Sanitätshäuser in DE, Umfeldsuche nach PLZ. Ausgabe Firmenname, Webseite, Telefon / E-Mail / WhatsApp"
• Interpretation: Strukturell identisch zu T10, nur Kategorie "Sanitätshaus" statt "Pflegedienst".
• Umgesetzt: wie erwartet nur ein zusätzlicher KATEGORIEN-Eintrag (shop=medical_supply), kein Aufwand an Such-/Router-/Frontend-Logik.
• Abhängigkeit: Sollte nach T10 kommen — nutzt dieselbe Umkreissuche-Anbindung, nur anderer Kategorie-Filter.

T12. Umkreissuche erweitert um Wohnformen (niedrig-mittel, Abh. T10) ✅

• Original (Zeile 16): "Umkreis Suche ergänzend mit Pflegeheime / Seniorenheime / Tagespflege / Demenzgruppen / betreutes Wohnen / Sozial Cafés / Altersheime mittels Filter zuschaltbar."
• Interpretation: Weitere zuschaltbare Kategorie-Filter (6-7 zusätzliche Einrichtungstypen) auf derselben T10-Infrastruktur. Der einzige Mehraufwand ist die richtige Kategorie-Zuordnung in der gewählten Datenquelle (nicht jede Kategorie ist bei Google Places/OSM 1:1 als eigener Typ hinterlegt, z. B. "Demenzgruppe" oder "Soziales Café" sind keine Standard-Kategorien — ggf. über Freitextsuche/Namensmuster statt Kategorie-Filter lösen).
• Umgesetzt: Pflegeheim, Betreutes Wohnen/Seniorenheim, Tagespflege, Demenz-Wohngruppe als vollwertige Kategorien (inkl. Mitabfrage älterer, laut OSM-Wiki noch nicht vollständig migrierter Tags). "Soziales Café" wie vermutet ohne verlässliches Tag — Behelfslösung über amenity=community_centre, Label markiert das transparent als "(geringe Datenlage)".
• Abhängigkeit: braucht T10.

T13b. Umkreissuche 24h-Pflegedienste (niedrig, Abh. T10, ergänzt 2026-07-29) ✅

• Herkunft: zusätzliches Tester-Feedback nach T8-Abschluss, nicht Teil der ursprünglichen Feedbackfromtester.txt.
• Umgesetzt: neue Kategorie pflegedienst_24h in derselben Registry. Kein eigenes OSM-Tag für "24-Stunden-Pflege" vorhanden — Namens-Musterfilter ("24h"/"24-Stunden" im Firmennamen) auf denselben ambulatory_care-Treffern statt eines Tag-Filters, Label transparent mit "(geringe Datenlage)" markiert (gleiche Kompromiss-Logik wie "Soziales Café"). Details siehe CLAUDE.md.

T13. Umkreissuche Therapie/Reha (niedrig-mittel, Abh. T10) ✅

• Original (Zeile 17): "Umkreis Suche Logopädie, Physiotherapie / Physiozentrum, Reha-Sport, Reha-Zentrum"
• Interpretation: Wie T12, weitere Kategorie-Filter (Therapie-/Reha-Einrichtungen) auf der T10-Infrastruktur.
• Umgesetzt: Logopädie, Physiotherapie, Reha-Zentrum als Kategorien. "Reha-Sport" bewusst ausgelassen — es existiert kein brauchbares OSM-Tag dafür (Kurse laufen meist über normale Sportvereine/Fitnessstudios ohne eigenen kartierbaren Ort); eine Kategorie mit strukturell unzuverlässiger Trefferquote anzubieten wäre schlechter als sie wegzulassen.
• Abhängigkeit: braucht T10.

---

Gruppe F: Benachrichtigungen (Katalog- & Umkreis-Änderungen, Push-Reminder)

Wichtiger Vorbehalt, bevor hier irgendetwas gebaut wird: Alle drei Punkte brauchen serverseitig proaktiv verschickte E-Mails (nicht nutzerausgelöst). Aktuell hat pflegepilot_v3 genau eine bewusste Ausnahme von "kein proaktiver Server-Mailversand" — das Passwort-Reset — mit der expliziten Notiz, das nicht als Freibrief für weiteren proaktiven Mailversand zu lesen (siehe CLAUDE.md, Abschnitt "Passwort-vergessen per SMTP"). Diese drei Punkte würden diese Architekturentscheidung bewusst aufweichen — das ist eine Produktentscheidung, keine reine Implementierungsdetail-Frage, und sollte vor Umsetzungsbeginn explizit noch einmal bestätigt werden.

T14. Benachrichtigung bei Leistungskatalog-Änderung (mittel-hoch) ✅

• Original (Zeile 20): "Benachrichtigungs-Funktion via E-Mail an den Nutzer parallel an den Patienten falls sich der Leitungskatalog aktualisiert oder verbessern oder verschlechtert."
• Interpretation: Wenn sich ein Katalogeintrag ändert (Betrag, Voraussetzung, Wegfall), sollen Nutzer, deren Patient diese Leistung zugewiesen hat, per E-Mail informiert werden. Der Leistungskatalog hat aktuell keine Versionierung — ähnlich wie beim bestehenden Changelog-System (versionierte Einträge + "gesehen"-Tracking pro Nutzer) müsste hier erst eine Änderungs-Historie pro Katalogeintrag eingeführt werden, bevor überhaupt erkennbar ist, dass sich etwas geändert hat.
• Abhängigkeit: braucht eine grundsätzliche E-Mail-Versand-Freigabe (siehe Vorbehalt oben).

T16. E-Mail-Push-Einstellungen + Tagebuch-Check-in (hoch) ✅

• Original (Zeile 23): "E-Mail Push Service einstellbar in den Nutzereinstellungen bezüglich ein und ausschalten und der Uhrzeit; 'Automatisierte Erinnerungen (Push-Notifications): „Wie war der Tag mit Oma heute?" – Kurze 30-Sekunden-Check-ins (Schlaf, Stimmung, Vorfälle, Medikation).' -> Damit das Tagebuch gefüllt wird."
• Interpretation: Nutzer-Einstellung (an/aus + Uhrzeit) für eine tägliche Erinnerungs-E-Mail, die zum Ausfüllen des Pflegetagebuchs anregt. Braucht einen echten Zeit-Scheduler — die App hat bewusst keinen (siehe CLAUDE.md: Demo-Reset läuft absichtlich über einen "lazy check" bei Request statt über Cron, weil es "keine Task-Scheduler-Architektur gibt und das auch so bleiben soll"). Ein pro-Nutzer-Uhrzeit-getriggerter täglicher Mailversand ist ohne einen solchen Scheduler nicht sauber umsetzbar — das ist der eigentliche Grund für die hohe Aufwandseinschätzung, nicht die E-Mail an sich.
• Abhängigkeit: braucht eine grundsätzliche E-Mail-Versand-Freigabe (siehe Vorbehalt oben) + eine neue Scheduler-Infrastruktur.

T15. Benachrichtigung bei Umkreis-Änderung (hoch, Abh. T10–T13, T16) ✅

• Original (Zeile 21): "Benachrichtung im Umkreis hat sich einer der Umkreis-Suchen-Dienste geändert."
• Interpretation: Wenn sich Kontaktdaten eines in der Umkreissuche gefundenen Dienstes ändern, soll der Nutzer benachrichtigt werden. Braucht einen wiederkehrenden Hintergrundjob, der gespeicherte/relevante externe Datensätze regelmäßig neu abfragt und mit dem vorherigen Stand vergleicht (Diffing).
• Umgesetzt (2026-07-29): app/umkreis_favoriten_watch.py — täglicher Hintergrundjob (Postgres-Advisory-Lock, gleiches Muster wie T16), fragt alle gemerkten Favoriten in Sammel-Anfragen per Overpass-ID-Filter ab (statt einer Anfrage je Favorit — Rücksicht auf das knappe Rate-Limit des öffentlichen Mirrors, real erlebt: nur 2 gleichzeitige Slots pro IP), vergleicht Name/Adresse/Telefon/E-Mail/Webseite und verschickt bei Abweichung eine gebündelte E-Mail pro Konto. End-to-end gegen einen echten gemerkten Favoriten verifiziert. Details siehe CLAUDE.md.
• Bewusste Einschränkung: ein komplett aus OSM verschwundener Favorit wird nur geloggt, nicht per Mail gemeldet (bräuchte eine Dedupe-Schutzmaßnahme gegen tägliche Wiederholungsmeldungen, die für den ursprünglichen Wunsch überkonstruiert wäre).

---

Gruppe G: Engagement & Alltagsnutzen

Zwei eigenständige Punkte, beide vom Tester mit derselben Motivation versehen: Gründe schaffen, die App regelmäßig zu öffnen.

T17. Budget-Tracker Entlastungsbetrag (mittel-hoch, Abh. T2/T3) ✅

• Original (Zeile 24): "Budget-Tracker: Eine visuelle Übersicht: „Du hast diesen Monat noch 125 € Entlastungsbetrag übrig. Wenn du ihn bis zum 30.06. nicht nutzt, verfällt er!" [...] Vorraussetzung hierfür ist das die Beträge vorher für den Patienten eingepflegt worden sind, im nachgang kann man pro Patient die Ausgaben erfassen, um dann täglich den Restbetrag genauer zu sehen."
• Interpretation: Baut direkt auf der in T2/T3 gebauten Leistungen-Verwaltung auf (der Entlastungsbetrag ist bereits ein Katalog-Eintrag, den ein Patient zugewiesen bekommen kann). Braucht zusätzlich: ein Budget/Zeitraum pro Leistung, eine neue "Ausgabe"-Erfassung (Betrag, Datum, Beschreibung) pro Leistung, Restbetrag-Berechnung und einen Verfallsdatum-Hinweis (Entlastungsbetrag ist laut Katalog bis 30.6. des Folgejahres übertragbar).
• Abhängigkeit: braucht T2/T3 (Leistungen-Verwaltung muss existieren, bevor man ihr ein Budget/Ausgaben hinzufügen kann).

T18. Krisen-Checklisten/Guides (niedrig-mittel technisch, Scope noch offen) ✅

• Original (Zeile 25): "Checklisten für Krisenmomente: Schnell abrufbare Guides, wenn es brennt (z. B. „Plötzliche Hospitalisierung – was ist am ersten Tag zu tun?"). -> Ist nur ein Beispiel, aber die Rubrik -Guides finde ich gut, sollten wir ausarbeiten."
• Interpretation: Technisch günstig (im Kern eine neue, einfache Content-Seite mit einer Liste abrufbarer Anleitungstexte, ähnlich simpel wie die bestehende Rechtstext-Anzeige) — der eigentliche Aufwand liegt im Inhalt, nicht im Code: welche Krisensituationen genau, wie viele Guides, wie detailliert. Der Tester selbst sagt, das Beispiel sei nur exemplarisch und die Liste müsse noch gemeinsam erarbeitet werden.
• Abhängigkeit: keine technische, aber braucht zuerst ein Scoping-Gespräch (welche Guides genau), bevor sinnvoll geschätzt oder gebaut werden kann.

---

Gruppe H: Erinnerungen & Fristen (ergänzt 2026-07-30)

Drei Punkte rund um Wiedervorlagen/Fristen im Aufgaben- und Antragsbereich. T20/T21 hängen beide an bestehenden Aufgaben-Daten, T19 braucht zusätzlich ein neues Wiederholungs-Konzept.

T19. Hilfsmittel-Wiederholungs-Reminder (mittel) ✅

• Original (Zeile 27): "Hilfsmittelbeantragung nach Zeit - z.b. Kompressionsstrümpfe - nach Beantragung korrekte Wiederholung unter Aufgaben ablegen als Reminder für den nächsten Antrag."
• Interpretation: Bei zeitlich begrenzten Verbrauchs-Hilfsmitteln (z. B. Kompressionsstrümpfe, die regelmäßig neu verordnet/beantragt werden müssen) soll nach einer Beantragung automatisch eine Wiedervorlage-Aufgabe für den nächsten fälligen Antrag angelegt werden.
• Entscheidung (per Rückfrage bestätigt): feste Intervalle je Katalog-Eintrag statt eines vom Nutzer selbst einzutragenden Werts — Begründung des Betreibers: "der Nutzer kennt die Intervalle nicht und wird nicht danach suchen, das ist unser Part."
• Umgesetzt: neues, optionales Feld wiederholung_monate im Katalog-Eintrag (static_data/katalog.py), bewusst nur bei kk_kompression gesetzt (6 Monate, gängige Praxis bei Kompressionsstrümpfen) — nicht pauschal bei allen Hilfsmitteln, da für andere Einträge kein belastbares Intervall bekannt ist (gleiche Zurückhaltung wie beim ausgelassenen "Reha-Sport" in T13). Beim Zuweisen einer Leistung mit gesetztem Intervall (POST /api/patienten/{pid}/leistungen/katalog) wird automatisch eine Aufgabe mit faellig_am = heute + X Monate angelegt. End-to-end gegen den echten Endpunkt getestet (Leistung + Aufgabe korrekt angelegt, danach wieder entfernt).
• Abhängigkeit: keine mehr — Entscheidung ist gefallen.

T20. Kalender-E-Mail-Erinnerungen (1/7 Tage vorher) (mittel) ✅

• Original (Zeile 28): "Kalender Benachrichtungen via E-Mail 1 Tag vor Fälligkeit und 7 Tage vor Fälligkeit (softreminder)"
• Interpretation: Zusätzlich zur bereits bestehenden täglichen Tagebuch-Erinnerung (T16) sollen Aufgaben mit einem faellig_am-Datum 7 und 1 Tag vorher per E-Mail angekündigt werden.
• Umgesetzt: reminder_scheduler.py (T16) um _sende_aufgaben_faelligkeits_erinnerungen() erweitert — läuft im selben Hintergrund-Thread/Advisory-Lock, kein zweiter Scheduler nötig. Zwei neue bool-Spalten auf Aufgabe (erinnerung_7_tage_gesendet/erinnerung_1_tag_gesendet) verhindern Doppel-Versand je Schwellenwert. Aufgaben ohne patient_id (patientenlose Admin-Aufgaben) werden bewusst übersprungen, da sich kein Kontoinhaber ermitteln lässt. Mit echtem E-Mail-Versand end-to-end verifiziert.
• Abhängigkeit: baute auf derselben Scheduler-Infrastruktur wie T16 auf, keine neue Architektur nötig.

T21. Kalender-Überfälligkeiten in der Sidebar (niedrig-mittel) ✅

• Original (Zeile 29): "Kalender Überfälligkeiten in der Sidebare Visuell-Darstellen."
• Interpretation: Ein Badge/Zähler in der Seitenleiste (Navigationspunkt "Kalender" bzw. "Aufgaben"), der die Anzahl überfälliger (nicht erledigter, faellig_am in der Vergangenheit) Aufgaben anzeigt.
• Umgesetzt: reine Anzeige-Ergänzung im (app)/layout.tsx auf bereits vorhandenen useAufgaben()-Daten, kein neuer Endpunkt nötig — roter Badge am "Kalender"-Nav-Punkt, nur sichtbar wenn Anzahl > 0.
• Abhängigkeit: keine.

---

Gruppe I: UX-Überforderung / Onboarding (ergänzt 2026-07-30)

T24. Onboarding / "Was tue ich als nächstes?" (hoch) ✅

• Original (Zeile 35): "[…] nach dem Vorschlag der Pflegestufe werden mir ein Haufen Möglichkeiten angezeigt, aber es gibt keinen konkreten Leitfaden der mich begleitet […] das gilt auch mit dem Punkt Patient speichern, hier fehlt mir ein Vorschlag wie geht es weiter? […] ich als Kunde habe von der Thematik kein Verständnis und würde mir hier die Unterstützung wünschen."
• Klärungsgespräch (2026-07-30): Option C (dynamische Fortschritts-Checkliste) gewählt, personalisiert nach Zielgruppe (nicht Pflegegrad), erscheint bei jedem neu angelegten Patienten, Wortlaut gemeinsam entworfen (wie bei T18) und direkt abgenommen. Side-Plan (C:\Users\Daniel\.claude\plans\onboarding-naechste-schritte.md) enthält die vollständige Diskussionsgrundlage.
• Umgesetzt: Neue Komponente NaechsteSchritte.tsx auf der Patientenakte, ganz oben. Drei Schritte ("Antrag gestellt", "Unterlagen hochgeladen", "Bescheid erhalten"), bewusst ohne neuen Datenbank-Zustand — der Fortschritt wird ausschließlich aus bereits vorhandenen Anträgen/Dokumenten abgeleitet (kein manuelles Abhaken, keine Fehlerquelle durch veraltete Haken). Verschwindet automatisch, sobald alle drei Schritte erreicht sind. Schritt 1 verlinkt je nach Zielgruppe des Patienten zum passenden Musterbrief-Antragstyp (Alterspflege→Erstantrag Pflegegrad, Bedürftige→Grundsicherung, Behinderte→Eingliederungshilfe) — dafür wurde die Musterbrief-Seite um Query-Parameter-Vorbelegung (?patientId=&typ=) erweitert, die es vorher nicht gab.
• Zwei Nachbesserungen nach direktem Nutzerfeedback: (1) Farbkontrast — ursprünglich fast nur Sky-Blautöne plus schwach sichtbare ⬜/✅-Emoji, jetzt echte Icons (grün/indigo) und weißer statt blauer Kartenhintergrund. (2) "Unterlagen hochladen, welche denn?" — Schritt 2 zeigt jetzt die bestehende AntragCheckliste (T1) inline für den tatsächlich gestellten Antragstyp, mit konkreten Dokumentnamen statt eines generischen Links. Dabei einen echten, vorbestehenden Bug gefunden und behoben: musterbrief_erstellen() speicherte Eingliederungshilfe/Grundsicherung/Blindenhilfe-Anträge bislang immer stillschweigend als typ="erstantrag" (CheckConstraint erlaubte die drei Werte nicht) — Migration d7f1a3c5e8b2 behebt das, siehe CLAUDE.md.
• Abhängigkeit: keine mehr — Klärung ist abgeschlossen, umgesetzt und deployed.

---

Gruppe J: Antragsverfolgung (ergänzt 2026-07-30)

T25. Antragsstatus-Tracking + Widerspruchs-Automatik (hoch) ✅

• Original (Zeile 37): "nach der Antragsstellung, müsste ein Modul hinzukommen, das regelmässig abfrägt ob der gestellt Antrag schon bewilligt oder abgelehnt worden ist, wenn bewilligt dann eintragen wieviel Geld bei diesem Antrag bewilligt worden ist, bei Ablehnung direkter Verweis auf den Widerspruchs-Generator mit einer Übernahme der wichtigsten Infos um schnell einen Widerspruch erzeugen zu können."
• Wichtiger Realitätscheck: es gibt keine externe Status-API einer Kranken-/Pflegekasse, die sich automatisch abfragen ließe — "regelmäßig abfragen" ist technisch eine periodische Erinnerungs-Mail an den Nutzer, keine echte externe Automatisierung. Vorab mit dem Betreiber geklärt.
• Umgesetzt (2026-07-31): Magic-Link-E-Mail mit drei Antwort-Buttons (bewilligt/abgelehnt/noch offen), Erinnerungsintervall je Antragstyp, bei Ablehnung eines Pflegegrad-Antrags eigene "Keine Sorge"-Seite mit eingebettetem Mini-Widerspruch-Generator (vorbefüllt) und Fristeskalations-Mail ca. 7 Tage vor Ablauf der Widerspruchsfrist. Sowohl App-generierte als auch manuell nacherfasste externe Anträge werden getrackt. Details siehe CLAUDE.md "Antragsstatus-Tracking + automatischer Widerspruchs-Vorschlag".
• Abhängigkeit: keine mehr.

---

Gruppe K: Kleine Textergänzungen (ergänzt 2026-08-01)

Drei unabhängige, reine Content-/Formularfeld-Ergänzungen — kein struktureller Aufwand, jeweils eine einzelne bestehende Stelle erweitern.

T31. MDK-Text auf Ergebnisseite ergänzen (niedrig) ⛔ blockiert

• Original (Zeile 51): "Seite 4: offizieller Text des MDK noch hinzufügen (kleiner) <--- Rsp Marcel"
• Interpretation: Auf der Pflegegrad-Schätzungs-Ergebnisseite (Schritt 5 des "Neuer Patient"-Assistenten) fehlt noch ein offizieller Hinweistext des Medizinischen Dienstes (MDK/MD), vermutlich als kleingedruckter Zusatz zum bestehenden Disclaimer ("keine amtliche Feststellung"). "Rsp Marcel" deutet auf eine noch ausstehende Rückfrage/Textzulieferung von einer dritten Person hin — der genaue Wortlaut liegt vermutlich noch nicht vor.
• Geprüft (2026-08-01): kein vorhandener MDK-Volltext irgendwo im Repository (weder pflegepilot_v3 noch pflegepilot_alpha_v2) — nur der bereits bestehende Kurz-Disclaimer. Bewusst kein Text erfunden/angenommen, da ein fälschlich als "offizieller MDK-Text" ausgegebener, tatsächlich erfundener Text ein greifbares Falschdarstellungsrisiko wäre, besonders in Kombination mit T34 (Vertrauen in die Pflegegrad-Einschätzung steht dort ohnehin zur Diskussion).
• Abhängigkeit: braucht zuerst den tatsächlichen Text (von "Marcel") vom Betreiber, bevor er eingebaut werden kann.

T32. Musterbrief: Feld "Pflege wird durchgeführt von" (niedrig) ✅

• Original (Zeile 53): "Musterbrief Erstantrag: +Pflege wird durchgeführt von <--- Rsp Marcel"
• Interpretation: Im Musterbrief-Erstantrag-Generator fehlt ein Feld/eine Zeile, wer die Pflege durchführt (Angehörige/r, Pflegedienst, gemischt — ähnliche Information wird bereits in Interview-Schritt 6, Frage 1 der Leistungsauswahl erfasst, siehe "Interview-Wizard Schritt 6" in CLAUDE.md). Naheliegend: diesen bereits erfassten Wert (falls vorhanden) im Musterbrief-Text mit ausgeben, statt ein komplett neues Datenfeld einzuführen.
• Umgesetzt (2026-08-01): Genutzt wurde stattdessen das schon länger bestehende Patient.pflegeperson-Freitextfeld (aus Interview-Schritt 5, nicht Schritt 6) — kein neues Frontend-Feld nötig, der Router liest patient.pflegeperson direkt vom ohnehin geladenen Patient-Objekt und gibt bei vorhandenem Wert eine zusätzliche "Pflege durch: ..."-Zeile im generierten Brief aus. End-to-end verifiziert. Details siehe CLAUDE.md "Tester-Feedback-Nachtrag T26/T31/T32".
• Abhängigkeit: keine mehr.

T30. Dokumenten-Scan-OCR: durchsuchbare PDFs + Volltextsuche (mittel-hoch) ✅

• Original (Zeile 48): "Dokumenten Scan mittels OCR optimieren? Bedarf vorhanden??"
• Umfang geklärt (2026-08-02, zwei Rückfragen): durchsuchbare PDFs (OCR-Textebene), der erkannte Text soll für eine Suche über die Dokumente hinterlegt sein, plus eine Möglichkeit, Textstellen zu kopieren und manuell in die Generatoren (Musterbrief etc.) einzufügen — bewusst keine automatische Feld-Erkennung mit Ein-Klick-Übernahme (im Gespräch als Alternative vorgelegt, aber abgelehnt zugunsten der einfacheren, für jedes Dokumentlayout zuverlässigen Markieren-&-Kopieren-Lösung).
• Umgesetzt: bilder_zu_durchsuchbarem_pdf() (Tesseracts eigener PDF-Renderer, pypdf für Mehrseiten-Zusammenführung) erzeugt beim Dokumenten-Scan ein PDF mit unsichtbarer Textebene, fällt bei jedem OCR-Fehler auf das alte reine Bild-PDF zurück. Dokument.ocr_text (neue Spalte) speichert den Volltext. GET /api/patienten/{pid}/dokumente?suche=... filtert per ILIKE auf Bezeichnung + OCR-Text; die Patientenakte selbst filtert clientseitig auf der bereits geladenen Liste (damit die "Unterlagen hochgeladen"-Prüfung von T24 nicht während einer aktiven Suche verfälscht wird). Neuer "Text anzeigen"-Button öffnet den erkannten Text in einer markier-/kopierbaren Textarea. Details siehe CLAUDE.md "T30: Durchsuchbare Dokumenten-Scans + Volltextsuche".
• Nachtrag (2026-08-08): Betreiber-Feedback, dass ganz normal hochgeladene PDFs (nicht nur Kamera-Scans) ebenfalls durchsuchbar sein sollen — pdf_text_extrahieren() (PyMuPDF-Textebene, OCR-Fallback nur je Seite ohne Text) ergänzt, plus ein Admin-Button zur einmaligen rückwirkenden Nachverarbeitung bereits vorhandener PDFs. Das bestehende Suchfeld in der Patientenakte brauchte dafür keine Änderung (filterte schon immer auch auf ocr_text, fand bei PDFs nur deshalb nichts). Details siehe CLAUDE.md "T30-Nachtrag: Volltextsuche auch für hochgeladene PDFs + Admin-Nachverarbeitung".
• Abhängigkeit: keine mehr.

---

Gruppe L: UX-Feinschliff (ergänzt 2026-08-01)

Drei UI-Detailkorrekturen, jeweils an einer bestehenden, bereits gebauten Stelle.

T26. Geburtsdatum-Eingabe: Format + Nummernblock (niedrig-mittel) ✅

• Original (Zeile 40): "die Geburtstags Eingabe gefällt den Nutzern nicht, für das Eingeben von Datum Feldern bitte einmal umbauen auf DD.MM.JJJJ Schreibweise, bei Mobilgeräten soll sich direkt der Nummern Block öffnen statt der regulären Tastatur."
• Erste Einschätzung (2026-08-01) war falsch — fälschlich als "bereits durch den bestehenden Wheel-Picker gelöst" markiert. Betreiber-Korrektur (2026-08-02): genau der Wheel-Picker-Dialog war nicht gewünscht, sondern ein echtes Zahlen-Eingabefeld ohne Kalender-/Dialog-Umweg.
• Umgesetzt (2026-08-02): DateWheelPicker.tsx komplett durch components/DateInput.tsx ersetzt (Datei gelöscht) — drei Zahlenfelder Tag/Monat/Jahr mit Punkt-Trennzeichen, automatischem Fokus-Sprung, und Validierung auf kalendarisch mögliche Werte (31.02. wird korrekt abgelehnt, Schaltjahre korrekt berücksichtigt). Betrifft alle 6 Einbindungsstellen: Geburtsdatum (Neuer Patient, Bearbeiten), Bescheiddatum (Widerspruch, Status-bearbeiten), Gültig-ab (Ummeldung), Fällig-am (Aufgabe anlegen). Details siehe CLAUDE.md "T26-Korrektur: Datumsfelder als Zahlenfelder statt Kalender-Dialog".
• Abhängigkeit: keine mehr.

T33. Interview Schritt 6: Bestätigung vor Auto-Weiterleitung (niedrig-mittel) ✅

• Original (Zeile 54): "Patienten Neu Anlegen - Step 6 Fragenkatalog - Auswahl der Fragen führt direkt zur nächsten Frage ohne Bestätigung, das ist bei Fehleingaben umständlich."
• Interpretation: Betrifft den erst kürzlich gebauten geführten Frage-Dialog in Interview-Schritt 6 (siehe CLAUDE.md "Interview-Wizard Schritt 6: geführter Frage-Dialog"): eine Antwort springt bewusst automatisch zur nächsten Frage.
• Umgesetzt (2026-08-02): Betreiber wählte "Bestätigen-Button statt Auto-Advance" (analog zur letzten Unterfrage in Schritt 4). Ein Klick markiert die Antwort jetzt nur noch visuell, ein expliziter "Weiter"-Button (disabled bis eine Antwort gewählt ist) löst den Sprung aus. Nebeneffekt: beim Zurückgehen wird die vorherige Auswahl jetzt automatisch hervorgehoben. Bewusst nur Schritt 6 geändert, nicht die analoge Schritt-4-Logik — der Tester bezog sich explizit auf Schritt 6. Details siehe CLAUDE.md "Tester-Feedback-Nachtrag T27/T28/T29/T33".
• Abhängigkeit: keine mehr.

T27. Krisen-Checkliste: Wortwahl + Umbenennung (niedrig-mittel) ✅

• Original (Zeile 42): "Krisen-Checkliste überarbeiten, die Formulierung für Tiere und Pflanzen ist unpassend, diese kann man nicht pausieren. sowie die Begrifflichkeiten einfach gestalten, Hospitalisierung ist zu fachlich, nutze Plötzlich ins Krankenhaus. Die Krisen-Checkliste sollten wir auch umbenennen, da Krisen-Checkliste zu negativ klingt. Ideen?"
• Umgesetzt (2026-08-02): Neuer Rubrik-Name "Wegweiser für schwierige Momente" (Betreiber-Wahl aus drei vorgeschlagenen Optionen), geändert in Sidebar, Guides-Seite und der Landingpage-Feature-Kachel. Hospitalisierung-Guide heißt jetzt "Plötzlich ins Krankenhaus". Tiere/Pflanzen-Zeile aufgeteilt in Versorgung organisieren (Tiere/Pflanzen) vs. Termine absagen (nur Termine "pausieren" ergibt Sinn). Details siehe CLAUDE.md.
• Abhängigkeit: keine mehr.

T28. Guide "Umzug ins Pflegeheim" (niedrig-mittel) ✅

• Original (Zeile 44): "Checkliste - Umzug ins Pflegeheim ausarbeiten"
• Umgesetzt (2026-08-02): Betreiber wählte "selbst entwerfen lassen". Fünfter Guide mit 8 Schritten (Heimvergleich, § 43 SGB XI-Antrag mit Verweis auf den Musterbrief-Generator, Kostenübernahme/Eigenanteil, Adressänderung mit Verweis auf den Ummeldungs-Generator, Vertragskündigungen, Umzugslogistik, Nachsendeauftrag, emotionale Seite). Details siehe CLAUDE.md.
• Abhängigkeit: keine mehr.

---

Gruppe M: Bugfix (ergänzt 2026-08-01)

T29. Doppelte Anträge/Briefe: Root-Cause + Löschen (mittel) ✅

• Original (Zeile 46): "bei der Erstellung von Anträgen und Briefen ist es jetzt ein paar mal vorgekommen, das diese doppelt erzeugt wurden obwohl man diese nur einmal erstellt hat, baue einen Buttons ein zum Löschen von Anträgen und Briefen, sowie überprüfe einmal wie das passieren kann."
• Root-Cause geprüft (2026-08-02): alle 5 Brief-Generatoren hatten bereits disabled={isPending} — reiner Doppelklick-Bug ausgeschlossen. Plausiblere Ursache: verlorene Serverantwort während der langsamen WeasyPrint-PDF-Erzeugung (Server verarbeitet fertig, Client bekommt keine Bestätigung, Nutzer klickt erneut).
• Umgesetzt: serverseitiger Zeitfenster-Duplikat-Schutz (_juengster_duplikat() in routers/briefe.py) — inhaltsgleicher Antrag für denselben Patienten/Typ innerhalb 20 Sekunden wird zurückgegeben statt neu erzeugt. End-to-end verifiziert (identischer Aufruf → gleiche ID, anderer Typ → neue ID). Zusätzlich DELETE /api/antraege/{aid} neu ergänzt (fehlte komplett), löscht auch die PDF-Datei; "Löschen"-Button in der Patientenakte. Details siehe CLAUDE.md "Tester-Feedback-Nachtrag T27/T28/T29/T33".
• Abhängigkeit: keine mehr.

---

Gruppe N: Grundsatzfragen mit Klärungsbedarf (ergänzt 2026-08-01)

T34. Pflegegrad-Einschätzung: Berechnungsgrundlage / ggf. entfernen (mittel, Klärung nötig) 🟡 teilweise umgesetzt

• Original (Zeile 52): "Seite 5: vermuteter Pflegegrad zu hoch eingeschätzt (Bsp. Ferdinand Rommel). angegeben 3-4, Realität eher 2-3 <--- Berechnungsgrundlage infrage stellen. Pflegegrad-Einschätzung weglassen - kann unter Umständen falsche Erwartungen wecken."
• Interpretation: Ein konkreter Fehleinschätzungs-Fall wird berichtet, UND der Tester stellt selbst zur Diskussion, ob die Pflegegrad-Schätzung (die bereits mit einem Disclaimer versehen ist, siehe CLAUDE.md "bewusst grob") überhaupt angezeigt werden sollte, statt sie zu reparieren — das ist eine Produktentscheidung, kein reiner Bugfix. Passt inhaltlich zu T36 (siehe unten): die 5 Situationsfragen sind laut CLAUDE.md ("Interview-Wizard Schritt 4") bereits als bewusst grobe, ursachenunabhängige Heuristik dokumentiert, keine Nachbildung des amtlichen NBA-Begutachtungsverfahrens.
• Optionen zur Diskussion: (a) Berechnungsgrundlage/Gewichtung der 5 Fragen überarbeiten, (b) die Ergebnis-Bandbreite präsentieren statt einer Punktschätzung (falls nicht schon so), (c) die Einschätzung ganz weglassen und durch reine Aufklärung ersetzen (nur noch "das entscheidet der MD, hier ist wie der Prozess abläuft").
• Umgesetzt (2026-08-05), Option zwischen (b) und (c): im Rahmen der T35/T36-Klärung entschied sich der Betreiber dafür, die Einschätzung weiterhin anzuzeigen, aber nie mehr als Fakt — nur noch als "vermuteter Pflegegrad", mit einem neuen "bestätigt"-Zustand, der ausschließlich über eine echte Rückmeldung vom Medizinischen Dienst (Antragsstatus "genehmigt" + zugeteilter Pflegegrad, T25-Formular) gesetzt wird. Details siehe CLAUDE.md "T34-Anschluss/T35/T36: Pflegegrad vermutet/bestätigt...". Noch nicht Teil dieser Umsetzung: Option (a), eine tiefere Überarbeitung der Berechnungsgrundlage/Gewichtung der 5 Fragen selbst (das Scoring blieb bei diesem Durchlauf bewusst unverändert, siehe T36) — falls der ursprünglich gemeldete Fehleinschätzungsfall (Ferdinand Rommel, PG 3-4 statt 2-3) trotzdem noch als eigenständiges Problem gesehen wird, bräuchte das ein separates Klärungsgespräch.
• Abhängigkeit: braucht ein Klärungsgespräch mit dem Betreiber, bevor irgendetwas gebaut wird (gleiches Muster wie T18/T25 ursprünglich) — sollte zusammen mit T36 besprochen werden, da beide dieselbe Interview-Bewertungslogik betreffen.

---

Gruppe O: Große Themen — Plan erforderlich (ergänzt 2026-08-01)

Drei Punkte, bei denen der Umfang schon aus der Beschreibung klar "hoch" ist. Für keinen der drei wurde bisher ein Plan erstellt — passiert erst, wenn die Umsetzung tatsächlich beginnt (gleiches Vorgehen wie beim ursprünglichen T25-Side-Plan).

T35. 4-Wochen-Pflegetagebuch vor Erstantrag (hoch, Plan nötig) ✅

• Original (Zeilen 50 + 55): "Pflegetagebuch über 4 Wochen führen um bessere Einschätzung geben zu können, in die 8 Fragen ggf. eingebunden" / "Für Pflegegrad-Bestimmung muss heutzutage ein 4-Wochen-Tagebuch geführt werden, dies wird dann als Erstantrag beigefügt. Wichtig: die Einträge müssen beschreiben, was die zu pflegende Person noch im Alltag KANN. -> Hier müssten wir schon beim Anlegen eines Patienten vor dem Fragekatalog fragen, ob zuerst ein 4-Wochen-Tagebuch geführt wird — falls ja, Fragen skippen und direkt ins Tagebuch. Sobald erstellt, wird es mit dem Erstantrag verschickt (PDF-Generierung ohne Download, mit direktem Verweis)."
• Warum hoch: berührt mehrere bereits bestehende, aber bisher unabhängige Systeme gleichzeitig: den Interview-Wizard (neue Weiche vor Schritt 4), das bestehende Pflegetagebuch-Feature (bräuchte eine "Tagebuch-Modus für Erstantrag" mit Zeitraum-Tracking über 4 Wochen — aktuell ist das Tagebuch ein reines Journal ohne Ziel-/End-Datum-Konzept), die Formulierungs-Vorgabe ("was die Person noch KANN", direkt verwandt mit T36) und die PDF-/Antrags-Pipeline (Tagebuch-Einträge müssten als Anhang in den bestehenden Erstantrag-PDF-Generator einfließen, plus ein neuer "ohne Download, direkter Verweis"-Versandweg, der von den bisherigen fünf PDF-Generatoren abweicht).
• Offene Fragen für den Plan: Wie wird der 4-Wochen-Zeitraum technisch verfolgt (Start-/Enddatum am Patienten? Eigene Tabelle?)? Was passiert, wenn der Nutzer vorzeitig einen Erstantrag stellen will, bevor die 4 Wochen um sind? Wie werden die Tagebuch-Einträge im PDF formatiert/zusammengefasst? Bleibt die bisherige freie Tagebuch-Nutzung (ohne Erstantrag-Bezug) parallel bestehen?
• Umgesetzt (2026-08-05): Betreiber wählte "weiches Angebot, kein Blocker" statt einer Wizard-Gating-Logik (keine neue Weiche vor Schritt 4 nötig) und "separates zweites PDF pro Antrag" statt einer Freitext-Einbettung. Optionales Patient.tagebuch_start_am + "4-Wochen-Tagebuch starten"-Button in der Patientenakte, Fortschrittsanzeige "Tag X von 28". Musterbrief-Generator bekam eine Checkbox "Pflegetagebuch als Anhang beifügen" (nur bei Erstantrag/Höherstufung), die serverseitig ein zweites, tabellarisches PDF erzeugt (Antrag.tagebuch_pdf_pfad) und über denselben autorisierungsgeprüften Download-Endpunkt ausliefert. Bisherige freie Tagebuch-Nutzung ohne Zyklus-Bezug bleibt unverändert möglich. End-to-end gegen die echte lokale Docker-Postgres-Instanz verifiziert. Details siehe CLAUDE.md "T34-Anschluss/T35/T36: ...".
• Abhängigkeit: inhaltlich verwandt mit T36 (Formulierungsrichtung "kann noch" statt "kann nicht") — sollte im selben Klärungsgespräch besprochen werden.

T36. Interviews ressourcenorientiert umbauen (hoch, Plan nötig) ✅

• Original (Zeile 57): "Die gesamten Interviews müssten umgebaut werden, da es eher darum geht was kann der Patient noch, nicht was kann er nicht. !!!"
• Warum hoch: betrifft nicht nur Formulierungen, sondern potenziell die Bewertungslogik selbst — die 5 Pflegegrad-Situationsfragen (static_data/pflegegrad_regeln.py) und die 8 Leistungs-Fragen (Interview-Schritt 6, siehe CLAUDE.md) sind aktuell überwiegend defizitorientiert formuliert ("Braucht Hilfe bei...", "Gibt es Probleme mit..."). Eine reine Wortlaut-Änderung ("kann noch X" statt "braucht Hilfe bei X") ist einfach, aber: wenn sich dabei auch bedeutet, dass Antworten umgekehrt/anders gewichtet werden müssen, ändert das die Pflegegrad-Schätzung selbst — muss sorgfältig geprüft werden, dass das Scoring (neuSchaetzung()-Äquivalent) nicht kaputtgeht. Betrifft außerdem die Formulierungs-Vorgabe aus T35 (Tagebuch-Einträge sollen ebenfalls "kann noch" beschreiben) — beide Punkte hängen inhaltlich zusammen und sollten gemeinsam geplant werden.
• Offene Fragen für den Plan: Nur Wortlaut, oder auch Antwortstruktur (z. B. von Ja/Nein-"Problem vorhanden" zu einer Skala "kann noch X von Y Schritten selbstständig")? Bleibt die Punktzahl-Berechnung unverändert, nur mit umgekehrter Fragerichtung? Betrifft das auch die bereits leicht neutralisierten Fragen aus der Session vom 2026-07-30 ("Interview-Wizard Schritt 4: neutralere Fragen")?
• Umgesetzt (2026-08-05): Betreiber wählte die aufwendigere Option "Wortlaut + neue Antwortstruktur". Die 5 Situationsfragen sind jetzt Checklisten mit 3 capability-first Teilschritten je Frage ("Kann noch...") statt einer Einzelauswahl aus 4 Optionen. Scoring bewusst unverändert gehalten (Punktwert = 3 − Anzahl angekreuzter Teilschritte, reproduziert exakt den bisherigen 0-3-Wertebereich) — per Regressionstest mit den historischen Schwellenwerten bestätigt, keine Verschiebung der Pflegegrad-Schätzung. Betrifft nur Schritt 4, nicht die 8 Leistungs-Fragen aus Schritt 6 (reine Logistik-Fragen, keine Fähigkeits-Fragen). Details siehe CLAUDE.md.
• Abhängigkeit: siehe T35 (gemeinsames Klärungsgespräch sinnvoll) und T34 (falls die Pflegegrad-Einschätzung ohnehin überarbeitet/entfernt wird, ändert das den Rahmen für diesen Umbau).

T37. Notfall-Card: Wallet-QR-Code zur Patientenverfügung (hoch, Plan nötig) ✅

• Original (Zeile 58): "Können wir eine Funktion einbauen mit der man in das Apple Wallet / Google Wallet einen QR-Code integriert, von dem aus ein Notarzt z. B. die Patientenverfügung auf dem Server einsehen kann? Jeder Nutzer kann selbst definieren was durch den QR-Code öffentlich gemacht werden soll. Quasi eine Notfall-Card."
• Warum hoch: komplett neues Feature mit mehreren eigenständig aufwendigen Teilen: (1) ein öffentlich per QR-Code erreichbarer, unauthentifizierter Lesezugriff auf ausgewählte Patientendaten — ein grundlegend neues Sicherheits-/Zugriffsmodell für eine App, die bisher konsequent alles hinter Login schützt (vergleichbar am ehesten mit den bestehenden Magic-Link-Token aus T25, aber dort führt der Link immer zu einer eingeloggten Session, nie zu einer öffentlichen Anzeige); (2) eine Auswahl-UI, mit der der Nutzer pro Patient festlegt, welche Felder überhaupt öffentlich sichtbar sein dürfen; (3) echte Apple-Wallet-Pass-Erstellung (.pkpass-Format) verlangt ein Apple-Developer-Zertifikat/Signierprozess — eine eigene, nicht triviale Infrastruktur-Abhängigkeit, die aktuell in keinem Teil dieser App existiert; Google-Wallet braucht ebenfalls eine eigene Entwickler-Registrierung/API-Anbindung. Ein einfacherer erster Schritt (nur QR-Code zu einer öffentlichen Web-Ansicht, ohne echte Wallet-Pass-Dateien) wäre deutlich günstiger, deckt aber nicht die explizit gewünschte Wallet-Integration ab.
• Sicherheits-/Datenschutz-Vorbehalt (wichtig für den Plan): ein unauthentifizierter, öffentlicher Zugriff auf medizinische Daten (auch nur auf einen Teil davon) ist ein deutlich anderes Risikoprofil als alles bisher in dieser App Gebaute — braucht mindestens einen nicht erratbaren, langen Token (kein sequenzieller Identifier), eine Widerrufs-/Neugenerierungs-Möglichkeit falls die Karte/das Handy verloren geht, und eine bewusste Entscheidung, ob/wie das in der Datenschutzerklärung offengelegt wird (ähnliches Muster wie bei der Umkreissuche-Drittübermittlung, aber hier geht es um selbst bereitgestellte Daten, nicht um einen Drittanbieter).
• Abhängigkeit: keine zu anderen Punkten dieser Liste, aber der aufwendigste und sicherheitskritischste Einzelpunkt — sollte nicht ohne ausführliches Klärungsgespräch (Scope: nur Web-Ansicht vs. echte Wallet-Passes, welche Felder maximal freigebbar, Widerruf) begonnen werden.
• Umgesetzt (2026-08-06): vier Klärungsfragen per AskUserQuestion beantwortet — Stufenplan (erst Web-Ansicht, echte Wallet-Passes zurückgestellt), Datenumfang Patientenverfügung + feste Notfall-Basisdaten (Blutgruppe/Allergien/Medikamente/Notfallkontakt, keine freie Feldauswahl), Widerruf über jederzeit neu generierbaren Token, Zugriffs-Log mit IP + Zeitstempel. Danach Plan-Mode-Durchlauf, Umsetzung, End-to-end-Verifikation gegen die lokale Docker-Postgres-Instanz und Deploy auf die NAS. Zwei Bugs erst nach echter Nutzung durch den Betreiber gefunden: (1) das Zugriffs-Log zeigte durchgehend die interne Docker-Netzwerk-IP des web-Containers statt der echten Besucher-IP, weil der serverseitige Datenabruf der öffentlichen Seite am Reverse-Proxy vorbeilief; (2) der "Patientenverfügung öffnen"-Link zeigte auf localhost:8100 statt der echten Domain, weil || statt ?? für die absichtlich leere NEXT_PUBLIC_API_URL auf der NAS verwendet wurde. Beide behoben, verifiziert, erneut deployed. Details siehe CLAUDE.md "T37: Notfall-Card" (inkl. Root-Cause und Lehren für künftige serverseitige Fetches).

---

Gruppe P: Eigene Ideen aus Betreiber-Gesprächen (nicht aus Tester-Feedback, ergänzt 2026-08-05)

Punkte, die nicht aus Feedbackfromtester.txt stammen, sondern aus direkten Gesprächen mit dem Betreiber entstanden sind — gleiche Backlog-Datei, damit es nur eine Quelle der Wahrheit gibt.

B1. Umkreissuche: "Nicht gefunden?"-Ergänzung / OSM-Beitrag anregen (niedrig-mittel, bewusst zurückgestellt)

• Anlass: Betreiber berichtete, dass bei einigen Testern bekannte, real existierende Physiopraxen und Pflegedienste in der Umkreissuche nicht gelistet wurden. Root-Cause-Diskussion (siehe Chat-Verlauf, keine Code-Recherche nötig): das ist kein API-/Bug-Problem, sondern eine Datenvollständigkeits-Lücke in OpenStreetMap selbst (die zugrundeliegende Datenquelle der Umkreissuche, siehe CLAUDE.md "Umkreissuche für lokale Pflege-Dienstleister") — ein Wechsel auf Photon oder Overture Maps wurde als Alternative diskutiert und verworfen, da beide ebenfalls überwiegend OSM-gespeiste Daten liefern und die Lücke damit nicht schließen würden.
• Idee: ein "Nicht gefunden?"-Hinweis/Link in der Umkreissuche-UI, der Nutzer ermutigt, einen fehlenden Anbieter direkt bei OpenStreetMap zu ergänzen — behebt die Lücke dauerhaft und kostenlos (kommt allen OSM-Nutzern zugute, nicht nur dieser App), statt nur das Symptom zu kaschieren.
• Status: vom Betreiber ausdrücklich zurückgestellt ("später angreifen, vorher haben wir noch genug aktive Posten") — nicht vergessen, aber keine Priorität vor den übrigen offenen Punkten (T34/T37).
• Abhängigkeit: keine. Kann jederzeit unabhängig von T34/T37 aufgegriffen werden, wenn Zeit dafür ist.

---

Bekannte Fehlerberichte (kein Feature-Wunsch)

Safari/iOS: Wizard springt von Schritt 2 zurück auf Schritt 1 statt zu Schritt 3

• Original (Zeile 33): "Browser Safari hat jetzt ein paar mal Probleme erzeugt beim Erstellen von neuen Patienten, hier ist das Problem, Nutzer füllt Step 1 aus geht weiter auf Step 2 und wird dann auf Step 1 zurückgeführt statt auf Step 3 weiter geleitet zu werden. Ich konnte das Problem nicht validieren, da kein Safari und iOS vorort. In Google Chrome und Firefox konnte ich es nicht reproduzieren."
• Einordnung: Die Wizard-Reducer-Logik selbst (NEXT-Action in patienten/neu/page.tsx) hat keinen Bug für den Übergang Schritt 2→3 — ein reiner State-Bug hätte nicht "zurück auf Schritt 1" zur Folge, sondern höchstens ein Hängenbleiben auf Schritt 2. Ein kompletter Reducer-Reset auf den Ausgangszustand (initialState.step = 1) erklärt das beschriebene Verhalten dagegen exakt — am plausibelsten durch einen unerwarteten Remount der Komponente.
• Bereits behoben, vermutlich derselbe Grund wie das separat gemeldete "Lädt…"-Hängenbleiben (siehe CLAUDE.md "Frontend-Produktions-Build statt next dev" und "iOS Safari: Autofill-Attribute nachgerüstet", beide 2026-07-29 umgesetzt): die App lief bis dahin über den Next.js-Entwicklungsserver (next dev/Turbopack) statt eines echten Produktions-Builds — dessen Hot-Module-Reload-Mechanismus kann unter ungünstigen Netzwerkbedingungen (Safari + Reverse-Proxy + Websocket) einen kompletten Seiten-Reload auslösen, was einen React-Komponenten-Remount und damit exakt einen State-Reset auf Schritt 1 zur Folge hätte. Umgestellt auf einen echten next build/next start-Produktions-Build, siehe CLAUDE.md für Details.
• Noch nicht am echten Gerät bestätigt (Betreiber hat kein iOS-/Safari-Testgerät) — beim nächsten Tester-Kontakt gezielt nachfragen, ob der Sprung zurück auf Schritt 1 seit dem 2026-07-29-Deploy noch auftritt, bevor eine weitere Ursache gesucht wird.

---

Empfohlene Bearbeitungsreihenfolge (Gruppen + Aufwand kombiniert)

1. ✅ T9 → T4 (niedrig, unabhängig, schnelle Gewinne)
2. ✅ T1 (mittel, unabhängig)
3. ✅ T2 → T3 (mittel → mittel-hoch, Kette)
4. ✅ T5 → T6 (mittel-hoch → mittel, Kette)
5. ✅ T18 (Krisen-Checklisten, Guide-Liste mit Betreiber abgestimmt)
6. ✅ T17 (Budget-Tracker, baut auf T2/T3 auf)
7. ✅ T14 (Katalog-Änderungsbenachrichtigung, Katalog-Snapshot-Vergleich)
8. ✅ T16 (Reminder-Scheduler, E-Mail-Freigabe erweitert)
9. ✅ T10 → T11 → T12 → T13 (Umkreissuche-Familie, OSM/Nominatim/Overpass, alle 10 Kategorien live)
10. ✅ T8 (OCR-Kartenerfassung, Tesseract offline, nur GKV/eGK)
11. ✅ T15 (Benachrichtigung bei Umkreis-Änderung, täglicher Hintergrundjob, Sammel-Abfrage per Overpass-ID-Filter)
12. ✅ T13b (24h-Pflegedienste, zusätzliches Feedback vom 2026-07-29)
13. ✅ T22 (Adresse-Autofill "wie mein Konto", niedrig, direkte Kopie des T4-Musters)
14. ✅ T21 (Kalender-Überfälligkeiten Sidebar, niedrig-mittel, reine Anzeige auf vorhandenen Daten)
15. ✅ T20 (Kalender-E-Mail-Erinnerungen, mittel, Erweiterung des bestehenden T16-Schedulers)
16. ✅ T19 (Hilfsmittel-Wiederholungs-Reminder, mittel, feste Katalog-Intervalle nach Rückfrage bestätigt)
17. ✅ T24 (Onboarding/Nächste-Schritte, hoch, dynamische Fortschritts-Checkliste ohne neuen DB-Zustand)
18. ✅ T25 (Antragsstatus-Tracking, hoch, Magic-Link-Erinnerungen + Widerspruchs-Automatik)
19. ✅ T32 (Musterbrief "Pflege durch", nutzt bestehendes pflegeperson-Feld, kein neues Formularfeld)
20. ✅ T26 (Geburtsdatum-Format, bereits durch Date-Wheel-Picker gelöst — geprüft, kein Code geändert)
21. ⛔ T31 (MDK-Text, blockiert — braucht den echten Wortlaut von "Marcel"/Betreiber)
22. ✅ T27 → T28 (Wegweiser-Umbenennung + Wording-Fixes + fünfter Guide "Umzug ins Pflegeheim")
23. ✅ T33 (Bestätigen-Button statt Auto-Advance in Interview Schritt 6)
24. ✅ T29 (serverseitiger Duplikat-Schutz für Antrag-Erstellung + Lösch-Endpunkt/-Button)
25. ✅ T30 (durchsuchbare Dokumenten-Scans + Volltextsuche, Umfang nach Klärung mittel-hoch statt niedrig)
26. 🟡 T34 (mittel, teilweise umgesetzt — Pflegegrad-Anzeige jetzt vermutet/bestätigt statt Punktschätzung als Fakt; Berechnungsgrundlage/Gewichtung selbst nicht angefasst)
27. ✅ T35 → T36 (hoch, umgesetzt 2026-08-05 — 4-Wochen-Tagebuch als weiches Angebot + zweites PDF, Situationsfragen als ressourcenorientierte Checklisten ohne Scoring-Verschiebung)
28. ✅ T37 (hoch, umgesetzt 2026-08-06 — Notfall-Card, Stufenplan Web-Ansicht zuerst, inkl. zweier nach dem Deploy gefundener und behobener Bugs)
29. 🕓 B1 (niedrig-mittel, bewusst zurückgestellt — Umkreissuche "Nicht gefunden?"-Ergänzung, erst nach T34 angehen)

Stand 2026-08-06: nur noch T34 (teilweise) und B1 (bewusst zurückgestellt) offen, T31 weiterhin blockiert. T1–T30, T32, T33, T35, T36, T37 umgesetzt/erledigt und deployed. T31 ist blockiert (braucht den echten MDK-Text von "Marcel"/Betreiber). T34 wurde im für T35/T36 nötigen Umfang mitentschieden (Anzeige vermutet/bestätigt); eine tiefere Überarbeitung der Berechnungsgrundlage selbst steht weiterhin offen, falls gewünscht. B1 ist explizit niedrig priorisiert. Zusätzlich weiterhin ein noch nicht am echten Gerät bestätigter Safari-Bug-Bericht, siehe "Bekannte Fehlerberichte".