Procedure
The integration lifecycle
Walks through an integration from scoping to live operation, naming the decision, the tool and the permission at each stage, with links to each task.
Every integration with Pensieve enters service through the same stages, from the first decision about the hospital's estate to a connection carrying live data. This page sets out what each stage settles, where it is done and whose permission it takes, with a link to the task behind it.
The stages
- 1
Decide the model and the systems of record
The hospital chooses how Pensieve takes its place in the estate: beside an incumbent, as the whole platform, or moving across in phases, the shapes compared in integration models. For each shared domain, such as registration, admissions, orders and billing, it names the system of record, which fixes the direction of each feed.
The decision belongs to the hospital's technology lead and the owner of each domain. Each site's billing mode follows from it and is held on the site in Nexus Manager, under the checks and approval that tax and finance systems describes.
- 2
Prepare what the connections depend on
The hospital readies the bridge host and its firewall openings, sample messages for each system, and its credentials and registrations, as readiness checklist lists item by item. It also names the people who will hold each permission. Each receives a role in Cirith Manager at this stage, because every later stage checks a capability one of them holds.
- 3
Install, register and enrol the bridge
The hospital's IT team places the signed build of orophin, the bridge, on a server on the hospital network and checks it against its published checksum. In Westron, the holder of the registration permission ties the bridge to one site, and Pensieve shows the new bridge token once.
Next, a second operator enrols the bridge's certificate request under the enrolment permission. The request comes from a key pair the bridge creates for itself on that server, and authentication between systems traces what the certificate proves.
- 4
Connect the bridge
On the host, the IT team gives the bridge the token from registration and points each listener at its port, by default 2575 for HL7 v2 and 2576 for analysers. The team then names the folders to watch and starts the bridge. With its certificate enrolled, the bridge dials out on port 443 and proves its new identity, as installing the bridge walks through.
- 5
Define each connection
An operator holding the connection write capability defines one connection per system in Westron. The connection records the class, category, wire format, endpoint, purpose of use and any credential reference.
A preset for the system's family can fill the defaults, and connections and credentials takes the operator through the wizard. The connection test then confirms reach: a direct connection's counterpart answers, and a bridge-hosted connection's bridge shows a live session.
- 6
Map fields and codes
Under the mapping write capability, each direction starts from a mapping pack and takes the connection's own rules on top, as mapping fields describes. Each message type the system sends is given a verb route, the rule that sends it to a typed fact, a scoped write or a parked state. Each outcome is followed in from message to record.
Under the terminology write capability, local codes are matched to the standard vocabularies, and each feed gets its handling for an unmatched code, as terminology mapping sets out. Mapping rules saved at this stage stay a draft until the connection is proven.
- 7
Prove the connection
Under the simulation capability, the system's sample messages run through a dry run on a sandbox site, using the dry run simulator. The connection's golden messages and round trip run against the same draft, and a failure returns the work to mapping. Each check is explained in proving an integration.
- 8
Activate
A holder of the mapping write capability promotes the proven draft to active, and a holder of the connection write capability then activates the connection. For the claims exchange and payment rails, activation also waits on a second person, whose approval is recorded in Vault.
- 9
Run it
Under the monitoring capability, operators watch health, inspect messages and replay what was held, and queued codes are resolved under the terminology write capability. The holder of the kill switch can stop a connection's intake. Each task is covered in running an integration, and the health board in monitoring a connection.
Changes after go-live
A change to a live connection's mapping enters the stages again at mapping. The active version keeps carrying traffic while the new draft is written and proven, and promotion swaps the two in one step.
A further system at the same site joins the stages at defining its connection, on the bridge already in service. A connection that leaves service goes through a clean disconnect, described in anatomy of a connection.
Common confusions
Can connections go live one at a time?
Each connection is proven and activated on its own. A bridge carries the connections already active while others on it are still being mapped, and each message is read by the active version of the connection it arrived on.
What does the IT team do on the bridge host?
It places and checks the signed build, lets the bridge create its key pair, gives it its token, sets the listeners and watched folders, and starts it. Registration, enrolment, connections, mapping and proof all happen in Westron, in the browser.
Read what the hospital prepares for each stage in readiness checklist, and who holds each permission named above in roles and responsibilities.