Concept explainer

Networks and trust zones

Describes the network zones an integration crosses, from the hospital network to the platform and partner services, and the protection on each leg.

Pensieve's integrations cross the hospital network, the platform and the partner services on the internet, and each leg between them always opens from the same end and carries its own protection. This page maps those zones and legs, sets out how each leg is protected, and states what the hospital firewall has to allow.

The zones

A trust zone is a part of the network run under one party's controls: the hospital's, Pensieve's or a partner's. A leg is the path traffic takes from one zone into another.

The hospital network holds the hospital's systems and orophin, the bridge. The platform holds meaning, access decisions and the record, and the partner services sit on the internet beyond both.

Figure 1.Diagram showing each leg with its protection: hospital systems reaching the bridge over TLS where they support it, the bridge's mutually authenticated link to the platform on port 443, the imaging source and staff browsers on HTTPS, the platform calling partner services and providers with the hospital's credentials, and providers' signed callbacks returning to the platform.

Leg	From	To	Protection	Opened by
Hospital network leg	A hospital system or analyser	A bridge listener or watched folder on the hospital network	TLS where the sending system supports it; otherwise the controls of the hospital network segment	The sending system
Bridge link	The bridge	The platform	A WebSocket over TLS 1.2 or higher on 443, mutually authenticated, with the platform's certificate pinned	The bridge
Large file upload	The bridge	Platform storage	HTTPS on 443 to a signed address issued for that one file	The bridge, on the platform's request
Imaging path	The imaging source	The Pensieve imaging store	DICOMweb over HTTPS on 443, authenticated on its own path	The imaging source
Browser path	A staff browser	One Pensieve address	HTTPS on 443 with TLS 1.2 or higher, carrying a session Pensieve issues	The browser
Identity provider calls	The platform	The identity provider's token endpoint and the address of its signing keys	The client secret and PKCE verifier on each token request, with OpenID Connect only	The platform
Partner calls	The platform	Exchanges, payers, partner FHIR servers and providers	HTTPS with the hospital's own credential for each service	The platform
Provider callbacks	The payment gateway and messaging providers	The platform	Signed by the provider and verified before they are read	The provider

Which part of the platform handles the traffic on each path is traced in the integration architecture. Where the platform zone runs, and where its data sits, are described in where it runs and where data lives.

The hospital network

The bridge's listeners bind to the hospital network alone. Among them are HL7 v2 over MLLP on port 2575 and the analyser feed on port 2576 by default, and the bridge also watches folders there. The HL7 listener can be held to a list of permitted sending addresses.

A leg from a sending system to the bridge is TLS-wrapped where that system supports it. Where it does not, the leg depends on the controls of the hospital network segment it crosses.

What the platform checks before it relies on anything the bridge forwards is set out in the trust boundary.

The bridge link

The bridge opens one long-lived connection outward to the platform on port 443: a WebSocket over TLS 1.2 or higher, with authenticated-encryption cipher suites only. Both ends authenticate. The bridge checks the platform's certificate against the one it pins, and the platform checks the bridge's identity at every connection, as authentication between systems sets out.

Acknowledgements, orders and worklist entries bound for the hospital network all travel on that link, so the hospital opens no port to the internet for them. A large file goes to platform storage over HTTPS on the same port, at a signed address the platform issues for that one file. The bridge itself is described in the bridge.

The imaging and browser paths

The imaging source opens its own connection to the Pensieve imaging store on port 443 and stores each study over DICOMweb, so a study's pixels travel apart from the bridge link. Only the study reference, which ties the study to its order, crosses on that link.

Each staff browser opens HTTPS connections on port 443 to a single Pensieve address, with TLS 1.2 or higher, and works on a session Pensieve issues after sign-in.

Single sign-on runs through the browser, which carries the identity provider's answer to Pensieve: a signed assertion with SAML, or an authorisation code with OpenID Connect. With OpenID Connect the platform then redeems the code at the identity provider's token endpoint and reads its signing keys, so both addresses have to be reachable from the platform.

Partner services

The platform calls national exchanges, payers, partner FHIR servers and providers itself, with the hospital's own credentials read from the secret store at the moment of each call. Their callbacks, such as a payment notification or a delivery receipt, are addressed to the platform and verified before they are read.

What the firewall allows

Outbound, the hospital allows port 443 from the bridge host and the imaging source to the Pensieve addresses supplied at installation. Staff browsers need port 443 to the Pensieve address they use.

Inside the hospital, each sending system needs to reach the bridge host on its listener port. The bridge host in turn needs to reach each system it delivers orders or worklist entries to, and each file interface needs a folder the bridge can read and move files out of.

The hospital's edge opens outward

The bridge link, the large-file upload, the imaging path and the browser path are each opened from inside the hospital's edge, and partner callbacks land on the platform. The platform's calls to an identity provider used over OpenID Connect need an opening only where that identity provider sits inside the hospital.

The rules at the bridge host and the imaging source are listed with source, destination and port in network requirements.

Common confusions

Does the integration need a tunnel between the hospital and Pensieve?

Every leg that leaves the hospital is an outbound connection on port 443 that carries its own authentication and encryption. The integration runs over those legs, with no tunnel between the hospital and the platform.

Does the bridge host need a route to the exchanges and payers?

The bridge reaches the Pensieve addresses supplied at installation. Exchanges, payers and providers are called from the platform, so the bridge host needs no route to them.

Read the proof each caller presents on these legs in authentication between systems, and which methods ride each leg in connection methods.