Anforderungen aus dem Abstimmungstermin (12.07.2026)
Zweck. Diese Datei hält die fachlichen Anforderungen und Bestätigungen fest, die im
Abstimmungstermin am 12.07.2026 (Demo des aktuellen Stands + Prozessdurchsprache) erhoben wurden.
Sie ist — wie Anforderungen-Workshop-2026-01-20.md — eine
Anforderungsquelle und auf die Module/Use-Cases/offenen Punkte des Lastenheft.md
sowie die Decision-/OP-Register gemappt (Traceability). Der Termin war überwiegend eine
Bestätigungs-/Schärfungssitzung zum live gezeigten Stand (0.72.0); wenige Punkte sind neue
Festlegungen oder Action-Items. Kanonisch bleiben Decision-Log.md (getroffene Entscheidungen),
Kunden-Besprechungspunkte.md (offene Kundenpunkte) und HANDOFF.md §4 (OPs).
Datenschutz (G-5/agents.md §8). Die Original-Transkription enthält PII (reale Personen-, Mitarbeiter- und Kundennamen, private Nebenbemerkungen) und gehört nicht ins Repo. Diese Zusammenfassung ist bereinigt: Beteiligte erscheinen nur nach Rolle, Kunden-/Mitarbeiternamen sind entfernt. Institutions-/Produktnamen (Bank, CRM, Signatur-, Ablage-Tool) sind keine natürliche- Personen-PII und bleiben stehen, wo sie eine Anforderung tragen.
1. Kontext & Beteiligte (Rollen)
- Anwender-Betrieb: Finanz-/Versicherungs- & Praxisberatung für (Zahn-)Arztpraxen (bestätigt, OP-DOMAIN-1). Premium-/Einzelfall-Betrieb ("kommt mal einer oder zwei pro Woche", kein Massengeschäft) → Datenqualität vor Volumen, kulanter Umgang mit Kundeneingaben.
- Beteiligte (Rollen): Inhaber/Geschäftsführung des Anwender-Betriebs (fachliche Domäne, Recht, Kundensicht) · Digitalisierungsberater/Entwickler (drkv) (zeigt den Stand, baut Medidentas).
- Anlass: Live-Demo des aktuellen Stands + Durchsprache des Kunden-Lebenszyklus; Vorbereitung des Folgetermins in ~2 Wochen (mit Taktano per Video zugeschaltet, danach Weiterarbeit an Medidentas).
2. Leitbild "Akte" (bestätigt & geschärft)
Die Akte eines Kunden ist die Zusammenführung dreier Quellen — plus mehr:
- CRM (Daylite): alle Kommunikationsdaten (Name/Titel/Vorname/Nachname, Anschrift, Praxis/en 0..n), Familienstand/Kinder, Steuer-ID, IBAN privat & Praxis, Steuerberater, Mailverkehr.
- Ablage (heute NextCloud): eingescannte Formulare, Personalausweis/Aufenthaltstitel, Immobiliendaten, Verträge, Vollmachten.
- Beratungsmandate: Tracking der aktiven Beratungsaufträge (Dexman, Existenzgründung, Versicherungs- check … — kürzer- oder längerlaufend).
Wichtig: Die Medidentas-Akte ist nicht nur die Vereinigung von CRM + Ablage, sondern beides plus die Orchestrierung/Beratungsmandate + Audit/Zeiten/Aufgaben — genau der eigengebaute Kern (G-1,
System-Charakter.md). Bestätigt das 3-Ebenen-/2-Ebenen-Modell der Beratungsaufträge (MED-D-95).
3. Anforderungsthemen → Mapping
| # | Thema | Kerninhalt (Termin) | Einordnung / Bezug |
|---|---|---|---|
| M1 | "Akte" = CRM + Ablage + Beratungsmandate (+ mehr) | Zusammenführung Daylite/NextCloud/Mandate zu einer orchestrierten Akte | bestätigt · MED-D-95 · System-Charakter.md · Beratungsauftraege.md |
| M2 | Zwei Ebenen: Kunden-Onboarding ↔ Beratungsprodukte | Erst Kunde onboarden (Beratungsvertrag), dann 0..n Beratungsprodukte je mit eigenem Lifecycle (Erstkontakt→Onboarding→Betreuung→Archivierung); Prozessschritte je Produkt überspringbar | bestätigt · MED-D-95 · MED-OP-AUFTRAG-1 |
| M3 | Betreuungsintensität: Intensiv/Standard/Basis | Bewusst nicht A/B/C und nicht Gold/Silber/Bronze — neutrale Stufe, damit der Kunde beim Screensharing nicht brüskiert wird | bestätigt gebaut · R1-F11 betreuungsmodell · D-35 · schärft OP-ABC-1 |
| M4 | Kunden-Lifecycle | Lead → Onboarding → Aktiv betreut → Ruhend → Archiviert | bestätigt gebaut · R1-F05 · Prozessmodell.md · OP-RUHEND-1 (Ruhend-Workflow offen) |
| M5 | Flat-Fee-Automatik | Hat ein Kunde eine monatliche Flat-Fee (erkennbar am Vertrag), erkennt das System automatisch: Beratungszeit wird nicht gesondert abgerechnet — die Zeit läuft aber weiter (Rentabilitätsauswertung) | neu → OP-TIME-1-Erweiterung (MED-D-108) |
| M6 | Onboarding-Formular: Kundendatenbogen-Felder übernehmen | Alle Felder aus dem bestehenden Kundendatenbogen ins Self-Service-Onboarding-Formular übernehmen | Action-Item · OP-DOCGEN-1-Rest · R2 |
| M7 | Review-and-apply "In Stammdaten übernehmen" | Kunde füllt selbst; Mitarbeiter prüft jedes Feld und übernimmt selektiv (filtert Blödsinn); Zwischenspeichern jederzeit; Feldvalidierung (E-Mail-Format usw.); freundlich-kulant (Premium, Feld-Freitext erlaubt → Service statt Blockade) | bestätigt gebaut · MED-D-84/88/89 · MED-OP-FORM-4 |
| M8 | Weltmodell (Feldstruktur einheitlich) | Titel/Vorname/Nachname immer separat; Anschrift Straße (inkl. Hausnr.) + PLZ + Ort, nie Einzeilen-Adresse; über alle Formulare gleich | bestätigt · G-8 · MED-D-85/86/87 · Weltmodell-Data-Dictionary.md |
| M9 | Drei Signaturstufen | (1) Einfache E-Signatur (Name + Opt-in Datenschutz — Willenserklärung/DSGVO-Zustimmung) · (2) DocuSign (fortgeschritten, rechtskräftig B2B, z. B. Dexman-Auftrag) · (3) Qualifiziert (Post-/Videoident — regulatorisch erforderliche Identität) | bestätigt · OP-SIGN-1 · MED-KB-5 · Unterschriften.md |
| M10 | Identitätsabgleich Personalausweis | Für regulierte Fälle (z. B. Wertpapierdepot): Abgleich "ist die Person wirklich diese Person?" mit Personalausweis | bestätigt/Compliance · OP-GWG-1 · RISK-25 |
| M11 | Wertpapierdepot-/Bankformulare (Sutor Privatbank Hamburg) | Alle Wertpapierdepots laufen über die Sutor Privatbank, Hamburg; Bankformulare (Geeignetheitstest · Risikoaufklärung · Dokumentation) evtl. nicht automatisiert befüllbar — abhängig von Blanko-PDFs | neu / Action-Item → MED-KB-8 · Bezug OP-DOCGEN-2 |
| M12 | Dexman-Kundenportal — E-Mail-Code-Login | Kein Passwort-Login: Kunde gibt E-Mail ein → Einmal-Code per Mail → Zugang; Backoffice kann Link auch selbst erzeugen & verschicken (1 Tag gültig, weiterleitbar an Vorzimmer) | neu (Design-Festlegung) · MED-D-108 → Dexman.md |
| M13 | Leistungsstatistik: Kunde pflegt selbst | Kunde trägt Leistungszahlen selbst ein (monatlich/quartalsweise) — gewollt (Verantwortung/Datenherkunft beim Kunden); PVS-Direktanbindung (Dampsoft/Charly/Evident/Computer konkret) ist späterer Ausbau, nicht Phase 1 | bestätigt (Phasenreihenfolge) · OP-DEX-1 · Dexman.md |
| M14 | Zeiterfassung & Abrechnung (SevDesk) | Abrechenbar/nicht-abrechenbar unterschieden (Timer manuell überschreibbar); SevDesk für E-Rechnung + Auto-Markierung "abgerechnet"; Abschlagsrechnungen als gängige Praxis (mindern Streitrisiko) | bestätigt · OP-TIME-1 · OP-INVOICE-1 |
| M15 | Mahnstufen-Banner | Kunde in Mahnstufe (z. B. 3) → Banner oben in der Akte (nicht weiterarbeiten / Rücksprache / nur mit Freigabe / Vorkasse) | neu (kleines Feature) → OP-INVOICE-1-Rest |
| M16 | Audit-Log inkl. Lese-Zugriff auf PII | Alles hashverkettet, gerichtsfest, umgekehrt chronologisch; protokolliert auch Zugriff auf personenbezogene Daten durch Mitarbeiter (Geburtsdatum/IBAN sind schützenswert) — automatisch | bestätigt gebaut · G-4 · D-50 · Slice 6 · KB-3 (BetrVG) |
| M17 | Barrierefreiheit | Von Anfang an mitgedacht (WCAG); vermeidet spätere Angreifbarkeit | bestätigt · D-22 · @angular/aria-Track (MED-OP-NG22-1) |
| M18 | Aufgaben & Wiedervorlagen aus Formularen | Abgeschicktes Formular → Erinnerung/Wiedervorlage; Mitarbeiter-Zuweisung + Kommentar + Erledigt; Antwort-Sichten aus dem Formular | bestätigt gebaut · R5/R7 · OP-WV-1 · MED-D-82 |
| M19 | Dokumenten-Baumstruktur (gruppiert) in der Akte | Dokumente in der Akte als gruppierte Baumstruktur statt flacher Liste anzeigen (hoch-/runterladen, Doku-Automatisierung, freies Dokument mit wählbarem Signatur-Niveau) | Action-Item · R3 · MED-D-80 |
| M20 | NextCloud entbehrlich + Read-Only-Notfall-Backup | Inhaber "hängt nicht an NextCloud"; Dokumente liegen bereits im System (R2). NextCloud/Read-Only nur als Notfall-Backup (Katastrophenfall handlungsfähig); Read-Only, weil manuelles Verschieben/Umbenennen die Ordner-Referenzen zerstört | bestätigt · MED-D-54/58/61 · MED-KB-4 · MED-OP-FILES-1 |
4. Action-Items (aus dem Termin)
| # | Action-Item | Verantwortlich (Rolle) | Bezug |
|---|---|---|---|
| A1 | Alle Felder aus dem Kundendatenbogen ins Onboarding-Formular übernehmen | Entwickler | M6 · OP-DOCGEN-1 |
| A2 | Blanko-Formulare Wertpapierdepot Sutor Privatbank Hamburg heraussuchen (Geeignetheitstest · Risikoaufklärung · Dokumentation) — über die formularkundige Ablage-Mitarbeiterin anfragen | Inhaber/Back-office | M11 · MED-KB-8 |
| A3 | Dexman als Beratungsprodukt in der Beratungsübersicht anlegen (Katalog vorhanden, verfuegbar:false scharfschalten wenn Ziel passt) | Entwickler | M2 · MED-OP-AUFTRAG-1 |
| A4 | Dokumenten-Ansicht der Akte als gruppierte Baumstruktur aufbauen | Entwickler | M19 |
| A5 | 2–3 Beispielkunden anlegen (Cockpit-Funktionalität demonstrieren) | Entwickler | Demo-Vorbereitung |
| A6 | Vollständigen Onboarding-Prozess bis zum Folgetermin durchklickbar machen | Entwickler | M2/M6/M7 |
| A7 | E-Mail-Code-Zugang (ohne Passwort) für das Dexman-Kundenportal umsetzen | Entwickler | M12 |
| A8 | Read-Only-Export in NextCloud als Notfall-Backup vorbereiten (Kontakt zum bisherigen NextCloud-Betreiber) | Entwickler/Inhaber | M20 · MED-KB-4 |
| A9 | Unterlagen (Kundendatenbogen etc.) zusammensuchen und senden — noch am Termintag | Inhaber | M6 |
| A10 | Folgetermin (~2 Wochen) mit Taktano per Video organisieren; Inhaber + Entwickler vor Ort, Taktano zugeschaltet | Inhaber/Entwickler | §5 |
5. Nächste Schritte & Termin
- Kurzfristig (bis Folgetermin): Akte-Übersicht bereinigen (zwei Dimensionen sauber trennen), Dexman als Produkt anlegen, Dokumenten-Baumstruktur, 2–3 Beispielkunden, Onboarding durchklickbar.
- Folgetermin in ~2 Wochen — vor Ort (Inhaber + Entwickler), Taktano per Video zugeschaltet; danach Weiterarbeit an Medidentas.
6. Compliance-Flags (proaktiv, DE/AT/CH)
- eIDAS-Niveau je Dokumenttyp (OP-SIGN-1): die drei Stufen (SES/DocuSign-AES/QES-Video-Postident) sind je Rechtswirkung zu belegen — DocuSign ist B2B tragfähig, regulierte Identität (GwG, Wertpapierdepot) verlangt Post-/Videoident bzw. QES. CH: ZertES.
- Identitätsprüfung / GwG (OP-GWG-1, RISK-25): der Personalausweis-Abgleich (M10) ist zu prüfen — greift bei LV-/Anlagevermittlung ggf. die GwG-Verpflichteten-Pflicht (§ 2 Abs. 1 Nr. 8 GwG)?
- Bank-/Depot-Formulare (M11): enthalten Finanz-/Eignungsdaten (DSGVO) — bei etwaiger Automatisierung Zweckbindung + AVV mit der Bank klären; Blanko-PDFs zuerst sichten.
- Lese-Zugriffslog auf PII (M16 / D-50): taugt potenziell zur Mitarbeiter-Leistungskontrolle → § 87 Abs. 1 Nr. 6 BetrVG (mitbestimmungspflichtig), strikte Zweckbindung (KB-3).
- Kundenportal-Login per E-Mail-Code (M12): Magic-Link/OTP ist passwortlos, aber die E-Mail-Strecke ist der Sicherheitsanker — Link-Gültigkeit kurz halten, Weiterleitbarkeit (an "Vorzimmer") bewusst akzeptiert, Zugriff auf Praxis-Kennzahlen (ggf. Art.-9-nah) auditieren.
Pflege. Neue Erkenntnisse aus Folgegesprächen hier ergänzen und in Decision-Log.md /
Kunden-Besprechungspunkte.md / HANDOFF.md überführen. Verbindlich umgesetzte Anforderungen sind im
Lastenheft.md kanonisch.