Concept explainer
Where it runs
Describes the hosting options for Pensieve, what runs in the hospital and what runs centrally, and the requirements each option places on a site.
Pensieve is one operating system for a hospital, not a set of tools each with its own database. That single substrate runs as managed services on Google Cloud Platform, and this page sets out the pieces it runs on, where those pieces sit, and the four models a hospital can choose to run them under.
One substrate, run as managed services
Beneath every system Pensieve presents there is one data model, one identity and permission model, one audit trail, one job engine and one integration layer. A department, a tariff or a form is configuration held as data, not a separate application, so the hosting is one stack rather than a bundle of stitched-together services.
That stack runs as managed containers on Cloud Run, so there is no vendor-managed virtual machine or operating system for anyone to log in to in the hosted models. The containers read and write a PostgreSQL record store, an object store for documents and images, and a per-tenant secret store holding the hospital's own credentials for its external systems. A regional log bucket, retention-locked and immutable, receives the audit and access records. Every store is encrypted with the deployment's own keys, held in the cloud key management service.
The four deployment models
A hospital chooses one of four models. They share the same build and the same feature set, and they differ in whose infrastructure the stack runs on, how one hospital is isolated from another, who holds the encryption keys, and what availability Pensieve can commit to.
| Model | Where it runs | Isolation | Keys held by | Availability commitment |
|---|---|---|---|---|
| DM-1 Dedicated | Pensieve's cloud, one project per hospital | A cloud project per hospital | Pensieve | Committed |
| DM-2 Shared | Pensieve's cloud, a shared estate | Logical, tenant-scoped in the datastore with per-tenant keys | Pensieve | Committed |
| DM-3 Customer cloud | The hospital's own cloud project | The hospital's own account | The hospital | Committed, subject to the hospital's project |
| DM-4 On-premise | The hospital's own hardware | Physical, the hospital's premises | The hospital | None |
DM-1 Dedicated is the recommended default. Its isolation is a separate cloud project with a separate database, separate keys and no shared data plane, which is the strongest isolation a hospital can have without running the infrastructure itself. In DM-2 the isolation is logical: every query is scoped to a tenant at the datastore, not only in application code, so a query that omits the tenant returns nothing rather than another hospital's rows. DM-4 is the weakest position, and Pensieve publishes no availability commitment for hardware it does not control.
A hospital's own data stays in its deployment
In every model Pensieve keeps no central copy, warehouse or training corpus of a hospital's data. A hospital's operational record, its backups and its logs stay in the deployment's own region, and Pensieve moves none of them to another deployment or to any analytics destination. The patient's clinical record is the one thing held outside the tenancy structure, and where data lives sets out how it is placed.
What runs inside the hospital
In the hosted models the only Pensieve software that runs inside the hospital is the on-site orophin bridge, which carries the connections to the hospital's own machines. Patient data transits the bridge and rests briefly in an encrypted local queue on a machine the hospital owns, cleared once the platform confirms the write. Staff reach everything else through a browser, so no record store and no application container runs at the hospital. DM-4 is the exception, and there the whole stack runs on the hospital's own hardware.
Data, as opposed to software, does sit on hospital hardware in two places. The first is the bridge queue above. The second is the downtime pack: the standard export mechanism produces it, and the hospital receives it onto storage the hospital nominates and administers, so no Pensieve component holds it at the site. Producing a pack is audited. Reading one is not, because the read happens where the platform has no visibility.
No component of the Platform is operated on hardware Pensieve owns. In the hosted models it runs on managed cloud services; in DM-4 the hardware is the hospital's. The Trust Center, where a hospital reads these documents, is a separate application that holds no hospital record data and is not connected to any deployment.
Does Pensieve keep a copy of our data outside our deployment?
No. There is no central data store, warehouse, analytics extract or training corpus of any hospital's records. A hospital's operational record, its backups, its logs and its encryption keys stay in the deployment's own region. The patient's clinical record sits outside the tenancy structure by design, and where data lives sets out how it is placed.
What runs on hardware Pensieve owns?
Nothing. The hosted models run on managed cloud services rather than Pensieve-owned machines, and in DM-4 the hardware belongs to the hospital.
Read how one deployment serves an organisation and its sites in multi-site and tenancy, where the data physically sits in where data lives, and who holds each duty per model in shared responsibility.