HL7 EAC Messages: Automated Equipment Command

HL7 EAC messages carry commands from a controlling system to laboratory automation equipment — the instructions that tell an analyzer, track, or robot to start a test run, abort it, load a specimen, prime, or change state. An EAC message is the action half of an equipment exchange: a controller (typically a laboratory automation manager or middleware) sends one EAC to a connected instrument with the operational state in EQU and one or more commands in ECD, and the instrument acts on them. This page explains what an EAC message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an EAC command relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an EAC message represents

An EAC message — EAC stands for Automated Equipment Command — communicates a command, or a batch of commands, from a controlling system to a piece of laboratory automation equipment. The core of the message is the pairing of EQU, which identifies the equipment instance and reports its current operational state, with one or more ECD segments, each of which carries a remote-control command, whether a response is required, the requested completion time, and the command parameters. Each ECD represents one instruction — start, abort, load, prime, hold — directed at the equipment named in EQU.

EAC is an unsolicited action message: the controller issues it on its own initiative, typically in response to a workflow event or an operator action upstream. The EQU segment pins the command to a specific equipment instance (EQU-1) at a specific moment (EQU-2), and reports the equipment's operational state in EQU-3, its local/remote control state in EQU-4, and alert level in EQU-5 as coded values. The sender is the controlling system; the receiver is the equipment or its instrument-side gateway. Because the message commands a physical device, the equipment state in EQU-3 and the command code in ECD-2 are the fields that drive behaviour, while the surrounding optional segments carry timing, specimen, container, and notification-clearing context for the command.

When an EAC message is sent

An EAC message is sent whenever the controlling system needs the equipment to do something — start a run, abort it, load or unload a specimen, prime a reagent, change to a hold or pause state. It is event-driven and unsolicited: the controller does not wait to be polled. EAC is paired in practice with EAR (the response to an equipment command) and lives alongside EAN (notification) and ESU (status update) in the Chapter 13 laboratory automation message set.

Trigger event

The EAC message type carries a single trigger event:

• EAC^U07 – Automated equipment command.

Because EAC has one trigger event, the receiver's handling turns on the command code in ECD and the equipment state in EQU — what is being asked of the device, and the state it is in when asked — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the controlling laboratory automation manager issuing an EAC command through the integration engine to a connected instrument, which then replies with an EAR.

{{diagram: laboratory automation manager / middleware → EAC command → integration engine → instrument / equipment gateway → EAR response → integration engine → laboratory automation manager}}

Typical senders: laboratory automation manager, laboratory middleware, LIS automation module.

Typical receivers: the controlled instrument, an instrument-side gateway, or a track-control system on the automation line.

Direction: the command leg of a request-response exchange — the EAC travels from the controller to the equipment, and the EAR returns the equipment's acknowledgement.

Segments in an EAC message

The EAC_U07 message opens with MSH, optionally carries software-identification in SFT, names the equipment in EQU, and then carries one or more COMMAND groups; the message closes with an optional ROL. Each command group opens with ECD and may carry timing in TQ1, specimen and container context in SPM/SAC, and any notifications the command clears in CNS. 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 command group from ECD onward repeats, so a single EAC message can issue several commands to the same equipment in one exchange. The canonical segment pages carry the full field-by-field detail.

Sample EAC message

Note. Constructed for illustration. Equipment identifiers, specimen identifiers, command numbers, and dates are fictional.

MSH|^~&|LAB_AUTO_MGR|MERCYGEN|ANALYZER01|MERCYGEN|202006150930||EAC^U07^EAC_U07|MSG00081|P|2.5.1
EQU|ANALYZER01^MERCYGEN^EUI|202006150930
ECD|1|START^Start Run^HL70368|Y|202006150935|TESTGROUP=CHEM7
SPM|1|SPEC456789^MERCYGEN||SER^Serum^HL70487
SAC|||TUBE789^MERCYGEN|||||||1

What this sample shows

The EAC^U07 in MSH-9 marks an automated equipment command. EQU identifies the equipment instance ANALYZER01 at 202006150930; the optional state, control, and alert-level fields are left empty here since the controller is issuing a command, not reporting state. ECD carries reference command number 1, the remote control command START, response required Y in ECD-3, a requested completion time of 202006150935 in ECD-4, and the parameter TESTGROUP=CHEM7 in ECD-5. SPM names the specimen SPEC456789 as serum, and SAC identifies the container TUBE789 in position 1 — together telling the analyzer which specimen, in which container, the start applies to.

Working with EAC messages

Read the equipment state in EQU before acting on the command

EQU-3 reports the equipment state at the moment the command is issued — a coded value drawn from the equipment-state code system that names whether the device is in use, idle, paused, on hold, in emergency stop, down, or shutting down. A START issued against equipment in an emergency-stop or down state cannot be honoured, and the receiver should reject it rather than queue it. Read the state in EQU first and reconcile against the command in ECD-2 before dispatching.

Honour the response-required flag in ECD-3

ECD-3 indicates whether the controller expects an EAR response. When it is Y, the equipment must return an EAR for that reference command number (ECD-1); when it is N, the controller is firing the command and not waiting. Correlate every response on the reference command number rather than the message control id.

Match SPM and SAC to the command

When the command targets a specific specimen — a load, an abort, a start of a single run — the SPM and SAC segments scope the command. Do not act on a specimen-directed command without resolving the specimen and container identifiers; a START with no SPM is a global run start, while a START with SPM and SAC is a directed run for that specimen in that container.

Use CNS to clear superseded notifications

Where a command resolves an alert the equipment previously raised — for example, an operator-acknowledged hold that an ABORT now clears — the CNS segment carries the cleared notification identifiers so the equipment can retire them. Send CNS alongside the command rather than relying on the equipment to infer the clear.

Vendor variance. The codes used in EQU-3 for equipment state, EQU-5 for alert level, and ECD-2 for remote control command are partly site- and vendor-defined. Some instruments accept a broad command vocabulary (START, ABORT, LOAD, PRIME, HOLD, RESUME) while others publish a constrained set. Confirm a partner's field usage and command vocabulary against their interface specification rather than assuming the base standard.

FHIR equivalent

An automated equipment command corresponds, conceptually, to a FHIR Task that references the controlled equipment as a Device resource, 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 EAC_U07, and laboratory automation equipment control sits largely outside FHIR's clinical resource scope — FHIR's strengths are clinical and administrative data rather than device-level command and control. A FHIR representation produced from an EAC message is therefore composed manually, taking the equipment instance from EQU into a Device reference and the command code, parameters, and timing from ECD into the Task. In most production integrations the EAC stays on the v2 channel.

Common pitfalls

Pitfall. Dispatching an ECD command without checking EQU-3. A START issued against equipment in an emergency-stop or down state cannot be honoured; queuing it as though the equipment were idle leads to silent failures and lost specimens.

Pitfall. Ignoring ECD-3. When response-required is Y, the controller is waiting for an EAR keyed on the reference command number; treating every command as fire-and-forget breaks the request-response loop.

Pitfall. Acting on a specimen-directed command without resolving SPM and SAC. A LOAD or START carrying specimen and container context is directed at that specimen — running the command globally instead can start the wrong run on the wrong tube.

How Vorro handles EAC messages

Vorro routes each EAC command from the controlling system to the target instrument, reads the equipment state in EQU before dispatch, and rejects or holds commands issued against equipment in a state that cannot honour them. Vorro keys every command on the reference command number in ECD, honours the response-required flag in ECD-3 by correlating the inbound EAR, resolves SPM and SAC for specimen-directed commands, retires cleared alerts through CNS, and, where a FHIR destination is configured, maps the command to a Task referencing the controlled Device — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• EAR — the automated equipment response that returns the equipment's acknowledgement of an EAC command.
• EAN — the automated equipment notification that the equipment raises when it needs the controller's attention.
• ESU — the automated equipment status update that reports a change in equipment state independent of a command.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for EAC_U07
• HL7 v2-to-FHIR IG — segment maps index — confirms no published ConceptMap for the EQU or ECD segments
• HL7 Messaging Standard Version 2.5.1 product brief