HL7 RPR Messages: Return Patient List

HL7 RPR messages return a list of candidate patients — the structured response to a request for patient information when the original query did not identify the patient uniquely. An RPR message answers an RQI request for patient information by returning the matching patients as PID records rather than a formatted display, so the requesting system can pick the right patient and requery with a definitive identifier. This page explains what an RPR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RPR patient list relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an RPR message represents

An RPR message — RPR stands for Return Patient List — communicates the set of patients that matched a request for patient information. The core of the message is the repeating PID list inside the PATIENT group: each candidate patient is returned as structured demographics — identifiers in PID-3, name in PID-5, date of birth in PID-7, sex in PID-8 — rather than as a rendered display line. The list is deliberately a selection aid, not the patient's full record; it carries enough demographic detail for a human or a system to disambiguate the candidates.

The sender is the system that holds the patient information (a payer, a provider directory, or a master patient index), and the receiver is the requesting application that issued the RQI. RPR sits one step downstream of the request: an RQI request for patient information asks "which patient do you mean?", and the RPR message answers with the candidates. Because the requester's original query was ambiguous, the returned PID list — not a single record — is the payload, and the requester is expected to select one and requery with the definitive identifier it carries.

When an RPR message is sent

An RPR message is sent in response to an RQI request for patient information that resolves to more than one candidate patient, or whenever the responding system returns a structured patient selection list rather than a formatted display. The response acknowledges the request through MSA and, where the query could not be satisfied, reports the condition through ERR.

Trigger event

The RPR message type carries a single trigger event:

• RPR^I03 – Return patient list (response to an RQI^I03 request for patient information).

Because RPR has one trigger event, the receiver's handling turns on the contents of the returned PID list and the acknowledgement in MSA — how many candidates matched and whether the request succeeded — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the patient-information source answering an RQI request through the integration engine, returning the candidate patient list to the requester.

{{diagram: requester (RQI^I03) → integration engine → patient-information source (payer / MPI / directory) → RPR^I03 patient list → requester}}

Typical senders: payer or benefits system, enterprise master patient index, provider or member directory.

Typical receivers: the provider or referral application that issued the original RQI request for patient information.

Direction: a response message returned to the system that issued the request, completing the query/response pair.

Segments in an RPR message

The RPR_I03 message is organised around an acknowledgement and query echo followed by one or more PROVIDER groups, each opening with PRD and carrying one or more PATIENT groups. Within a PATIENT group the PID is required and the next-of-kin segments are optional and repeating; the candidate-patient list is the message's payload. 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 PATIENT group built around PID repeats once per candidate patient within each PROVIDER group, so a single RPR message can return several patients for selection. The canonical segment pages carry the full field-by-field detail.

Sample RPR message

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

MSH|^~&|MPI|MERCYGEN|REFAPP|MERCYGEN|202006150900||RPR^I03^RPR_I03|MSG00021|P|2.5.1
MSA|AA|REQ00007
QRD|202006150900|R|I|QRY00007|||10^RD|@PID.5^DOE|DEM
PRD|RP|SMITH^ROBERT^B^^^^MD|^^^MERCYGEN||||NPI1234567^^^CMS&2.16.840.1.113883.4.6&ISO^NPI
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
PID|2||MR67890^^^MERCYGEN^MR||DOE^JANE^M||19751104|F

What this sample shows

The RPR^I03 in MSH-9 marks a returned patient list. MSA carries the acknowledgment code AA and echoes the request control id REQ00007, tying the response to the RQI that triggered it. QRD echoes the original query — a demographic lookup on the name DOE with a quantity limit of 10. PRD names the referring provider (RP) the list is returned for. The two PID segments are the payload: two candidate patients named DOE — MR12345 (John, born 1980-01-01) and MR67890 (Jane, born 1975-11-04) — each carried with enough demographic detail for the requester to select one and requery with the definitive medical record number in PID-3.

Working with RPR messages

Read the candidates from the PID list, not a display

The selectable patients live in the repeating PID segments, returned as structured demographics rather than a rendered line. Iterate every PID in each PATIENT group and present the identifier in PID-3, the name in PID-5, and the birth date in PID-7 as distinct fields — do not collapse them into a single string, because the requester is expected to read back the PID-3 identifier to requery.

Correlate the response to its request

Use MSA-2 to match the RPR to the RQI it answers, and treat QRD as the echo of what was asked. A response that arrives without a matching outstanding request — or with an MSA-1 other than AA — should not be treated as a completed lookup; check ERR before discarding it.

Paging with the continuation pointer

A DSC at the end of the message means the candidate list is incomplete. Resend the query carrying the continuation pointer from DSC to retrieve the next batch, and accumulate the PID records across responses rather than treating each batch as the full result set.

The provider role on PRD

PRD opens each PROVIDER group, and PRD-1 distinguishes the referring provider (RP) from the referred-to provider (RT). When a message carries more than one PROVIDER group, key the candidate lists by the provider role rather than assuming a single context.

Vendor variance. The acknowledgement and query-echo segments — MSA, ERR, QRD, and QRF — are optional in the RPR_I03 structure, so some responders return the full echo of the request while others return only the PRD and PID payload. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A returned patient list corresponds conceptually to a FHIR Bundle of type searchset containing one Patient resource per candidate — the same shape a FHIR Patient search returns when a query matches more than one record.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RPR_I03. A FHIR searchset Bundle produced from an RPR message is therefore assembled manually: each returned PID becomes a Patient resource as a Bundle entry, the candidate count drives the Bundle total, and a continuation pointer from DSC maps to the Bundle's paging links.

Common pitfalls

Pitfall. Treating the first PID as the answer. RPR returns a list precisely because the request was ambiguous; selecting the first candidate instead of presenting all of them defeats the purpose of the message.

Pitfall. Ignoring the continuation pointer. A DSC at the end of the message means more candidates remain; processing only the first batch silently drops matches that paged onto later responses.

Pitfall. Skipping the acknowledgement check. An MSA-1 other than AA, or a populated ERR, means the request was not fully satisfied; reading the PID list without checking the acknowledgement can present a partial or failed result as complete.

How Vorro handles RPR messages

Vorro receives the RPR response over MLLP or another transport, correlates it to the originating RQI on the control id echoed in MSA-2, and routes the candidate list to the requesting application in the format that system expects. Vorro reads each candidate from the repeating PID list, preserves the PID-3 identifiers so the requester can requery definitively, follows the continuation pointer in DSC to assemble paged results, and, where a FHIR destination is configured, maps the list to a searchset Bundle of Patient resources — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• REF — the patient referral message exchanged in the same I-series patient-referral conversation.
• RQI — the request for patient information that an RPR message answers.
• RPI — the return patient information message that returns a single patient's detail rather than a candidate list.

Sources

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