HL7 EQP Segment: Equipment/Log Service

The EQP (Equipment/Log Service) segment describes a single service or log entry generated by a piece of laboratory automation equipment. While EQU identifies which device is reporting and what state it is in, EQP explains what the equipment was doing — the event type, when the service started and ended, optional log file location, and a free-form transaction payload.

In HL7 v2.5.1 EQP has five fields and is repeatable inside ESU and ESR message structures, allowing a single equipment status message to carry multiple log services in chronological order.

Purpose

EQP turns equipment activity into structured log entries that automation managers, LIS interfaces, and middleware can store and query. Each EQP instance captures:

The kind of service performed (heartbeat, error, maintenance, command/response, notification).
The service window via Start Date/Time and End Date/Time.
An optional file name that points at a longer log artifact persisted elsewhere.
A free-text transaction blob that holds vendor-specific detail.

Together, multiple EQP segments in a single message form a mini service journal for the device described by the preceding EQU.

Used in

EQP is used inside the laboratory automation equipment status messages defined in HL7 chapter 13:

ESU — Equipment Status Update — one or more EQP segments report what services the device performed since the last update.
ESR — Equipment Status Request — responses include EQP segments enumerating the log services that satisfy the request window.

EQP usually appears between EQU (the equipment identifier and state) and ISD (interaction-level detail).

Field-by-field reference

Field metadata below is derived from the HAPI HL7 v2.5.1 segment javadoc. Length values are not surfaced by the javadoc and are shown as "—"; refer to the base HL7 v2.5.1 standard for normative lengths. Required (R) reflects the segment-level optionality recognised by HL7.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
EQP-1	Event Type	ce	—	R	—	HL70450	Coded type of the equipment service event
EQP-2	File Name	st	—	O	—	—	Optional pointer to an external log file
EQP-3	Start Date/Time	ts	—	O	—	—	Start of the service window being reported
EQP-4	End Date/Time	ts	—	O	—	—	End of the service window being reported
EQP-5	Transaction Data	ft	—	O	—	—	Formatted-text payload of transaction detail

Most-used fields

EQP-1 Event Type — the most important field; downstream routing logic almost always switches on this code. Values come from HL70450.
EQP-3 Start Date/Time — anchors the event to a timeline and is used to correlate with EQU-2.
EQP-4 End Date/Time — together with EQP-3 forms the duration of a maintenance window, calibration, or error condition.
EQP-5 Transaction Data — carries the actual log lines or transaction payload. Keep it bounded — engines often truncate or reject very large FT values.

Version differences (2.3 to 2.8.2)

v2.3: EQP did not exist.
v2.4: EQP introduced alongside EQU as part of the laboratory automation chapter. Structure already included Event Type, File Name, Start/End Date/Time and Transaction Data.
v2.5 / v2.5.1: No structural change. Event Type is locked to user-defined table HL70450.
v2.6: EQP unchanged; some implementations begin attaching multiple EQPs per EQU.
v2.7 / v2.7.1: HL7 publishes normative truth tables. EQP-1 remains the only required field at the segment level.
v2.8 / v2.8.2: EQP unchanged. Modern implementations increasingly favour referencing an external log artifact via EQP-2 instead of inlining large transaction blobs in EQP-5.

Common mistakes

Omitting EQP-1 Event Type. Without it, downstream systems cannot classify the log entry and most engines will reject the message.
Sending End Date/Time earlier than Start Date/Time. Some engines will accept this silently and produce negative-duration analytics.
Embedding multi-megabyte payloads in EQP-5. The FT data type technically allows it, but framing and TCP segmentation in MLLP can choke. Reference an external file via EQP-2 for anything large.
Treating EQP as singular. The segment is repeatable inside ESU/ESR; collapsing several services into one EQP loses information.
Using local-time-only TS values. EQP-3 and EQP-4 should always carry a UTC offset so the eventual log timeline is unambiguous.

Examples

Minimal EQP (only Event Type populated):

EQP|HEARTBEAT^Heartbeat^HL70450

Fully-populated EQP:

EQP|MAINT_START^Maintenance Start^HL70450|/var/log/analyzer07/maint-20260610.log|20260610081530-0500|20260610082030-0500|Routine PM.brOperator: tech42.brResult: PASS

Annotated breakdown:

EQP                                            Segment ID
|MAINT_START^Maintenance Start^HL70450         EQP-1 Event Type (CE, table HL70450)
|/var/log/analyzer07/maint-20260610.log        EQP-2 File Name (ST, external log pointer)
|20260610081530-0500                           EQP-3 Start Date/Time (TS, with offset)
|20260610082030-0500                           EQP-4 End Date/Time (TS, with offset)
|Routine PM.brOperator: tech42.brResult: PASS   EQP-5 Transaction Data (FT)

In-context excerpt from an ESU equipment status update:

MSH|^~&|AUTO-MGR|VORRO-LAB|LIS|VORRO-LAB|20260610082030-0500||ESU^U01^ESU_U01|MSG00051|P|2.5.1
EQU|ANALYZER-07^^VORRO-LAB^EI|20260610082030-0500|OPERATING^Operating^HL70365|REMOTE^Remote Control^HL70365|NORMAL^Normal^HL70365
EQP|MAINT_START^Maintenance Start^HL70450|/var/log/analyzer07/maint-20260610.log|20260610081530-0500|20260610082030-0500|Routine PM completed
EQP|HEARTBEAT^Heartbeat^HL70450||20260610082030-0500||Resuming routine heartbeat
ISD|10051|HEMATOLOGY^Hematology Analyzer^HL70499|ACTIVE^Active^HL70511

In-context excerpt from an ESR equipment status response:

MSH|^~&|AUTO-MGR|VORRO-LAB|LIS|VORRO-LAB|20260610090000-0500||ESR^U02^ESR_U02|MSG00052|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|ERROR^Error^HL70450||20260610085500-0500|20260610085930-0500|Reagent pack low: channel 3
EQP|NOTIF^Notification^HL70450||20260610085945-0500||Operator paged
ISD|10052|CHEMISTRY^Chemistry Analyzer^HL70499|HELD^Held^HL70511

FHIR mapping

There is no segment-level ConceptMap for EQP in the v2-to-FHIR IG. Practical mapping options:

EQP-1 Event Type maps to the code of an Observation or AuditEvent representing the device service.
EQP-3 / EQP-4 Start and End Date/Time map to Observation effectivePeriod or AuditEvent period.
EQP-2 File Name maps to a DocumentReference resource, or to an Observation derivedFrom/focus reference pointing at the external log artifact.
EQP-5 Transaction Data is typically projected to Observation valueString, AuditEvent.outcomeDesc, or a Provenance additionalInfo element.

Most integrators model EQP as either an Observation (when the service is sensor- or measurement-flavoured) or an AuditEvent (when the service is operational, like maintenance or operator command).

Engine considerations

Engines like Mirth Connect, Rhapsody and InterSystems IRIS treat EQP as repeating inside ESU_U01/ESR_U02. Verify that any custom transformer iterates EQP rather than reading only the first instance.
EQP-5 (FT) commonly contains escape sequences such as .br. Make sure your engine's escape configuration matches the producer so newlines render correctly.
Some lightweight parsers truncate fields beyond 64 KB. If EQP-5 exceeds that, prefer EQP-2 with an external file pointer.
When normalising EQP into a relational store, key on (EQU-1, EQP-1, EQP-3) to avoid double-inserting when the same heartbeat is rebroadcast.

How Vorro parses and produces EQP

Vorro parses EQP using the HAPI HL7 v2.5.1 model and stores each instance as an equipment service record linked to its parent EQU. On the inbound path:

EQP-1 is validated against the configured HL70450 vocabulary; unknown event types are tagged for operator review rather than dropped.
EQP-3 and EQP-4 are converted to timezone-aware timestamps. If EQP-4 precedes EQP-3, the record is flagged with a time_inversion quality bit instead of being silently accepted.
EQP-5 is normalized: HL7 escape sequences are decoded, and the result is stored as both raw and normalized text so audits remain faithful.
EQP-2 is resolved against the platform's connected storage so log artifacts can be retrieved by downstream consumers.

On the outbound path, Vorro builds EQP segments from internal service records, batching multiple services into a single ESU when they share the same EQU. Large transaction payloads are automatically promoted from inline EQP-5 to an external file referenced by EQP-2, keeping the wire-format message lean.

Sources

← Back to HL7 v2 Guide