Das Dashboard beantwortet die Frage, was heute ansteht - nicht, welche Daten es gibt. Jede Kachel endet in einer Handlung: Fristen-Ampel, wartet auf andere (mit Tagen seit dem letzten Kontakt), offene Nachforderungen des Bezirks mit Fortschrittsbalken, ungepruefter Posteingang, unverbuchte Belege, Kennzahlen. Zwoelf Abfragen in einem Promise.all, kein N+1. Cent-Betraege werden beim Verlassen der Serverseite gewandelt. Kacheln zu Modulen, die ein Mitleser nicht freigegeben bekommen hat, entfallen ganz - sie zeigen nicht "0", denn das waere eine Aussage ueber Daten, die er nicht sehen darf. Kontaktprotokoll als Schnellerfassung: Datum vorbelegt, Art als grosse Knopfreihe, Dauer als Schnellwahl, ein Freitextfeld. Alles andere eingeklappt. Ziel sind unter 20 Sekunden am Handy. Das Haekchen "persoenlicher Kontakt zur betreuten Person" ist bewusst NICHT vorbelegt - es wandert in den Jahresbericht nach § 1863 BGB, und ein versehentlich gesetztes Haekchen waere dort eine falsche Angabe gegenueber dem Gericht. Aus demselben Grund gilt der Textbaustein "regelmaessiger persoenlicher Kontakt" erst ab persoenlichem Kontakt in mindestens 75 Prozent der Monate. Sonst schreibt die Auswertung ausdruecklich, dass kein persoenlicher Kontakt dokumentiert ist. Ein geschoenter Bericht hilft niemandem. Protokolldaten werden als 12:00 UTC gespeichert und durchgaengig in UTC gerechnet, sonst kippt die Zeitzone einzelne Besuchstage. 51 Tests. Etappe: 2 Phase: Alltag
4.8 KiB
Schema-Wünsche aus Dashboard und Kontakten
Diese Datei sammelt, was beim Bauen von /heute und den Kontakten
aufgefallen ist. prisma/schema.prisma wurde nicht geändert – alles
hier ist ein Vorschlag für eine spätere Migration, mit der Begründung
daneben.
1. Heimkostenmonat: Kostenseite und Deckungsseite überschneiden sich
Was ich gebaut habe. Die Kennzahl „Deckungslücke“ rechnet exakt nach der Gruppierung im Schema:
Gesamtkosten = pflegeEigenanteil + unterkunftVerpflegung
+ investitionskosten + ausbildungsumlage + zusatzleistungen
Deckung = pflegekasse + leistungszuschlag + rente
+ sonstigeEinkuenfte + sozialhilfe + eigenmittel
Deckungslücke = Gesamtkosten − Deckung
Das Problem. pflegeEigenanteilCent heißt „Eigenanteil“. Der
einrichtungseinheitliche Eigenanteil ist definitionsgemäß schon um die
Leistung der Pflegekasse nach § 43 SGB XI gekürzt. Steht in derselben
Zeile zusätzlich pflegekasseCent als Deckung, wird dieser Betrag doppelt
gezählt, und das Dashboard weist eine Überdeckung aus, die es nicht gibt.
Dasselbe gilt für leistungszuschlagCent (§ 43c SGB XI), der den
Eigenanteil ebenfalls mindert.
Wunsch. Entweder
- den Kommentar am Feld schärfen: „
pflegeEigenanteilCentist der Brutto-Pflegesatz;pflegekasseCentundleistungszuschlagCentwerden davon abgezogen" – dann stimmt die Rechnung oben; oder - ein Feld
heimrechnungGesamtCentergänzen, das schlicht die Summe der Heimrechnung trägt, und die Aufteilung nur noch informativ führen.
Solange das offen ist, sollte das Heim-Modul entweder den Bruttosatz oder
pflegekasseCent = 0 erfassen – konsequent das eine oder das andere.
Wer die Kachel zum ersten Mal sieht und einen absurden Wert findet, weiß
mit dieser Notiz, woran es liegt.
2. Kontaktprotokoll.datum könnte @db.Date sein
Was ich gebaut habe. Das Feld ist DateTime. Die Schnellerfassung
kennt nur einen Tag, keine Uhrzeit; gespeichert wird deshalb bewusst
12:00 UTC. Um die Mittagszeit herum verschiebt keine Zeitzone den
Eintrag auf den Vor- oder Folgetag, und die Auswertung („an wie vielen
Tagen bestand persönlicher Kontakt?") zählt zuverlässig.
Wunsch. datum DateTime @db.Date – dann verschwindet die
12:00-Konvention, und der Typ sagt, was gemeint ist. Fachlich zählt beim
Jahresbericht nach § 1863 BGB der Tag, nicht die Uhrzeit.
Falls die Uhrzeit später doch gebraucht wird (Zeiterfassung für die
Vergütung), wäre ein zusätzliches beginnUhrzeit String? sauberer als das
Datumsfeld doppelt zu belegen.
3. Kontakt: kein Feld für „nicht mehr zuständig"
Sachbearbeiter wechseln. Heute bleibt nur der Papierkorb – dann ist aber auch die Gesprächshistorie aus dem Verzeichnis verschwunden, obwohl sie für den Jahresbericht und für Rückfragen weiter gebraucht wird.
Wunsch. aktivBis DateTime? @db.Date oder aktiv Boolean @default(true).
Das Verzeichnis würde inaktive Kontakte einklappen statt löschen, und die
Historie bliebe sichtbar. Ein nachfolgerId String? auf denselben Typ
wäre die Kür: „Frau Krämer, jetzt Herr Sandner".
4. Nachforderung: kein betreuteId
Nachforderung hängt nur über antrag an der betreuten Person. Jede
Abfrage muss deshalb über die Beziehung filtern:
where: { antrag: { betreuteId, geloeschtAm: null }, geloeschtAm: null }
Das funktioniert, ist aber die einzige Stelle im Dashboard, an der die
Zugriffsprüfung nicht direkt auf einer Spalte sitzt. Bei einer späteren
Row-Level-Security in Postgres wäre eine denormalisierte betreuteId
(wie bei DokumentVerknuepfung) die einfachere Grundlage.
5. Vermoegensposten: kein Kennzeichen „zählt nicht in die Summe"
Die Kachel „Vermögen" summiert je Posten den jüngsten Wertstand und
zieht VERBINDLICHKEIT ab. Posten ohne jeden Wertstand werden gesondert
gezählt und ausgewiesen („2 Posten haben noch keinen Wert und fehlen in
dieser Summe") – stillschweigend als 0 zu führen wäre in einer
Rechnungslegung nach § 1865 BGB falsch.
Offen bleibt der Fall „bewusst nicht bewertbar" (Hausrat, persönliche Gegenstände). Heute sieht er aus wie „vergessen".
Wunsch. ohneWertBegruendung String? – analog zu
belegFehltBegruendung bei Buchung. Dann kann die Kachel zwischen
„fehlt noch" und „bewusst ohne Wert" unterscheiden.
6. Kein Modell für die Sachstandsanfrage
Die Kachel „Wartet auf andere" verlinkt auf
/vorgaenge/<id>?aktion=sachstandsanfrage. Ob daraus ein Schreiben wird,
entscheidet das Vorgangsmodul. Wird eine Anfrage verschickt, sollte
Vorgang.letzterKontaktAm fortgeschrieben werden – sonst bleibt der
Vorgang für immer rot, obwohl gerade nachgefasst wurde. Das ist kein
Schema-Wunsch, sondern eine Verabredung zwischen den Modulen; sie steht
hier, damit sie nicht verloren geht.