betreuungs-cockpit/docs/schema-wuensche/substanz.md

Schema-Wünsche aus Etappe 6 „Substanz“

Das Schema wurde nicht angefasst. Hier steht, was beim Bauen von Immobilie, Verträgen und Pflege gefehlt hat — mit der Umgehung, die stattdessen gewählt wurde, damit später klar ist, was zu migrieren wäre.

---

1. Buchung.immobilieId

Problem. Das Kostenkonto der Immobilie (Grundsteuer, Gebäude­versicherung, Energie, Wasser, Instandhaltung, Schornsteinfeger) kann nur über die Kategorien GRUNDSTEUER, IMMOBILIE_BETRIEBSKOSTEN, IMMOBILIE_INSTANDHALTUNG und MIETEINNAHME zusammengestellt werden. Eine Zuordnung „diese Buchung gehört zu diesem Objekt“ gibt es nicht.

Folge. Solange nur ein Objekt geführt wird, ist die Zuordnung eindeutig. Bei einem zweiten Grundstück wären die Zahlen falsch. Die Oberfläche sagt das an der Auswertung ausdrücklich dazu.

Wunsch.

model Buchung {
  immobilieId String?
  immobilie   Immobilie? @relation(fields: [immobilieId], references: [id], onDelete: SetNull)
}

---

2. Eigene Buchungskategorie für die Gebäudeversicherung

BuchungKategorie.VERSICHERUNG sammelt alle Versicherungen ein, auch Sterbegeld und Haftpflicht. Für das Kostenkonto eines Hauses ist das zu grob; die Gebäudeversicherung muss dort erscheinen, die private Unfallversicherung nicht.

Umgehung. Die Gebäudeversicherung wird als IMMOBILIE_BETRIEBSKOSTEN gebucht. Das steht als Hinweis an der Auswertung.

Wunsch. IMMOBILIE_VERSICHERUNG in BuchungKategorie.

---

3. Inventarstueck — Inventarliste der Wertgegenstände

Problem. Für die Fotodokumentation und die Inventarliste eines leerstehenden Hauses fehlt ein Modell mit bezeichnung, raum, geschaetzterWertCent und verbleib. Vermoegensposten passt fachlich (Art WERTGEGENSTAND, Verknüpfung auf immobilieId, Wert über Wertstand, Fotos über DokumentVerknuepfung), hat aber keine Felder für Raum und Verbleib.

Umgehung. Raum, Verbleib und Bemerkung stehen als beschriftete Zeilen im ohnehin verschlüsselten notizenVerschluesselt; gelesen und geschrieben wird das ausschließlich über src/lib/immobilie/inventar.ts. Der geschätzte Wert liegt als Wertstand mit der Quelle „eigene Schätzung“.

Wunsch.

model Inventarstueck {
  id                   String    @id @default(cuid())
  betreuteId           String
  immobilieId          String?
  bezeichnung          String
  raum                 String?
  geschaetzterWertCent BigInt?
  verbleib             String?   // "im Haus", "Heimzimmer", "verschenkt", "entsorgt", "verkauft"
  bemerkungVerschluesselt String?
}

---

4. Immobilie.checklisteUebernommenAm

Ob die Leerstands-Checkliste schon einmal übernommen wurde, lässt sich nur daran ablesen, ob ImmobilienCheckpunkt-Zeilen existieren. Das genügt, weil die Übernahme über den stabilen Titel abgleicht und keine Dubletten erzeugt — sauberer wäre ein systemSchluessel am Checkpunkt.

Wunsch.

model ImmobilienCheckpunkt {
  systemSchluessel String?
  @@unique([immobilieId, systemSchluessel])
}

Bis dahin dient der titel als Schlüssel; er darf deshalb beim Bearbeiten eines übernommenen Punktes nicht geändert werden, ohne dass die nächste Übernahme ihn erneut anlegt.

---

5. Pflegegrad-Historie als eigenes Modell

Betreute trägt den aktuellen Pflegegrad, seit wann und das Bescheiddatum. Frühere Grade gehen verloren, sobald der Grad hochgestuft wird — für den Jahresbericht und für eine Höherstufung ist aber genau die Kette interessant.

Umgehung. Jede Begutachtung wird als Gesundheitsereignis mit der Art PFLEGEBEGUTACHTUNG erfasst; der Verlauf zeigt daraus die Historie. Der Grad selbst steht im Titel und in der verschlüsselten Beschreibung, ist also nicht auswertbar.

Wunsch.

model Pflegegradstand {
  id            String    @id @default(cuid())
  betreuteId    String
  grad          Int
  gueltigAb     DateTime  @db.Date
  bescheidVom   DateTime? @db.Date
  antragAm      DateTime? @db.Date
  ergebnis      String?   // "hochgestuft", "abgelehnt", "unverändert"
}

---

6. Strukturierte Felder am Gesundheitsereignis

Die Schnellerfassung für COPD braucht Zahlen, die man später auswerten will: Sauerstofffluss in l/min, Stunden pro Tag, Schweregrad einer Exazerbation, ob stationär behandelt wurde.

Umgehung. Diese Angaben werden als beschriftete Zeilen in die verschlüsselte Beschreibung geschrieben (src/lib/pflege/ereignis-details.ts). Sie sind damit lesbar, aber nicht summierbar. Auswertbar bleiben nur Art, Datum, bisDatum und abwesenheitstage — das reicht für Exazerbationen je Jahr und Krankenhaustage je Jahr.

Wunsch. Ein details Json?-Feld am Gesundheitsereignis wäre falsch (Gesundheitsdaten gehören verschlüsselt). Besser wären wenige typisierte, unverschlüsselte Kennzahlen ohne Diagnosebezug:

model Gesundheitsereignis {
  stationaer        Boolean @default(false)
  schweregrad       Int?    // 1 leicht, 2 mittel, 3 schwer
}

---

7. Vertrag.vertragsnummerVerschluesselt war nicht registriert

Das Feld steht im Schema, fehlte aber in VERSCHLUESSELTE_FELDER in src/lib/crypto/feld.ts — sealen('Vertrag', { vertragsnummer }) hätte geworfen. Der Eintrag wurde ergänzt; das Schema blieb unverändert.

---

8. Vertrag.laufzeitJahre

Der Kündigungsrechner braucht die Vertragsdauer, um die Verlängerung zu bestimmen. Das Schema kennt nur beginnAm, endeAm und kuendigungsfristMonate.

Umgehung. Fehlt endeAm, rechnet src/lib/vertraege/kuendigung.ts mit einer Verlängerung um ein Jahr — der Regelfall bei Versicherungen — und schreibt diese Annahme als Hinweis in das Ergebnis.

Wunsch.

model Vertrag {
  laufzeitJahre            Int?
  verlaengertSichAutomatisch Boolean @default(true)
}