Das Patientenportal: produktionsreif in vier Wochen

Was gebaut wurde

Ein produktionsreifes Patientenportal in vier Wochen. Patientinnen und Patienten bekommen direkten Portalzugriff: Termine, Nachrichten, Dokumente, Videokonsultation und Selfservice für die eigenen Stammdaten. Das Portal steht nicht für sich allein, sondern hängt am bestehenden Praxis-Management-System (PMS) und arbeitet mit den Daten, die schon da sind.

57 Features in vier Wochen. Über 320 Entwicklungsstunden, aus der Zeiterfassung verifiziert, nicht geschätzt. Rund 858 automatisierte Tests. 12 Releases. Eine laufende Testumgebung. Kein Prototyp, sondern ein produktionsreifes System mit Testsuite, CI/CD und einer Architektur, die trägt.

Zum Vergleich: klassische Entwicklung ohne AI bräuchte für denselben Umfang typischerweise 12 bis 16 Wochen mit einem 3- bis 4-köpfigen Team. Hier war es eine Person, AI-gestützt, in vier Wochen. Das Arbeitsvolumen von knapp zwei Entwicklern über ein Quartal, verdichtet auf einen Monat, ohne Abstriche bei Tests, Architektur oder Dokumentation.

Die Rahmenbedingung

Ein Patientenportal ist kein Inselprodukt. Sein Wert entsteht erst in der Anbindung: an den Praxiskalender, an die Stammdaten, an die Abläufe, die im PMS längst laufen. Genau dort scheitern die meisten Projekte. Nicht am Frontend, sondern an der Integration in ein System, das bereits im Betrieb ist.

Die Vorgabe war deshalb nicht, schnell eine Hülle zu zeigen, sondern ein Portal zu bauen, das gegen das echte PMS funktioniert und nicht gegen einen Mock. Was in vier Wochen entsteht, muss am echten PMS bestehen, nicht auf einer Folie.

Was das Portal kann

Eigene Online-Terminbuchung. Patientinnen und Patienten buchen selbst, angebunden an den Praxiskalender über die PMS-Schnittstelle. Konfigurierbare Öffnungszeiten, und das Praxisteam kann direkt im Kalender für Patienten buchen. Eine eigene Buchung statt eines externen Dienstes.

Videokonsultation auf eigener Infrastruktur. Kein externes Video-SaaS. Die Konsultation läuft auf der eigenen Infrastruktur, die Patientendaten bleiben in eigener Hand.

Zwei-Wege-Anbindung ans PMS. Ein Patient beantragt eine Stammdaten-Änderung, die Praxis genehmigt, die Änderung wird zurück ins PMS geschrieben. Ein echter Roundtrip, kein Insel-Portal, das Daten nur anzeigt.

Onboarding per Einladungslink. Das PMS übergibt die Patientendaten, das Portal erfasst sie automatisch und füllt die Stammdaten vor, die Einladung kommt als Link. Kein Doppelerfassen, kein umständliches Registrieren.

Real-time Nachrichten zwischen Praxis und Patient. Live, und bewusst filter- und abschaltbar, damit aus einem Kanal keine Nachrichtenflut wird.

Wie es gebaut und betrieben wird

White-Labeling ohne Code-Deploy. Logo, Farben und Texte sind pro Standort konfigurierbar. Eine Codebase, viele Praxen, ohne Fork.

Modularer Aufbau. Nicht einzelne Features, sondern ganze Funktionsblöcke (Terminbuchung, Video, Nachrichten, Dokumente) lassen sich pro Standort zu- und abschalten. Das Produkt wird pro Kunde zugeschnitten, nicht kopiert.

Vollautomatisierter Aufbau von Runtime und CI/CD. Die komplette Umgebung (Test und Produktion) und die Delivery-Pipeline stehen automatisiert: ein Push deployt die Testumgebung, ein Tag deployt Produktion, mit Format-, Typecheck- und Test-Gates, automatischen Datenbank-Migrationen und Health-Checks. Kein manuelles Deployment, produktionsreif ab Tag eins.

Dazu die Selbstverständlichkeiten, sauber gebaut: 2FA, internes Task-Routing und eine Praxis-Dokumentenbibliothek.

Die Architektur

Core-first, Ports & Adapters. Das PMS sitzt hinter einem sauberen Adapter. Die Domänenlogik lebt in einem eigenen Package, framework-agnostisch und testbar. Das PMS ist angebunden, nicht einbetoniert. Der Adapter lässt sich austauschen, ohne die Kernlogik anzufassen.

Ein Monorepo mit geteilten Types: ändert sich ein Vertrag zwischen Portal und Schnittstelle, bricht der Build sofort und nicht erst in Produktion. Ein hierarchisches Config-Modell in drei Stufen (Anbieter, Standort, Nutzer) trägt das White-Labeling und die Modul-Schalter, ohne Code-Deploy.

Und dann die Kombination, an der die meisten Systeme zerbrechen: Multi-Mandant und Multi-Role zugleich. Viele Standorte auf einer Codebase, sauber getrennt, und eine Person, die gleichzeitig mehrere Rollen trägt (Patient, Praxispersonal, Arzt, Admin). Getragen von einer einheitlichen Identität mit typisierten Profilen: Die Berechtigungen kommen über ABAC aus dem Kontext (wer, welche Praxis, welche Ressource), nicht aus einer starren Rolle. Multi-Mandant und Multi-Role zusammen sind die Königsklasse der Zugriffsarchitektur. Mit klassischem RBAC bricht das Modell. ABAC trägt es.

Und die Qualität ist eingebaut, nicht behauptet: rund 858 Tests über Unit-, Integrations- und End-to-End-Ebene, als Gate vor jedem Push. Der Beweis ist kein Claim, sondern eine laufende Testsuite.

Was daraus bleibt

Ein Portal, das gegen ein echtes PMS läuft und in vier Wochen produktionsreif ist, ist kein Zufall und keine Abkürzung. Es ist das Ergebnis von Disziplin: eine saubere Grenze zwischen Kernlogik und Anbindung, Tests als Gate statt als Nachgedanke, Betrieb als Automatik statt als Handarbeit.

Die eigene Infrastruktur für Video, die austauschbare PMS-Anbindung, die abschaltbaren Module: das ist Souveränität by design statt eines Vendor-Lock-ins, der später teuer wird. Und das Tempo kam nicht trotz der Disziplin, sondern wegen ihr.