HL7 ESR messages carry a request from a controlling system to a piece of laboratory automation equipment for the equipment's current status — a poll asking, in effect, "what state are you in right now?" An ESR message is the question half of a status exchange: a controller (typically a laboratory automation manager or middleware) sends one ESR naming the equipment instance in EQU, and the instrument replies with an ESU carrying its current operational state. This page explains what an ESR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ESR request relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an ESR message represents
An ESR message — ESR stands for Automated Equipment Status Request — is a controller's request for the current status of a laboratory automation device. The message is intentionally minimal: it carries an MSH plus a single EQU segment that identifies which equipment instance the status is being requested for. There are no command parameters, no specimen context, and no timing — the message asks one question, about one device, and waits for a reply.
ESR is a solicited-status pattern: the controller does not wait for the equipment to volunteer an ESU on a state change, but actively polls it. The EQU segment pins the request to a specific equipment instance in EQU-1. The equipment-state fields in EQU (EQU-3 for state — EI in-use, IT idle, EM emergency-stop, DT down, HD hold, PA pause — EQU-4 local/remote control state, EQU-5 alert level) are the fields the responder will fill in when it returns the ESU; on the outbound ESR they typically carry the controller's last-known view, or are left blank. The sender is the controlling system; the receiver is the equipment or its instrument-side gateway.
When an ESR message is sent
An ESR message is sent whenever the controlling system needs the current state of a piece of automation equipment and cannot wait for the next unsolicited ESU. Typical triggers are operator-initiated status checks, controller startup and reconnection (when the controller wants to resync its view of every connected device), periodic health polls, and reconciliation after a communications outage. ESR is paired in practice with ESU (the status update that answers it) and lives alongside EAC (command), EAR (command response), and EAN (notification) in the Chapter 13 laboratory automation message set.
Trigger event
The ESR message type carries a single trigger event:
ESR^U02– Automated equipment status request.
Because ESR has one trigger event and one substantive segment, the receiver's handling turns on the equipment instance identifier in EQU — which device is being polled — rather than on the trigger code in MSH-9. The response is an ESU^U01.
Integration topology
The diagram shows the controlling laboratory automation manager issuing an ESR request through the integration engine to a connected instrument, which then replies with an ESU.
{{diagram: laboratory automation manager / middleware → ESR request → integration engine → instrument / equipment gateway → ESU response → integration engine → laboratory automation manager}}
Typical senders: laboratory automation manager, laboratory middleware, LIS automation module.
Typical receivers: the polled instrument, an instrument-side gateway, or a track-control system on the automation line.
Direction: the request leg of a request-response exchange — the ESR travels from the controller to the equipment, and the ESU returns the equipment's current state.
Segments in an ESR message
The ESR_U02 message is intentionally minimal. It carries MSH followed by a single EQU that names the equipment instance whose status is being requested. There are no repeating groups, no optional segments, and no command, specimen, or timing context. 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every ESR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (ESR^U02), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
EQU | Equipment Detail. Identifies the equipment instance the status is being requested for. EQU-1 carries the equipment instance identifier — the only field that must be populated on the outbound request. EQU-2 the event date/time, EQU-3 the equipment state (EI in-use, IT idle, EM emergency-stop, DT down, HD hold, PA pause), EQU-4 the local/remote control state, and EQU-5 the alert level typically reflect the controller's last-known view, or are left blank for the equipment to populate on the returning ESU. Required, and the heart of the message. |
[ ] = optional, { } = repeating
ESR has no repeating groups: one ESR polls one equipment instance. To poll several devices, send several ESRs. The canonical segment pages carry the full field-by-field detail.
Sample ESR message
Note. Constructed for illustration. Equipment identifiers and dates are fictional.
MSH|^~&|LAB_AUTO_MGR|MERCYGEN|ANALYZER01|MERCYGEN|202006150930||ESR^U02^ESR_U02|MSG00091|P|2.5.1
EQU|ANALYZER01^MERCYGEN^EI|202006150930|||
What this sample shows
The ESR^U02 in MSH-9 marks an automated equipment status request. EQU identifies the equipment instance ANALYZER01 at MERCYGEN and stamps the request at 202006150930. The state, control, and alert fields (EQU-3, EQU-4, EQU-5) are left blank — the controller is asking, not asserting — and the instrument will populate them in the returning ESU^U01.
Working with ESR messages
Treat ESR as a poll, not a heartbeat
ESR is a request-response poll, not a keepalive. Every ESR sent must be matched with an ESU within a reasonable window — if none arrives, the device is unreachable or hung, and the controller should escalate rather than assume the previous state still holds. Set a response timeout and treat a missing ESU as a status in its own right.
Populate only EQU-1 on the outbound request
EQU-1 is the field that scopes the request — it identifies the equipment instance being polled. The state, control, and alert fields are the equipment's to fill in on the response. Sending an outbound ESR with EQU-3 populated does not change the device's state; it is read by the receiver, at best, as the controller's last-known view, and at worst ignored.
Correlate the response on equipment instance, not message control id
Because the only meaningful field on an ESR is EQU-1, the responding ESU is correlated to the request on equipment instance identifier rather than on MSH-10. A controller polling many devices in parallel should key its open-request table on EQU-1.
Reach for ESR sparingly
Unsolicited ESU on state change is the primary status channel; ESR is the reconciliation channel. Polling every device on a short timer pushes load onto the line for little gain. Use ESR on startup, after a reconnect, after a missed window, or on operator demand — not as a substitute for the equipment's own change-driven ESU.
Vendor variance. The codes used in
EQU-3for equipment state are partly site- and vendor-defined. Some instruments publish a broad set (EI,IT,EM,DT,HD,PA) while others publish a constrained subset, and a handful add proprietary states. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A request for the current status of a piece of equipment corresponds, conceptually, to a FHIR Device read — fetching the current Device resource for the named equipment — or to a Task that requests that read, with a MessageHeader at the head of a Bundle when carried as a messaging exchange.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for ESR_U02, and laboratory automation equipment status sits largely outside FHIR's clinical resource scope — FHIR's strengths are clinical and administrative data rather than device-level state and polling. A FHIR representation produced from an ESR message is therefore composed manually, taking the equipment instance from EQU into a Device reference. In most production integrations the ESR stays on the v2 channel.
Common pitfalls
Pitfall. Treating ESR as fire-and-forget. An ESR with no matching
ESUis a failed poll, not a successful one. Sending the request and moving on leaves the controller with a stale view of the device.
Pitfall. Polling on a tight timer. ESR is for reconciliation, not for continuous monitoring; the primary status channel is unsolicited
ESU. High-frequency polling burns bandwidth on the automation line without improving the controller's view.
Pitfall. Correlating the response on
MSH-10. Because the substantive content of ESR is the equipment instance inEQU-1, the returningESUis keyed on equipment instance, not on message control id. A controller that keys onMSH-10alone may fail to match responses correctly when several polls are in flight.
How Vorro handles ESR messages
Vorro routes each ESR request from the controlling system to the target instrument, keeps an open-request table keyed on the equipment instance identifier in EQU, and correlates the returning ESU on EQU-1 rather than on MSH-10. Vorro enforces a response timeout and surfaces unanswered polls as a status in their own right, throttles polling so ESR is used for startup, reconnect, and reconciliation rather than as a continuous monitor, and, where a FHIR destination is configured, maps the request to a Device read — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- ESU — the automated equipment status update that answers an ESR request and also carries unsolicited state changes from the equipment.
- EAC — the automated equipment command that the controller issues to act on the equipment once its state is known.
- EAN — the automated equipment notification that the equipment raises when it needs the controller's attention.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for ESR_U02
- HL7 v2-to-FHIR IG — segment maps index — confirms no published ConceptMap for the EQU segment
- HL7 Messaging Standard Version 2.5.1 product brief
