Glossary
Integration glossary
Defines the terms used across the integration documentation, from bridge, connection and receipt key to verb route, typed fact, sandbox site and kill switch.
Pensieve's integration pages share one working vocabulary, and this glossary defines each of its terms in a sentence or two. The terms describe three parts: orophin, the bridge on the hospital network; Westron, the console where connections are defined and watched; and the platform that receives, maps and sends the traffic between them.
Bridge and agent
The Integrations pages say bridge, while the console and the earlier interoperability pages say agent, as in registering an agent. Both words name the same installation.
The terms
| Term | Meaning |
|---|---|
| Acknowledgement | The reply a sender reads. The bridge confirms receipt once a message is durably queued, and the platform's verdict follows on the sender's held connection: an HL7 v2 acknowledgement in original mode or a FHIR OperationOutcome. |
| Boundary audit record | One append-only row per crossing that names its direction, its bridge or target, the access decision, the purpose of use and any consent reference, with a hash standing in for the payload. |
| Bridge | orophin, the software installed on a host on the hospital network, which frames messages and queues them encrypted. It carries traffic both ways over one outbound, mutually authenticated link on port 443. |
| Connection | The platform's record of one outside system: how it is reached, its wire format, its purpose of use, its mapping and any credential reference. A connection is bridge-hosted or direct, and belongs to one site. |
| Connection category | The kind of counterpart a connection reaches. Every bridge-hosted connection has the bridge category, and a direct one is ABDM, the National Health Claims Exchange, a TPA, an insurer or a custom REST service. The category decides which endpoint details the connection holds. |
| Connection class | Whether a connection is bridge-hosted, reaching a system on the hospital network over the bridge link, or direct, called by the platform itself. The class decides the route every exchange on the connection takes. |
| Direct connection | A connection to a service the platform calls itself, over HTTPS with the hospital's own credentials: the claims exchange, ABDM, an insurer, a TPA or a partner FHIR server. |
| Dry run | A sample message run through the production pipeline on a sandbox site. It shows the parse, the validation, the writes it would make, the route and the acknowledgement, and saves nothing. |
| Governed outbound path | The path every outbound exchange with a hospital system or partner takes: held on a durable queue for its target, sent with an idempotency key, each attempt bounded by a fixed time budget, and settled as a response event. Payments, sign-in and messaging use dedicated provider adapters. |
| Held message | A message set aside for an operator: on the bridge once its delivery attempts run out, or on the platform when it cannot be mapped or validated. It stays held until an operator resolves or replays it. |
| Idempotency key | The key every attempt of one outbound send carries, so its receiver can recognise a repeat. It is an HMAC-SHA256 over the canonically serialised payload together with the site, the bridge or connection, the target and its endpoint, and the trace identifier of the request. |
| Intake grant | The right of one bridge to deliver into the site it serves, checked inside every receipt transaction and withdrawn when the bridge is revoked. |
| Integration engine | The part of the platform that receives each inbound message, maps and routes it, and sends the outbound exchanges with hospital systems and partners. Translation, mapping and routing all run there, and the bridge applies none of them. |
| Integrity record | A record written in each inbound message's receipt transaction, holding the SHA-256 hash of the stored bytes with the site, bridge, sending system and message identifier, so what arrived can be proved later. |
| Kill switch | The Westron control that halts intake ahead of any write and ends live sessions within seconds once engaged. An engaged switch moves its connection to archived, and releasing it returns the connection to active. |
| Mapped record | The result of giving an inbound message meaning: its mapped values, verdict and issues, stamped with the mapping configuration, mapping pack and terminology versions that produced it. Tools read values from it under their own permissions. |
| Mapping configuration | A connection's versioned mapping rules for one direction, moving from draft to active to retired. Each rule applies one of eight transforms and carries no embedded code. |
| Mapping pack | A built-in base mapping for a common message source. A connection's mapping configuration starts from a pack and overrides it field by field. |
| Modality worklist | The list of scheduled imaging work a modality reads. A scheduled imaging order is sent to it so the modality picks up the right patient and order. |
| Parked message | A mapped message with no verb route to take it. It waits with its mapped record kept, and can be replayed once a route exists. |
| Purpose of use | The lawful basis a connection carries, copied onto the boundary audit record of each crossing it makes. Traffic on a connection with no purpose set is refused. |
| Receipt key | The identity of an inbound message: its site, its bridge, the sending system and the message's own identifier. A message arriving again within seven days settles to its first receipt. |
| Sandbox site | A site marked for testing, and the only kind of site that accepts a dry run. |
| Scoped write | A verb route outcome that writes mapped values into a record the connection may update, held to the bridge's allow-list of records and fields. |
| Site overlay | The layer of entries a site keeps over a shared central base. Where the two disagree, the site's entry is used. |
| System of record | The system whose copy of a given kind of data is authoritative, decided domain by domain when Pensieve runs beside another system. Copies held elsewhere follow it. |
| Terminology overlay | The site overlay for codes, written when a person resolves an unmapped code. A code with no match there or in the central base is handled by the rule set for its feed, such as queuing it for a person. |
| Trace identifier | The one identifier a crossing carries from the bridge frame through the boundary record, the event and the response, in W3C Trace Context form. |
| Typed fact | An event raised from a mapped message, such as the fact that a lab result is available. It points at the mapped record without carrying its clinical values, which the owning tool reads under its own permissions. |
| Unmapped-code queue | The queue of codes no map resolved, each kept with its original code and code system until a person maps it in Westron. |
| Verb route | A rule that sends a mapped message, by its verb, to one of three outcomes: a typed fact, a scoped write or a parked state. The verb is the HL7 v2 message type, trigger event and order control, or the FHIR resource type and status. |
| Westron | The console where the integration team registers bridges, defines and maps connections, runs dry runs, watches health, replays messages and uses the kill switch. Each panel needs its own capability. |
Where each term is explained
The bridge and the network it crosses are explained in the bridge and networks and trust zones, and connections with their classes and categories in anatomy of a connection. The governed outbound path and idempotency keys are covered in outbound exchanges, and the integration engine in the integration architecture.
Receipt keys, mapped records, verb routes, typed facts, scoped writes, parked messages and acknowledgements are followed in from message to record, and held messages in message failure and replay. Intake grants, purpose of use, boundary audit records, integrity records and trace identifiers belong to governance of integrated data.
Mapping configurations and packs are set out in mapping fields, overlays and the unmapped-code queue in terminology mapping, and dry runs and sandbox sites in proving an integration. The kill switch and the Westron panels an operator works are covered in running an integration, the modality worklist in imaging and the authoritative holder of each domain in system of record.
Common confusions
Is a receipt key the same as an idempotency key?
A receipt key identifies an inbound message, so a message sent again settles to its first receipt. An idempotency key rides an outbound send, so the receiver can recognise a retry of it.
What separates a parked message from a held one?
A parked message mapped cleanly and waits only for a verb route, and replaying it after the route is added carries it to its outcome. A held message failed along the way, and it waits for an operator to resolve the failure or replay it.
Is a boundary audit record part of the audit trail?
They are kept apart. The audit trail answers who read or changed a patient's record, and a boundary audit record answers what crossed the integration boundary, in which direction and under which purpose, without the content itself.
Read the access, identity and audit terms in security glossary, and the wider platform vocabulary in glossary.