HL7 QID Segment: Query Identification

The QID (Query Identification) segment uniquely identifies a query within a response message. It carries just two fields: the Query Tag that ties the response back to the original request, and the Message Query Name that states which named query was executed. QID is deliberately small. Its single job is to label a response so the receiving application knows exactly which query the response answers, even when many queries are in flight at once.

Purpose

The purpose of QID is identification, not result reporting. Where QAK reports the status and hit counts of a query, QID simply names the query so the response can be correlated and routed. The Query Tag is the primary correlation key, generated by the requester and echoed back unchanged; the Message Query Name records the identity of the named query (the same value the requester placed in QPD-1). Together these two fields make a response self-describing without depending on message-header ordering or transport metadata.

Used in

QID is part of the modern query group built on the Query by Parameter framework. It is used in:

RSP (response) query messages, where QID leads the response and identifies the query being answered. See QBP and the query framework.

In a normal exchange a client sends a QBP (query by parameter) message whose request is defined by QPD and shaped by RCP. The responder returns an RSP message in which QID and QAK lead the response: QID restates the query identity and Query Tag, and QAK reports the outcome before the matching data follows.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (QID.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
QID-1	Query Tag	st	—	R	—	—	Echoes the request Query Tag for correlation
QID-2	Message Query Name	ce	—	R	—	—	Identifies the named query that was run

Most-used fields

QID-1 Query Tag: the primary correlation key. It is the value the requester generated and placed in QPD-2; receivers match it to pair a response with its request. In QID this field is required.
QID-2 Message Query Name: identifies the named query, mirroring QPD-1 from the request. It lets the receiver confirm the response answers the query it expected.

Version differences (2.3 to 2.8.2)

QID belongs to the Query by Parameter family that became the standard query mechanism in 2.4 and 2.5. In 2.3 there was no QID segment; query identity was handled through the older QRD/QRF query group and message-level acknowledgment. From 2.4 onward QID is stable, with the same two fields, the Query Tag and the Message Query Name, in the same order across 2.4 through 2.8.2. The Message Query Name is documented with the CE data type in 2.5.1; later versions lean toward the CWE coded element convention, but the field position and intent are unchanged. Because QID is so compact, it has seen essentially no structural drift; the practical version concern is which named-query identifiers your trading partner supports, not the segment layout.

Common mistakes

Omitting the Query Tag. QID-1 is required and is the correlation key; leaving it blank makes responses impossible to pair with requests.
Generating a fresh tag on the response side. The Query Tag must echo the requester's value exactly, not be regenerated by the responder.
Confusing QID with QAK. QID identifies the query; it does not report status or hit counts. Putting status values in QID is a common error.
Mismatching the Message Query Name. QID-2 should equal the QPD-1 value from the request; a mismatch signals the responder answered a different query.
Expecting QID to repeat. Neither field repeats in v2.5.1.

Examples

Minimal valid segment (both fields are required):

QID|Q4815162342|Z44^Demographics Query^HL70471

Fully-populated segment (QID has only two fields, so this is also the full form):

QID|Q4815162342|Z44^Demographics Query^HL70471

Annotated breakdown:

QID|Q4815162342|Z44^Demographics Query^HL70471
    |          |
    |          +-> QID-2 Message Query Name = Z44 (named query, mirrors QPD-1)
    +------------> QID-1 Query Tag = Q4815162342 (echoes request, correlation key)

In-context excerpt 1, a patient demographics response (RSP^K11) where QID and QAK lead the response:

MSH|^~&|MPI|CENTRAL|EHR|CLINIC_A|20260610101500||RSP^K11^RSP_K11|MSG00099|P|2.5.1
MSA|AA|MSG00042
QID|Q4815162342|Z44^Demographics Query^HL70471
QAK|Q4815162342|OK|Z44^Demographics Query^HL70471|1|1|0
PID|1||MR12345^^^CLINIC_A^MR||DOE^JANE^Q||19850214|F

In-context excerpt 2, a response to a different named query showing how QID labels each answer:

MSH|^~&|MPI|CENTRAL|EHR|CLINIC_A|20260610101600||RSP^K11^RSP_K11|MSG00101|P|2.5.1
MSA|AA|MSG00044
QID|Q9001234567|Z45^Visit History Query^HL70471
QAK|Q9001234567|OK|Z45^Visit History Query^HL70471|2|2|0
PID|1||MR67890^^^CLINIC_A^MR||ROE^RICHARD^P||19720930|M

FHIR mapping

QID is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR Implementation Guide for QID because query/response infrastructure has no direct FHIR resource equivalent. In FHIR, query identification is implicit in the RESTful interaction: the HTTP request and its parameters define the query, and the searchset Bundle returned in response is self-identifying through its self link and the search parameters echoed there. The correlation role QID plays in v2 is handled at the protocol layer in FHIR rather than by a dedicated resource or element, so there is no direct translation; engines bridging v2 query traffic synthesize identity from the search context.

Engine considerations

Interface engines treat QID as a small, non-repeating header segment for responses. The most common engine task is correlation: store the outgoing Query Tag when a QBP is sent and match it against inbound QID-1 to reunite an asynchronous response with its request. Engines often validate that QID-1 is present (it is required) and that QID-2 equals the requested query name, flagging mismatches. Because QID and QAK usually appear together at the top of an RSP, routing logic frequently reads both in one pass: QID for identity, QAK for outcome.

How Vorro parses and produces QID

When parsing an inbound RSP, Vorro reads QID positionally and lifts the Query Tag into the response correlation key and the Message Query Name into the query-identity field of its structured response model. It cross-checks QID-1 against the originating QPD-2 and QID-2 against the originating QPD-1, raising a normalized warning when they disagree. When producing a QID for a response it generates, Vorro echoes the requester's Query Tag verbatim and copies the requested Message Query Name, ensuring the response is self-describing and correlatable. Both fields are required, so Vorro enforces their presence before transmission.

Sources

← Back to HL7 v2 Guide