Concept explainer
The trust boundary
Explains where Pensieve trusts data from another system and where it validates it, and how orophin marks the origin of each message.
Pensieve draws one firm line between the systems a hospital already runs and the record it keeps, and this page explains where the platform trusts data from another system, where it validates that data instead, and how orophin marks the origin of each message that crosses. On the hospital side of the line sits the bridge, which frames a message and forwards it. On the Pensieve side sits the parsing, the validation and the access decision that turn a forwarded message into a written fact.
Where the line sits
A trust boundary is the point at which the platform stops treating data as something it produced and starts treating it as something it has to check. The bridge runs on a machine on the hospital network, outside the platform's control, so the platform treats everything the bridge forwards as untrusted until it has read and validated it for itself.
The division of labour follows from that constraint. The bridge frames and forwards; Pensieve parses, validates and decides. Meaning is assembled only on the trusted side of the line, where the terminology, the record shape and the access rules live.
What the bridge does
The bridge reads only the envelope of a message, its start, its end and its size, and forwards the content as it stands. It holds none of the clinical vocabulary, and it reaches the record only by asking the platform, which takes the access decision and writes the entry. Patient data passes through it, and a message waits in the bridge's local queue, encrypted on the hospital's own machine, until the platform confirms the write and the queue entry is cleared. What the bridge never does is interpret that content.
This keeps a machine on the hospital network from acting on a record on its own. An attacker who took the bridge would reach the messages still queued there, and beyond them would gain only the narrow scope that one installation already holds, because meaning and authority stay on the trusted side.
Marking the origin
Every message the bridge forwards carries the marks that let the platform place it. The boundary reads those marks before it reads the content, so a message is attributed to a known connection from the moment it arrives.
The configured connection the message arrived on.
The kind of system that produced it, such as a laboratory or a registration feed.
The message's own identifier in the system that sent it.
The moment the boundary took delivery.
The platform reads these marks together as a receipt key. A message that arrives a second time, after a dropped acknowledgement, is recognised as the same message and re-acknowledged with its first receipt, so a replay settles to the one entry the platform already holds.
Receipt, then validation
The boundary handles a message in two stages, and the order between them is the load-bearing part. The raw message is stored durably first, so the record of what was received holds even when the content later proves incomplete.
| Stage | What happens | Outcome |
|---|---|---|
| Structural receipt | The boundary confirms the message reads as the format it declares and stores the raw message durably. | A framed message is held, even where its clinical content later proves incomplete. |
| Semantic validation | Pensieve translates the codes to the hospital's own vocabulary, maps the message to the record shape and validates it. | A message that fails validation is held and marked, and its sender is told the verdict. |
Because the raw message is the durable record of what arrived, a validation failure marks the message rather than discarding it, and the boundary turns away only bytes that read as no known format at all.
One decision, one record
Every crossing takes one access decision at the boundary. A message from a connection an administrator has switched off is refused before any write, so control of a connection is control of what it may do.
Beside each crossing the platform writes one durable record of the event, holding the origin marks and the verdict without the clinical content, so the audit trail can later answer what came in, from where, and whether it was applied. Read what that record holds in the audit trail.
The acknowledgement path
A sender that holds its connection open awaiting a reply reads an application acknowledgement that reports whether its message was accepted. Pensieve builds that acknowledgement on the trusted side and hands the bytes back to the bridge, which emits them unchanged on the held connection.
The platform builds the reply
The acknowledgement bytes are assembled on the trusted side and carried out unchanged. The bridge emits what the platform built, so the verdict a sending system reads always reflects the platform's own decision.
Common confusions
Does a stored message mean an applied message?
A framed message is stored durably at receipt, which makes it safe and replayable. Whether it applied to the record is the separate validation verdict, and the acknowledgement carries that verdict back to the sender.
Where are a message's codes translated?
Translation runs on the trusted side, after receipt. The bridge forwards the sender's codes as they stand, and Pensieve maps them to the hospital's own vocabulary during validation.
What settles a duplicate?
The origin marks form a receipt key. A message that arrives twice is matched to its first receipt and re-acknowledged with it, so delivery stays exact across a dropped acknowledgement.
Read how each request enters and leaves the platform through one door in and one door out.