HL7 EQU Segment: Equipment Detail

The EQU (Equipment Detail) segment transmits the operational snapshot of a single piece of automated laboratory equipment at a given moment in time. It is the anchor segment for lab automation status messages, identifying the equipment instance, the timestamp of the event, and the high-level state of the device. Downstream automation managers, middleware, and LIS interfaces rely on EQU to correlate equipment activity with subsequent log services (EQP) and interaction details (ISD).

EQU was introduced as part of the HL7 v2.4 laboratory automation chapter and remains structurally stable through v2.8.2. In v2.5.1 it contains five fields, only the first of which is required by the standard.

Purpose

EQU exists to give automation supervisors and LIS interfaces a normalized way to describe equipment status events. Whereas observation segments (OBX) describe what was measured, EQU describes the device that is doing — or attempting to do — the measuring. Each EQU instance ties a unique equipment identifier to a timestamp, a coded operational state, a control mode, and an optional alert level.

Typical drivers for sending EQU include:

A scheduled or on-demand equipment heartbeat from an analyzer to an automation manager.
A state transition such as moving from "Idle" to "Operating" or from "Operating" to "PM Required".
A response to an Equipment Status Request asking for the present condition of one or more devices.

Used in

EQU is the leading detail segment for the laboratory automation equipment status messages defined in HL7 chapter 13:

ESU — Equipment Status Update — unsolicited status broadcast from equipment to the automation manager.
ESR — Equipment Status Request — request/response pair where the response carries EQU with the latest known state.

Inside these messages EQU is paired with EQP (Equipment/Log Service) and ISD (Interaction Status Detail) segments to provide the full picture of an equipment event.

Field-by-field reference

The table below lists every EQU field as defined by the HAPI HL7 v2.5.1 model. Length values are omitted because HAPI does not surface them in the segment javadoc; refer to the base HL7 v2.5.1 standard for normative lengths. Required (R) flags reflect the standard's segment-level optionality.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
EQU-1	Equipment Instance Identifier	ei	—	R	—	—	Primary identifier of the equipment instance
EQU-2	Event Date/Time	ts	—	O	—	—	Timestamp the equipment event occurred
EQU-3	Equipment State	ce	—	O	—	HL70365	Current operational state of the device
EQU-4	Local/Remote Control State	ce	—	O	—	—	Whether device is under local or remote control
EQU-5	Alert Level	ce	—	O	—	—	Severity of any active equipment alert

Most-used fields

In production lab automation traffic the following fields carry most of the integration value:

EQU-1 Equipment Instance Identifier — the universal key used by automation managers and LIS interfaces to correlate every downstream segment with a specific device.
EQU-2 Event Date/Time — the basis for state-change timelines, SLA tracking, and reconciliation against EQP start/end timestamps.
EQU-3 Equipment State — drives dashboards, paging, and routing decisions; values originate from user-defined table HL70365 (Equipment State).
EQU-5 Alert Level — used to decide whether an EQU should escalate to operators or simply be logged.

Version differences (2.3 to 2.8.2)

v2.3: EQU did not exist; equipment status was conveyed through proprietary OBX or NTE constructs.
v2.4: EQU introduced as part of the new laboratory automation chapter. Initial structure already included the five fields present today.
v2.5 and v2.5.1: No structural change. v2.5.1 confirms EQU-1 as the only required field and links EQU-3 to user-defined table HL70365.
v2.6: Equipment automation triggers continue unchanged; EQU's structure remains stable.
v2.7 / v2.7.1: HL7 begins publishing normative truth tables for required/optional fields; EQU-1 stays required.
v2.8 / v2.8.2: EQU is preserved unchanged. Implementations sometimes layer additional Z-segments alongside EQU for vendor-specific telemetry.

Common mistakes

Sending EQU without an Equipment Instance Identifier. EQU-1 is required and is what every downstream system uses to key the message.
Putting a free-text equipment name into EQU-1.1 instead of a structured EI value. EI is a composite type and should carry an identifier plus assigning authority.
Mixing local timestamps and UTC across EQU-2 and EQP-3/EQP-4. Equipment messages frequently traverse time zones — keep them aligned and always include the offset.
Inventing custom Equipment State codes without coordinating with the automation manager. EQU-3 should draw from HL70365 or a clearly versioned local extension.
Using EQU-5 Alert Level as a free-text severity. It is a CE and benefits from a controlled vocabulary so dashboards can render it consistently.

Examples

Minimal EQU (only the required field populated):

EQU|ANALYZER-07^^VORRO-LAB^EI

Fully-populated EQU:

EQU|ANALYZER-07^^VORRO-LAB^EI|20260610081530-0500|OPERATING^Operating^HL70365|REMOTE^Remote Control^HL70365|NORMAL^Normal^HL70365

Annotated breakdown:

EQU                                Segment ID
|ANALYZER-07^^VORRO-LAB^EI         EQU-1 Equipment Instance Identifier (EI)
|20260610081530-0500               EQU-2 Event Date/Time (TS, with offset)
|OPERATING^Operating^HL70365       EQU-3 Equipment State (CE, table HL70365)
|REMOTE^Remote Control^HL70365     EQU-4 Local/Remote Control State (CE)
|NORMAL^Normal^HL70365             EQU-5 Alert Level (CE)

In-context excerpt from an ESU equipment status update:

MSH|^~&|AUTO-MGR|VORRO-LAB|LIS|VORRO-LAB|20260610081530-0500||ESU^U01^ESU_U01|MSG00041|P|2.5.1
EQU|ANALYZER-07^^VORRO-LAB^EI|20260610081530-0500|OPERATING^Operating^HL70365|REMOTE^Remote Control^HL70365|NORMAL^Normal^HL70365
EQP|STATUS^Status^HL70450|||20260610081530-0500|Routine heartbeat from ANALYZER-07
ISD|10042|HEMATOLOGY^Hematology Analyzer^HL70499|ACTIVE^Active^HL70511

In-context excerpt from an ESR equipment status request response:

MSH|^~&|AUTO-MGR|VORRO-LAB|LIS|VORRO-LAB|20260610090000-0500||ESR^U02^ESR_U02|MSG00042|P|2.5.1
EQU|CHEMISTRY-03^^VORRO-LAB^EI|20260610090000-0500|PM_REQUIRED^PM Required^HL70365|LOCAL^Local Control^HL70365|WARNING^Warning^HL70365
EQP|STATUS^Status^HL70450|||20260610090000-0500|Response to status request 88234
ISD|10043|CHEMISTRY^Chemistry Analyzer^HL70499|HELD^Held^HL70511

FHIR mapping

There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for EQU. Conceptually, EQU data maps to the FHIR Device and DeviceMetric resources:

EQU-1 Equipment Instance Identifier corresponds to Device.identifier.
EQU-2 Event Date/Time corresponds to DeviceMetric.measurementPeriod or an Observation effectiveDateTime when the EQU is wrapped in a status Observation.
EQU-3 Equipment State maps to Device.status (active/inactive/entered-in-error) and, more richly, to a custom Observation about the device.
EQU-4 Local/Remote Control State maps to a Device extension or a DeviceMetric operationalStatus Observation.
EQU-5 Alert Level maps cleanly to an Observation referencing the Device with a category of device-alert.

Integrators normalising lab automation traffic into FHIR generally emit one Device resource per equipment instance and one Observation per EQU event.

Engine considerations

Most integration engines (Mirth Connect, Rhapsody, InterSystems IRIS, Cloverleaf) ship out-of-the-box parsers that accept EQU as part of ESU_U01/ESR_U02 structures.
Engines that strictly validate against the v2.5.1 message profile reject EQU messages missing EQU-1; relaxed parsers may accept them but lose downstream correlation.
Watch out for engines that auto-strip empty trailing fields. Round-trip parsing is safe with EQU because all optional fields are CE/TS and survive normalization, but field counts in custom encoders should still be verified.
When mapping EQU to internal normalized device tables, treat EQU-1.2 (namespace) and EQU-1.3 (universal ID) as the composite primary key so multi-tenant lab networks do not collide.

How Vorro parses and produces EQU

The Vorro integration platform parses EQU using the HAPI HL7 v2.5.1 model under the hood and projects each field into a strongly-typed equipment event record. On the inbound path:

EQU-1 is normalized into a (namespace, id, universalId, universalIdType) tuple and indexed for fast lookup across ESU and ESR streams.
EQU-2 is converted to a timezone-aware timestamp and reconciled with the surrounding EQP-3/EQP-4 window to flag late-arriving heartbeats.
EQU-3, EQU-4 and EQU-5 are validated against the configured Equipment State, Control State and Alert Level vocabularies; unknown codes are tagged for operator review rather than dropped.

On the outbound path, Vorro produces EQU segments from device telemetry feeds, ensuring EQU-1 always carries an assigning-authority component and that EQU-2 is emitted with an explicit UTC offset. Vorro's pipeline writes the EQU alongside generated EQP and ISD segments so the resulting ESU/ESR message is structurally complete on the wire.

Sources

← Back to HL7 v2 Guide