Bei klinischer Software ist nicht das Produkt mit zu wenigen Funktionen das gefährlichste. Es ist das Produkt, das handlungsbereit wirkt, obwohl es das nicht ist.
Das war die Gestaltungsaufgabe hinter EPI WohnWerk KIS, einem Qualifikationsdemonstrator, den wir für eine Schweizer Ausschreibung in der Epilepsie-Betreuung gebaut haben. Der Kontext der Auftraggeberin ist substanziell: rund 300 Klientinnen und Klienten, 400 Mitarbeitende, sechs Rollengruppen und 60 Ressourcenagenden in der stationären Betreuung. Die Ausschreibung verlangt den Nachweis von vier verbundenen Abläufen: Fach- und Leistungsdokumentation, anfallsspezifische Verlaufsdokumentation, Terminplanung und Closed-Loop-Medikation.
Unser Ziel war nicht eine elegante Oberfläche, die ein fertiges klinisches Produkt suggeriert. Wir wollten das kritische Verhalten in funktionierender Software zeigen — und gleichzeitig jede noch nicht erteilte Freigabe unübersehbar machen.
Statusgrenze: Dies ist ein lokales Qualification-Preparation-Release mit ausschliesslich synthetischen Daten. Es ist nicht freigegeben für Patientendaten, Versorgung, Diagnose, Therapieentscheide, produktive Identitäten, autoritativen Datenaustausch mit Drittsystemen, Hosting oder einen privaten Piloten.
Sechs Rechte, eine verbindliche Zustandsänderung
Bei der Medikamentenverabreichung wird ein lockerer Prototyp gefährlich. Die Ausschreibung verlangt alle sechs Rechte: richtige Person, richtiges Medikament, richtige Dosis, richtiger Zeitpunkt, richtiger Applikationsweg und richtige Dokumentation. Das sechste Recht darf kein Kontrollkästchen sein, das angeklickt wird, bevor überhaupt etwas gespeichert ist.
Der Demonstrator löst deshalb eine konkrete fällige Dosis gegen genau eine aktive Verordnungsversion auf, prüft alle sechs Bedingungen, schreibt Verabreichung und Audit-Ereignis gemeinsam und liest den gespeicherten Zustand zurück, bevor Erfolg gemeldet wird. Falsche Identität, veraltete Verordnung, falsche Dosis oder Applikation, doppelte Verabreichung und eine Nichtgabe ohne Begründung werden blockiert.
Der Browser ist nicht die klinische Instanz. Fastify und PostgreSQL führen Transaktionen, Versionsprüfungen und klinische Regeln auf dem Server aus. Diese Trennung ist entscheidend: Die Oberfläche kann führen, aber nur die autoritative Zustandsänderung belegt, was tatsächlich passiert ist.
Ein Leitstand, der sich nicht selbst freigeben kann
Klinische Systeme brauchen mehr als eine Release-Checkliste. Sie brauchen eine zuverlässige Trennung zwischen Nachweisen, die das Umsetzungsteam erbringen kann, und Entscheiden, die ausschliesslich die verantwortliche Institution treffen darf.
Der V1.5-Leitstand berechnet vier lokale Qualifikationspakete: Zweck und Claims, einen synthetischen Human-Factors-Probelauf, DSFA- und Hosting-Vorbereitung sowie lokale IAM-Mechanik. Genau fünf externe Gates bleiben fail-closed. Die Anwendung besitzt keine Route, die diese externen Entscheide auf Grün setzen kann.
Die harten Systementscheide bleiben eindeutig: Echtdaten sind nicht erlaubt; Versorgung ist nicht erlaubt; öffentliches Hosting ist nicht erlaubt; autoritative Mutationen in Drittsystemen sind nicht erlaubt; und solange ein externes Gate offen ist, ist auch ein privater synthetischer Pilot nicht autorisiert.
Das ist eine stärkere Sicherheitseigenschaft als ein Hinweis in einem PDF. Die Grenze lebt im Datenmodell, in den API-Entscheiden, in der Oberfläche und in automatisierten Tests.
Zugriffskontrolle unterhalb der Oberfläche
Der Demonstrator authentifiziert über einen lokalen Keycloak Identity Provider und prüft stabiles Subject, Audience, Authentifizierungszeit und Rolle. Der PostgreSQL-Runtime ist weder Datenbank-Owner noch Superuser. Erzwungene Row-Level Security schützt 18 klinische Tabellen und begrenzt jede Rolle auf den zugewiesenen synthetischen Klientenscope.
Bei Integrationen gilt dieselbe Wahrheitsdisziplin. FHIR-R4-Contracts und Medikationssicherheits-Antworten sind strukturiert und prüfbar, bleiben aber klar als simuliert markiert, bis eine echte Lieferantenanbindung verifiziert ist. Ein Fixture ist ein nützlicher Architekturnachweis; es ist keine Lieferantenabnahme.
Nachweise statt Theater
Das Release stützt sich auf ausgeführte Evidence, nicht nur auf Screenshots:
- 52/52 PostgreSQL-Integrationstests bestehen über Anwendung, Qualifikation, RLS und Resilienzverhalten.
- Ein synthetischer Human-Factors-Probelauf deckt sechs Rollen und zwölf Szenarien ab, mit null kritischen Fehlern im Dry Run — ohne eine Abnahme durch echte Nutzende oder eine klinische Freigabe zu behaupten.
- Dependency Audit und Secret Scan bestehen ohne bekannten Vulnerability-Fund im dokumentierten Release-Check.
- Ein verschlüsselter, isolierter Restore verifiziert Migrationen, Forced-RLS-Tabellen, unveränderliche Trigger, den Zustand der externen Gates und die Audit-Kette.
- In den getesteten Desktop- und 390/320-Pixel-Ansichten findet Axe keine schwerwiegenden oder kritischen Accessibility-Probleme.
Das beweist nicht, dass das System für den klinischen Einsatz bereit ist. Es beweist etwas Präziseres: Operal kann aus einem komplexen institutionellen Brief ein ausführbares System machen, wichtige Aussagen an Nachweise binden und verhindern, dass das System eine Autorität vergibt, die ihm nicht gehört.
Das ist Jurisdictional Integrity jenseits des Hostings. Kontrolle darüber, wer handeln darf, was die Software behaupten darf, woher der Nachweis kommt — und welcher Entscheid beim Menschen bleiben muss.