Concept explainer
What happens when the link drops
Explains how Pensieve behaves when a site loses its network link, what stays available locally, and how work rejoins once the link returns.
When a site loses its network or its power, Pensieve does not go down with it. The hosted platform stays available, and the site simply cannot reach it. From the ward this looks like an outage, and the hospital's downtime procedure takes over. This page sets out what keeps running, what stops, what the ward reads while the link is down, and where the responsibility for the gap sits.
What stays up and what stops
Pensieve runs in the cloud, apart from the hospital's building. A lost link or a power cut at the site removes the path between the two, not the platform itself. The record is safe and unchanged, and the moment the link returns the site reaches it again. What differs is what each piece does in the meantime.
| Component | What happens while the link is down |
|---|---|
| Staff desktop in Chamber | Stops. No browser reaches the record store directly, so the desktop cannot serve the record from the hospital's side. The ward reads the downtime pack instead, which is a separate file the hospital holds rather than a live view of the record. |
| The orophin bridge | Keeps running. Its listeners still accept messages from the hospital's own machines, and each message is sealed into the local encrypted queue. |
| Outbound pushes to external systems | Held in a durable queue with a size cap and a time limit, and retried rather than lost. |
| Another site | Unaffected when it runs on its own plane. On a shared plane, DM-2 Shared, the outage reaches every site on that plane at once. |
The last row is the principal availability cost of DM-2 Shared: the sites on one plane share an outage. A site on its own plane, under DM-1 Dedicated or DM-3 Customer cloud, is untouched by another site's trouble.
The bridge keeps catching work
orophin, the bridge on the hospital network, does not depend on the outbound link to keep working. Its listeners go on accepting messages from the hospital's own analysers and administration software, together with the study references its imaging source sends. Each message is sealed before it touches disk and written to a local encrypted write-ahead queue on the hospital's own machine.
A message is cleared only on the platform's commit confirmation, never on send, so nothing counts as delivered until Pensieve has recorded it. When the link returns, the bridge replays every pending and unacknowledged message, and Pensieve recognises any that already landed. Outbound pushes to external systems are held the same way, in a durable queue, and retried rather than lost. The mechanics of that queue are set out in message failure and replay.
The hospital's downtime procedure
A hospital does not stop admitting patients because a system is unreachable. While the link is down the ward works on paper and against the downtime pack, then brings the work back into Pensieve afterwards. Every deployment carries a downtime procedure, built with the hospital during onboarding rather than written during the first outage.
Paper is the floor
Printed fallback forms are the record while the link is down. They are stored where the ward can reach them without the system, and every paper entry is brought back into Pensieve afterwards as a late entry that carries its true clinical time and is never back-dated to disguise the gap.
| Element | What the hospital holds ready |
|---|---|
| Paper fallback forms | Printed and current registration, admission, medication administration, and the emergency and theatre record sets. |
| The downtime pack | A read-only encrypted extract of active in-patient summaries and current medication orders, produced by the export mechanism and refreshed on the schedule the hospital sets. It is the hospital's own file rather than a second record, and the section below sets out how it is held. |
| Declaration and communication | Who declares downtime, how the wards are told, and who tells them it is over. |
| Back-capture | How paper entries are entered afterwards, by whom, and within what period, recorded as late entries with their true clinical time. |
| Rehearsal | The hospital exercises the procedure, because one that nobody has practised is a document rather than a capability. |
The downtime pack
The pack is a file the hospital holds, not a second record. Pensieve's export mechanism produces it, the hospital receives it onto storage it nominates and administers, and from the moment it lands it is the hospital's own material under the hospital's own controls. It carries no live view of the record, it takes no writes, and each refresh supersedes the last, so the site holds one current pack rather than a history of them.
| Question about the pack | The answer |
|---|---|
| What it holds | Active in-patient summaries and current medication orders for the site that receives it. It carries no closed encounter, no billing record, no imaging study and no audit trail. |
| Where it sits | On storage the hospital nominates and administers, inside the hospital's own estate and its own country. Pensieve runs no record store at the site, and the pack is a file rather than a store. |
| Who may read it | The staff the hospital's downtime procedure names. The access decision does not reach the pack, so the care relationship, the patient's directives and the sensitivity clearances that govern a live read do not travel with it. |
| Whether a read is logged | Producing a pack is written to the audit trail with the role that requested it and the time. Reading one is not, because the read happens on the hospital's own storage where the platform has no visibility. |
| How long it is kept | Until the next refresh supersedes it. Each pack carries the time it was produced, so a stale one is recognisable, and the hospital destroys the superseded copy on its own schedule. |
| What happens at exit | The hospital destroys it. The pack sits outside Pensieve's systems, so the Certificate of Deletion records what Pensieve deleted and names the pack as material the hospital holds and destroys itself. |
A pack read leaves no line in the access history
The access history answers who read a record in Pensieve. It cannot answer who read the downtime pack, because that read never reaches the platform. A hospital that runs a pack takes on that gap deliberately. It decides who may open the pack, keeps its own account of who did, and keeps the pack narrow so the gap stays small. Write that into the downtime procedure rather than discover it during a review.
Who owns the gap
Pensieve supplies the templates, the export mechanism and the back-capture workflow. The hospital owns the procedure, decides who declares downtime, and rehearses it. That split is the same one that runs through the rest of operations: Pensieve provides the mechanism, and the hospital runs the drill. Read it in full in shared responsibility, and see how far and how fast recovery reaches in recovery objectives.
Does a link drop lose the messages a hospital system sent while it was down?
No. The bridge seals each message into its local encrypted queue and holds it until Pensieve confirms the write, then replays whatever is outstanding when the link returns, so an outage delays delivery rather than losing it.
Can staff read the record from a copy held at the site?
Only from the downtime pack, the hospital's own read-only extract of active in-patient summaries and current medication orders. The live desktop needs the link, because no browser reads the record store directly, and a pack read is outside the platform's access decision and outside the audit trail.
Is the downtime procedure something Pensieve runs?
No. Pensieve supplies the templates, the export mechanism and the back-capture workflow, and the hospital owns and rehearses the procedure itself.