HL7 QIP Data Type: Query Input Parameter List

QIP (Query Input Parameter List) is the two-component v2.5+ composite that pairs a segment-field name with one or more values to be applied as an equality filter. It is the pragmatic replacement for QSC in v2.5+ batch-query templates — where QSC supported a rich set of relational operators but only one value per criterion, QIP drops the relational operator and instead lets a single parameter carry a repeating value list joined by the sub-component delimiter &.

QIP was introduced in v2.5 and is the canonical content of QPD-3 in modern published query profiles.

Purpose

QIP exists because most real-world query templates are simpler than QSC allows: the sender wants to say "patient identifier is one of MR884412 or MR000999," not "order date is greater than 2026-01-01 AND less than 2026-06-24." Encoding "one of" using QSC requires multiple repetitions with OR conjunctions, which is verbose and easy to get wrong; QIP encodes the same thing as a single parameter with a repeating value list.

QIP also better matches the way modern receivers actually implement queries: as a parameter dictionary (name → value list) rather than a relational query engine. The two-component shape maps cleanly onto FHIR search parameters (?identifier=MR884412,MR000999), onto HTTP query strings, and onto SQL WHERE col IN (...) clauses.

Component reference

Source: HAPI HL7v2 v2.8.1 javadocs — QIP. QIP has two components separated by ^.

Seq	Name	Data Type	Length	Req	Description
QIP.1	Segment Field Name	st	—	R	Segment-field reference. Conventionally prefixed with `@` and using dot notation (e.g. `@PID.3.1`) when referring to a specific component, distinguishing the input-parameter form from the QSC `SEG-N` style.
QIP.2	Values	st	—	O	One or more values for the named parameter. Multiple values are joined by the sub-component delimiter `&` and are treated as an `OR` (`IN`) match by the receiver.

QIP.2 uses & as an intra-component repeat. Encoders must be careful: the & here is not a sub-component delimiter in the structural sense (QIP has no sub-components), it is a value-list separator unique to this type.

Most-used components

QIP.1 Segment Field Name — always populated; the parameter name.
QIP.2 Values — populated except when the query template defines a parameter whose presence alone is meaningful (rare).

Within QIP.2, the most-used pattern is a single value; a &-joined value list is used when the receiver supports IN-style filtering for that parameter.

Where it's used

QPD-3 User Parameters — the canonical home of QIP in v2.5+ batch query templates. A single QPD-3 carries a repeating QIP list, one per named input parameter the template accepts.

Version differences

v2.1–v2.4 — No QIP. Query input parameters were expressed as QSC criteria or as bespoke fields in narrow query segments.
v2.5 — QIP introduced. QPD-3 typed as a repeating QIP. Published query profiles (e.g. Z22 PDQ) standardize the parameter names QIP.1 should carry.
v2.5.1 / v2.6 / v2.7 / v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — QIP structure unchanged. New published query profiles continue to be issued with QIP-shaped parameter lists.

Common mistakes

Using ~ instead of & for multiple values. ~ is the field-repetition delimiter and would split the QIP across repetitions of QPD-3 (one parameter name per repetition); & keeps multiple values under a single parameter name. The semantic difference is AND/OR grouping — get this wrong and the receiver runs the wrong query.
Mixing QIP and QSC in the same QPD-3. QPD-3 is typed by the query profile; a profile that declares QIP cannot also accept QSC repetitions. Bridges must pick one form per outbound message.
Dotted vs hyphenated field reference. Published profiles use the @PID.3.1 form (with leading @ and dot separator) in QIP.1; QSC uses PID-3. Receivers that strictly validate against the profile reject the wrong form.
Encoding a value-set lookup as a &-joined list. MR&AN&SS is three identifier types, not one identifier with three sub-pieces. If the parameter expects a single value of a coded type, use the appropriate code system, not a &-list.
Empty values with no meaning declared. Some profiles allow an empty QIP.2 to mean "any value"; others reject it. Read the profile.

Examples

Single parameter, single value:

@PID.3.1^MR884412

Single parameter, multiple values (OR/IN semantics):

@PID.3.1^MR884412~MR000999

Wait — that previous example uses ~, which is wrong. The correct multi-value form uses &:

@PID.3.1^MR884412&MR000999

When repeating across parameters, ~ separates QIP repetitions inside QPD-3, while & joins multiple values inside one QIP:

@PID.3.1^MR884412&MR000999~@PID.5.1^SMITH

In context — full v2.8.1 query message using a PDQ-style template:

MSH|^~&|EMR|MERCY|EHR|MERCY|20260624102000-0500||QBP^Q22^QBP_Q21|MSG-QRY-44871|P|2.8.1
QPD|Q22^Find Candidates^HL70471|QID-44871|@PID.3.1^MR884412&MR000999~@PID.5.1.1^SMITH
RCP|I|10^RD

Common pitfall — value list joined with ~ instead of &:

QPD|Q22^Find Candidates^HL70471|QID-44871|@PID.3.1^MR884412~@PID.3.1^MR000999

The emitter intended "identifier in (MR884412, MR000999)" but encoded it as two separate QIP repetitions for the same parameter name. Strict receivers reject the duplicate parameter; permissive receivers may apply only the last value, silently dropping MR884412.

FHIR mapping

The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for QIP. QIP entries map to FHIR search parameter name=value pairs.

HL7 v2 (QIP)	FHIR search query
QIP.1 Segment Field Name	named SearchParameter (e.g. `@PID.3.1` → `identifier=`)
QIP.2 Values (single)	the value portion (`identifier=MR884412`)
QIP.2 Values (`&`-joined)	comma-joined values for `OR` semantics (`identifier=MR884412,MR000999`)

A QIP-shaped QPD-3 maps onto a complete FHIR search URL: Patient?identifier=MR884412,MR000999&family=Smith.

Engine considerations

Delimiter awareness. A parser that treats & strictly as a sub-component delimiter inside QPD-3 will mis-split QIP.2 value lists. Vorro and HAPI treat & inside QIP.2 as a value-list separator first and a sub-component delimiter only as a fallback.
Profile binding. The set of valid QIP.1 names is profile-defined. Engines should validate QIP.1 against the declared profile (QPD-1 carries the message query name + value set) and report an ERR with an ELT for any out-of-profile parameter.
HAPI accessors. ca.uhn.hl7v2.model.v281.datatype.QIP exposes getSegmentFieldName() and getValues(); the value list comes back as an array.
No relational operators. QIP cannot express GT/LT/range queries. Profiles that need a range typically declare two parameters (e.g. @OBR.7.MIN, @OBR.7.MAX) rather than reaching for QSC; mixing QIP and QSC in one segment is not legal.
Repetition vs value list. Each QIP.1 should appear at most once per QPD-3; multi-value semantics belong inside QIP.2 with &.

How Vorro parses and produces QIP

Vorro parses QIP into an internal Parameter(name, values[]) record where values is always a list, even for single-value parameters — this normalization eliminates a class of bugs where downstream code branches on "is this a scalar or a list." The & delimiter is handled at the QIP-parse level, before the structural sub-component delimiter logic runs, so QIP.2 value lists never get split into spurious sub-components.

When producing outbound QIP, Vorro emits a single QIP.2 component with &-joined values when there are multiple, and a bare scalar when there is one. Vorro never emits a QIP with a duplicate QIP.1 across repetitions of QPD-3; if the destination expects that wire shape, an explicit profile flag forces the alternate encoding and logs the deviation.

Sources

← Back to HL7 v2 Guide