Concept explainer
The bridge
Explains the orophin bridge, the binary that carries messages between Pensieve and other hospital systems on a site network.
The bridge is orophin, a single binary a hospital installs on its own network to carry messages between Pensieve and the systems already running at a site. It is the one path by which a hospital's laboratory analysers, information systems and archives reach the platform, and by which the platform reaches them.
What the bridge is
An agent is a single installation of the bridge, running as one program on one machine at one site. One agent serves one site, holds one identity, and opens one outbound connection to Pensieve that many system connections travel through.
The bridge sits where the hospital's systems sit, on a server or workstation on the same network as the laboratory system, the information system and the imaging archive. It speaks the protocols those machines speak, HL7 v2 messages, lab analyser feeds, CSV file drops and DICOM imaging references, and forwards what it receives.
One outbound path
Every connection the bridge carries rides a single outbound channel to the platform, opened by the bridge and held open. The platform opens no connection inward, and the bridge exposes no public port, so its listeners bind to the site network alone.
The channel is mutually authenticated, so each end proves its identity to the other before a message crosses.
Framing at the edge, meaning at the centre
The bridge reads only the envelope of a message, its start, its end and its size, and forwards the content as it stands. Pensieve parses that content, maps its fields, resolves its codes, authorises the write and records it.
This division is deliberate. The bridge runs on a machine the hospital controls rather than the platform, so it holds no clinical vocabulary, maps no code, takes no access decision and makes no entry in the record. It does hold the content it carries. A message waits in the bridge's local queue, encrypted on disk on that hospital machine, until Pensieve confirms the write and the bridge clears it. Meaning is assembled on the trusted side.
| The bridge | The platform | |
|---|---|---|
| Carries messages across the site network | Present | Absent |
| Reads message shape and forwards raw content | Present | Absent |
| Holds message content on disk | Present | Present |
| Parses, maps and interprets a message | Absent | Present |
| Holds the terminology vocabulary | Absent | Present |
| Decides access and writes the record | Absent | Present |
A message survives the network
Loss-free by design
The bridge holds a durable local store. A message accepted from a system is written there before the sending machine is acknowledged, so a message survives a network outage and a restart and arrives once the link returns. The platform recognises a repeat and records each message once.
While the link is down the bridge queues messages in that store, and on reconnect it dials out again and replays the queue. Because the platform settles duplicates, a replay after a lost acknowledgement is safe, and delivery stays exact.
The trust boundary
The bridge runs on a machine outside the platform's control, so the platform treats it as untrusted and grants it only its own narrow scope. The agent proves itself once, at the handshake, by a certificate whose name matches its identity together with a short-lived token, and the platform re-checks that identity against its registry at every handshake.
Because the bridge holds only its own scope and keeps no vocabulary and no record, an attacker who took the machine would reach the messages still waiting in its queue and nothing further. Beyond those, they would learn only what that one agent may already read, and could write only what the platform independently authorises.
The agent's own certificate and token, held in the machine keystore.
A durable queue of messages waiting to cross, encrypted on disk and cleared once Pensieve confirms the write.
The reads and writes the platform has granted this one agent.
Two kinds of connection
The bridge carries connections to systems the hospital owns, its laboratory, information, pharmacy, radiology and billing systems. Systems the hospital uses without owning, a national exchange or an insurer, the platform reaches directly with the hospital's own credentials, aside from the bridge.
Both kinds are defined and held in the console. Read how a connection is set up in connections and credentials.
Imaging keeps its own route
Imaging studies follow a separate path. The picture data travels straight to the platform's imaging store over its own authenticated route, and the bridge carries only the study reference, so a large scan stays clear of the message channel and reaches the image study viewer tied to the right patient and order.
Common questions
Does the bridge store patient data?
Yes, for as long as a message is waiting. Each message sits in the bridge's durable local queue, encrypted on disk on the hospital's own machine, and is cleared once Pensieve confirms the write. The bridge does not interpret what it holds. It carries no clinical vocabulary, maps no code and makes no entry in the record.
How many bridges does a hospital run?
One agent per site. A hospital group runs one agent at each site, each with its own identity and its own outbound channel.
What happens when the network drops?
The bridge queues messages in its local store and dials out again on a jittered schedule. On reconnect it replays the queue, and the platform records each message once.
Install the bridge on a site and confirm it reaches its systems in installing the bridge.