In clinical software, the most dangerous product is not the one that lacks features. It is the one that looks ready to act when it is not.
That was the design problem behind EPI WohnWerk KIS, a qualification demonstrator we built for a Swiss epilepsy-care tender. The buyer context is substantial: approximately 300 clients, 400 staff, six role groups and 60 resource agendas across residential care. The tender asks bidders to prove four connected workflows — clinical and service documentation, seizure-focused progress documentation, scheduling, and closed-loop medication.
Our aim was not to make a polished screen that implied a finished clinical product. It was to demonstrate the critical behaviour in working software while making every ungranted approval impossible to miss.
Status boundary: this is a local qualification-preparation release using synthetic data only. It is not approved for patient data, care delivery, diagnosis, treatment decisions, productive identity, authoritative vendor exchange, hosting or a private pilot.
Six rights, one committed state change
Medication administration is where a loose prototype becomes dangerous. The tender requires all six rights: the correct person, medication, dose, time, route and documentation. The sixth right cannot be a checkbox clicked before anything is stored.
So the demonstrator resolves one due dose against one active order version, verifies all six conditions, commits the administration and audit event together, then reads the stored state back before reporting success. Wrong identity, stale order, wrong dose or route, duplicate administration and missing reasons for non-administration are blocked.
The browser is not the clinical authority. Fastify and PostgreSQL execute transactions, version checks and clinical rules on the server. That distinction matters: interface behaviour can guide a user, but only the authoritative state change can prove what happened.
A control plane that cannot approve itself
Clinical systems need more than a release checklist. They need a reliable separation between evidence the delivery team can produce and decisions only the responsible institution can make.
The V1.5 control plane calculates four local qualification packages: intended purpose and claims, a synthetic human-factors rehearsal, DPIA and hosting preparation, and local IAM mechanics. Exactly five external gates remain fail-closed. The application exposes no route that can turn those external decisions green.
The hard decisions returned by the system remain explicit: real data is not allowed; care use is not allowed; public hosting is not allowed; authoritative vendor mutation is not allowed; and a private synthetic pilot is not authorised while any external gate remains open.
That is a more meaningful safety property than a disclaimer in a PDF. The boundary lives in the data model, API decisions, interface and automated tests.
Access control below the interface
The demonstrator authenticates through a local Keycloak identity provider and validates stable subject, audience, authentication time and role. Its PostgreSQL runtime is neither database owner nor superuser. Forced row-level security protects 18 clinical tables, limiting each role to its assigned synthetic client scope.
Integrations follow the same truth discipline. FHIR R4 contracts and medication-safety responses are structured and testable, but remain clearly marked simulated until an actual vendor connection is verified. A fixture is useful evidence of architecture; it is not vendor acceptance.
Evidence, not theatre
The release is backed by executed evidence, not screenshots alone:
- 52/52 PostgreSQL integration tests pass across application, qualification, RLS and resilience behaviour.
- A synthetic human-factors rehearsal covers six roles and twelve scenarios, with zero critical dry-run errors — while explicitly not claiming real-user or clinical acceptance.
- Dependency audit and secret scan pass with no known vulnerability finding in the recorded release check.
- An encrypted, isolated restore verifies the migrations, forced-RLS tables, immutable triggers, external-gate state and audit chain.
- Tested desktop and 390/320-pixel views show no serious or critical Axe accessibility findings.
This does not prove that the system is ready for clinical use. It proves something more precise: that Operal can turn a complex institutional brief into an executable system, bind important claims to evidence, and keep the system from granting authority it does not own.
That is Jurisdictional Integrity applied beyond hosting. It is control over who may act, what the software may claim, where the evidence comes from — and which decision must remain human.