HL7 QRY_A19 Patient Query

The older QRD/QRF-style way to ask for patient information.
HL7 message structure QRY_A19 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
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
QRD
 Original-Style Query Definition Yes No
QRF
 Original style query filter No No

QRY_A19 is an older patient query message. A requester sends QRD and QRF criteria to another system and expects patient information back in an ADR_A19 response. You still see this pattern in legacy ADT integrations, older departmental systems, and interfaces that predate the QBP/QPD query style.

The message is simple, but not casual. QRD defines the query timing, format, priority, ID, quantity, subject, and what department or data type is being requested. QRF narrows the search with where/when/filter criteria.

A small QRY A19 example

MSH|^~\&|PORTAL|CITYHOSP|ADT|CITYHOSP|20260717102000||QRY^A19^QRY_A19|QRY190001|P|2.5.1 QRD|20260717102000|R|I|QRY190001|||1^RD|123456^^^CITYHOSP^MR|DEM|ADT QRF|CITYHOSP|20260717000000|20260717235959

What workflow it represents

The sender wants patient information from an ADT or patient administration source. The receiver searches its patient data and replies with ADR_A19, usually including status and patient groups with EVN, PID, PV1, and related optional segments.

Modern interfaces often prefer QBP/RSP because QPD parameters are easier to profile cleanly, but QRY_A19 remains important when maintaining older systems. The safest approach is to document the local QRD/QRF contract explicitly rather than treating it as a generic patient search.

How to read the structure

MSH is the normal HL7 header. QRD carries the main query definition, including the query ID that the response can echo. QRF supplies filter details such as source, date range, and other constraints.

Because the structure has no PID in the request, the patient identifier or search data lives inside QRD and QRF fields. That makes profile documentation essential: the receiver must know which field carries MRN, account number, name, date of birth, or another query key.

Implementation traps

Do not assume every QRY_A19 sender uses QRD the same way. Some older systems put patient identifiers in the "who subject filter"; others use local variations. A parser that only works with one vendor's layout may look standards-based while being very local.

Also avoid treating A19 as an event notification. It is a request for information. If the receiver updates patient state because it received a QRY_A19, something has gone badly off course.

Reference notes

HL7 v2.3.1 and reference sites describe A19 as a patient query interaction using QRY_A19 and ADR_A19. See HL7 v2.3.1 A19 and Caristix QRY_A19.