Hospital information systems

Pensieve exchanges patients, visits, orders and results with the HIS, EHR and departmental systems a hospital keeps running beside it. This page lists what flows each way and which tool owns it, shows how a result finds its order, and sets out how the connection is configured.

What flows

An incumbent system reaches Pensieve through orophin, the bridge on the hospital network, which takes its HL7 v2 messages on the MLLP listener and accepts its FHIR pushes. Inbound, Gate acts on admissions and visits, Atlas on a patient's details and Forge on orders and results.

Outbound, an order leaves as an HL7 v2 message carried as a command over the bridge, or as a FHIR bundle over a direct connection. A patient or visit change made in Pensieve takes one route only: a FHIR transaction bundle sent over a direct connection to the FHIR server of the system of record.

Admissions and patient changes

Where the incumbent keeps registration or admissions, its ADT feed keeps Pensieve's following copy of each visit current. Each message becomes a typed fact for Gate, which opens, moves or closes the visit, and a change to the patient's own details also reaches Atlas.

The ADT pack, the base mapping a new connection starts from, reads the fields below. The connection's own rules add any further field the incumbent sends, as mapping fields describes. HL7 v2 shows how an update treats a field left out and a field sent empty.

The patient class carries a required binding to Pensieve's visit classes. A message whose class has no match is answered with a rejection and held, and once an operator maps the class, a replay carries the message through.

Orders and their answers

An order a clinician places in Forge leaves through the governed outbound path. Over HL7 v2 it is an ORM^O01 or OML^O21 with the new-order control code and the placer order number in ORC-2. The ordered test goes in OBR-4, written in the receiving system's code through the connection's terminology.

An accession is the reference Pensieve mints for every order it sends, and the fulfilling system returns it with the result. A receiving system that speaks FHIR takes the order as a ServiceRequest with its Specimen, in one transaction bundle. FHIR explains the conditional create, keyed on the accession, that keeps a resent bundle from creating the order twice.

The receiving system confirms the order with ORR^O02 or ORL^O22, returning the placer number together with the filler number it assigned, and Forge records the acknowledgement. A later order message whose order control reports a new status updates the same order, which Pensieve finds by its placer number.

How a result finds its order

A result comes back carrying the references its order is known by: the accession in OBR-3, the placer number in ORC-2 and the filler number in ORC-3. Pensieve attaches the result to the order those references name, so two open orders for the same patient each receive their own result.

The typed facts a result raises, and the keys each one carries, are listed in from message to record.

Departmental systems

A radiology information system sends its reports as ORU^R01 results against the imaging order, and its studies travel their own path, traced in imaging.

A pharmacy or stock system that exchanges files writes delimited rows to a folder the bridge watches. The platform maps every row by the connection's field rules, and file drops sets out how the folder is laid out and collected.

Configuring the connection

An operator whose role carries the Westron capability for connections defines each incumbent system the bridge reaches as a bridge-hosted connection. Each connection names its purpose of use, such as receiving admissions or sending orders.

A preset for common HIS families fills the connection's defaults, among them the HL7 v2 listener on port 2575. The ADT pack or the laboratory results and orders pack then supplies its base mapping.

A direct connection to an incumbent FHIR server the platform can reach authenticates with SMART Backend Services, signing its assertion with the hospital's own key. The key is kept in the platform's secret store, and the connection carries only a reference to it.

Both kinds go live only after a dry run on a sandbox site passes, the gate covered in proving an integration. For each feed the incumbent sends in, that dry run uses the incumbent's own sample messages.

Common confusions

Read how the incumbent's feeds shape each deployment in integration models, and how a laboratory result is mapped, verified and escalated in laboratories and analysers.