HL7 QRY Original Mode Query

HL7 message structure QRY groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
Message Header Yes No
Original-Style Query Definition Yes No
Original style query filter No No

QRY is the generic original-mode query shape in HL7 v2. It is the compact, older pattern built around QRD and optional QRF, before the later query-by-parameter model moved most new query work into QBP-style messages.

In real interfaces, use a concrete QRY trigger page when you know it, such as QRY_A19, QRY_PC4, QRY_Q01, or QRY_R02. This generic page is mostly useful when a local feed really does advertise only the abstract QRY structure or a site-defined trigger wrapped in the original-mode grammar.

A small generic QRY example

MSH|^~\&|PORTAL|CITYHOSP|MPI|CITYHOSP|20260717113000||QRY^Z99^QRY|QRY00001|P|2.5.1 QRD|20260717113000|R|I|QRY00001|||10^RD|123456^^^CITYHOSP^MR|DEM^Demographics^L|MPI|T QRF|MPI|20260101000000|20260717235959|ACTIVE

What workflow it represents

The sender is usually a legacy application, integration engine, departmental system, or migration bridge asking another system for a focused answer. The receiver owns the requested data and returns whatever response message the query profile defines.

Original-mode QRY messages can still be operationally important because they often sit in older patient lookup, result lookup, order status, master-file, or clinical repository workflows. They are not usually where you want to design a brand-new interface unless you are matching an established partner.

How to read the structure

MSH identifies the local query event and message structure. QRD is required and carries the query date/time, format, priority, query ID, quantity limit, subject, topic, department, and response level. QRF further narrows the query by source, date range, status, or other local filters.

The structure panel is intentionally tiny because the real contract lives in the query profile. Two feeds can both say QRY and still mean very different things in QRD-8, QRD-9, QRF-4, and the response message.

Implementation traps

The big trap is treating QRD and QRF as self-explanatory. They are not. The receiver must publish which QRD fields it actually reads, which identifiers it accepts, what status and date filters mean, and which response message comes back.

Also avoid broad "give me everything" queries unless the receiver explicitly supports them. Old query interfaces can be surprisingly easy to overload, and continuation behavior is often weaker than in newer QBP/RSP workflows.

Reference notes

HL7 Chapter 5 describes original-mode QRD/QRF queries as the older compatible query style and recommends the v2.4 query-by-parameter model for newer work. The local v2.5.1 structure for QRY contains MSH, required QRD, and optional QRF.