Concept explainer
Where data lives
Describes where Pensieve stores clinical and financial data, the regions and systems involved, and how residency requirements are met.
A hospital's data does not sit in one place. Its structured record, its documents and imaging studies, its credentials for outside systems, and its audit trail each live in a store built for that job, each of them encrypted with the deployment's own keys and held in the deployment's own region. This page sets out the four stores, how every query is scoped to one hospital, where the data physically sits under each model, the two copies the hospital holds outside those stores, and the one record that is placed outside the tenancy on purpose.
The four stores
A hospital's data is separated by the kind of thing it is, and each kind lives in a store suited to it. The structured record sits in a relational store, large binaries sit in an object store, the hospital's own credentials sit in a secret store, and the audit and access records sit in a log bucket that cannot be altered. Every store is encrypted at rest with the deployment's own keys, held in the cloud key management service.
| Store | What it holds | Notable property |
|---|---|---|
| PostgreSQL record store | The hospital's structured record: registrations, orders, results, prescriptions, billing and financial records | Never reachable from the public internet |
| Object store | Documents, scanned material, imaging studies and generated PDFs | Encrypted with the deployment's own keys |
| Per-tenant secret store | The hospital's own credentials for its external systems | Each tenant's secrets are held under that tenant's keys |
| Regional log bucket | Audit and access records | Immutable and retention-locked. Engineers cannot alter or delete it |
Scoped to one hospital
The stores are shared by kind, not by hospital. Every query is scoped to the tenant at the datastore itself, not only in the application code, so a query that forgets the tenant returns nothing rather than another hospital's rows. Pensieve does not build, hold or derive a dataset that crosses a hospital boundary for analytics, benchmarking or model training, by architecture and by contract.
The site is the tenant. A hospital's operational record, meaning its money, beds, rosters, catalogues and configuration, stays inside that site's tenancy and never crosses to another site. The database carries no public address of its own, and the only public entry point is the load balancer, so a person on the public internet cannot reach the record store at all.
Where it physically sits
Where the data sits depends on the deployment model. Storage, backups and logs all stay in the deployment's own region and country, so residency follows from where the deployment is provisioned rather than from a promise made about it. The region is chosen once, at contracting, and changing it later is a data migration rather than a setting.
| Where it sits | DM-1 Dedicated | DM-2 Shared | DM-3 Customer cloud | DM-4 On-premise |
|---|---|---|---|---|
| Record, documents, imaging studies | Pensieve's cloud project, the deployment region | The shared regional estate | The hospital's own project, the hospital's region | The hospital's premises |
| Messages waiting on the bridge | The hospital's own machine on its network | The hospital's own machine on its network | The hospital's own machine on its network | The hospital's own machine on its network |
| Backups | Same region | Same region | The hospital's project and configured location | The hospital's own media |
| Audit and access logs | Regional log bucket, same region | Same region, tenant-tagged | The hospital's project | The hospital's own log storage |
| Encryption keys | Dedicated key ring | Per-tenant keys | The hospital's key service | The hospital's |
| Who chooses the region | Pensieve, recorded on the order form | Pensieve, per estate | The hospital | The server room is the region |
One copy of patient data sits outside those four stores, on hardware the hospital owns. orophin, the bridge on the hospital network, holds each message it accepts in a durable local queue, encrypted on disk, until Pensieve confirms the write and clears it. Nothing there is parsed, indexed or added to the record, and the queue serves no site but its own. Read how that queue fills and drains in message failure and replay.
No central copy
In every model Pensieve keeps no central copy, warehouse, analytics extract or training corpus of a hospital's data in any other location. A hospital's operational record, its backups, its logs and its keys stay in the deployment's own region, and Pensieve moves none of them to another deployment. The patient's clinical record is placed outside the tenancy structure, as this page sets out below.
The copy the hospital holds for downtime
A second copy sits outside the four stores, and the hospital holds this one on storage of its own choosing. Where a hospital runs a downtime procedure, the standard export mechanism produces a downtime pack of active in-patient summaries and current medication orders, and the hospital receives it onto storage it nominates and administers, so a ward can read it while the site cannot reach the platform. The pack is the hospital's own material. It is encrypted, each refresh supersedes the last rather than adding to a set, and it stays in the deployment's own country because the storage holding it is the hospital's own.
The pack does not make a second record. The record it is drawn from stays the authoritative one, and it is still read from the platform under the access decision. The pack is a read-only extract taken from that record at a stated moment, and it takes no writes. Producing a pack is written to the audit trail. Reading one is not, because the read happens on the hospital's own storage, where the platform has no visibility, which is why the pack is kept narrow and why the hospital's downtime procedure names who may open it. Read what it holds and how long it lasts in what happens when the link drops.
The record that sits outside the tenancy
One record is placed outside the tenancy structure on purpose: the patient's own clinical record. It belongs to the patient, who holds the decision rights over who may read it. It exists once rather than as a separate copy in each hospital, it has no owning hospital, and it follows the patient to each site that treats them. Custody follows the care. Each hospital that treats the patient is the custodian of the care it delivers there, and none of them is the owner of the record. The hospital is the Data Fiduciary, answerable to the patient and the regulator for the care it delivers. Pensieve, as Data Processor, owns nothing and holds no record of its own.
The boundary runs both ways. The clinical record travels with the patient, and the operational record stays with the site, so a patient who moves does not carry a site's operating record, and a site cannot reach a patient it is not treating.
Does Pensieve hold a copy of our data somewhere central?
No. A hospital's operational record, its backups, its logs and its keys stay in the deployment's own region. There is no central warehouse, analytics extract or training corpus, and Pensieve moves none of that data to another deployment. The patient's clinical record sits outside the tenancy structure and follows the patient, as the section above sets out.
Can a query accidentally return another hospital's rows?
No. Every query is scoped to the tenant at the datastore itself, so a query that omits the tenant returns nothing rather than another hospital's data.
Does any patient data sit on the hospital's own machines?
Yes, in two places. Messages waiting to cross sit in the bridge's local queue, encrypted, on the machine the hospital runs orophin on, and are cleared once Pensieve confirms the write. Where the hospital runs a downtime procedure it also holds a downtime pack, an encrypted read-only extract of active in-patient summaries and current medication orders, on storage it nominates and administers. That pack is the hospital's own file, it takes no writes, and each refresh supersedes the last. In the hosted models nothing else runs at the site: no record store and no application container. In DM-4 On-premise the record itself sits on the hospital's premises as well.
Read how long each class of data is kept in retention, which infrastructure each model runs on in where it runs, and how each read and change is recorded in the audit trail.