Kliniq
Surgical Scheduling
OP-Planung
am Limit
OP-Zeit ist die knappste Ressource einer Klinik — und wird trotzdem meist über geteilte Tabellen und Telefonate geplant. Überlappende Buchungen rutschen durch, niemand hat eine Live-Sicht auf den Tag, und jede Änderung löst eine weitere Runde manueller Koordination aus — eine Reibung, die mit wachsender Klinik leise immer größer wird.
Konfliktfrei
per Konstruktion
Kliniq ist eine von Grund auf gebaute Planungsplattform — ein Kotlin / Spring Boot 3 Backend mit jOOQ über PostgreSQL und ein SvelteKit-Frontend. Überlappende Buchungen werden nicht bloß im Anwendungscode wegvalidiert; ein Postgres-EXCLUDE-Constraint macht sie schlicht unmöglich einzufügen. Server-Sent Events halten jeden offenen Plan live, Drag-and-Drop verschiebt eine Buchung direkt, und ein selbst gehosteter Auth-Stack (Argon2id + WebAuthn-Passkeys) trägt das Ganze ohne externen Identity-Provider. Solo gebaut und ausgeliefert, von Anfang bis Ende.
Doppelbuchungen möglich
Postgres-EXCLUDE-Constraint
RBAC-Rollen
Admin · Manager · Personal
Echtzeit-Plan
Server-Sent Events
Backend-Tests
dazu 8 Playwright-E2E
Konfliktfrei per Konstruktion
Ein Postgres-EXCLUDE-USING-gist-Constraint über jeden OP-Saal und einen tstzrange macht zwei überlappende Buchungen physisch unmöglich einzufügen — Integrität von der Datenbank garantiert, nicht durch hoffnungsvolle Prüfungen im Anwendungscode.
Buchungs-Zustandsmaschine
Jede Buchung durchläuft einen deterministischen Lebenszyklus — Geplant → Laufend → Abgeschlossen / Storniert — mit abgesicherten Übergängen in der Domänenschicht, die unzulässige Sprünge ablehnen, bevor sie die Datenbank erreichen.
Echtzeit über SSE
Server-Sent Events streamen jedes Anlegen, Bearbeiten und Stornieren an alle verbundenen Dashboards — der Plan bleibt klinikweit live, ohne Polling und ohne manuelles Neuladen.
Selbst gehostete Auth
Argon2id-Hashing, WebAuthn-Passkeys, Redis-gestützte Sessions, CSRF-Schutz und IP-basiertes Rate-Limiting — ein vollständiger Identity-Stack von Grund auf gebaut, ohne Auth0 oder externen Provider.
Live-Demo
Die Demo läuft auf kliniq.izotov.dev mit drei Operationssälen und zwei Wochen Buchungen. Melde dich als Demo-Chirurg an — [email protected], Passwort DemoSurgeon2026! — und verschiebe eine Buchung; ein zweiter Browser-Tab sieht die Änderung ohne Neuladen.
Fragen
zur Architektur?
Ich erkläre gern, warum der Schutz vor Doppelbuchungen in der Datenbank sitzt und nicht in der Oberfläche — und was das an anderer Stelle an Komplexität gekostet hat.