Product tour
On-site hub and downtime
What happens when the internet drops: an on-site hub, safe-mode levels, sealed downtime reports and a restore drill.
Diagram: replication. The on-site hub keeps alerts and messages running with the internet down.
What exists Pilot
- An on-site hub that runs alerts and messaging with the internet down and replicates when it returns.
- Replication bundles that are encrypted, signed, hash-chained and sequence-numbered; on-site MRNs use a separate range.
- A read limiter whose trip pauses cloud sync only; resuming needs two signers.
- Downtime mode: a ladder of levels with a role-based ceiling, banners, sealed downtime reports that are re-verified on every read, and back-entry of paper records with original and entry times.
- A browser read cache that lives only in memory, is read-only and is cleared when the screen locks.
- Backups with per-table digests, a signed manifest and an isolated restore drill.
Limits Open
- No screen yet to resolve a replication conflict; it pauses sync until resolved by other means.
- Promoting a restored backup records the dual-authorised decision only; it does not swap the live database.
- Site secrets and the backup signing key are demo-grade, and key custody is an open owner decision.
- No uptime or recovery-time figure is published or promised.
- Code status is derived from order names, because there is no structured code-status field.
Common questions
Does it work without internet?
In part. The on-site hub runs alerts and messaging locally, and downtime mode and an in-memory read cache support the chart. It has been tested on synthetic data only, and we publish no uptime figure. Resolving a replication conflict has no screen yet.
Is there a backup?
There is a verifiable backup and an isolated restore drill. Promoting a restore records the decision with two authorisers and does not replace the live database. Key custody is not production grade.
See on-site hub and downtime on synthetic data
A short walkthrough. No patient information needed.