HL7 ADR Messages: ADT Response

HL7 ADR messages carry a query response to a patient demographics and visit request — the answer to a system that asked "tell me what you know about this patient." An ADR message wraps the same patient and visit data found in an ADT message inside a query-response envelope driven by a QRD query definition segment, and is sent from the system that holds the patient record back to the system that asked for it. This page explains what an ADR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an ADR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an ADR message represents

An ADR message — ADR stands for ADT Response — communicates a responding system's answer to a patient query. The core of the message is the repeating QUERY_RESPONSE group, which carries the full patient and visit record for each matching patient: demographics in PID, visit data in PV1, and optional supplements including allergies, diagnoses, insurance, and observations. The QRD query definition segment at the head of the message echoes back the original query so that the requester can correlate the response to its question.

The sender is the system that owns the authoritative patient record — most often an ADT system or a master patient index — and the receiver is the system that initiated the query, such as a departmental application or an integration engine that needs to bootstrap a patient context. ADR sits inside a request-response exchange: a querying system sends an QRY^A19 patient query, and the responding system returns an ADR^A19 carrying the matches. Because the response reuses the same patient-and-visit segments as an ADT notification, a system that already parses ADT messages can process the QUERY_RESPONSE group with minimal additional logic.

When an ADR message is sent

An ADR message is sent in response to a patient-query request. A single query can produce a response whose QUERY_RESPONSE group repeats once per matching patient, so a broad query by name or date of birth can return several patients in a single ADR. If no patients match, the response carries an empty QUERY_RESPONSE group or omits it entirely, and the QAK query acknowledgement segment signals the no-data result.

Trigger event

The ADR message type carries a single trigger event:

• ADR^A19 – Patient query response.

The trigger A19 pairs with the QRY^A19 patient query. Because ADR has one trigger event, the receiver's handling turns on the contents of the QUERY_RESPONSE group and on the acknowledgement code in QAK — which was added in v2.4 and indicates whether the query found data, found no data, or encountered an error — rather than on the trigger code in MSH-9 alone.

Integration topology

The diagram shows a querying system issuing a patient query through the integration engine to the ADT system, which returns an ADR response.

{{diagram: querying system → QRY^A19 → integration engine → ADT system → ADR^A19 → integration engine → querying system}}

Typical senders: ADT system, master patient index, enterprise patient registry.

Typical receivers: departmental application, integration engine, ancillary system bootstrapping a patient context, or any system that needs demographics and visit data on demand.

Direction: request-response exchange — the querying system sends a QRY^A19, and the ADT system responds with an ADR^A19.

Segments in an ADR message

The ADR_A19 message opens with a header block (MSH, MSA, optional ERR segments, QAK, and QRD) and then carries one or more repeating QUERY_RESPONSE groups, each of which holds the full patient and visit record for one matching patient. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

The QUERY_RESPONSE group from EVN through ACC repeats once per matching patient, so a single ADR message can carry several complete patient records. The canonical segment pages carry the full field-by-field detail.

Sample ADR message

Note. Constructed for illustration. Patient identifiers, dates, and names are fictional.

MSH|^~&|ADTSYS|MERCYGEN|DEPT|MERCYGEN|20260604103000||ADR^A19^ADR_A19|MSG00031|P|2.5.1
MSA|AA|MSG00030
QAK|QRY20260604001|OK
QRD|20260604103000|R|I|QRY20260604001|||1^RD|SMITH^JOHN|DEM|ALLERGY~VISIT
EVN|A08|20260604090000
PID|1||MR99001^^^MERCYGEN^MR||SMITH^JOHN^A||19750315|M|||123 MAIN ST^^BOSTON^MA^02101^USA
PD1|||MERCY PRIMARY CARE^^FAC001
NK1|1|SMITH^JANE^|SPO^Spouse^HL70063|123 MAIN ST^^BOSTON^MA^02101^USA|^PRN^PH^^^617^5550199
PV1|1|I|2N^201^A^MERCYGEN|EL|||ATTEND01^JONES^ALICE^^^DR|REF01^BROWN^CHARLES^^^DR||MED|||||||ADM01|VN|ADM|||||||||||||||20260601080000
AL1|1|DA^Drug Allergy^HL70127|PENICILLIN^Penicillin^L|SV^Severe^HL70128|ANAPHYLAXIS
DG1|1|ICD10^I10^ICD-10-CM|I10^Essential (primary) hypertension^ICD-10-CM|20260601|W
IN1|1|PLAN01^BlueCross PPO^HL70072|INS001^BlueCross BlueShield|BCBS^^123 INSURER AVE^^BOSTON^MA^02110|||GROUP9901|SMITH^JOHN^A|SEL^Self^HL70063|19750315|

What this sample shows

The ADR^A19 in MSH-9 marks a patient query response. MSA carries acknowledgement code AA — the query was accepted — and echoes the originating message control id MSG00030. QAK tags the query id QRY20260604001 and signals OK, meaning matching data was found. QRD echoes the original query definition: issued at 20260604103000, requesting demographic and allergy and visit subjects for patient SMITH^JOHN. The single QUERY_RESPONSE group then carries the full record: EVN records an A08 update event, PID carries medical record number MR99001 and patient demographics, PD1 names the primary-care facility, NK1 identifies the spouse, PV1 places the patient inpatient on unit 2N under attending physician JONES^ALICE, AL1 flags a severe penicillin allergy, DG1 records an ICD-10 hypertension diagnosis, and IN1 records a BlueCross PPO insurance plan.

Working with ADR messages

Correlate the response to the query using QAK and QRD

The QAK query tag and the QRD query id together are the keys that tie the ADR response back to the originating QRY^A19 request. Preserve the query tag on the outbound request, match it against QAK-1 on the response, and check the query result status in QAK-2 before processing the QUERY_RESPONSE group — a status of NF (no data found) means the group is empty and no patient data should be processed.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key. ADR responses can be retransmitted after network failures; treating a repeated control id as a duplicate prevents a replayed response from overwriting a patient record that has since changed or from creating a duplicate context in the consuming application.

Handle multiple patients in one response

The QUERY_RESPONSE group repeats once per matching patient. A query by name or date of birth can return several groups in a single ADR. Iterate over every group rather than assuming the response holds a single patient — process each PID independently and present the list to the user or application that initiated the query.

QAK is version-sensitive

QAK was added in v2.4 and is required in v2.5.1. Systems on earlier versions may omit it. When interoperating with v2.3 or v2.3.1 senders, do not fail hard on a missing QAK; infer query status from MSA instead and flag the version gap in your interface specification.

Vendor variance. The insurance group (IN1, IN2, IN3) and guarantor (GT1) are optional and their presence varies widely across ADT systems. Some systems include full insurance detail in every ADR response; others omit it entirely. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A patient query response corresponds conceptually to a search response returning Patient and Encounter resources — PID maps to Patient and PV1 maps to Encounter, with supplementary resources for allergies (AllergyIntolerance), diagnoses (Condition), observations (Observation), and coverage (Coverage).

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for ADR_A19 — the ADR message appears in the v2-to-FHIR message maps index only by its absence. A FHIR representation produced from an ADR message is therefore mapped manually, taking patient demographics from PID, visit context from PV1, and supplementary data from the optional segments within the QUERY_RESPONSE group.

Common pitfalls

Pitfall. Processing the QUERY_RESPONSE group without checking QAK. A QAK-2 status of NF (no data found) or AE (error) means the group carries no usable patient data; skipping the status check and attempting to parse an empty or error response produces spurious nulls or parse failures.

Pitfall. Assuming a single patient per ADR. The QUERY_RESPONSE group repeats once per matching patient. A query by common name or date of birth can return several groups; code that reads only the first PID silently discards the rest.

Pitfall. Ignoring the QRD echo. The QRD in the response echoes the original query definition. Failing to correlate the query id in QRD with the originating request makes it impossible to match async responses to their requests in high-volume environments where multiple queries are in flight simultaneously.

How Vorro handles ADR messages

Vorro ingests ADR responses over MLLP or another transport, deduplicates on MSH-10, and correlates each response to its originating query using the query tag in QAK and the query id in QRD. Vorro reads the query result status before processing the QUERY_RESPONSE group, iterates over every group when the response carries multiple patients, and routes the patient and visit data to every subscribed destination in the format that system expects. Where a FHIR destination is configured, Vorro maps the patient demographics to a Patient resource and the visit data to an Encounter resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• ADT — the admit/discharge/transfer notification that carries the same patient and visit data as an ADR but as an unsolicited event rather than a query response.
• QBP — the query by parameter message, the modern replacement for QRY-based queries in v2.5 and later.
• RSP — the response to a QBP query, the modern counterpart of ADR in the query-response model.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for ADR_A19
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for ADR
• HL7 Messaging Standard Version 2.5.1 product brief