Kunden-Besprechungspunkte — Medidentas (lebend)
Lebende Liste offener Punkte, die mit dem Kunden zu besprechen/bestätigen sind — bevor die zugehörige
Umsetzung final gebaut wird. Ergänzend zum Decision-Log.md (dort stehen die getroffenen Entscheidungen)
und zur Offene-Punkte-Tabelle in HANDOFF.md §4. Pflege (verbindlich): je PR mitführen — neue Punkte
als KB-n ergänzen, erledigte auf ✅ setzen (mit Datum + Ergebnis), nicht löschen (Audit-Trail, G-4).
| ID | Status | Thema | Was ist zu klären? | Bezug |
|---|---|---|---|---|
| MED-KB-13 | 🟡 tlw. beantwortet | Kunden-Self-Service-Portal: Auth-Mechanismus + DSGVO/AVV-Freigabe (MED-D-279) | Vor dem Bau der öffentlichen Auth-Fläche (Slice S2/S5) mit dem Kunden zu klären: (1) Auth-Mechanismus ✅ beantwortet (MED-D-283, 2026-08-27): „passwortlos zum Testen" → passwortlos/Magic-Link, flag-gated gebaut (Passwort-Login nur auf ausdrücklichen Wunsch). Verbleibend vor Go-Live: (2) DSGVO/revDSG — Rechtsgrundlage (Art. 6(1)(b) Vertragserfüllung), Betroffenenrechte-Prozess (Auskunft/Berichtigung/Löschung), AVV mit Mail-/Auth-Provider, EU-/CH-Residenz bestätigen; Medidentas = Verantwortlicher. (3) Mehrere Kontaktpersonen je Mandant mit eigenem Login — gewünscht? (4) Welche Stammdatenfelder darf der Kunde proaktiv aktualisieren (Einreichung → 4-Augen-Freigabe)? (5) Go-Live setzt realen Mail-Versand (OP-DM-8) voraus. | MED-D-279 · RISK-33 · Golden Rule (Zero Trust) · OP-DM-8 · docs/architektur/Kunden-Self-Service-Portal.md |
| MED-KB-12 | 🟡 offen | Definition „offen zu fakturieren" im Cockpit-Filter (MED-D-252) | Der neue Cockpit-Filter „Zu fakturieren" listet Mandanten mit abrechenbarer, noch nicht abgerechneter Leistungszeit (abrechenbar && !abgerechnet, R13-F08/F09; abgeleitet, nicht persistiert). Mit dem Kunden zu bestätigen: (1) Ist „abrechenbar & nicht abgerechnet" die richtige Definition von „hier ist etwas offen zu fakturieren", oder braucht es zusätzliche Kriterien (z. B. Mindest-Minuten/-Betrag, nur abgeschlossene Aufträge, nur ab einem Stichtag)? (2) Soll ein Betrag statt/neben den Minuten angezeigt werden (setzt Stundensätze/Preise voraus — heute nicht im Modell)? (3) Abgrenzung zur echten Rechnungsstellung: die Rechnung entsteht extern (SevDesk, OP-INVOICE-1); wann gilt Zeit als „abgerechnet" — bei Übergabe an SevDesk, bei Rechnungsstellung oder bei Zahlungseingang (bestimmt, wann der Filter den Mandanten fallen lässt)? | MED-D-252 · OP-INVOICE-1 · R13-F08/F09 · service.ts (offeneFakturierungMinuten) |
| KB-1 | 🟡 offen | Mandanten-Gruppierung — Ablage-Wirkung | Wie soll die "Klammer" (mehrere Personen → eine Gruppe, z. B. "Eheleute Müller") die NextCloud-Ablage beeinflussen? Vorschlag Variante A (flach: jede Person behält ihren eigenen Mandantenordner unter ihrem Buchstaben + ein gemeinsamer Gruppenordner für geteilte Dokumente; Querverweise im UI) weicht vermutlich von der ursprünglichen Kunden-Vorgabe ab ("Klammer wirkt auf die Ablage" klang eher nach physischer Verschachtelung, Variante B). Vor dem Bau bestätigen. | D-32 · OP-MANDGRP-1 · Dokumentenverwaltung-NextCloud.md |
| KB-2 | 🟡 offen | Miteigentum an einer Gesellschaft | Eine gemeinsam gehaltene Praxis/Gesellschaft (z. B. eine BAG oder MVZ-GmbH, die mehreren Personen einer Gruppe gehört): Soll sie einer Person zugeordnet bleiben (heutiges Modell Praxis.mandantId, 1:n) und die Gruppe bildet nur die Klammer — oder soll Miteigentum echt abgebildet werden (Zuordnung auf Gruppen-Ebene bzw. m:n-Beteiligung Person↔Gesellschaft)? Bestimmt den Datenmodell-Zuschnitt der Gruppierung. | D-45 · OP-MANDGRP-1 |
| KB-3 | 🟡 offen | Umfang & Mitbestimmung der Zugriffs-(Lese-)Protokollierung | Die geplante Protokollierung von Lesezugriffen auf sensible Entitäten (D-50/RISK-27) erfasst, welcher Mitarbeiter wann welchen Mandanten, welche Beratungsdoku oder welchen Gesundheitsbogen eingesehen hat. Das taugt potenziell zur Leistungs-/Verhaltenskontrolle → in DE mitbestimmungspflichtig (§ 87 Abs. 1 Nr. 6 BetrVG), Nähe RISK-11/21/26. Zu klären: (1) exakter Umfang der Whitelist (reicht die vorgeschlagene Liste?), (2) Zweckbindung verbindlich festlegen (nur Missbrauchserkennung/Breach/Betroffenenauskunft, keine Mitarbeiter-Auswertung), (3) Betriebsrat-Beteiligung + Transparenz gegenüber Mitarbeitern, (4) Retention der Zugriffs-Events. | D-50 · RISK-27 · OP-AUDIT-1 |
| MED-KB-4 | ✅ geklärt | NextCloud-Hosting + lokaler Mac-Sync (Rollout) | ✅ Kundenrichtung bestätigt (12.07., Meeting M20): der Inhaber "hängt nicht an NextCloud" — Dokumente liegen bereits im System (R2, MED-D-61), NextCloud ist entbehrlich. Gewünscht bleibt nur eine Read-Only-Notfall-Sicht (Katastrophenfall: "hier sind deine Dokumente, du bist handlungsfähig"), ausdrücklich read-only, weil manuelles Verschieben/Umbenennen die Ordner-Referenzen zerstören würde — kein unabhängiges Backup mit eigener Wiederherstellungs-Semantik, sondern ein Blick auf dieselben R2-Dokumente. Damit ist Punkt (0) faktisch entschieden (Verzicht auf schreibendes NextCloud + kein Finder-Sync); offen bleibt nur der Bau des Read-Only-Exports (Action-Item A8, Kontakt zum bisherigen NextCloud-Betreiber). — ⚙️ Update 06.07.: Betreiber hat die geschlossene Ablage scharfgeschaltet (Bucket medidentas-ablage EU angelegt, ABLAGE_BACKEND=r2, MED-D-61) — Punkt 0 damit faktisch in Richtung "geschlossene Ablage" entschieden; weiterhin einzuholen: formale Kundenbestätigung (Verzicht auf NextCloud + kein Finder-Sync = bewusste Abkehr vom Mac-Sync-Wunsch) und Klärung, ob eine NextCloud-"read-only"-Sicht später ergänzt wird. — ✅ Update 20.07.: formal bestätigt — "NextCloud ist rein read-only-Sicht auf die Dokumente in der App": Punkt (0) damit vollständig entschieden, keine offene Kundenklärung mehr; offen bleibt ausschließlich der Bau dieser Read-Only-Sicht (weiterhin Action-Item A8, nicht Teil dieser Session — s. MED-OP-FILES-1 in HANDOFF.md §4). (Überholt, s. Update 20.07. oben — Punkt (0) ist entschieden, keine offene Kundenklärung mehr, insbesondere kein Finder-/Mac-Sync; Rest dieses Absatzes bewusst nicht gelöscht, sondern als historischer Verlauf stehengelassen, G-4): Analyse MED-OP-FILES-1 (2026-07-06, Dokumentenverwaltung-NextCloud.md §Alternativen-Check) bestätigte NextCloud (A-1); der damals diskutierte Mac-Sync-Wunsch wäre mit dem offiziellen Desktop-Client erfüllbar gewesen — durch die finale Entscheidung gegen jeden lokalen Sync (kein Finder-Sync) überholt. Zu bestätigen war: (0) Ausstehende Kundenbestätigung (MED-D-54, vorläufig entschieden 06.07.; V2 "R2 + App-UI" ist gebaut und per Config umschaltbar — 0.50.0/MED-D-58, Default aus): Verzicht auf NextCloud — geschlossene Ablage in Eigenverwahrung (R2 + App-UI, keine Nutzer-Eingriffe möglich, RBAC D-48 + Zugriffslog D-50 lückenlos); eine NextCloud-"read-only"-Sicht kann später ergänzt werden (Stöbern im Finder/Web, schreibend bleibt die App der einzige Pfad; Hinweis: auch read-only umgeht das Lese-Zugriffslog D-50 → Umfang dann klären). Preis der geschlossenen Ablage: kein lokaler Finder-Sync (widerruft das Nice-to-have vom selben Tag), Bearbeiten = Download→Re-Upload. Dieser Bestätigungspunkt geht allen anderen voran — bei Bestätigung entfallen (1)/(2) weitgehend. Falls unbestätigt: (1) Hosting — managed (z. B. Hetzner Storage Share, EU, AVV, ab ~5 €/Monat) vs. Selbstbetrieb vs. CH-Anbieter (Infomaniak kDrive = Plan B, revDSG); (2) Sync-Rollout — je Mitarbeiter eigener NextCloud-Account + Gruppen-Share (App behält den einen technischen Service-User, D-48); klassischen Sync-Client nutzen (macOS-Virtual-Files-Client 2026 fehleranfällig); (3) Rechte/Art. 9 — lokaler Voll-Sync umgeht das App-RBAC (D-48): welche Ordner (Gesundheitsbogen R6-F18, signierte Verträge R4) dürfen auf Mitarbeiter-Macs liegen? Kontrollpunkt = NextCloud-Gruppenrechte. | MED-OP-FILES-1 · A-1 · D-48 · Dokumentenverwaltung-NextCloud.md |
| MED-KB-5 | 🟡 offen | Tatsächliche Vertragsschließung / echte E-Signatur (Phase 2) | Phase 1 (rechtsverbindliche Einreichung, SES — MED-D-63/0.51.0) ist gebaut. Zu klären, bevor Phase 2 gebaut wird: (1) welche Dokumenttypen brauchen eine echte Signatur statt der SES-Einreichung; (2) welches eIDAS-Niveau (AES/QES) akzeptieren die Produktgeber je Dokumenttyp; (3) Anbieter DocuSign (Provider-Abstraktion + Niveau-Matrix stehen, signatur/provider.ts) → HTTP-Adapter + Webhook + EU-Datenresidenz/AVV (US-Transfer, OP-SIGN-1) + QES-CSP; (4) Identität bei GwG-Pflicht (OP-GWG-1). Zusätzlich: Bestätigungstext der "rechtsverbindlich abschicken"-Erklärung juristisch abnehmen (RISK-18). | MED-D-63 · OP-SIGN-1 · OP-GWG-1 · RISK-18 · Unterschriften.md |
| MED-KB-6 | 🟡 teil-entschieden | Strukturierte Persistenz von Bank-/Ausweis-PII im Onboarding | ⚙️ Update 07.07. (MED-D-71): Auf Nutzer-Vorgabe "IBANs explizit in den Stammdaten" werden IBANs jetzt strukturiert gespeichert — mandant.iban_privat (R1-F13) + praxis.iban (R1-F29), normalisiert + Mod-97-validiert (Migration v30). Der frühere Default "nur Checkliste" ist damit für IBANs revidiert. Weiterhin offen/zu härten: (1) Feld-Verschlüsselung at rest (heute Klartext in D1; Cloudflare verschlüsselt Storage-seitig, aber keine anwendungsseitige Feld-Verschlüsselung) — Bedarf/Verfahren klären; (2) Rechtsgrundlage + Zweckbindung dokumentieren (Art. 6 DSGVO; Zweck SEPA-Mandat/Abrechnung), Aufbewahrung/Löschkonzept, Zugriff (RBAC D-48); (3) Personalausweis/Ausweisnummer bleibt Checklisten-Nachweis + Ablage-Datei (keine strukturierte Ausweis-PII, G-6) — bestätigen, ob das reicht; (4) Abgrenzung zum externen SEPA-Einzug (SevDesk/Bank, OP-INVOICE-1). ⚙️ Update 22.07. (MED-D-179): Der Klärungsbedarf zu Verschlüsselung/Retention erstreckt sich jetzt zusätzlich auf die versionierten Stammdaten-Snapshots — die StammdatenVersion-Kette hält bewusst frühere PII-Werte (alte Anschriften/private IBANs) append-only vor (GoBD/§147 AO). Zugriff ist bereits gehärtet (mandantenscoped, RBAC D-48, Lesezugriff auditiert D-50, lazy-load G-6); offen bleibt dieselbe (1)/(2) — At-Rest-Feldverschlüsselung der Snapshots und konkrete Löschfrist/Retention der Historie. | MED-D-70 · MED-D-71 · MED-D-179 · G-5/G-6 · D-48 · D-50 · OP-INVOICE-1 · Lastenheft.md §4.2/§4.5 |
| MED-KB-10 | 🟡 offen | Steuernummer & Steuer-ID beim Mandanten — Bedarf & Rechtsgrundlage | Der Design-Prototyp "Akten-Cockpit 1a" führt im Stammdaten-Grid Steuernummer und Steuer-ID; beide wurden bei der Design-Übernahme (MED-D-241) bewusst noch nicht ins Datenmodell aufgenommen (RISK-30). Vor dem Bau mit dem Kunden zu klären: (1) Wofür braucht Medidentas die Felder überhaupt (welcher Beratungs-/Dokument-Prozess)? (2) Insbesondere die Steuer-ID ist §139b AO-reguliert — Verwendung nur für gesetzlich zugelassene Zwecke, kein allgemeines Ordnungsmerkmal; ohne klaren Zweck nicht speichern (Zweckbindung/Datenminimierung, DSGVO Art. 5, G-5/G-6). (3) Falls benötigt: Rechtsgrundlage, Aufbewahrung/Löschkonzept, Aufnahme ins Weltmodell/Data-Dictionary (G-8) — dann erst Persistenz + UI. | MED-D-241 · RISK-30 · G-5/G-6/G-8 · Weltmodell-Data-Dictionary.md |
| MED-KB-9 | 🟡 offen | Produkt-Katalog erweitern: Immobilienfinanzierung + Dexpansion (Dentale Expansion) | Nutzeranstoß (20.07.) — zwei mögliche weitere Beratungsauftrag-Produkte über den mit MED-KB-7 bestätigten 9er-Katalog (MED-D-99) hinaus: (1) Immobilienfinanzierung — Finanzierung von Immobilien/Grundbesitz; Abgrenzung zum bestehenden Produkt Praxisfinanzierung unklar (das eher Praxis-Erwerb/-Ausstattung/-Übernahme adressiert, nicht privaten/gewerblichen Immobilienerwerb) — eigenständiges Produkt oder Unterfall? (2) Dexpansion (Dentale Expansion) — Beratung zur Praxis-Expansion (weitere Standorte, MVZ-Aufbau, ggf. M&A); Abgrenzung zum bestehenden, vorbereiteten Produkt Dexman-Controlling (verfuegbar:false, laufendes Rentabilitäts-/Liquiditäts-Controlling, R10/Dexman) unklar — Dexpansion klingt nach einmaliger Strategieberatung, Dexman-Controlling nach Dauer-Betreuung; ggf. zwei getrennte Produkte statt eines. Vor dem Bau zu klären (analog MED-KB-7-Prozess): Produktnamen/-Zuschnitt final bestätigen; Praxis-Bezug (Person/Praxis/beides); Dauer-Betreuung vs. Einmal-Leistung; Buchbar-Flag. | MED-KB-7 · MED-D-99 · MED-OP-AUFTRAG-1 · Beratungsauftraege.md §3 |
| MED-KB-11 | 🟡 offen | Fremd-Formular-Einbindung über DocuSign-Templates (Weg B, MED-D-248) | Neue Fremd-Formulare binden wir über DocuSign-Templates mit Tabs ein (deckt auch flache Bank-PDFs; s. Fremdformulare.md §8). Vor dem Rollout mit dem Kunden zu klären: (1) Welche Fremd-Formulare konkret (Liste priorisieren — überlappt MED-KB-8 Sutor)? (2) Wer pflegt die DocuSign-Templates (Tab-Platzierung im DocuSign-Editor — Ablage-/formularkundige Mitarbeiterin? Berater? zentraler Template-Verantwortlicher?) und wer hat DocuSign-Editor-Zugang? (3) Ankertext-Verlässlichkeit je Formular (haben die PDFs stabile Textmarken für AnchorStrings, oder braucht es Koordinaten — und wer aktualisiert bei Partner-Layout-Änderungen)? (4) eIDAS-Niveau je Formular (SES/AES/QES — bezieht MED-KB-5 ein). (5) Kundenseitige Korrektur-Schleife — wie (nicht ob): der verbindliche Formular-Rücklauf-Regelkreis (MED-D-89/MED-OP-FORM-4 — Feld-Sichtung approve/deny mit Ablehnungsgrund · Mail-Feedback · Korrektur über denselben Link · akzeptierte Felder gesperrt · append-only Audit) gilt auch für Fremd-Formular-Rückläufe. Zu klären ist die konkrete Anwendung bei signierten Formularen: eine bereits signierte DocuSign-Fassung lässt sich nicht „per Link wieder öffnen" wie ein unsigniertes Onboarding-Formular → wie sieht die Korrektur aus (neuer Envelope / Nachtrag / Berater-Korrektur mit Kundenbestätigung)? Die heutige Berater-Rücklauf-Prüfung (AD-009, Vier-Augen) ist der Übernahme-Schritt, nicht ein Ersatz für die Kunden-Korrektur-Schleife. | MED-D-89 · MED-OP-FORM-4 · MED-D-248 · MED-KB-5 · MED-KB-8 · OP-SIGN-1 · Fremdformulare.md §8 |
| MED-KB-8 | 🟡 offen | Wertpapierdepot-/Bankformulare (Sutor Privatbank Hamburg) | Alle Wertpapierdepots des Anwender-Betriebs laufen über die Sutor Privatbank, Hamburg. Zu klären, bevor eine (Voraus-)Befüllung dieser Bankunterlagen gebaut wird: (1) Liegen Blanko-PDFs vor (Geeignetheitstest · Risikoaufklärung · Dokumentation)? Ohne Blanko-Vorlage keine Automatisierung — die formularkundige Ablage-Mitarbeiterin sucht die Formulare heraus (Action-Item A2). (2) Sind die Formulare maschinell befüllbar (AcroForm-Felder) oder nur Scans? (3) Datenfluss/AVV: Eignungs-/Finanzdaten (DSGVO) — Zweckbindung + Datenminimierung; die eigentliche Ident-/Eignungsprüfung macht die Bank (M10/M11). Bezug: Meeting 12.07. M11, OP-DOCGEN-2 (template-basierte Individualverträge), OP-GWG-1. | Meeting-2026-07-12 M11 · OP-DOCGEN-2 · OP-GWG-1 · Anforderungen-Meeting-2026-07-12.md |
| MED-KB-7 | ✅ geklärt (12.07., MED-D-99) | Produkt-Katalog der Beratungsaufträge bestätigt (MED-D-95) | Medidentas strukturiert Beratungsleistungen jetzt als Beratungsaufträge je Mandant (3-Ebenen-Modell, 0.68.0). Initialer Katalog: Dentmarking-Gutachten · Versicherungsoptimierung · Praxisfinanzierung · Geldanlage · Dexman-Controlling (vorbereitet). Mit dem Kunden zu bestätigen, bevor Slice B die Artefakte (Beratungsdoku/Dokumente/Wiedervorlagen) an Aufträge bindet: (1) Namen/Zuschnitt der Produkte; (2) fehlen Produkte (z. B. Existenzgründung, Abrechnungsberatung, Nachfolge)? (3) welche Produkte sind Dauer-Betreuung (Status "laufend betreut") vs. Einmal-Leistung; (4) welche sind praxisbezogen vs. personenbezogen. ✅ Ergebnis (12.07., Kunde/Nutzer): Katalog auf 9 Produkte erweitert — zusätzlich Existenzgründung · Abrechnungsberatung · Praxisnachfolge (alle einmalig) sowie Investitionsberatung Erneuerbare Energien; Geldanlage → "Kapitalanlage" umbenannt; Versicherungsoptimierung, Kapitalanlage und Investitionsberatung sind Person ODER Praxis/Gesellschaft (Praxis-Bezug optional). Umgesetzt in 0.69.0 (MED-D-99, Migration v37). Damit ist der Weg für Slice B frei. | MED-D-95 · MED-D-99 · MED-OP-AUFTRAG-1 · Beratungsauftraege.md |
Legende Status: 🟡 offen · ✅ geklärt (Datum + Ergebnis in "Was ist zu klären?" ergänzen) · ⛔ verworfen.