System-Charakter — Was für eine Anwendung ist Medidentas?
Zweck. Dieser Anker beantwortet die Frage vor den Use-Cases: Welche Art von Anwendung ist
Medidentas, und was ist der eigengebaute Kern? Er bündelt die Architektur-Haltung, die sonst über
CLAUDE.md, das Lastenheft und die Workshop-Anforderungen
(Anforderungen-Workshop-2026-01-20.md) verteilt ist.
Er trifft keine neuen Entscheidungen — er macht die bestehenden lesbar.
In einem Satz. Medidentas ist eine Vorgangs-/Lebenszyklus-Orchestrierung für ein beratendes Back-office — ein „Dirigent", der bewährte Standard-Werkzeuge (NextCloud, DocuSign/PandaDoc, CRM, Transkription) zu einem lückenlosen, rechtssicheren Ablauf zusammenführt. Der Eigenwert liegt nicht in den Werkzeugen, sondern im Takt dazwischen.
1. Welche Art von Anwendung?
Drei bekannte Muster überlagern sich:
- Case-Management- / Workflow-System. Jeder Mandant/Vorgang (R1/R2) ist ein „Fall", der als Zustandsmaschine durch den Lebenszyklus läuft (Lead → Onboarding → Beratung → Unterschrift → Ablage → Betreuung → Archiv). Lifecycle-Status ≠ fachliche Phase (Lastenheft §5.2) — flexibles Case-Management, kein starrer, linearer Prozess.
- Orchestrierungs-/Integrationsschicht (vertical SaaS). Eine dünne Schicht über Best-of-Breed-Tools, die deren Schritte ansteuert und Status idempotent zurückführt (Webhooks + Reconciliation). Das ist der operative Kern von G-1 „integrate-before-build".
- System of Record für Prozess & Compliance — bewusst nicht für die Daten selbst (s. §3).
Kurzform: vertikales, compliance-getriebenes Case-Management mit Orchestrierungs-Kern — plus dünner Plattform-Host für Spezial-Tools (R10).
2. Der Kern (was Medidentas selbst ist)
Alles andere ist angebunden; eigengebaut ist nur dieser harte Kern. Streiche eines davon, und es ist nicht mehr Medidentas, sondern „noch ein Tool".
| # | Kern-Baustein | Warum Eigenbau | IDs |
|---|---|---|---|
| 1 | Träger des Lebenszyklus — Mandant + Vorgang als zentrale Entität, die den Prozess-Zustand hält | kein Standard-Tool kennt diesen Vorgang | R1, R2 |
| 2 | Orchestrierungs-Engine — treibt Schritte über die externen Tools, idempotente Status-Nachführung | die Verschaltung ist das Produkt | R2, R9, §7 NFR |
| 3 | Abgeleiteter Zustand statt gespeichertem — „Onboarding vollständig?", „was ist fällig?" wird berechnet | „eine Wahrheit", kein Drift | G-2, S-3, R5 |
| 4 | Append-only Audit-Log — lückenlos, manipulationssicher, „nicht reverse-engineerbar" | Rechtssicherheit ist nicht zukaufbar | G-4, R8 |
| 5 | Cockpit / True North — beantwortet jederzeit die drei Leitfragen | der Sinn des Ganzen | UC-6 |
3. Der entscheidende Charakterzug: System of Engagement, nicht of Data
Der Grund, warum die Anwendung schlank bleibt — Medidentas besitzt die Daten nicht, es steuert und bezeugt sie:
| Datenart | Wahrheit liegt bei | Medidentas hält |
|---|---|---|
| Dokumente | NextCloud (A-1) | Referenz + Status (S-2) |
| Kundenstammdaten | CRM (A-3) | Referenz per Link (S-1) |
| Unterschriften | DocuSign/PandaDoc (A-2) | Niveau + Status (R4) |
| Transkription | Standard-Tool (A-8) | Protokoll→Aufgaben-Orchestrierung (R11) |
→ Medidentas ist bewusst kein DMS, kein CRM, kein Signatur-Backend, keine Transkriptions-Engine. Es ist die Wahrheits- und Steuerungsschicht darüber.
4. Das Rückgrat: „eine Wahrheit"
Der Workshop (20.01.2026) hat den eigentlichen Job präzisiert: jedes Datum nur einmal anfassen, dann überall automatisch wiederverwenden (deckt sich mit G-2). Das ist die Linie, die alle Module verbindet:
Jeder Pfeil ist Orchestrierung; fast jeder Kasten außer der R5/R6/R8/R11-Logik ist angebunden.
5. Schichten-Modell
6. Die schärfste Formulierung
Medidentas ist die orchestrierende Wahrheitsschicht eines Beratungs-Back-office: ein Case-Management-Kern, der den Kunden-Lebenszyklus über Standard-Werkzeuge hinweg lückenlos steuert und rechtssicher dokumentiert — und dabei selbst nur den Prozesszustand, die Referenzen und den Audit-Trail besitzt, nicht die Daten.
7. Konsequenzen (Prüfstein für jede Funktion)
- Baue ich gerade ein Standard-Tool nach? → Stopp, anbinden (G-1), Eigenbau begründen.
- Speichere ich abgeleiteten Zustand? → Stopp, ableiten (G-2).
- Ist die Aktion auditierbar? → sonst fehlt der Kern (G-4).
- Beantwortet die Funktion eine der drei True-North-Fragen direkter/schneller/genauer? → sonst kritisch hinterfragen (Sanity-Checkliste).
Pflege. Ändert sich der grundlegende System-Charakter (nicht ein einzelnes Modul), hier nachziehen —
und nur hier; Modul-/Felddetails bleiben im Lastenheft kanonisch
(Decision-Sprawl vermeiden).