Concept explainer
Governance of integrated data
Shows how access decisions, purpose of use, provenance, audit records and retention hold for every crossing, so integrated data stays under the hospital's controls.
Pensieve holds data that arrives through an integration to an access decision, a recorded purpose of use and an audit record at every crossing, as it holds data a member of staff enters. This page sets out how each control holds at a crossing, and every one of them runs on the platform, out of reach of the machine that hosts the bridge.
A decision at every crossing
Each bridge holds an intake grant, the permission to deliver messages into the one site it serves, and Cirith Manager checks that grant for every message the bridge sends. The site is taken from the bridge's verified identity, so a message stays at its bridge's site whatever the message itself claims.
The check commits with the message
The intake grant is read inside the receipt transaction that stores the raw message, its integrity record and its boundary record. A grant revoked a moment earlier stops the next message at the check, before any of the three is written.
A scoped write, where a mapped message writes into a record, may touch only the records and fields on its bridge's allow-list, as from message to record describes. A write outside the list is refused and logged as a security event.
A send to a partner starts from an action that the authorisation model permitted, such as a claim filed in Vault. It leaves on a connection that carries a purpose of use.
Purpose of use
Purpose of use is the lawful reason for a crossing, and it is recorded on every boundary record. It is set on the connection when the connection is defined and read from there for each message and each send, so a sending system cannot alter it. A crossing whose connection lacks a purpose fails closed.
Duties held apart
Three different people hold the permissions to register a bridge, to enrol its certificate and to revoke it. Each of the three actions is written to the security events.
Westron grants each panel through its own capability, so a person sees only the panels whose capability they hold. The platform checks every action again as it arrives, so the console carries no authority of its own.
Reading the decoded clinical values of a message in the message inspector also takes the record permission for that patient. Watching a connection's traffic and reading what it carries are separate rights.
The integration records
The integration engine keeps its own records of each crossing, beside the audit trail that records access to the patient record and changes in it. Each is append-only and free of patient data, and the trace identifier ties a crossing's boundary record to its integrity record and to any security event it raised.
| Record | What it holds | What it never holds |
|---|---|---|
| Boundary audit record | One row per crossing: its direction, the bridge or target, the access decision, a hash of the payload, the purpose of use, the consent reference where one applies, and the trace identifier | The message content |
| Integrity record | One row per inbound message, written in its receipt transaction: the site, the bridge, the sending system, the message's own identifier and the SHA-256 hash of the stored bytes | The message content |
| Security event | Each refused or suspect crossing, such as a cross-site attempt, an out-of-scope write, a replay burst or repeated failed authentication, and each bridge registration, enrolment and revocation | Clinical content |
| Upload trail | One row per file that crosses: the connection or person that placed it, the time and a hash of its name | The file name or its rows |
Provenance of mapped data
A mapped record carries the versions that produced it: the mapping configuration, the mapping pack and the terminology releases its codes resolved against. It points to the raw message, stored verbatim at receipt, so each mapped value traces back to the bytes that arrived and the rules that read them. Each translated code keeps the sender's original code and text beside it.
Consent on outbound sharing
Records leave through ABDM with the patient's consent, given through the ABDM consent manager. The ABDM consent artefact is built from the consent Pensieve holds on the patient's record, described in consent and directives, so the patient's decision lives in one place.
The boundary record of each share carries the consent reference it was made under, and a share without one is refused before it leaves the platform.
Abuse controls and the kill switch
Intake is rate-limited per bridge and per site, counted against the identities the platform has verified. Repeated failed authentication locks the caller out, and a burst of replayed messages is detected. Each of these controls answers with the same generic refusal, which does not reveal which control was met.
An anomaly check runs continuously over the security events and boundary records. It raises an advisory for an operator to review when a bridge at a site shows a cluster of cross-site refusals, probes or replays. The check reads and reports, leaving permissions and traffic as they stand.
The kill switch in Westron stops intake before any write and closes live sessions within seconds. Engaging it raises a security event, and the switch itself records who engaged it and when.
Erasure and retention
When the hospital accepts a lawful request, the raw interface copies of that person's data can be erased: the stored message and any rows or file it carried. The message's site is compared with the operator's site before anything is deleted, and the integrity and boundary records remain, so the trail still shows what arrived and when.
A message's receipt key is kept for seven days, the window in which a repeat settles to its first receipt. Every other record follows its record class in retention.
Common confusions
Does the bridge decide what a message may write?
The platform decides. The bridge forwards the message, and the intake grant, the site and the allow-list of records and fields are all checked on the platform.
Can an integration operator read the patient data a connection carries?
An operator needs two separate grants for that: a Westron capability to watch the connection, and the patient's record permission before the message inspector shows decoded clinical values.
Do the integration records hold patient data?
They hold hashes, identifiers, purposes and decisions. The raw message sits apart from them as the source for replay, and it can be erased on a lawful request while the records remain.
Read how a bridge and each partner prove who they are in authentication between systems, and how operators work these controls day to day in running an integration.