Management Summary — Medidentas Digital
Zielgruppe: Management / Business. Zweck: Ziel, Arbeitsweise, Fortschritt, aktueller Status und nächste Schritte auf einen Blick — pyramidal, ohne technische Vorkenntnisse lesbar. Tiefe steht in den verlinkten Dokumenten. Stand: Version
0.127.1(Vor-MVP).
Kernaussage (BLUF)
Medidentas Digital ist eine Plattform, die den gesamten Kunden-Lebenszyklus eines beratungs-/vermittlungsnahen Betriebs lückenlos und rechtssicher orchestriert — von der ersten Anfrage bis zum betreuten, archivierten Mandat. Statt Insellösungen und E-Mail-Zettelwirtschaft entsteht eine Wahrheit: jeder Kunde, jeder offene Schritt, jede Unterschrift und jeder Nachweis an genau einer, auditierbaren Stelle.
Die Anwendung ist live (app.medidentas.com, EU-Datenresidenz) und funktional weit gediehen: der
Kern-Prozess ist end-to-end gebaut (Version 0.127.1, 692 automatisierte Tests). Sie ist noch vor dem
MVP (1.0.0): die fachliche Orchestrierung und die Dokumentenablage (R2, produktiv) stehen; der
DocuSign-Kern für E-Signaturen ist gebaut und gegen die Demo live verifiziert (MED-D-238/239) — offen
bleibt hier nur die Prod-Umschaltung für echte Rechtswirkung (Consent/QES + AVV). E-Mail-Versand und
KI-Assistent laufen heute bewusst noch über austauschbare Platzhalter. Der Sprung auf 1.0.0 = die
Prod-Aktivierung der Signatur + diese Platzhalter durch die echten Anbieter ersetzen.
Status auf einen Blick
| Dimension | Stand |
|---|---|
| Version | 0.127.1 — Vor-MVP (1.0.0 = fertiges MVP) |
| Betrieb | Live auf app.medidentas.com (Cloudflare, EU-Datenresidenz, Zugang über Cloudflare Access) |
| Fachlicher Umfang | Kern-Lebenszyklus end-to-end gebaut (Mandant → Onboarding → Beratung → Unterschrift → Ablage → Wiedervorlage → Archiv) |
| Qualitätssicherung | 692 automatisierte Tests, CI-Gate + externer Code-Review vor jedem Merge |
| Reifegrad Integrationen | Orchestrierung ✅ · Ablage (R2) ✅ · DocuSign-E-Signatur gebaut + demo-verifiziert (Prod-Rechtswirkung offen) 🟡 · E-Mail/KI noch Platzhalter 🟡 |
| Investierte Zeit | ≈ 200 h bisher (KW27–KW30 2026, laufende Woche) — Detail je Session: ../betrieb/Timesheet.md |
| Nächster Meilenstein | 1.0.0 (MVP) — echte Anbieter-Anbindung statt Platzhalter |
1. Ziel — Warum Medidentas?
Das Herz des Systems ist die lückenlose, rechtssichere Orchestrierung des Mandanten-Lebenszyklus. Drei Leitfragen ("True North") muss die Plattform jederzeit schnell und korrekt beantworten:
- Wo steht der Kunde im Prozess? — welcher Schritt, was fehlt?
- Was ist offen und fällig? — Wiedervorlagen, ausstehende Unterschriften, fehlende Angaben.
- Ist alles vollständig & rechtssicher dokumentiert? — Beratungsdoku, Unterschriften, Belege: lückenlos, auditierbar, DSGVO-konform.
Das Problem, das gelöst wird: In der Praxis verteilt sich der Kundenprozess heute über CRM, Mailpostfächer, Dateiablagen und Signatur-Tools — Aufgaben gehen unter, Fristen werden übersehen, die rechtssichere Dokumentation ist mühsam. Medidentas Digital legt eine dünne, eigengebaute Orchestrierungs-Schicht darüber, die die bewährten Fachwerkzeuge verbindet und den Prozess führt und bezeugt.
Der Nordstern ist das MVP 1.0.0. Jedes Feature und jedes Dokument muss mindestens eine der drei
True-North-Fragen direkter, schneller oder genauer beantworten — sonst wird es kritisch hinterfragt.
2. Arbeitsweise — Wie wir bauen
Die Entwicklung folgt acht Leitprinzipien (G-1…G-8); die wichtigsten in Management-Sprache:
| Prinzip | Bedeutung fürs Geschäft |
|---|---|
| G-1 Standardwerkzeuge anbinden statt nachbauen | Dokumente → NextCloud, Unterschriften → DocuSign/PandaDoc, Kundenstamm → CRM. Eigenbau nur dort, wo er differenziert — die Orchestrierung. Spart Zeit/Geld, kein "Rad neu erfinden". |
| G-2 Eine Wahrheit (Everything-as-Code) | Alles Wissen und jede Entscheidung liegt versioniert im Repository; keine doppelte, widersprüchliche Datenhaltung. Volle Nachvollziehbarkeit. |
| G-3 Selbsterklärbarkeit | Sprechende Begriffe aus der Beratungspraxis (z. B. "Unterschrift ausstehend" statt technischer Codes) — in App und Doku. |
| G-4 Rechtssichere, lückenlose Doku | Beratungsdoku, Unterschriften und Belege sind append-only und auditierbar — nicht nachträglich manipulierbar. Pflicht, nicht Kür. |
| G-5 / G-6 Datenschutz & Datensparsamkeit by design | So wenig personenbezogene Daten wie möglich, EU-/CH-Residenz, Bereinigung schon am Eingang. |
| G-7 Betriebskosten automatisch ziehen | Laufende Cloud-/KI-Kosten werden je Dienst direkt aus dessen Abrechnungs-API gezogen — nicht von Hand gepflegt. |
| G-8 Weltmodell/Data Dictionary | Jede Entität/jedes Wertobjekt einmal definiert, überall gleich strukturiert (z. B. Anschrift = Straße · PLZ · Ort). |
Dazu vier drkv-Standard-Bausteine (Default, Abweichung wird begründet): Echtzeit (Live-State
möglichst gepusht statt per Reload, Weiterentwicklungsrichtung), moderne Frameworks (aktuelle
Stable-Stände, laufende Wartung), ein In-App-Chatbot (ein Assistent über App und Doku, RAG auf
Live-Daten, vorschlagend statt ausführend — ../architektur/In-App-Assistent.md) und
Feedback (immer sammeln und anzeigen, kein Klartext-PII).
Way-of-Working: kleine, überprüfbare Änderungen über Feature-Branches und Pull-Requests; jede Änderung
durchläuft ein automatisiertes CI-Gate + einen externen Code-Review, bevor sie live geht. Dokumentation ist
Liefergegenstand jedes Schritts (zielgruppen-gerecht, pyramidal, visuell) — kein Nice-to-have. Jede
Design-Entscheidung wird als Entscheidung protokolliert. Details: ../konventionen/Entwicklungsansatz.md.
3. Fortschritt — Was gebaut wurde
Aus der Spezifikation ist eine live betriebene Anwendung geworden. Der komplette Kern-Lebenszyklus ist als zusammenhängende Kette gebaut:
| Baustein | Was er leistet | Status |
|---|---|---|
| Mandant & Onboarding | Kundenanlage, Self-Service-Onboarding-Formulare (vorausgefüllt), Pflicht-Nachweise | ✅ gebaut |
| Dokumente & Ablage | Dokumenten-Ledger, Ablage-Referenzen, "an jeder Stelle" erzeugbar | ✅ gebaut |
| Unterschriften | E-Signatur-Strecke inkl. eIDAS-Niveau je Dokumenttyp | ✅ DocuSign gebaut + demo-verifiziert · Prod-Rechtswirkung offen |
| Beratungsdokumentation | Rechtssichere Protokolle inkl. Pflichtangaben, KI-Vollständigkeits-Check | ✅ gebaut |
| Gesprächsnotizen / Meeting-Doku | Protokoll → Aufgaben ableiten → an Team delegieren (als Wiedervorlagen) | 🟡 Kern gebaut · echte Transkription offen |
| Wiedervorlagen & Fristen | Terminierte Erinnerungen, Delegation, "nichts fällt durch" | ✅ gebaut |
| Freitext-Dokumente | Frei geschriebene Dokumente ins Hauslayout setzen → zur Unterschrift | ✅ gebaut |
| Zeiterfassung & Abrechnung | Live-Zeiterfassung je Mandant, Leistungszeit-Ledger | ✅ gebaut |
| Audit-Log (quer) | Lückenlose, verkettete Nachweiskette über alles | ✅ gebaut |
| Identität, Rollen & Rechte | Zugang über Cloudflare Access, Rollen-/Rechte-Matrix je Mandant | ✅ gebaut |
| Spezial-Tools (Dentmarking, Dexman) | Praxis-Kennzahlen/Controlling als zubuchbare Fähigkeiten | 🟡 Dentmarking gebaut · Dexman geplant |
Zusätzlich wurde der Prozess in einem fünfstufigen Fahrplan (P1–P5) geschärft: eine autoritative Prozess-Landkarte, ein quer-liegendes Dokumenten-Ledger, sichtbare offene Wiedervorlagen, Freitext-Dokumente und zuletzt die Gesprächsnotizen/Meeting-Doku (P5).
4. Aktueller Status — Wo wir stehen
Version 0.127.1, live in der EU mit Compliance-by-Design-Kontrollen. Die Anwendung läuft auf Cloudflare
(Workers + Datenbank in der EU) hinter einem geschützten Zugang, mit Markenauftritt analog medidentas.de.
Vollständige DSGVO/revDSG- bzw. eIDAS/ZertES-Konformität ist damit noch nicht erklärt — offene Punkte
(u. a. Prod-Umschaltung der E-Signatur für echte Rechtswirkung — der DocuSign-Kern ist demo-verifiziert —, realer E-Mail-Versand offen) stehen in
docs/betrieb/Compliance.md und docs/betrieb/Risikoregister.md.
Der entscheidende Status-Punkt für das Management: Die fachliche Orchestrierung ist vollständig. Bei der Anbindung externer Dienste ist der E-Signatur-Kern (DocuSign) bereits gebaut und gegen die Demo live verifiziert — offen ist nur die Prod-Umschaltung (echte Rechtswirkung); die übrigen Anbindungen (E-Mail, KI) laufen bewusst noch über austauschbare Platzhalter:
| Externer Dienst | Heute | Wozu der Platzhalter |
|---|---|---|
| Dokumentenablage (Cloudflare R2, produktiv seit MED-D-61; NextCloud als Alternativ-Treiber vorbereitet) | ✅ produktiv aktiv (kein Platzhalter mehr) | — |
| E-Signatur (DocuSign / PandaDoc) | DocuSign-Kern gebaut + gegen die Demo live verifiziert (JWT/Envelope/Webhook, MED-D-238/239); Prod-Rechtswirkung noch nicht scharf | Nur noch Prod-Umschaltung (Consent/QES + AVV) + Anbieter-/Niveau-Kundenentscheidung — kein Fake mehr im Kern |
| E-Mail-Versand | protokolliert statt versendet | Versand-Anbieter noch offen |
| KI-Assistent / Transkription | deterministische, EU-sichere Platzhalter | Echte KI erst mit EU-Datenresidenz + Auftragsverarbeitungs-Vertrag |
Dieses Vorgehen ist Absicht (G-1): Der differenzierende Kern — die Orchestrierung — ist fertig und getestet; die Anbieter sind über klare Verträge austauschbar und werden angebunden, sobald die kaufmännischen/rechtlichen Voraussetzungen (Verträge, Datenresidenz) geklärt sind.
Compliance-Haltung (DE/AT/CH): DSGVO/revDSG, eIDAS/ZertES und Aufbewahrungsfristen (GoBD) sind by design berücksichtigt (EU-Residenz, append-only Audit, Datenminimierung); kritische regulatorische Punkte werden proaktiv in einem Risikoregister geführt.
5. Nächste Schritte — Der Weg zu 1.0.0
Das Tor zum MVP 1.0.0: die Platzhalter durch die echten Anbieter ersetzen. Das Rückschreiben der
Onboarding-Antworten in die Stammdaten ist inzwischen gebaut (0.61.0, MED-D-88). Konkret priorisiert:
| Nächster Schritt | Nutzen | Abhängigkeit |
|---|---|---|
| E-Signatur in Prod scharf schalten (DocuSign, AES/QES) | Rechtsverbindliche Unterschriften — der Kern ist demo-verifiziert, offen ist die Prod-Rechtswirkung (Consent/QES + AVV) | Kundenentscheidung Anbieter + Niveau (MED-KB-5) |
| Echter E-Mail-Versand (OP-DM-8) | Kunden-Feedback und Erinnerungen werden zugestellt statt nur protokolliert | Versand-Anbieter-Wahl |
| Doku-Wellen 2–3 (MED-OP-DOKU-2/3) | Doku-Regeln je an genau einem Ort + geschärfter Konsistenz-Check (Welle 1 "eine Wahrheit" ist umgesetzt) | — (buildbar) |
| Echte Transkription für Gesprächsnotizen | Automatisches Protokoll aus dem Gespräch statt manueller Erfassung | Tool-Wahl + EU-Residenz/AVV |
| In-App-Assistent (KI über App & Doku) | Fragen beantworten, Insights, Feedback — vorschlagend, RBAC-sicher | EU-LLM-Wahl |
| Smarte Formular-Vorschläge ausweiten (MED-OP-VALID-1, USP — Slice 1–4 bereits gebaut: Ausfüll-Formular, Praxis-PLZ, PLZ↔Ort-Plausibilität, Onboarding-Formular) | Client-UI für die Ausfüll-Formular-Vorschläge selbst; Dentmarking-Fragebogen bewusst nicht vereinheitlicht (eigenes Zahlen-Bereichs-Konzept, semantisch andersartig) — dort bleibt die Client-seitige Duplikation ein eigener Folgepunkt | Mandant-Stammdaten-Editierbarkeit = eigene Prozess-Entscheidung; echtes LLM später (Fake-Seam bereits produktiv) |
| Betriebskosten automatisch ziehen (G-7) | Laufende Cloud-/KI-Kosten transparent, ohne Handpflege | Provider-APIs |
| HQ-Eigentümer-Zuordnung der Domain | Organisatorischer Abschluss | interner Schritt |
Entscheidungsbedarf (Management/Kunde): einige Schritte hängen an Kundenentscheidungen — insbesondere Signatur-Anbieter & -Niveau, Transkriptions-Tool (mit EU-Residenz/AVV) und die produktiven Zugänge. Diese offenen Punkte werden gebündelt in den Kunden-Besprechungspunkten geführt.
Vertiefung
| Frage | Dokument |
|---|---|
| Kompakter Gesamtstand + offene Punkte | HANDOFF.md |
| Warum & Wie (True North · G-1…G-8 · Way-of-Working) | ../konventionen/Entwicklungsansatz.md |
| Was ist heute gebaut? | ../fachlich/Feature-Liste.md |
Weg zu 1.0.0 (Slice-Plan, Backlog) | ../fachlich/MVP-Scope.md |
| Wie der Prozess abgebildet wird | ../architektur/Prozessmodell.md |
| Offene Kundenentscheidungen | ../betrieb/Kunden-Besprechungspunkte.md |
| Compliance & Risiko (DE/AT/CH) | ../betrieb/Compliance.md · ../betrieb/Risikoregister.md |