Concept explainer
Outbound exchanges
Explains how Pensieve sends orders, patient updates and claims to other systems through one durable outbound path, and what happens when a send fails.
Pensieve sends orders, patient updates, claims and consented record shares to the systems around a hospital, and this page follows one send from request to outcome. Exchanges with hospital systems and partners leave through the governed outbound path, where each send waits on its target's own queue and carries one key across every retry.
What leaves the platform
Outbound work starts in a tool. Forge sends orders to the laboratory or department that fulfils them, and Vault files claims and sends charges to a finance system that keeps the books. A change to a patient or a visit goes to the system of record for that domain, and each target is a connection defined in Westron.
| Exchange | Standard | Route |
|---|---|---|
| An order to a laboratory or department | An HL7 v2 order message, or a FHIR R4 transaction bundle of ServiceRequest with Specimen | Through the bridge to a system on the hospital network, or direct to a partner FHIR server |
| A scheduled imaging order | A DICOM modality worklist entry | Through the bridge to the modalities that read the worklist |
| A patient and encounter update | A FHIR R4 transaction bundle of Patient with Encounter | Direct to the FHIR server of the system of record |
| An eligibility check, pre-authorisation or claim | FHIR R4 bundles, signed with JWS and encrypted with JWE under the hospital's own keys | Direct to the National Health Claims Exchange |
| A record shared through ABDM | FHIR R4 bundles built to the NRCeS profiles, each payload encrypted for its recipient | Direct to ABDM, once the patient consents through the ABDM consent manager |
| Invoices and charges | FHIR R4 Invoice, ChargeItem and ChargeItemDefinition | To an external finance system, through a billing connector in Westron |
A TPA or insurer outside the exchange is reached as a direct connection holding the hospital's credentials. When an outside laboratory also runs Pensieve, an order reaches its systems through that laboratory's own bridge, and the results return to the matching order.
Provider links keep their own adapters
Payments, staff sign-in and patient messaging have dedicated adapters of their own, called from the platform outside the governed outbound path, as the integration architecture describes.
The path, step by step
Every send takes the same steps, along the single exit path described in one door in and one door out.
- 1
The tool records the request
The tool writes the send request inside the transaction that commits the change behind it, so an order and its request commit together. The request is an event on the event log, delivered to the outbound path after the commit.
- 2
The request joins its target's queue
The request is stored on a durable queue kept for its target, with a fixed ceiling on the sends in flight, so a slow partner delays only its own queue. The entry takes its identity from the request's key, so an event delivered twice is queued once.
- 3
A worker sends it
A worker claims the entry under a lease and sends it by the route its connection sets. If the worker stops part-way, the lease lapses and another worker takes the entry up.
- 4
A transient failure is tried again
A timeout or an unreachable target leaves the entry on its target's queue to be tried again. Each attempt runs inside a fixed time budget of seconds and repeats the first attempt's key.
- 5
The outcome settles
The path writes the outbound boundary record and emits a response event carrying the target's reply or the error, which the event log delivers to the requesting tool.
The idempotency key
An idempotency key is the value a send carries so that its receiver can tell a retry from a new request. Pensieve computes it as an HMAC-SHA256 over the payload, serialised canonically under RFC 8785. The hash also covers the site, the bridge or connection, the target, its endpoint and the request's trace identifier.
The key is fixed when the request is recorded, so all attempts at one send share it, while a separate request, under its own trace, gets a different one. Canonical serialisation gives the same content the same bytes, and including the site in the hash keeps two sites that send identical content on separate keys.
For a partner FHIR server, Pensieve adds a second guard, creating an order conditionally on its accession, as FHIR sets out.
Bridge-hosted and direct targets
A bridge-hosted target is a system on the hospital network, such as a laboratory information system. The platform sends the request as a command down the bridge link.
The bridge delivers it in that system's own protocol and returns the result, so outbound work opens no port to the internet. The command names its connection by an opaque handle, which keeps the hospital's network addresses off the link.
A direct target is a service the platform calls itself, such as the claims exchange, ABDM, a partner FHIR server or an insurer endpoint. Each call presents a credential the hospital owns, fetched from the secret store for that call alone, as authentication between systems sets out.
When a send fails
While its target is out of reach, a send waits on that target's durable queue, up to the queue's size cap and time limit. One that still cannot be delivered within those limits settles with an error, shown by the requesting tool against the order or claim and by Westron against the connection.
An outage at the hospital's own site holds outbound pushes in the same way, as what happens when the link drops describes.
The record of each send
Every send writes one outbound boundary record, free of clinical content, holding its direction, target, payload hash, purpose of use and trace identifier. An ABDM share's record also names the consent it relied on.
The record takes its identity from the send, so a second write of the same outcome finds the first record and leaves it as written. These records sit with the other integration records in governance of integrated data.
How a hospital system hears of a change
A hospital system learns of a change through its connection, as one of the outbound exchanges in the table above: an order in HL7 v2 or FHIR, or a patient and encounter change as a FHIR transaction to the system of record's FHIR server. By design, the event log serves only the platform's tools and the outbound path, and offers no outbound webhooks or outside subscriptions.
Common confusions
Does a failed send keep retrying until it succeeds?
Retries stop at the limits of its target's queue, a size cap and a time limit, and each attempt has a fixed budget of seconds. A send undelivered at those limits settles with an error that the requesting tool and Westron both show.
Can a hospital system subscribe to Pensieve's events?
It receives changes as outbound exchanges on its own connection: orders in HL7 v2 or FHIR, and patient and encounter changes only through its FHIR server.
Does a retry create a second order at the partner?
Every attempt repeats the first attempt's key, so a receiver that keeps the keys it has seen settles a repeat to its first answer. For a partner FHIR server, Pensieve also sends the order as a conditional create on its accession, so a repeated send finds the order already there.
Read how the outbound path sits beside the inbound paths in the integration architecture, and what each direction guarantees in delivery guarantees.