Client Documentation
Trier
Integration
Outbound - EDIS Expects

Outbound - EDIS Expects Screen

When a patient registers with Trier a new record will be created in the EDIS Expects table by sending an ADT^A05 (an expect booking message). Trier will send this message with the following information:

Trier InfoTrier data keyEDIS Expects fieldHL7 V2
patient brief description of problemproblem.patientdiagnosis/problemOBX
triage nurse descriptionproblem.triagediagnosis/problemOBX
patients pain scorepaindiagnosis/problemOBX
how frail is patientfrailtydiagnosis/problemOBX
patient allergiespatient.allergies.descriptiondiagnosis/problemOBX
severitypatient.allergies.severitydiagnosis/problemOBX
surnamepatient.lastNamesurnamepatient name (PID.1)
first namepatient.firstNamegiven namepatient name (PID.2)
date of birthpatient.dateOfBirthDOBdatetime of birth (PID.7)
genderpatient.genderSexsex (PID.8)

Trier will receive a response to the A05 message that includes a unique identifier for the created record in the EDIS Expects table.

If any patient information is updated in Trier. An ADT^A08 message will be sent to update the record in the EDIS Expects table. This update message will include the unique id for the record that needs to be updated.

Data Requirements

The Trier data fields sent to the diagnosis/problem EDIS field are all wrapped into a single text field. Most of these data fields are optional, the only thing that is required is either the problem.patient or problem.triage field. If neither of these fields are populated then the message will not be sent to EDIS.

Surname, first name, dob, and gender are all required to send the message to EDIS.

As soon as an encounter in Trier has enough data to be sent to EDIS, the message will be sent.

Handling the Async Response

Sending the HL7 message to EDIS is essentially an async process.

Trier will

  1. Send and A05 message to EDIS, generating a message control ID.
  2. Store the message control ID in the encounter record.
  3. Some time later, EDIS will send a response HL7 message to Trier. (This message contains the same control ID from before)
  4. Trier will check that the result returned indicates the Expect record was successfully created.
  5. If the result is successful, Trier will:
  6. Find the encounter with the matching message control ID.
  7. Update the encounter with the EDIS Expect ID (Trier will insert this into the edisID field of the encounter). This ID was inserted by EDIS into the Visit Number field.

To avoid sending duplicate messages to EDIS, Trier will only send an A05 message to EDIS if the encounter does not have a control ID. Esentially, if the encounter has a control ID, then the message has already been sent to EDIS. This does introduce a limitation where an update to an encounter may fail to be sent to EDIS because the response from EDIS was not yet received.

If an encounter has a edisID message it is assumed that the encounter has been sent to EDIS. If any field that is sent to EDIS has been updated, Trier will send an A08 message to EDIS to update the encounter.

Trier will not send any messages to EDIS if the encounter is in the triaged state. EDIS will no longer receive updates once the patient has been triaged.

Limitations

The biggest limitation is that data sent to the Expects table in EDIS can only be updated while it is still in the Expects table. One the patient is moved to the triage step in EDIS, the data can no longer be updated. The problem is that EDIS does not emit a message when the patient is moved from the Expects table to the triage table. This means that Trier will not know when to stop sending updates to EDIS. The admit patient message is only received once clerking and linking happen in webPAS, this step can happen up to 30 minutes after the patient has been triaged.

The potential work around is to handle an 'already triaged' error when an A08 is sent to EDIS for a patient that has already been triaged. Trier can then update its own record to indicate the patient is triaged. Unfortuantely, this does meen that any update that was included in that A08 message will now be out of sync with what is on EDIS. It will only be in sync again once the patient is clerked/linked in webPAS.

Code

  1. sendHL7() converts an encounter to a HL7 elements object.
  2. mllp-adapter converts HL7 elements object into a HL7 message and sends it to HIH.

sendHL7

The encounters service has an integration hook called sendHL7() This hook is registered to both the encounter.create and encounter.update events. This hook will send an A05 or A08 message to EDIS depending on the state of the encounter. The code for sendHL7() is in the integration.ts file.

It will:

  • check the encounter is not in the triaged state
  • check if the encounter is ready to be sent to EDIS
  • check if the encounter has already exists in EDIS (by checking edisID) and if any data has changed since the last time it was sent to EDIS.
  • determine if an A05 or A08 message should be sent
  • generate a HL7 elements JSON object from the encounter data
  • call the mllp-adapter service
  • store the control ID for an A05 message if the message was sent successfully (positive result from mllp-adapter)

mllp-adapter

The mllp-adapter service converts a HL7 elements JSON object into a HL7 message and sends it to HIH by the MLLP protocol.

The code for this is in the mllp-adapter folder. It is a regular imminently service. The service has a custom send() method that:

  • converts the HL7 elements JSON object into a HL7 message
  • connect to the HIH server by the MLLP protocol
  • sends the HL7 message and awaits for an acknowledgement message
  • responds with 'success' or 'error' depending on the acknowledgement message