HL7 EAR Messages: Automated Equipment Response

HL7 EAR messages return the response of a piece of laboratory automation equipment to a command issued by a controlling system — the message that says whether the equipment accepted the command, could not perform it, or hit an error, and reports the state of the equipment and any specimens or containers that came out of it. An EAR message is the answer half of a command-response exchange on the lab automation floor: a manager system sends an EAC command and the equipment replies with an EAR carrying the EQU equipment detail and one or more command-response groups built around ECD and ECR. This page explains what an EAR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an EAR response relates conceptually to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an EAR message represents

An EAR message — EAR stands for Automated Equipment Response — communicates the equipment's response to a command issued against it. The EQU segment identifies the equipment instance, stamps the event datetime, and reports the equipment's current state. Each command-response group then echoes one command, reports the specimens and containers it acted on, and ends with the outcome: the ECD segment echoes the original command so the requester can match the response to it, optional SPM and SAC segments name the specimens and containers the command touched, and the ECR segment closes the group with the response code in ECR-1 — AC accepted, CR cannot perform, or ER error — the response datetime in ECR-2, and any response parameters in ECR-3.

EAR is a command-response message issued by the equipment to the system that controls it. The sender is the laboratory automation equipment — an analyzer, a sample handler, an aliquotter, a storage device — and the receiver is the equipment manager, automation controller, or middleware that issued the originating command. Because the response replays the command and reports the outcome, the ECD and ECR pair is the authoritative record of how the equipment acted, while the surrounding EQU carries the equipment-level context. Any specimens identified or containers handled as a result of the command travel with the response in the optional SPM and SAC segments inside the command-response group.

When an EAR message is sent

An EAR message is sent in reply to an EAC automated equipment command — it is never unsolicited. When a manager or controller issues a command against a piece of automation equipment, the equipment processes the command, decides whether it can carry it out, and returns a single EAR message with the outcome of each command in ECR and the equipment's state in EQU.

Trigger event

The EAR message type carries a single trigger event:

• EAR^U08 – Automated equipment response.

Because EAR has one trigger event, the receiver's handling turns on the response code in ECR — AC, CR, or ER — and the equipment state in EQU, rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the equipment manager issuing an EAC command through the integration engine and the laboratory automation equipment replying with the matching EAR response.

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

Typical senders: laboratory automation equipment — analyzers, sample handlers, aliquotters, decappers, storage devices, track systems.

Typical receivers: the equipment manager, automation controller, or laboratory-automation middleware that issued the originating EAC command.

Direction: the response leg of a command-response exchange on the laboratory automation floor — the EAR travels back to whichever system sent the EAC command.

Segments in an EAR message

The EAR_U08 message opens with MSH, optionally carries software-identification in SFT, names the responding equipment in EQU, then carries one or more COMMAND_RESPONSE groups, and closes with an optional ROL. Each command-response group opens with the echoed command in ECD, then carries the specimens and containers the command touched in SPM and SAC, and reports the outcome in ECR. 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-response group from ECD through ECR repeats, so a single EAR message can answer many commands at once. The ECD and ECR segments are specific to Chapter 13 equipment automation and are not used outside that context. The canonical segment pages carry the full field-by-field detail.

Sample EAR message

Note. Constructed for illustration. Equipment identifiers, command parameters, dates, and container ids are fictional.

MSH|^~&|ANALYZER01|MERCYGEN_LAB|AUTOMGR|MERCYGEN|202006150930||EAR^U08^EAR_U08|MSG00046|P|2.5.1
EQU|ANALYZER01^MERCYGEN^EUI|202006150930
ECD|1|LD^Load^HL70368|N|RACK^R001^CARRIER
SPM|1|SPEC0001||SER^Serum^HL70487
SAC||TUBE0001|||||||||||RACK^R001^1
ECR|AC^Accepted^HL70387|202006150930|

What this sample shows

The EAR^U08 in MSH-9 marks an automated equipment response. EQU identifies the responding equipment as ANALYZER01 and stamps the event at 202006150930. The command-response group opens with ECD echoing the original command — a LD (Load) command against rack R001 — followed by SPM and SAC naming the specimen and container the command acted on (specimen SPEC0001 in tube TUBE0001, in position 1 of rack R001), and closes with ECR reporting AC (accepted) in ECR-1 with the response datetime in ECR-2. The order — ECD first, specimen and container in the middle, ECR last — is the v2.5.1 command-response group structure.

Working with EAR messages

Read ECR-1 first

The response code in ECR-1 is the gate. AC means the equipment accepted the command and acted on it; CR means the equipment cannot perform the command in its current state; ER means the command failed. Read ECR-1 before anything else in the command-response group — a CR or ER means the specimens and containers in the trailing segments were not acted on as the command intended.

Match the response to the command through ECD

An EAR is meaningless without the command it answers. The ECD segment echoes the original command parameters, and the manager uses that echo to match the response to its outstanding command. Pair the EAR's ECD with the EAC's ECD rather than relying on message order — multiple commands may be answered in one EAR, and the order in which they are reported is not guaranteed to match the order they were sent.

EQU is equipment context, not command status

The equipment state in EQU reports the device's overall condition at the time of the response, not the outcome of an individual command. A device can be in an OK state while still returning a CR for a specific command — the state reports the floor, the ECR-1 reports the action. Surface both.

Specimens and containers travel with the command

When the command acted on specimens or containers, the SPM and SAC segments report which ones — by specimen id, container id, and carrier position. Reconcile these against the command's intended targets rather than the manager's expectation, since the equipment may have skipped or substituted positions during execution.

Vendor variance. The SPM and SAC segments are optional and are included only when the command identified specimens or handled containers. Some equipment populates SPM and SAC for every load and unload, while others return only EQU/ECD/ECR and leave the specimen reconciliation to the manager. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

Laboratory automation equipment sits outside FHIR's clinical-resource scope. The response of a piece of equipment to a command is best represented conceptually as a Task in a completed, on-hold, or failed state — Task being the FHIR resource that represents the request to do something and the outcome of doing it.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for EAR_U08 and no segment maps for the Chapter 13 equipment automation segments EQU, ECD, and ECR. A FHIR Task produced from an EAR message is therefore composed manually, taking the command echo from ECD, the response code from ECR-1, the response datetime from ECR-2, and the equipment identifier from EQU to populate the Task's status, output, and owner.

Common pitfalls

Pitfall. Posting the trailing SPM and SAC segments without checking ECR-1. A CR or ER means the command did not act on those specimens and containers as intended; treating them as confirmed posts an imaginary action against the specimen record.

Pitfall. Matching the response to the command by message order. Multiple command-response groups can appear in one EAR and the equipment is not obliged to return them in the order they were sent. Match on the ECD echo, not the position.

Pitfall. Conflating equipment state with command outcome. An OK in EQU does not mean every command succeeded — read ECR-1 for each command-response group separately.

How Vorro handles EAR messages

Vorro correlates each EAR response to its originating EAC command through the echoed ECD, reads the response code in ECR to gate downstream processing, and routes the response — equipment state, command outcome, and any specimen and container detail — to every subscribed destination in the format that system expects. Vorro reads the equipment identifier and state from EQU, pairs each SPM and SAC with the command-response group it belongs to, and, where a FHIR destination is configured, maps the response to a Task resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message or its Chapter 13 segments.

Related messages

• EAC — the automated equipment command that an EAR is sent in response to.
• EAN — the automated equipment notification, used by equipment to push unsolicited alerts rather than answer a command.
• ESU — the automated equipment status update, used by equipment to report a change of state.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for EAR_U08
• HL7 v2-to-FHIR IG — segment maps index — confirms no segment maps for the Chapter 13 EQU, ECD, and ECR segments
• HL7 Messaging Standard Version 2.5.1 product brief