HL7 RPL_I02 (Patient Selection Display List) | Integration Soup HL7 Reference Guide

HL7 RPL_I02 Patient Selection Display List

A human-readable candidate list returned after an older patient selection query.

HL7 message structure RPL_I02 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

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
MSA	Message Acknowledgment	Yes	No
RPL_I02.PROVIDER	Provider group	Yes	Yes
PRD	Provider Data	Yes	No
CTD	Contact Data	No	Yes
NTE	Notes and Comments	No	Yes
DSP	Display Data	No	Yes
DSC	Continuation Pointer	No	No

RPL_I02 is the display-list response for an older patient selection workflow. A requester asks for possible patients, and the receiver returns display rows rather than fully structured patient records. It is useful to understand when maintaining older referral or registration interfaces, but newer systems usually prefer query-by-parameter patterns with structured responses.

The key difference from RPR_I03 is the response format. RPL_I02 uses DSP display rows, which are meant for a person or simple screen workflow. RPR_I03 returns repeating PID segments, which are easier for another system to process.

A small RPL I02 example

MSH|^~\&|MPI|CITYHOSP|REFERRAL|CITYCLINIC|20260718104500||RPL^I02^RPL_I02|RPL020001|P|2.5.1 MSA|AA|RQI020001 PRD|RT|City Hospital^Patient Registry|1 Hospital Way^^Auckland^^1010^NZ|^^^MPI|CITYHOSP CTD|PR|Registry^Team|1 Hospital Way^^Auckland^^1010^NZ|^WPN^PH^^64^9^5553000 NTE|1||Three possible patient matches returned for review. DSP|1||123456^^^CITYHOSP^MR Smith^Jane 19800314 F 12 High Street DSP|2||998877^^^CITYHOSP^MR Smith^Janet 19800314 F 14 High Street DSP|3||776655^^^CITYHOSP^MR Smyth^Jane 19800315 F 12 High Street DSC|PAGE2|I

What workflow it represents

The sender is usually a registry, referral hub, MPI, or patient administration system responding to an older patient lookup. The receiver is a user-facing application or integration workflow that needs to show possible candidates for manual selection.

Because the rows are display text, this message is best treated as a presentation response. It can support a person making a choice, but it is a poor contract for automated matching unless both systems have a very specific row format agreement.

How to read the structure

MSH and MSA identify the response and the request it answers. The required provider group uses PRD and optional CTD to identify the responder.

NTE can add a human note. DSP repeats for the display rows. DSC appears when the response is continued and the requester must ask for the next page or batch.

Implementation traps

The obvious trap is parsing DSP display text as if it were a stable data model. It might work until the registry changes spacing, column order, name formatting, or which identifier it shows first.

Also handle continuation deliberately. If DSC is present and the UI only displays the first page, users may make a selection from an incomplete candidate list.

Reference notes

HL7 terminology identifies I02 as the RQI/RPL request and receipt of a patient selection display list. The local v2.5.1 structure for RPL_I02 uses MSH, MSA, provider contact, notes, DSP display data, and optional DSC continuation.