Reference table
Roles and responsibilities
Sets out who does what in an integration, from registering and enrolling a bridge to mapping, approving, holding credentials and watching health.
Pensieve builds and runs the machinery of each integration, and the hospital decides how it is used, by whom and on which systems. This page divides each integration duty between the two, then lists the duties in Westron with the capability each one takes.
The division of duties
Each row applies the split in shared responsibility to one integration duty, with the condition that binds the two sides in its notes.
| Duty | The hospital | Pensieve | Notes |
|---|---|---|---|
| Hosting the bridge | Provides and runs the bridge's server on its network, and places and starts the signed build | Supplies signed builds for Windows x64, Linux x64 and Linux arm64, each with a published checksum | The host's access controls and endpoint protection are the hospital's |
| The hospital network | Opens outbound port 443 from the bridge host and imaging source, and lets each sending system reach the bridge | Supplies the Pensieve addresses at installation and the firewall rules | A sending system that cannot wrap its leg in TLS sits on a segment the hospital protects |
| Bridge registration, enrolment and revocation | Grants each of the three permissions to a different named person, who acts in Westron | Mints the bridge identity, signs and pins its certificate, and closes a revoked bridge's sessions within seconds | The bridge token is shown once, at registration |
| Defining connections | Defines each connection with its purpose of use, and names the system of record for each shared domain | Supplies presets for common system families and the test that checks each connection's reach | A preset fills defaults, and the hospital's own samples prove the result |
| Mapping and approval | Writes each connection's own rules and routes, reads its dry runs and promotes a proven version | Supplies the mapping packs and runs the golden messages and round trip, refusing a promotion they have not cleared | Each version keeps who wrote it and when |
| Terminology overrides | Resolves queued codes into the site overlay and sets how each feed treats a code with no match | Keeps the central base of SNOMED CT, LOINC, ICD-11 with derived ICD-10, and UCUM, and translates every code on the platform | The sender's original code stays beside each resolved term |
| Credentials and registrations | Holds its own registrations and accounts, from ABDM to its merchant account, and supplies each credential | Keeps each credential by reference in the secret store and reads it on the platform at the moment of a call | The claims and payment rails switch on only after a second person's approval |
| Watching health | Its operators watch the health board, the message inspector and the security events, and work the queues | Reads health from real calls, runs the anomaly check and pages its own on-call engineer for the most serious signals | Anything needing Pensieve goes to support as a ticket |
| Replay | Its operators replay parked and held messages once the cause is corrected | Keeps each message's raw bytes for replay, and settles a replay on the existing record | Messages held on the bridge are worked from the bridge's queue |
| Erasure on a lawful request | Decides the request as Data Fiduciary, and its operator erases the raw interface copies in Westron | Checks each copy's site before deleting it, and keeps the records free of patient data | The hash of each erased message stays in its integrity record |
| Support | Its authorised support contacts raise tickets with identifiers and error references, and propose a severity | Confirms or corrects the severity and works to its targets | Patient data stays out of every ticket |
When something fails, the platform keeps every message it has received and holds each outbound send until it is delivered or closes with an error. The hospital's operators then decide what to correct, what to replay and when to stop a connection.
Capabilities in Westron
Each Westron duty takes a capability, which reaches a person through the role they hold at the active site, granted in Cirith Manager. How the console shows each panel and checks each action is set out in governance of integrated data. Westron works on one site at a time, so a person who runs connections at two sites holds a role at each.
Separate capabilities let each duty follow the role that already does that work. A clinical coder resolves codes, an auditor reads the security events and an integration engineer writes mappings, each with the capability that duty needs. Connections, mappings and terminology each carry a read capability apart from the write capability, so a person can follow an area while leaving its changes to others.
| Duty | Capability holder |
|---|---|
| Register a bridge for a site | The holder of the registration permission |
| Enrol a bridge's certificate, first or replacement | The holder of the enrolment permission, granted to a different person from the registrant |
| Revoke a bridge | The holder of the revocation permission, granted to a third person |
| Define, test, activate and delete connections | Holders of the connection write capability |
| Read and export a connection's configuration | Holders of the connection read capability |
| Write mapping rules and verb routes, and promote a proven version | Holders of the mapping write capability |
| Run a dry run on a sandbox site | Holders of the simulation capability |
| Resolve a queued code into the site overlay | Holders of the terminology write capability |
| Watch health, inspect messages and replay them | Holders of the monitoring capability |
| Read a message's decoded clinical values in the message inspector | Monitoring holders who also hold that patient's record permission |
| Engage or release a kill switch | Holders of the kill switch capability |
| Read boundary records and security events | Holders of the audit capability |
| Upload, view and govern files in Westron | Holders of the file read, write or governance capability, by action |
| Erase the raw interface copies of a person's data | Holders of the erasure capability |
| View or update orders in the outside laboratory console | Holders of the laboratory console read or write capability, by action |
Duties outside Westron
Each site's billing mode is held on the site record in Nexus Manager, which also holds the site's Health Facility Registry identifier for ABDM. A change of mode is made from the settings of Vault, and the cases in which it waits for a second person's approval are set out in tax and finance systems.
The second approval for a claims or payment rail is requested and given in Vault, under the rules in approval and second signature. Bulk loads of the hospital model, rate cards and remittances run under permissions of their own in Nexus Manager and Vault, which bulk loads lists.
Pensieve's access to records
Pensieve keeps no standing access to a hospital's data, and every Westron capability comes from a role the hospital itself grants. Engineer access to a record for a ticket follows the approved, time-limited grant in getting help.
Naming the holders
The people behind each duty are named before the stage that needs them, as readiness checklist lists, and each receives the role that carries their capabilities. A role's capabilities and their inheritance are explained in roles and relationships, and the way a person holds roles at a site in people and roles.
A holder who leaves is disabled in Nexus Manager, which ends their sessions and refuses their next sign-in, and a successor is granted the same role. The bridges and connections they set up keep running, since each belongs to its site.
Common confusions
Why are there three bridge permissions?
They are separate capabilities, so the hospital grants each to a different person through their roles. The person able to withdraw a bridge is then not one of the two who brought it into service. Each action is recorded as a security event, so the record shows who registered, enrolled and revoked every bridge.
Who deals with a provider when its service fails?
The provider account belongs to the hospital, which therefore holds the relationship with that provider. Pensieve answers for the adapter that calls the provider, and a fault on that side is raised through support.
Does Pensieve approve our mappings?
The hospital promotes each mapping version, and Pensieve's checks decide whether it may: promotion waits until the dry run, golden messages and round trip have passed.
Read how operators carry out these duties on a live connection in running an integration, and where each duty first falls in the integration lifecycle.