Search all 478 artefacts by title, document ID or content.
Disclosure | Family 3, Security, Privacy & Trust Disclosures
This document is for the person who has to decide whether Pensieve can be operated safely inside a hospital: the IT head, the group CIO, the incumbent maintenance partner, or an external reviewer.
This document is the source of truth for: platform-architecture, tenancy-architecture, extensibility-model, integration-architecture, marketing:/product/architecture
Those surfaces render this text from here. They do not keep their own copy, so they cannot drift from it.
Artefacts this one references or cannot be issued without.
Artefacts that would be blocked if this one were missing or out of date.
Position as at 01 August 2026 | Public
DM-1 Dedicated |
DM-2 Shared |
DM-3 Customer Cloud |
DM-4 On-Premise |
|---|---|---|---|
| Yes | Yes | Yes | (Section 9 records what differs, and what is not available) |
This document is for the person who has to decide whether Pensieve can be operated safely
inside a hospital: the IT head, the group CIO, the incumbent maintenance partner, or an external reviewer.
It describes what the Platform is technically: its layers, its tenancy model, how it is configured rather than customised, how it integrates, how it is released and observed, and where its limits are.
It deliberately does not repeat what other documents own:
| Subject | Where it lives |
|---|---|
| Security controls in depth | WPR-GL-001 |
| Network and data-flow diagrams, per model | DIS-GL-006 (sanitised), DIS-GL-007 (detailed, NDA) |
| Which deployment model to choose | WPR-GL-004 |
| Encryption and key management specifics | DIS-GL-011 |
| Tenant isolation mechanics | DIS-GL-032 |
| Interoperability standards supported | DIS-GL-029 |
| Uptime, performance and capacity figures | DIS-GL-030 |
| What Pensieve has and does not have | WPR-GL-005 |
Pensieve is an operating system for a hospital, not a hospital-management application.
The practical meaning of that sentence is architectural rather than promotional:
| Property | What it means technically |
|---|---|
| One substrate, not a suite of modules | There is a single data model, a single identity and permission model, a single audit trail, a single job engine and a single integration layer. Registration, pharmacy, billing, laboratory, procurement and analytics are configurations of that substrate, not separate applications with their own databases stitched together at the edges |
| No inter-module integration | The commonest source of failure in a hospital estate is a module boundary: a patient who exists in three systems, a charge captured in one and not another. Those boundaries do not exist inside the Platform because there is one record |
| Configuration, not code, for the hospital-specific parts | Departments, forms, workflows, tariffs, packages, reports, roles and approval chains are configuration held as data, versioned and auditable. A new department is a configuration change, not a release |
| Extension without forking | Where a hospital needs something the substrate does not yet express, it is added to the substrate for every hospital, not branched for one. There is exactly one code line |
| The Platform is deployed, not installed | A deployment is provisioned from declarative configuration. There is no per-hospital build, no per-hospital binary and no per-hospital branch |
The consequence a reviewer should test: ask whether adding a department, a tariff structure or a report
requires a release. If a supplier says yes, it is a module vendor. In Pensieve it does not.
| # | Layer | What it does | Reviewer's question it answers |
|---|---|---|---|
| 1 | Edge | TLS termination, web application firewall, rate limiting, request routing | How does traffic get in, and what stops abuse |
| 2 | Identity and authorisation | Authentication, session binding to a tenant, role and permission evaluation on every request | Can a user of one hospital ever see another's data |
| 3 | Application services | The Platform API, running as managed containers | What executes the business logic |
| 4 | Workflow and jobs | Background workers for scheduled work, exports, document generation and integration traffic | What happens when nobody is looking at a screen |
| 5 | Record | The relational store holding the hospital's structured record | Where the data actually is |
| 6 | Object store | Documents, scanned material, images and generated PDFs | Where large binaries live |
| 7 | Secret store | The hospital's own credentials for its external systems, per tenant | Who holds our ABDM and payer credentials |
| 8 | Key management | Envelope encryption keys, per deployment or per tenant | Who can decrypt |
| 9 | Audit and log | Immutable, retention-locked audit and access records | Can we prove who saw what |
| 10 | Configuration | The versioned definition of this hospital's departments, forms, workflows, tariffs, roles and reports | What makes this hospital's Platform this hospital's |
Layer 10 is the one that distinguishes the architecture. In most hospital software the equivalent of layer 10 is source code. Here it is data: versioned, diffable, exportable, and changeable without a release.
The diagram of how these layers connect, per deployment model, is DIS-GL-006. It is not repeated here.
| Component | Choice | Why, and what a reviewer should know |
|---|---|---|
| Cloud | Google Cloud Platform | DM-1, DM-2 run in Pensieve Labs's cloud organisation; DM-3 runs in the hospital's own project on the same platform, which is why the deployment is portable between them |
| Compute | Managed containers (Cloud Run) | No Pensieve Labs-managed virtual machines and no Pensieve Labs-operated operating system in the hosted models. There is no server for an attacker to log in to, and no patching queue for a host Pensieve Labs cannot see |
| Record store | PostgreSQL | A single relational store per deployment (DM-1, DM-3, DM-4) or a logically isolated store per tenant (DM-2). Standard, exportable, and readable by the hospital's own tools on export |
| Object store | Managed object storage | Documents and images, encrypted with the deployment's own keys |
| Secrets | Managed secret store, per tenant | The hospital's own credentials: custody, rotation and revocation are ADD-GL-007 and DIS-GL-025 |
| Keys | Cloud key management service | Dedicated key ring per deployment in DM-1; per-tenant keys in DM-2. Detail is DIS-GL-011 |
| Logs | Regional log bucket, retention-locked | Immutable, and Pensieve Labs engineers cannot alter or delete them (DIS-GL-013, DIS-GL-034) |
| Trust Center | Next.js on Vercel with a managed Postgres | Separate from the Platform. No Customer Data of any hospital is held in the Trust Center |
No component of the Platform is operated on hardware Pensieve Labs owns. In DM-4 the hardware is
the hospital's (ADD-GL-008).
The isolation mechanics per model are DIS-GL-032 and are not restated. The architectural summary:
| Model | Boundary | What a tenant shares with another |
|---|---|---|
DM-1 |
A cloud project per hospital. Dedicated services, database, object store, secret store, key ring and log bucket | Nothing. There is no network path, no shared identity plane and no shared datastore |
DM-2 |
Logical isolation within a shared platform: row-level security enforced in the datastore, per-tenant encryption keys, tenant bound to the session at the identity layer | Compute capacity and the platform's own control plane. No data |
DM-3 |
The hospital's own cloud project | Nothing: it is the hospital's account |
DM-4 |
The hospital's own hardware | Nothing |
Two properties hold in every model, including DM-2:
Pensieve Labs does not build, hold or derive a dataset spanning
hospitals, for analytics, benchmarking, product improvement or model training. That is architectural
and contractual: ADD-GL-006 5 and DPA-GL-001.This section exists because it is the part reviewers most often assume must be custom code.
| Configurable | Held as | Versioned | Changeable without a release |
|---|---|---|---|
| Departments, specialities, service points | Data | Yes | Yes |
| Forms and their fields, validation and mandatory rules | Data | Yes | Yes |
| Clinical documentation templates | Data | Yes | Yes |
| Workflows, states and transitions | Data | Yes | Yes |
| Roles, permissions and approval chains | Data | Yes | Yes |
| Tariffs, packages, payer schemes and discount rules | Data | Yes | Yes |
| Order sets and protocols authored and approved by the hospital's own clinicians | Data | Yes | Yes |
| Reports and dashboards | Data | Yes | Yes |
| Document layouts and print formats | Data | Yes | Yes |
| Integration mappings | Data | Yes | Yes |
| Notification and escalation rules (administrative, not clinical alarms) | Data | Yes | Yes |
Three consequences.
DM-1 deployment for a two-hundred-bed hospital
is measured in days rather than months.DIS-GL-023.What configuration may never express. A hospital cannot configure the Platform to produce a clinical
determination. The boundary in DIS-GL-028 Section 7 is enforced in the substrate, not in each configuration, and
a rule the hospital authors is presented as the hospital's rule, with its inputs and its threshold visible
(DIS-GL-028 Section 9).
The governing principle is DIS-GL-024: the hospital is the participant, and the Platform acts on the
hospital's own authority using the hospital's own credentials.
| Property | Position |
|---|---|
| Credential custody | Per-tenant secret store, encrypted with the tenant's keys. Rotation, revocation and destruction on exit are ADD-GL-007 and DIS-GL-025 |
| Who the counterparty sees | The hospital. Pensieve Labs is not a registered participant in ABDM, NHCX or any payer network and does not represent that it is |
| Standards | DIS-GL-029 records what is supported. This document does not restate it |
| Direction | Outbound calls originate from background workers, never from a user's browser |
| Failure behaviour | An integration failure degrades that integration, not the Platform. Queues retain work and replay; the hospital sees the queue |
| Device integrations | Analysers, imaging modalities and printers are reached over the hospital's own network segment. Pensieve does not analyse an image or a device signal (DIS-GL-028 Section 7.1) |
| Adding an integration | Mapping and configuration where the interface is one the Platform already speaks; otherwise a substrate change, on the single code line |
What is deliberately absent: there is no Pensieve Labs-operated central integration hub through
which hospitals' traffic passes. Each deployment calls out for itself. That removes a shared component that
would otherwise see every hospital's data.
The process is DIS-GL-031 and the contractual position is ADD-GL-002. Architecturally:
| Property | Position |
|---|---|
| Code lines | One. No per-hospital branch, no per-hospital build |
| Deployment unit | An immutable container image, promoted between environments; the same image runs in every hosted deployment |
| Configuration | Separate from the image, per deployment, versioned |
| Database change | Forward-compatible migrations; a release does not require downtime for a schema change of the ordinary kind |
| Rollback | Every release has a documented rollback path (ADD-GL-002 3.5) |
| Who applies it | Pensieve Labs in DM-1, DM-2; Pensieve Labs under delegated access in DM-3; by agreed window in DM-4 (ADD-GL-002 6) |
| Observability | Structured logs, request tracing and service metrics inside the deployment. Telemetry does not carry record content out of the deployment |
| Audit trail | Separate from operational logging, immutable, retention-locked, readable and exportable by the hospital (DIS-GL-013) |
Nothing about a hospital's data leaves its deployment for Pensieve Labs's operational purposes.
Where Pensieve Labs needs to diagnose a fault, an engineer's access is second-person approved,
time-bound and logged, DIS-GL-033.
| Item | Position |
|---|---|
| Scaling model | Horizontal, by adding container instances. Concurrency is managed by the platform rather than by capacity planning per hospital |
| The real constraint | The record store, not the application tier. Capacity is monitored per deployment (POL-GL-126) |
| Published figures | DIS-GL-030. This document does not state an uptime, latency or throughput figure, because a figure without its measurement method is not information |
| Bed count | Pricing bands vary with beds; the architecture does not. A two-hundred-bed and a two-thousand-bed deployment differ in capacity allocated, not in shape |
| Multi-site | Each site is its own deployment or its own tenant. Group-level views exist only where ADD-GL-010 Schedule 1 records the sharing and its lawful basis |
| Degraded operation | Where an integration or an external system is unavailable, the Platform continues and queues. Where the Platform itself is unavailable, the hospital's downtime procedure governs (DIS-GL-015 Section B3), and it is the hospital's, not Pensieve Labs's |
| Property | DM-1 |
DM-2 |
DM-3 |
DM-4 |
|---|---|---|---|---|
| Cloud account owner | Pensieve Labs |
Pensieve Labs |
Hospital | Not applicable |
| Compute | Managed containers, dedicated project | Managed containers, shared platform | Managed containers, hospital's project | Hospital's hardware |
| Record store | Dedicated | Logically isolated per tenant | Dedicated, hospital's project | Hospital's hardware |
| Keys | Dedicated key ring | Per-tenant keys | Hospital's project, hospital may hold the key material | Hospital's |
| Who applies releases | Pensieve Labs |
Pensieve Labs |
Pensieve Labs under ADD-GL-009 |
By agreed window (ADD-GL-002 6) |
| Availability commitment | Yes (SLA-GL-001) |
Yes | Limited (SLA-GL-001 5) |
None (SLA-GL-001 6) |
| Features requiring external egress | Available | Available | Subject to the hospital's egress policy | Unavailable without permitted egress (DIS-GL-027 Section 6) |
| Backup custody | Pensieve Labs |
Pensieve Labs |
Hospital's project | Hospital (ADD-GL-008) |
| Time to go-live | Fastest | Fast | Medium: depends on the hospital's cloud readiness | Slowest; breaks the fourteen-day path |
DM-1 is the recommended default. The reasons are architectural as much as commercial: it gives the
strongest isolation story without requiring the hospital to hold cloud competence, and it is the only model
in which Pensieve Labs controls every dependency it is asked to commit to. WPR-GL-004 Part E states
the recommendation in full.
| Question | Document |
|---|---|
| Show me the data flows and every boundary crossing | DIS-GL-006, or DIS-GL-007 under NDA |
| How is data encrypted, and who holds the keys | DIS-GL-011 |
| How do you stop one hospital seeing another's data | DIS-GL-032, and Section 4 above |
Who at Pensieve Labs can reach our data, and how is it approved |
DIS-GL-033, DIS-GL-012 |
| What is logged, for how long, and where | DIS-GL-013, DIS-GL-034 |
| What are your recovery objectives | DIS-GL-014 |
| What third parties are involved | DIS-GL-009 |
| What standards do you interoperate with | DIS-GL-029 |
| What happens when we leave | DIS-GL-023, ADD-GL-017 |
| What certifications do you hold | None. WPR-GL-005 states what exists instead |
| Is it a medical device | No. DIS-GL-028 |
| Do you use AI, and does it touch clinical decisions | DIS-GL-027, ADD-GL-006. It does not |
Stated because a reviewer will find them, and finding them here is better than finding them later.
11.1 This document is architectural, not a design specification. It describes shape and boundaries. It
does not publish internal service names, repository structure, schema, hostnames or capacity figures.
DIS-GL-007 carries the detailed network view at the NDA tier; internal design is not published at any
tier, because publishing it would help an attacker more than it would help a reviewer.
11.2 No certification underwrites any statement here. Pensieve Labs holds none (WPR-GL-005).
What is offered instead is that every claim in this document is testable against a named document, and that
several of those documents record what is not yet done.
11.3 DM-4 is architecturally the weakest position and is described as such. The hardware, the
environment, the backup custody and the physical security are outside Pensieve Labs's control, no
availability commitment is possible, and features requiring egress are unavailable. It exists because some
hospitals require it, not because it is a good outcome.
11.4 Legacy device constraints. Where a hospital's existing analyser or imaging node cannot offer
transport encryption, the limitation is recorded in the deployment record rather than solved by
Pensieve Labs (WPR-GL-001 Section 17.6). The compensating control is network segmentation, which is the
hospital's.
11.5 Published performance figures are limited. DIS-GL-030 states what has been measured.
Pensieve Labs does not publish a figure it has not measured, which means some questions have the
answer "not yet measured" rather than a number.
11.6 The configuration model has a boundary. Not everything a hospital may want is configurable today;
where it is not, it is a substrate change on the single code line, with a roadmap position and no
guarantee of date. ADD-GL-002 7.2 records that a capability that does not exist is not a
condition of go-live.
| Identifier | Artefact | Relationship |
|---|---|---|
WPR-GL-001 |
Security Whitepaper | The control set; this document is its architectural companion |
WPR-GL-003 |
Data Protection & Privacy Whitepaper | The privacy architecture |
WPR-GL-004 |
Deployment Models Explained | Which model, and why |
WPR-GL-005 |
Trust & Assurance Overview | What exists in place of certification |
DIS-GL-006, DIS-GL-007 |
Network & data-flow diagrams | The diagrams this document does not repeat |
DIS-GL-011 |
Encryption Disclosure | Keys and algorithms |
DIS-GL-029 |
Interoperability & Standards | What the Platform speaks |
DIS-GL-030 |
Uptime, Performance & Capacity | The measured figures |
DIS-GL-031 |
Change Management & Release | The release process |
DIS-GL-032 |
Multi-Tenancy Isolation | The isolation mechanics |
DIS-GL-033 |
Remote Access & Support Model | How engineers reach a deployment |
DIS-GL-027, DIS-GL-028 |
AI disclosure; clinical safety boundary | The two boundaries the architecture enforces |
ADD-GL-007 |
BYOK / BYOC Credential Handling Addendum | Credential custody |
ADD-GL-008, ADD-GL-009 |
On-Premise Supplement; Delegated Cloud Access | DM-4 and DM-3 particulars |
ADD-GL-002 |
Support & Maintenance Addendum | Release entitlement and version currency |
| Version | Date | Author | Summary |
|---|---|---|---|
| 1.0.0 | 01 August 2026 | Security | Initial issue. Describes the ten-layer architecture, the single-code-line and configuration-as-data model that makes a department a configuration rather than a release, the tenancy boundary per deployment model with datastore-level tenant scoping, the integration architecture in which each deployment calls out on the hospital's own credentials with no central hub, and a limitations section that states the DM-4 position and the unmeasured performance questions plainly. |