HL7 EQL EQL
HL7 field reference EQL fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
EQL carries an embedded query-language style request in older query workflows.
Query segments define what the sender is asking for, how the receiver should format the answer, and how a multi-message response is continued or limited.
A query is an interface contract. The tag, parameters, row definitions, sort/filter rules, and continuation pointers must match exactly or the receiver may return technically valid data that is not what the requester expected.
The v2.5.1 structures show EQL in EQQ_Q04 - EQQ Q04. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
EQL-1 is the requester's handle for this query. Echoing it back correctly is what lets the requester match a response to the question it asked.
EQL-2 tells the receiver what response style is expected. Use the values from HL7 table 0106 exactly as the profile defines them; changing the format changes how the rest of the response should be interpreted.
EQL-3 names the query, event, stored procedure, virtual table, or profile being invoked. This is the semantic switch for the query, so both sides need to agree on the allowed names and their parameter rules.
EQL-4 tells the receiver the state of this query workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.