The EQL (Embedded Query Language) segment carries a string-encoded query expression embedded inside a legacy HL7 v2 query message. Where modern HL7 v2 queries use stored query identifiers and parameter lists, EQL transports a fragment of an SQL-like grammar in a single ST field so the receiver can execute an ad-hoc query against its repository. It is part of the family of legacy query header segments alongside QRD and the parameter list segment QID.
EQL is rarely emitted by modern systems but is still encountered when integrating with legacy laboratory, registry, and master-file systems that pre-date FHIR search and that never adopted the stored-query model.
Purpose
The purpose of EQL is to attach an embedded query expression to a query message so the responder can parse and execute it. EQL-1 (Query Tag) is the correlator the responder echoes back so requesters can match responses to requests. EQL-2 (Query/Response Format Code) tells the responder what response shape to produce — record-oriented, tabular, or display-oriented. EQL-3 (EQL Query Name) names the query so audit trails and access controls can identify it. EQL-4 (EQL Query Statement) carries the actual query text in the EQL grammar.
Because the query expression is opaque to the HL7 transport, EQL is fundamentally a string-passing mechanism: the value of EQL-4 is parsed and executed entirely by the responder, and senders rely on bilateral agreement about the grammar and the available column names. This is the principal reason EQL has been superseded in modern interfaces by stored queries identified by QID and, in FHIR, by parameterized search.
Used in
EQL is used in the legacy QRY query message family — specifically the variants that allow an embedded query expression in place of a stored query identifier. Within those messages EQL follows the MSH header and, when present, the QRD query definition segment, and supplies the embedded expression the responder is expected to execute. The QRY message communicates an ad-hoc query from a requester to a responder, and EQL carries the query payload.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v251/apidocs/ca/uhn/hl7v2/model/v251/segment/EQL.html) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| EQL-1 | Query Tag | st | — | R | — | — | Correlator echoed back by the responder |
| EQL-2 | Query/Response Format Code | id | — | O | — | — | Shape of the response payload |
| EQL-3 | EQL Query Name | ce | — | R | — | — | Named identifier for the embedded query |
| EQL-4 | EQL Query Statement | st | — | O | — | — | The embedded query text to execute |
Most-used fields
EQL-1 (Query Tag) and EQL-3 (EQL Query Name) are the two values every embedded query must carry — the first because it correlates the response to the request and the second because it names the query for audit, access control, and caching. EQL-4 (EQL Query Statement) is the actual payload and is almost always populated in practice; an EQL with only a name and no statement is meaningful only when the name itself resolves to a pre-registered statement on the responder. EQL-2 (Query/Response Format Code) is used by responders to decide whether to emit a record-oriented or tabular response, and is consulted by requesters expecting a specific shape.
Version differences (2.3 to 2.8.2)
EQL was introduced as part of the original v2 query infrastructure and carried its four-field structure through v2.5.1. HL7 deprecated the embedded query approach in favor of stored queries (identified by QID) in later versions, and EQL is marked as withdrawn in versions after v2.5.1. Most modern engines retain parsing support for inbound EQL from legacy partners but do not generate it on outbound interfaces. Transforms that bridge a v2.5.1 EQL interface to a v2.7+ partner typically convert the embedded statement into a stored query identifier plus a parameter list, or terminate the EQL at the engine boundary and re-issue the equivalent FHIR search.
Common mistakes
The most common mistake is omitting EQL-1 (Query Tag), which leaves the requester unable to correlate the response. Another is putting the human-readable query name into EQL-4 (the statement) instead of EQL-3 (the name), so the responder cannot recognize the query for audit or caching. Implementers also confuse EQL with QRD — QRD defines what is being queried at the message level, while EQL carries the embedded expression that implements the query. Finally, EQL-4 is a single ST field and the embedded statement must respect HL7 escape rules for the field, component, repetition, and escape separators; un-escaped pipes inside an EQL statement break the surrounding HL7 frame.
Examples
Minimal EQL (tag and name only):
EQL|Q44219||LAB_RESULTS_BY_MRN^Lab Results by MRN^L
Fully-populated EQL with an embedded statement:
EQL|Q44219|R|LAB_RESULTS_BY_MRN^Lab Results by MRN^L|SELECT OBR.OBR_3, OBX.OBX_3, OBX.OBX_5 FROM RESULTS WHERE PID.PID_3 = 'MRN778812' AND OBR.OBR_7 BETWEEN '20260601' AND '20260610'
Annotated breakdown:
EQL|Q44219|R|LAB_RESULTS_BY_MRN^Lab Results by MRN^L|SELECT OBR.OBR_3, OBX.OBX_3, OBX.OBX_5 FROM RESULTS WHERE PID.PID_3 = 'MRN778812' AND OBR.OBR_7 BETWEEN '20260601' AND '20260610'
| | | |
| | | +--> EQL-4 EQL Query Statement (ST) = embedded query text
| | +--------------------------------------> EQL-3 EQL Query Name (CE) = LAB_RESULTS_BY_MRN
| +-----------------------------------------> EQL-2 Query/Response Format Code (ID) = R (record-oriented)
+-------------------------------------------------> EQL-1 Query Tag (ST) = Q44219 (correlator)
In-context excerpt 1 — EQL inside a legacy QRY^Q01 query message, after MSH and QRD, carrying an embedded lab-results query for a single patient:
MSH|^~&|REPORTING|EAST|LIS|NORTHLAB|20260610120000||QRY^Q01^QRY_Q01|MSG70011|P|2.5.1
QRD|20260610120000|R|I|Q44219|||50^RD|MRN778812^^^EAST^MR|RES^Results^HL70048
EQL|Q44219|R|LAB_RESULTS_BY_MRN^Lab Results by MRN^L|SELECT OBR.OBR_3, OBX.OBX_3, OBX.OBX_5 FROM RESULTS WHERE PID.PID_3 = 'MRN778812' AND OBR.OBR_7 BETWEEN '20260601' AND '20260610'
In-context excerpt 2 — EQL inside a QRY^Q01 carrying an embedded master-file lookup over a registry, where the responder is expected to return a tabular result:
MSH|^~&|REGISTRY-UI|CENTRAL|MFREG|CENTRAL|20260610123000||QRY^Q01^QRY_Q01|MSG70022|P|2.5.1
QRD|20260610123000|T|I|Q44220|||200^RD|||MFR^Master File^HL70048
EQL|Q44220|T|PROVIDER_BY_NPI^Provider by NPI^L|SELECT STF.STF_3, STF.STF_2, STF.STF_4 FROM PROVIDERS WHERE STF.STF_2 = '9988776'
FHIR mapping
There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for EQL, so the target is "Not mapped at the segment level." Conceptually, EQL has no clinical FHIR resource equivalent: it is query infrastructure, and the modern equivalent is a FHIR search interaction whose criteria correspond to EQL-4 and whose response shape corresponds to EQL-2. EQL-1 (Query Tag) corresponds to the bundle identifier used to correlate an asynchronous FHIR search response with its request, and EQL-3 (Query Name) corresponds to a named search operation or a SearchParameter identifier. Any EQL transform must be defined locally and verified per interface because no normalized mapping is standardized.
Engine considerations
EQL has no repeating fields, so an engine treats each segment as a single embedded query. The required EQL-1 must be preserved verbatim across the request/response cycle so the requester can correlate; engines that rewrite control values must keep EQL-1 stable. The EQL-4 payload must be HL7-escaped before transmission: literal pipes, carets, ampersands, and tildes inside the query text must be replaced with their escape sequences so the surrounding HL7 frame is not corrupted. Because the EQL grammar is bilaterally agreed and not standardized at the HL7 level, engines bridging EQL to a stored-query or FHIR-search partner must maintain a translation table from EQL-3 query names and EQL-4 statement shapes to the target's parameterized form, and they must terminate any partner that cannot be mapped rather than passing opaque text through.
How Vorro parses and produces EQL
When Vorro parses EQL, it normalizes the segment into an embedded-query record correlated by EQL-1 (Query Tag) and identified by EQL-3 (EQL Query Name). EQL-2 is resolved into a response-shape enum the response builder can act on, and EQL-4 is captured as an HL7-unescaped string so the query parser receives the original text. If the EQL-3 name is on the registered translation list, Vorro can rewrite the embedded statement into a stored query plus parameters before dispatching downstream; otherwise the original EQL is preserved for an explicit EQL-capable partner.
When Vorro produces EQL, it emits exactly one segment per query, always populating EQL-1 with the correlator and EQL-3 with the registered query name. EQL-2 is written as the agreed ID value, and EQL-4 is HL7-escaped before serialization so the surrounding HL7 frame is preserved regardless of the embedded grammar. Outbound EQL is generated only when the destination partner explicitly requires it; modern destinations are served via stored queries identified by QID or via FHIR search.
Related pages
- QRD Segment: Original-Style Query Definition
- QID Segment: Query Identification
- QRY^Q01 Message: Query, Original Mode
- DSC Segment: Continuation Pointer
