HL7 ESU Messages: Automated Equipment Status Update

HL7 ESU messages report the operating status of laboratory automation equipment — the record that a piece of equipment is currently in use, idle, paused, on hold, in emergency stop, shutting down, or down, together with the local/remote control state and the alert level at the time the status was captured. An ESU message is sent from automated laboratory equipment to a controlling system, either on a periodic heartbeat or in response to a state change. This page explains what an ESU message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ESU status update relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an ESU message represents

An ESU message — ESU stands for Automated Equipment Status Update — communicates the current operating state of a piece of laboratory automation equipment. The core of the message is the EQU segment, which carries the equipment instance identifier, the event date and time, the equipment state, the local/remote control state, and the alert level. The EQU is deliberately a snapshot — it records the state of the equipment at one instant, not a log of state transitions.

The sender is the laboratory automation equipment (or its controller), and the receivers are the systems that need to know how the equipment is running — most often the laboratory automation manager, the LIS, and any monitoring or scheduling component. ESU sits in the operational layer of HL7 Chapter 13 Laboratory Automation: where an order-driven message tells the equipment what to do, the ESU message reports how the equipment itself is doing. Because state and alert level drive routing, throttling, and operator alerting, the EQU — not the surrounding envelope — is the authoritative record of equipment status.

When an ESU message is sent

An ESU message is sent on a periodic heartbeat or when the equipment changes state. A single instrument can produce a stream of ESU messages over a shift — periodic snapshots interleaved with event-driven updates when the equipment moves between states such as idle, pause, hold, or down — and each message carries the time the state was observed in EQU, so the operating history can be reconstructed from the messages themselves.

Trigger event

The ESU message type carries a single trigger event:

• ESU^U01 – Automated equipment status update.

Because ESU has one trigger event, the receiver's handling turns on the contents of EQU — the equipment state, control state, and alert level — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the automation equipment emitting a status update through the integration engine to the systems that record and act on it.

{{diagram: lab automation equipment → ESU message → integration engine → automation manager / LIS / monitoring}}

Typical senders: laboratory automation equipment, analyser controllers, track and sorter systems.

Typical receivers: laboratory automation manager, LIS, monitoring or alerting platform, and scheduling component.

Direction: unidirectional notification from the equipment to the systems that record, monitor, and react to its operating state.

Segments in an ESU message

The ESU_U01 message is short and flat: it consists of the MSH header, an optional repeating software segment SFT, the required EQU equipment detail segment, an optional repeating group of ISD interaction status detail segments, and an optional ROL at the end. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The ISD group repeats once per tracked interaction, so a single ESU message can report the state of the equipment as a whole together with the disposition of each interaction it is currently handling. The canonical segment pages carry the full field-by-field detail.

Sample ESU message

Note. Constructed for illustration. Equipment identifiers, dates, and disposition codes are fictional.

MSH|^~&|TRACK01|MERCYLAB|AUTOMGR|MERCYLAB|202006150900||ESU^U01^ESU_U01|MSG00012|P|2.5.1
EQU|TRACK01^Mercy Lab Track 1^L|202006150900
ISD|1|OK^Operating normally^L|N
ISD|2|WN^Sample misread^L|W

What this sample shows

The ESU^U01 in MSH-9 marks an automated equipment status update. EQU carries the equipment instance TRACK01 (EQU-1) and the event time 202006150900 (EQU-2); the equipment-state, control-state, and alert-level fields (EQU-3 through EQU-5) take coded values from the equipment-state and alert-level code systems and are populated by the instrument according to its own table mappings. Two ISD segments follow: interaction 1 is operating normally, and interaction 2 reports a sample misread with a warning status. The receiver therefore knows the track is operating, but that one of its interactions is degraded.

Working with ESU messages

Read the state from EQU, not the envelope

The equipment state and alert level live in EQU, not in the message envelope. EQU records the state at the event time in EQU-2 and is a snapshot, not a transition log, so consecutive ESU messages with the same EQU-3 value are valid heartbeats and not duplicates. Reconcile against EQU rather than inferring the state from the arrival of the message itself.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the equipment instance identifier in EQU-1 together with the event date and time in EQU-2 as the natural business key for a status snapshot. Equipment feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed status from raising a second alert or rewriting the current state from a stale snapshot.

Heartbeats and the status sequence

EQU-2 carries the event date and time of the snapshot, so a stream of ESU messages for one piece of equipment should advance monotonically in time. Sequence by EQU-2 rather than arrival order, so an out-of-order heartbeat does not appear to revert the equipment to an earlier state.

Alert level and control state

EQU-5 records the alert level at the time of the snapshot and EQU-4 records whether the equipment is under local or remote control. Surface both on the operations dashboard rather than discarding them — an in-use instrument under local control with a raised alert level differs, operationally, from the same instrument under remote control with a normal alert level.

Vendor variance. The coded values in EQU-3 (equipment state), EQU-4 (local/remote control state), and EQU-5 (alert level) are largely vendor- and site-defined — instrument manufacturers publish their own code sets for the operating states their devices report. The ISD group is optional and is included only when the equipment tracks per-interaction status, so some instruments repeat the full interaction set on every ESU while others send only the equipment snapshot in EQU. Confirm a partner's code tables and field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

An equipment status update corresponds to the FHIR DeviceMetric resource, with the equipment itself as a Device resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for ESU_U01 and no ConceptMap for the EQU equipment detail segment — equipment status updates sit outside the clinical scope the Implementation Guide currently covers. A FHIR DeviceMetric produced from an ESU message is therefore mapped manually, taking the equipment instance, event time, state, control state, and alert level from EQU and referencing the Device derived from the equipment identifier.

Common pitfalls

Pitfall. Treating a repeated equipment state as a duplicate. Consecutive ESU messages with the same EQU-3 are valid heartbeats — deduplicating on state instead of on MSH-10 silently drops the operating-status stream.

Pitfall. Ignoring the local/remote control state in EQU-4. A remote command sent to an instrument under local control will not take effect; reading EQU-3 without EQU-4 misses that the equipment is operator-controlled.

Pitfall. Assuming a fixed date-time precision. Some senders stamp EQU-2 as YYYYMMDDHHMM and others as a full timestamp with an offset; do not assume a timezone — normalize on ingest.

How Vorro handles ESU messages

Vorro ingests the ESU feed over MLLP or another transport, deduplicates on MSH-10, and routes each status update to every subscribed destination in the format that system expects — the automation manager, the LIS, and any monitoring or alerting platform. Vorro reads the equipment state, control state, and alert level from EQU, surfaces per-interaction dispositions from each ISD, and, where a FHIR destination is configured, maps the snapshot to a DeviceMetric resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• ESR — the automated equipment status request that prompts a status update.
• EAN — the automated equipment notification that reports an equipment event or alarm.
• EAC — the automated equipment command sent to direct an instrument's behaviour.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for ESU_U01
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for EQU
• HL7 Messaging Standard Version 2.5.1 product brief