Concept explainer
The integration architecture
Traces every path data takes into and out of Pensieve, through the bridge, the integration engine, the governed outbound path and the provider adapters.
Pensieve carries integration traffic on a fixed set of paths, each with a defined entry point and a record of what crossed. This page traces every path, names the component that does each part of the work, and shows where each path ends.
The components
The integration engine is the part of the platform that receives, maps, routes and sends integration traffic. It works with orophin, the bridge on the hospital network, and with the components in the table below. The connections they carry are set up and watched in Westron.
| Component | Where it runs | What it does |
|---|---|---|
| The bridge | A host on the hospital network | Listens to hospital systems, queues each message encrypted, and carries traffic both ways on one outbound link |
| The integration engine | The platform | Receives each inbound message, gives it meaning, routes it and builds the verdict for its sender |
| The governed outbound path | The platform, as the integration engine's sending side | Queues each exchange with a hospital system or partner, sends it with an idempotency key and records the response |
| The provider adapters | The platform | Reach the payment gateway, the identity provider and the messaging providers, and verify their signed callbacks |
| The event log | The platform | Carries each committed change to the tools that subscribe to it and to the outbound path |
| The tools | The platform | Act on typed facts under their own permissions and request outbound exchanges |
| Westron | The platform, used in the browser | Configures and watches every bridge, connection, mapping and route |
The inbound path
A hospital system sends to a bridge listener on the hospital network. HL7 v2 over MLLP and analyser feeds over ASTM arrive on ports 2575 and 2576 by default, alongside FHIR pushes and delimited files in watched folders. The bridge, described in the bridge, seals each message into its encrypted queue, confirms receipt to the sender and forwards the message on its link.
The integration engine receives each message in one transaction, then translates its codes, applies the connection's mapping and validates the result. The message's verb routes it to a typed fact for the owning tool, a scoped write or a parked state. Each step is followed in from message to record.
The outbound path
A tool records an outbound request in the same transaction as its change, and the event log, described in events, hands it to the governed outbound path. The path queues each request durably for its target and sends it with an idempotency key that every retry repeats.
The outcome returns to the tool as a response event, beside an outbound boundary record. A target on the hospital network is reached as a command on the bridge link. Retries, the time budget and what a failed send looks like are set out in outbound exchanges.
Direct partner paths
The national exchanges, insurers, TPAs and partner FHIR servers are direct targets of the outbound path, each configured as a direct connection in Westron. Vault sends eligibility checks, pre-authorisations and claims to the National Health Claims Exchange as FHIR R4 bundles, signed and encrypted with the hospital's own keys. ABDM record sharing runs under the hospital's registration and the patient's consent, with each payload encrypted end to end.
A partner FHIR server receives transaction bundles once Pensieve has read its declared capability, and that connection authenticates with SMART Backend Services. An insurer or TPA outside the exchange is a direct connection too, and the platform calls its endpoint with the credential the hospital holds for it.
Provider adapters
Payments, staff sign-in and messaging reach their providers through dedicated adapters, outside the governed outbound path. The payment gateway runs on the hospital's own merchant account, and staff sign in through the hospital's identity provider over SAML 2.0 or OpenID Connect. Raven sends through the messaging providers configured for the hospital.
Each adapter calls its provider from the platform and reads its credentials from the secret store. It verifies the provider's signed callbacks, such as a payment notification, a sign-in response or a delivery receipt, before acting on them, and keeps its own record of each exchange. Every method, with its protocol and direction, is listed in connection methods.
Imaging and the browser
A study travels from the imaging source to the Pensieve imaging store over DICOMweb on port 443, on an authenticated connection apart from the bridge link. The bridge carries only the study reference and the worklist entry that lets a modality pick up a scheduled order with the right patient.
Staff reach Pensieve in the browser over HTTPS on port 443, at one Pensieve address. Every read and write they make meets the same entry checks as any other request, set out in one door in and one door out.
Control over every path
Westron is where bridges and connections are configured and watched: registrations, credentials, mappings, terminology, routes, dry runs, health, message inspection, replay and the kill switch. Cirith Manager decides each crossing, checking inside the receipt transaction that the bridge still holds its grant to deliver into its site.
Who may use each Westron panel, and who may register, enrol or revoke a bridge, is set out in governance of integrated data. The network legs each path crosses, and the protection on each, are described in networks and trust zones.
Where each path ends
The table sets the paths side by side: what each carries, which way it runs and where it ends.
| Path | Carries | Direction | Where it terminates |
|---|---|---|---|
| Inbound from the hospital network | HL7 v2 messages, FHIR pushes, analyser results and delimited files | In, with the verdict returned to an HL7 v2 or FHIR sender that holds its connection | The integration engine, then a typed fact for the owning tool, a scoped write or a parked state |
| Outbound to hospital systems | Orders and worklist entries | Out, with a response event back to the tool | A system on the hospital network, reached by a command on the bridge's link |
| Direct partner exchanges | Claims, eligibility checks, ABDM sharing, and FHIR order, patient and encounter transactions with a server the platform can reach | Out, with a response event back to the tool | The partner's service, called from the platform |
| Provider adapters | Payments, staff sign-in, and messages to patients and staff | Out, with signed callbacks in | The payment gateway, the identity provider or a messaging provider |
| Imaging | DICOM studies | Into the imaging store, then read back from it | The Pensieve imaging store |
| Browser | Staff sessions | Both ways | One Pensieve address |
Common confusions
Does the integration engine run on the bridge?
The integration engine runs on the platform. The bridge frames, queues and carries messages, and holds none of the vocabulary, mappings or routes the engine applies.
Do partner services connect into the hospital network?
Partner services are called from the platform, and their callbacks return to the platform, which verifies them. The bridge's listeners take traffic from the hospital network alone, and the platform reaches the bridge over the link the bridge opened.
Do payments, sign-in and messaging use the governed outbound path?
They use dedicated provider adapters called from the platform. The governed outbound path carries exchanges with hospital systems and partners.
Read how one inbound message becomes a record in from message to record, and which ports and firewall rules the paths need in network requirements.