HL7 RPL messages return a formatted, human-readable display list of candidate patients in response to a request — the list a user reads to select the correct patient for a referral. An RPL message is the reply to an RQI (Request for Patient Information) sent with the I02 trigger, and it is returned from the system that holds the patient records to the requesting system that will display the list for selection. This page explains what an RPL message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RPL display list relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RPL message represents
An RPL message — RPL stands for Return Patient Display List — carries a list of candidate patients formatted for display so that a user can pick the right record. The core of the message is the DSP segment, which holds the display data for the list: each DSP carries one pre-formatted row of text rather than structured patient fields. DSP-1 is the set ID, DSP-2 is the display level, DSP-3 is the data line itself — the line of text to show the user — DSP-4 marks a logical break point in the display, and DSP-5 carries a result ID. The list is deliberately not a set of structured patient records; it is the text the receiving system renders for a human to read and choose from.
The sender is the system that holds the candidate patient records — a payer, a clearinghouse, or another provider's system — and the receiver is the requesting system that issued the RQI and will present the list for selection. RPL sits on the response side of a referral lookup: an RQI^I02 asks for a display list of patients matching a query, and the RPL message returns that list. Because the rows in DSP are pre-formatted for display rather than parsed, the MSA acknowledgement — not the display rows — is the part the requesting system reads programmatically to confirm the original RQI was accepted.
When an RPL message is sent
An RPL message is sent in response to an RQI request carrying the I02 trigger event — the request for a patient selection display list. When the requesting system needs a user to choose among patients matching a query, the receiving system assembles the matching records into a display list and returns them in an RPL. A large result set is paged: the DSC continuation pointer at the end of the message lets the requester ask for the next block of display rows.
Trigger event
The RPL message type carries a single trigger event:
RPL^I02— Return patient display list. The response to anRQI^I02request, returning a formatted, human-readable display list of candidate patients for selection on a referral.
Because RPL has one trigger event, the receiver's handling turns on the contents of the message — the acknowledgement in MSA, the display rows in DSP, and the continuation pointer in DSC — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the system that holds the patient records returning an RPL display list through the integration engine to the requesting system that will present it for selection.
{{diagram: payer / provider system → RPL message → integration engine → requesting provider system (display list for patient selection)}}
Typical senders: payer eligibility system, clearinghouse, referred-to provider's EHR, or health information exchange holding the candidate patient records.
Typical receivers: referring provider's EHR, practice management system, or referral management application that displays the list for a user to select from.
Direction: response — the RPL message answers an earlier RQI^I02 request and returns the display list, with DSC supporting paged retrieval of further rows.
Segments in an RPL message
The RPL message opens with MSH and the acknowledgement, error, and query segments that tie the response back to its request, then carries a repeating PROVIDER group and the display data. The PROVIDER group — opening with PRD and optionally followed by CTD — repeats once per provider involved in the referral. The DSP display segment repeats once per row of the list, and the DSC continuation pointer closes the message. 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every RPL message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RPL^I02), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
[{MSA}] | Message Acknowledgement. Acknowledges the original RQI request: the acknowledgement code in MSA-1 and the message control id of the RQI being answered in MSA-2. This is the part of the message the requesting system reads programmatically to confirm the request was accepted. Optional and repeating. |
[{ERR}] | Error. Carries any error conditions detected in processing the original RQI — the error location and code. Present when the lookup failed or partially failed; absent on a clean response. Optional and repeating. |
[{QRD}] | Query Definition. Echoes the query parameters from the original request — the query date/time, query format, priority, and the subject of the query — so the requester can correlate the display list with the question it asked. Optional and repeating. |
[QRF] | Query Filter. Supplements QRD with the filter criteria applied to the query, such as the date range or the fields the result set was limited to. Optional; present only when the QRD is present and filter detail is carried. |
{PRD} | Provider Data. The key segment of the PROVIDER group. Identifies a provider involved in the referral: the provider role in PRD-1 (RP = referring provider, RT = referred-to provider), the provider name in PRD-2, and the provider identifier (NPI or other) in PRD-7. The PROVIDER group repeats once per provider, so a referral with a referring and a referred-to provider carries two PRD segments. |
[{CTD}] | Contact Data. Contact information for the provider identified in the preceding PRD — name, address, and telecommunication details for the contact person at that provider. Optional and repeating within each PROVIDER group. |
[{DSP}] | Display Data. The core of the message. Each DSP carries one pre-formatted row of the patient display list rather than structured patient fields: the set ID in DSP-1, the display level in DSP-2, the data line — the text to show the user — in DSP-3, a logical break point in DSP-4, and a result ID in DSP-5. Optional and repeating; the list is built from one DSP per row. |
[DSC] | Continuation Pointer. Closes the message and supports paging. When the result set is larger than one message, DSC-1 carries a continuation pointer the requester echoes back to retrieve the next block of display rows. Optional; absent when the whole list fits in one message. |
[ ] = optional, { } = repeating
The PROVIDER group from PRD through CTD repeats once per provider involved in the referral, and the DSP segment repeats once per row of the display list, so a single RPL message can return a multi-line list of candidate patients. The canonical segment pages carry the full field-by-field detail.
Sample RPL message
Note. Constructed for illustration. Patient identifiers, provider identifiers, dates, and names are fictional.
MSH|^~&|PAYERSYS|BCBSIL|REFAPP|CITYMED|20260604083500||RPL^I02^RPL_I02|MSG00088|P|2.5.1
MSA|AA|MSG00047
QRD|20260604083000|D|I|Q001|||10^RD|PAT^^^|DEM|||
PRD|RP|SMITH^CAROL^A^^^DR|||||1234567890^NPI
DSP|1|1|MARY E JOHNSON F 1975-03-15 MRN PAT98765|
DSP|2|1|MARIE A JOHNSON F 1975-11-02 MRN PAT43210|
DSP|3|1|MARY JOHNSON F 1981-07-22 MRN PAT55512|
DSC|CONT0001
What this sample shows
The RPL^I02 in MSH-9 marks a returned patient display list. MSA acknowledges the original request with code AA and echoes the RQI control id MSG00047 in MSA-2, tying the response to its request. The QRD echoes the query that produced the list, and the PRD carries role code RP for the referring provider Dr. Carol Smith with NPI 1234567890. Three DSP segments carry the list, one row each: DSP-1 numbers the rows 1, 2, and 3, and DSP-3 holds the pre-formatted line of text for each candidate patient — name, sex, date of birth, and medical record number, laid out for a user to read. The DSC continuation pointer CONT0001 signals there are more rows to retrieve.
Working with RPL messages
Read the acknowledgement from MSA, not the display rows
The part of an RPL the requesting system reads programmatically is MSA, not the DSP rows. MSA-1 carries the acknowledgement code for the original RQI, and MSA-2 echoes the RQI's control id so the response can be correlated to its request. The DSP rows are pre-formatted text for display — treat them as opaque presentation lines rather than parsing fields out of them.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and correlate the response to its request through MSA-2, which echoes the RQI's control id. Referral lookups are retried after timeouts, and treating a repeated control id as a duplicate prevents the requesting system from rendering the same display list twice or re-prompting the user.
Page through the list with DSC
A large candidate list is split across messages. When DSC carries a continuation pointer, the whole list did not fit in one message; echo the pointer back in a continuation request to retrieve the next block of DSP rows. Assemble the rows in DSP-1 set-ID order across pages rather than relying on arrival order.
Preserve the display formatting
The data line in DSP-3 is laid out by the sender for human reading — column spacing and field order are part of the message, not incidental whitespace. Render the line as supplied rather than collapsing whitespace or reflowing it, so the columns the sender aligned stay aligned for the user selecting a patient.
Vendor variance. The layout of the
DSP-3data line is sender-specific — there is no standard column order, andDSP-2, the display level, may be used to distinguish heading rows from data rows in some systems and ignored in others. Confirm a partner's display-line layout against their interface specification rather than assuming a fixed format.
FHIR equivalent
A returned patient display list conceptually corresponds to a FHIR Bundle of type searchset containing the candidate Patient resources, with a MessageHeader at the head of the Bundle for a messaging exchange — the FHIR analogue of a patient search that returns matching records for selection.
There is, however, no published mapping to lean on, and the fit is loose by nature. The HL7 v2-to-FHIR Implementation Guide provides no message map for RPL_I02 and no ConceptMap for the DSP display data segment. The deeper mismatch is structural: RPL returns pre-formatted display text in DSP-3, whereas a FHIR searchset Bundle carries structured Patient resources. A Bundle produced from an RPL message is therefore composed manually, and where the source DSP rows are display text rather than parsed fields, the structured Patient data must be recovered from the sender's display-line layout or from a separate structured lookup.
Common pitfalls
Pitfall. Parsing patient fields out of the
DSP-3data line. The data line is pre-formatted display text with no standard column order; extracting structured fields from it by position breaks the moment a sender changes its layout. Use the line for display and obtain structured patient data from a structured response, not from the display row.
Pitfall. Ignoring the
DSCcontinuation pointer. A present continuation pointer means the list is incomplete; treating the first message as the full result set hides candidates and can lead a user to select the wrong patient because the right one was on a later page.
Pitfall. Reading the display rows instead of
MSAto judge success. A failed or partial lookup is reported inMSAandERR, not in the absence ofDSProws; an empty list with anAAacknowledgement is a valid "no matches" result, not an error.
How Vorro handles RPL messages
Vorro receives RPL messages over MLLP or another transport, deduplicates on MSH-10, and correlates each response to its originating RQI through the control id echoed in MSA-2. Vorro reads the acknowledgement and any ERR conditions to confirm the lookup succeeded, preserves the pre-formatted DSP display rows for the requesting application to render, and follows the DSC continuation pointer to assemble a paged list across messages. Where a FHIR destination is configured, Vorro 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 and the DSP rows carry display text rather than structured data.
Related messages
- RQI — the Request for Patient Information message; an
RQI^I02request is what an RPL display list answers. - RPI — the Return Patient Information message, the structured-data response to an RQI request for insurance information.
- REF — the patient referral message that initiates a clinical referral, the workflow in which a patient display list is selected.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RPL_I02
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for DSP
- HL7 Messaging Standard Version 2.5.1 product brief
