Reference table

Readiness checklist

Lists what a hospital prepares before an integration begins, from the bridge host and network to interface samples, test systems, credentials and named owners.

Every connection Pensieve makes, whether through orophin, the bridge, or from the platform, rests on things only the hospital can provide. This page lists them by area, with the reason each area matters.

The hospital's technology lead closes each item before the stage that depends on it, in the order set out in the integration lifecycle.

Hosting and network

The bridge carries every connection to a system on the hospital network, so its host and the openings around it come first. Each site has its own bridge, and a hospital with several sites prepares a host at each. The host also keeps the bridge's encrypted queue of messages awaiting the platform's confirmation, and the hospital protects it as it would any server that holds patient data.

The exact firewall rules are in network requirements, and placing the bridge on its host is covered in installing the bridge.

A server on the hospital network for the bridge, run by the hospital's IT team, on Windows x64, Linux x64 or Linux arm64.

Outbound port 443 from the bridge host to the Pensieve addresses supplied at installation.

Outbound port 443 from the imaging source to the Pensieve imaging store, where imaging is connected.

Reach from each sending system to the bridge's listeners, by default port 2575 for HL7 v2 and port 2576 for analysers.

Reach from the bridge host to each system it sends orders or worklist entries to.

A folder for each file interface, on a share the bridge host can read and write.

A protected network segment for each sending system that cannot wrap its leg to the bridge in TLS.

Systems and samples

Each connection's mapping is written from its system's interface specification and proven against that system's samples. The proof exercises the message types it has samples for, so a complete set of samples is the item in this group to start on earliest.

The system of record named for each shared domain sets which way each feed runs, as system of record explains.

The interface specification of each system that will connect: the message types, fields and codes it sends and accepts.

Sample messages from each system, covering every message type it sends.

A test instance of each incumbent system, for drawing samples with made-up patients.

The system of record for each shared domain, such as registration, admissions, orders and billing.

The billing mode for each site.

The order in which systems will be connected, starting with the feeds the first domain needs.

Samples use made-up patients

A sample becomes a dry-run input and can join the golden messages kept with its connection. Each one therefore comes from a test instance, or has every patient detail replaced with made-up values before it is shared.

Credentials and registrations

Every national, payer and provider service runs under the hospital's own registration or account, so each of these connections is set up only after the hospital holds its credentials. Each credential is kept by reference, as authentication between systems sets out. Staff sign-in through the hospital's identity provider is configured as single sign-on describes.

Switching on the claims or payment rail also takes a second person's approval, which is why that approver appears under People below.

The hospital's ABDM registration, with its participant code and client credentials.

The Health Facility Registry identifier of each site taking part in ABDM.

The hospital's participation in the National Health Claims Exchange: its participant code, signing key and decryption key.

The hospital's credential for each insurer or TPA reached over a direct connection, outside the claims exchange.

For each partner FHIR server, the hospital's client registration there and the key its assertions are signed with.

A merchant account with the payment gateway, with its key identifier, its key secret and the secret that signs its notifications.

Accounts with the messaging providers for each channel in use, with SMS templates registered under DLT and WhatsApp templates approved.

The identity provider's details for each organisation, for SAML 2.0 or OpenID Connect.

People

Each duty below, apart from support, is carried by a capability or permission granted through a role in Cirith Manager, so its holder is named before the stage that needs it. Bringing a bridge into service takes two of the three bridge holders, and the third can withdraw it. What each holder does is set out in roles and responsibilities.

Three named people for the bridge: one to register it, one to enrol its certificate and one to revoke it.

An owner for each connection's mapping, who reads its dry runs and promotes proven versions.

A terminology owner for each site, who resolves queued codes into the site overlay.

The operators who watch connection health, inspect messages and replay them.

The holders of the kill switch.

The second person who approves switching on the claims and payment rails.

The second person who approves a change to a site's billing mode.

The hospital's authorised support contacts for integration tickets.

Data

Codes matched in advance sit in the site overlay from the first live message, which keeps the unmapped-code queue short. Any other local code falls to its feed's handling for unmatched codes, which on a clinical feed queues it for a person by default.

The hospital model and reference datasets load from files, each checked row by row before it is written, as bulk loads describes.

Each system's local codes, such as in-house test codes, with the standard code each should resolve to.

The handling for each feed when a code finds no match: pass it through, use a fixed code, try another map or queue it for a person.

The hospital model in the Nexus Manager templates: units, locations, services, asset types, assets, role definitions and staff invitations.

Rate cards as CSV datasets for Westron, in manifests of up to 50,000 rows.

Common confusions

Must every item be ready before work starts?

Each connection needs only its own items. The bridge host, the network openings and the three bridge holders come before any connection to the hospital network, and a rail's credentials only when that rail is set up.

Can samples come from the live system?

They can, once every patient detail in them is replaced. A test instance is the simpler source where one exists, because its messages already have the right shapes and carry no real patients.

What does Pensieve supply at installation?

Pensieve supplies the addresses that the bridge host and the imaging source reach, and the signed builds of the bridge with their published checksums.

Read how the samples prove each connection before it carries live data in proving an integration.