Architecture
Everything critical runs inside the hospital. Each hospital has its own on-site node that serves the kiosks and staff screens, and connects to a regional cloud when a connection is available.
Front ends
Section titled “Front ends”| Interface | Used by | Purpose |
|---|---|---|
| Kiosk | Patients | Self check-in and structured clinical questions |
| Clinical | Triage nurses | Waiting room board, nurse confirmation, manual check-in, kiosk status |
| Hospital Admin | Site managers | Departments, kiosks and devices, routing rules, integrations |
| Content | Clinicians | Writing, testing and publishing pathways |
Kiosks, Clinical and Hospital Admin are served by the hospital node.
Hospital node
Section titled “Hospital node”Each hospital runs its own node on site. It holds:
- check-in, the triage engine and routing
- local sign-in, so staff can sign in with locally cached credentials
- the local database and cached pathways
- FHIR and HL7 integration with the hospital’s existing systems
There are two nodes per site, so one can fail without stopping check-in.
Offline by default
Section titled “Offline by default”If the connection drops, the waiting room does not notice.
| Keeps working offline | Waits for reconnection |
|---|---|
| Check-in and questionnaires | New pathway versions |
| Scoring and red flags, from cached pathways | Cross-site reports and dashboards |
| Waiting room board and nurse confirmation | Off-site backup of the latest records |
| Routing and hospital system integration | |
| Staff sign-in with locally cached credentials |
Every change is queued on site and replayed in order once the node is back online.
When connected, the hospital node uses the cloud for:
- sync and off-site backups
- pathway content, published from the Content studio
- reports and monitoring
There are two independent clusters:
| Region | Serves | Nodes |
|---|---|---|
| EU | Hospitals in the EU | 3 × OVHcloud Advance-1 |
| UK | Hospitals in the UK | 3 × OVHcloud Advance-1 |
Each hospital is attached to exactly one region, so its patient data stays in its territory.
Cluster layout
Section titled “Cluster layout”Each cluster consists of three OVHcloud Advance-1 dedicated servers running Kubernetes. Three nodes is the minimum for a highly available control plane: etcd keeps quorum and the cluster stays operational if any single server fails.
Multi-hospital design
Section titled “Multi-hospital design”One codebase is configured at three levels.
| Level | Managed in | What it controls | Patient data |
|---|---|---|---|
| Central | Content studio | Pathways, safety questions, languages | None |
| Territory | Hospital Admin | Which pathway versions are live, data residency | Stays in territory |
| Hospital | Hospital Admin | Departments, kiosks, routing rules, opening hours | Isolated per hospital |
Every query is scoped to one hospital by the database itself, not only by application code, so a bug cannot leak another hospital’s patients.
Triage engine
Section titled “Triage engine”Clinical rules are tested, versioned data rather than code.
- Author: clinicians write pathways in the Content studio, with no code changes.
- Test: each pathway carries reference cases. A release is blocked if any case is under-triaged.
- Sign off: the clinical safety officer approves each version before it goes live.
- Run: scoring is deterministic. The same answers give the same result, with the reasons shown.
The engine suggests. A nurse confirms every acuity score, and every change is logged with a reason.
Technology
Section titled “Technology”| Layer | Choice |
|---|---|
| Front ends | React, TypeScript |
| Kiosk | Offline-capable web app |
| Services | Go |
| Data | PostgreSQL on site and in cloud |
| On site | Small node per hospital |
| Cloud | Kubernetes, UK and EU regions |
Backups are restored and tested, not just taken, and monitoring alerts the team before staff notice a problem.