Reference table
Shared responsibility
Sets out which operational duties rest with Pensieve and which rest with the hospital, across hosting, backup, monitoring and updates.
Running a hospital on Pensieve divides into two kinds of work, and the line between them is steady. Pensieve supplies the mechanism, and the hospital owns the procedure and the judgement. This page sets out the fixed split, then the few duties that move with the deployment model.
The dividing line
Most duties do not move between deployment models. Pensieve runs the hosted software, watches it, and keeps the mechanisms a hospital needs when something fails. The hospital keeps its own procedure, its own devices and network, its own clinical configuration, and its own answer to a patient. Each row below states the mechanism Pensieve supplies and the procedure the hospital owns.
| Concern | Pensieve | The hospital |
|---|---|---|
| Running the Platform | Runs the hosted Platform on managed containers and applies each release. | Nothing to operate in the hosted models. In DM-4 On-premise the hospital agrees the release window. |
| Monitoring | Monitoring and alerting run continuously and route to an on-call engineer. | Reports what it observes through support, and follows its own escalation. |
| The downtime procedure | Supplies the paper-form templates, the export mechanism and the back-capture workflow. | Owns the procedure, declares downtime, tells the wards, and rehearses it. |
| Endpoints and network | Holds no responsibility for the hospital's devices or local network. | Its own endpoint and network response, including during a destructive compromise. |
| Clinical configuration | Holds the substrate that carries the configuration, and produces no clinical determination. | Authors and approves its order sets and rules, and stands behind the people who act. |
| A patient's data request | Refers a request it receives directly to the hospital's grievance officer. | Decides and answers the patient, as the Data Fiduciary for the care it delivers. |
Why the line sits here
Pensieve holds no clinical certification and takes no clinical decision. The mechanisms are ours to build and run. The judgement about a patient, and the procedure a ward follows when a screen is dark, stay with the hospital that employs the clinicians.
Duties that move by deployment model
Three duties shift with the model: who executes the backup, who holds the media, who performs a restore, and who controls remote access. Each cell below reads as a property that holds, or does not hold, for that model.
| DM-1 Dedicated | DM-2 Shared | DM-3 Customer cloud | DM-4 On-premise | |
|---|---|---|---|---|
| Pensieve executes the backup | Present | Present | Present | Absent |
| Pensieve holds the backup media | Present | Present | Absent | Absent |
| Pensieve performs the restore | Present | Present | Present | Partial |
| Remote access is the hospital's to switch off | Absent | Absent | Present | Present |
| Pensieve holds standing access to data | Absent | Absent | Absent | Absent |
In DM-1 Dedicated and DM-2 Shared, Pensieve executes and holds the backups and performs any restore. In DM-3 Customer cloud, Pensieve executes the backup inside the hospital's own cloud project, so the hospital holds the media while Pensieve still runs the restore. In DM-4 On-premise the hospital executes and holds everything, and restores its own system with Pensieve's support. Pensieve commits recovery objectives only where it controls the infrastructure. The mechanics and their conditions are set out in recovery objectives.
Remote access moves the same way. In DM-1 and DM-2 the control is procedural: an engineer reaches production only under a request that a second person approves, that is least-privilege, time-bound and expiring, and that is written to the hospital's own immutable audit trail. In DM-3 and DM-4 the control is structural: the hospital grants and revokes access through its own identity system, or no access exists at all until the hospital opens a session.
No standing vendor access
In every deployment model, no Pensieve identity holds standing permission to read a hospital's data. The default is no access, not restricted access. A hospital can ask for its own tenant's access records at any time and see how often, and by whom, an access was used. That check does not require trusting Pensieve, and reading it is the hospital's own control over its own record. See the audit trail.
When the Platform is unavailable
The split is clearest at the moment of an outage. When an integration or an external system is unavailable, the Platform continues and queues the work. When the hospital's own network or power is lost, the hosted Platform stays up but the hospital cannot reach it, and the hospital's downtime procedure governs. Pensieve builds that procedure with the hospital during onboarding and supplies its templates, but the hospital owns it and exercises it. The behaviour of each case is described in what happens when the link drops.
Can Pensieve read our records without us knowing?
No standing access exists in any model. In DM-1 and DM-2 every access is approved by a second person, expires on its own, and is logged in the hospital's own immutable audit trail. In DM-3 and DM-4 the hospital holds the switch, so there is nothing to read unless the hospital opens the door.
Who holds our backups?
In DM-1 and DM-2 Pensieve executes and holds them. In DM-3 Pensieve executes the backup inside the hospital's own project, so the hospital holds the media. In DM-4 the hospital executes and holds everything and restores with Pensieve's support.
Who answers a patient who asks about their record?
The hospital does. It is the Data Fiduciary for the care it delivers, and it decides and answers. A request a patient sends to Pensieve directly is referred to the hospital's grievance officer rather than actioned by Pensieve.