HL7 QSC Data Type: Query Selection Criteria

QSC (Query Selection Criteria) is the four-component composite that encodes a single selection criterion in an HL7 v2 query — a segment-field reference, a relational operator, a value to compare against, and an optional conjunction tying it to the next criterion. It is the v2-era ancestor of a FHIR SearchParameter expression, designed to let a query message specify "PID-3 EQ MR884412" or "OBR-7 GT 20260101" in a way the receiver can mechanically evaluate.

QSC was introduced in v2.3 and lives primarily in QPD-3 in pre-v2.5 query templates and in QRD-7 (Who Subject Filter) selection criteria. In v2.5+ batch-query templates QSC is largely superseded by QIP, which trades operator richness for repeating multi-value support.

Purpose

QSC exists to make a v2 query message self-describing. Rather than baking query parameters into the message type ("Q01 means by-patient-id"), QSC lets the sender enumerate any number of field operator value triples, joined by AND/OR, that the receiver must satisfy. The result is a single QPD or QRD segment that can express "all OBR rows for patient MR884412 with order date after 2026-01-01 OR patient MR000999," which would otherwise require a bespoke message type per query.

The cost of that flexibility is that the receiver must implement a small query engine — parse the field name, look up the actual segment field, apply the operator, combine via the conjunction — and most v2 receivers historically implemented only a subset. QSC therefore tends to be used as a suggestion the sender hopes the receiver will honor, not a guarantee.

Component reference

Source: HAPI HL7v2 v2.8.1 javadocs — QSC. QSC has four components separated by ^.

All components after QSC.1 are optional; an emitter that knows the receiver supports only EQ may omit QSC.2 and let the receiver default.

Most-used components

• QSC.1 Segment Field Name — the only required component; identifies the column being filtered.
• QSC.3 Value — the literal to compare; omitted only when QSC.2 is EQ and the receiver supports "field present" semantics.
• QSC.2 Relational Operator — defaults to EQ at most receivers; emit explicitly when using any other operator.
• QSC.4 Relational Conjunction — only meaningful when more than one QSC is present in the same field; defaults to AND.

Where it's used

• QPD-3 User Parameters — in pre-v2.5 query templates, QPD-3 carries a repeating QSC list expressing the query's selection criteria. v2.5+ templates more commonly use QIP.
• QRD-7 Who Subject Filter — in the original (pre-v2.5) query mechanism, QRD-7 carried repeating QSC.

Version differences

• v2.1 / v2.2 — No QSC. Query criteria were either fixed by message type or encoded in narrow QRD fields.
• v2.3 / v2.3.1 / v2.4 — QSC introduced. Used in QRD-7 and (where QPD existed) QPD-3.
• v2.5 / v2.5.1 — QPD-3 transitioned toward QIP for batch-query templates; QSC remained available for ad-hoc relational criteria. QRD itself was deprecated in v2.5 in favor of QPD, though QRD messages remained legal.
• v2.6 / v2.7 / v2.7.1 / v2.8 / v2.8.1 / v2.8.2 — QSC composition unchanged. HL70209 and HL70210 code systems unchanged.

Common mistakes

• Bare field name in QSC.1. "PID3" or "PatientID" will not resolve at most receivers; use the canonical SEG-N form PID-3.
• Operator typos. ==, !=, <>, >= are common borrowings from SQL/programming languages but are not valid HL70209 codes. Use EQ, NE, LT, GE.
• Mixing AND and OR ambiguously. QSC.4 attaches to the next repetition, not the previous one. Three criteria with AND~OR~ mean (a AND b) OR c, not a AND (b OR c). When operator precedence matters, split the query.
• Using CT against a coded field. CT is a substring match on the raw text. Against a coded field (CWE/CE), the substring search runs against the encoded triple, not the human-readable name. Use EQ against the identifier component instead.
• Omitting QSC.3 with a relational operator. PID-3^GT with no value is meaningless and most receivers reject the entire query rather than guess.

Examples

Minimal — segment-field reference only (receiver applies default operator EQ against an empty value, typically a "field present" check):

PID-3

Equality match on patient ID:

PID-3^EQ^MR884412^AND

Date range — order date after 2026-01-01:

OBR-7^GT^20260101000000^AND

Substring match on family name:

PID-5.1^CT^Smith^AND

In context — QPD segment carrying a QSC list separated by ~:

MSH|^~&|EMR|MERCY|EHR|MERCY|20260624102000-0500||QRY^Q02|MSG-QRY-44871|P|2.4
QPD|Q22^Find Patient^HL70471|QID-44871|PID-3^EQ^MR884412^OR~PID-3^EQ^MR000999^AND
RCP|I|10^RD

In context — QRD-7 with two criteria (find ORU results for a patient between two dates):

QRD|20260624102000|R|I|QID-99001|||10^RD|MR884412^^^MERCY^MR|ORU|OBR-7^GE^20260101^AND~OBR-7^LE^20260624^AND

Common pitfall — SQL-style operator:

QPD|Q22^Find Patient^HL70471|QID-44871|PID-3^==^MR884412^AND

== is not in HL70209; the receiver either rejects the query or silently ignores the criterion and returns all patients.

FHIR mapping

The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for QSC. FHIR replaces v2 ad-hoc query criteria with named SearchParameters; a QSC field+operator+value combination must be translated to the equivalent FHIR search query string.

The translation is not 1:1 — GN (generic) and the receiver-side semantics of CT against composite types have no direct FHIR equivalent and require negotiation between sender and receiver.

Engine considerations

• Implement a minimum subset. A pragmatic v2 receiver implements EQ, NE, LT, LE, GT, GE against scalar fields and treats CT as case-insensitive substring against ST fields. GN is receiver-defined and most engines leave it unimplemented.
• Operator precedence. Default left-to-right grouping per QSC.4. If the query author needs different grouping, split into multiple QPD/QRD instances or document a profile.
• Type coercion. QSC.3 is ST; the receiver coerces to the target field's type (NM, DT, ID). Coercion failures should be reported via an ERR with an ELT pointing at the offending QSC repetition.
• HAPI accessors. ca.uhn.hl7v2.model.v281.datatype.QSC exposes getSegmentFieldName(), getRelationalOperator(), getValue(), getRelationalConjunction().
• v2.5+ migration. When migrating ad-hoc queries to v2.5+ batch templates, convert each QSC into a QIP only when the operator is EQ; for other operators retain QSC or document a profile extension.

How Vorro parses and produces QSC

Vorro parses QSC into an internal Criterion(field, operator, value, conjunction) record and assembles a list of criteria into an internal Query tree with explicit grouping. The tree representation lets Vorro evaluate the query against its internal patient/order index without relying on left-to-right defaulting — when a sender's AND/OR pattern is ambiguous, Vorro applies the documented HL7 left-to-right default and tags the query as "ambiguous grouping" for operator review.

When producing outbound QSC, Vorro emits criteria in the order they appear in the internal Query tree, using AND/OR at each junction. Operators outside HL70209 are never emitted; if a destination cannot express a criterion (e.g. a regex match), Vorro logs the gap rather than encoding an out-of-vocabulary operator.

Related pages

• QIP data type — Query Input Parameter List (the v2.5+ batch-query analog)
• QPD segment — Query Parameter Definition
• QRD segment — Original-Style Query Definition (deprecated v2.5)

Sources

• HAPI HL7v2 v2.8.1 javadoc — QSC datatype
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief