HL7 RPI messages return patient information — most commonly insurance eligibility or coverage data — in response to an RQI request. An RPI message is sent by the system that holds the patient or insurance record back to the system that asked for it, completing the request/response exchange that underpins referral and pre-authorisation workflows. This page explains what an RPI message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how an RPI response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RPI message represents
An RPI message — RPI stands for Return Patient Information — delivers patient demographic and insurance data back to a requesting system. The requesting system sent an RQI because it lacked the information needed to complete a referral or authorisation; the RPI is the answer. A payer, clearinghouse, or referred-to provider system assembles the response from its records and sends it back through the same integration path.
The structure of the message mirrors the RQI it answers. The repeating PROVIDER group, each opening with a PRD segment, carries the providers involved in the referral — the referring provider (RP role in PRD-1) and the referred-to provider (RT role in PRD-1) — so the requesting system can confirm which parties the response addresses. The PID segment returns the patient's demographic record as held by the responding system. The optional, repeating INSURANCE group — IN1, IN2, IN3 — carries each insurance plan and any certification or authorisation data the responding system holds for the patient. When the RPI is sent as a direct application-layer response to the RQI, an MSA segment precedes the provider groups, acknowledging the original request by echoing its message control id.
When an RPI message is sent
An RPI message is sent when a system that received an RQI has located the requested patient or insurance record and is ready to return it. Because the RQI/RPI exchange is synchronous in most implementations — the requesting system holds its workflow open waiting for the reply — the RPI is generated and transmitted as soon as the lookup completes. An RPI carrying an error acknowledgement in MSA (acknowledgement code AE or AR) signals that the request could not be fulfilled, so the requesting system can alert the user rather than waiting indefinitely.
Trigger events
The RPI message type carries two trigger events:
RPI^I01— Return of insurance information. The responding system returns the patient's insurance eligibility or coverage data in answer to anRQI^I01request. This is the most common trigger in referral and pre-authorisation workflows.RPI^I04— Return of patient information. The responding system returns general patient demographic information, not limited to insurance, in answer to a broader patient-information request.
The trigger code in MSH-9 tells the receiving system which flavour of information is being returned, allowing the same inbound handler to route the payload to the correct downstream process.
Integration topology
The diagram shows the responding system returning an RPI message through the integration engine to the system that issued the original RQI request.
{{diagram: payer / clearinghouse / referred-to provider system → RPI message → integration engine → referring provider system}}
Typical senders: payer eligibility system, clearinghouse, referred-to provider's EHR, or health information exchange.
Typical receivers: referring provider's EHR, practice management system, or referral management application.
Direction: response — the RPI message completes the request/response exchange initiated by an RQI.
Segments in an RPI message
The RPI message opens with MSH, optionally followed by one or more MSA acknowledgement segments when the message is sent as a direct response to an RQI. A repeating PROVIDER group — PRD and optional CTD — then carries the providers involved. Patient demographics follow in PID, optionally supplemented by next-of-kin and guarantor data. The optional, repeating INSURANCE group carries each coverage plan. Message-level notes close 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 RPI message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RPI^I01 or RPI^I04), 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. Present when the RPI is sent as a direct application-layer response to an RQI. Echoes the message control id from the original RQI in MSA-2 and carries the acknowledgement code in MSA-1 — AA for accepted, AE for application error, AR for application reject. The requesting system uses MSA-2 to correlate the response to the originating request. Optional and repeating. |
{PRD} | Provider Data. The key segment of the PROVIDER group. Returns information about 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, the provider address in PRD-4 through PRD-6, 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. Required; at least one PROVIDER group must be present. |
[{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. |
PID | Patient Identification. Returns the patient's demographic record as held by the responding system — the identifier list in PID-3, the patient name in PID-5, date of birth in PID-7, sex in PID-8, and address in PID-11. Required; the requesting system reconciles the returned PID against its own patient record to confirm the correct patient was found. |
[{NK1}] | Next of Kin/Associated Parties. The patient's next of kin or associated persons as held by the responding system. Optional and repeating; included when the responding system holds this information and it is relevant to the referral or request. |
[{GT1}] | Guarantor. The financial guarantor for the patient's account. Optional and repeating; relevant when the referral or insurance response involves billing responsibility or coordination of benefits. |
[{IN1}] | Insurance. Opens the optional, repeating INSURANCE group. Returns the patient's insurance plan information as held by the responding system — plan ID, company name, group number, member ID, and subscriber details — giving the requesting system the coverage data it needs to authorise the referral or verify eligibility. Optional and repeating to accommodate multiple insurance plans. |
[IN2] | Insurance Additional Information. Supplements IN1 with additional insurance data such as the subscriber's employer, coordination of benefits order, and Medicaid case number. Optional; present only when the INSURANCE group is present. |
[IN3] | Insurance Additional Information — Certification. Carries pre-certification and authorisation data for the insurance plan — certification number, certified begin and end dates, and the certifying entity. Optional; present only when the INSURANCE group is present and certification data is available. |
[{NTE}] | Notes and Comments. Message-level notes that apply to the returned patient information as a whole — for example, a notice that coverage could not be verified or that a secondary plan is pending. Optional and repeating. |
[ ] = optional, { } = repeating
The PROVIDER group from PRD through CTD repeats once per provider involved in the referral. The INSURANCE group from IN1 through IN3 repeats once per insurance plan. The canonical segment pages carry the full field-by-field detail.
Sample RPI message
Note. Constructed for illustration. Patient identifiers, provider identifiers, insurance plan data, dates, and names are fictional.
MSH|^~&|PAYERSYS|BCBSIL|REFAPP|CITYMED|20260604083500||RPI^I01^RPI_I01|MSG00048|P|2.5.1
MSA|AA|MSG00047
PRD|RP|SMITH^CAROL^A^^^DR|123 MAIN ST^^CHICAGO^IL^60601^USA|||1234567890^NPI
PRD|RT|JONES^ROBERT^B^^^DR|456 OAK AVE^^CHICAGO^IL^60602^USA|||0987654321^NPI
PID|1||PAT98765^^^BCBSIL^MR||JOHNSON^MARY^E||19750315|F|||789 ELM ST^^CHICAGO^IL^60603
GT1|1||JOHNSON^MARY^E||789 ELM ST^^CHICAGO^IL^60603|3125550199||19750315|F
IN1|1|PPO001^BlueCross PPO^BCBS|BCBSIL|BlueCross BlueShield of Illinois||||||GRP12345|20260101|20261231|||JOHNSON^MARY^E|Self|19750315|789 ELM ST^^CHICAGO^IL^60603
IN2|1|SSN987654321|||||||||||||||||||||||||||||||GRP12345
IN3|1|CERT20260604^^^BCBSIL|20260604|20261231|||BCBSIL^BlueCross BlueShield of Illinois
What this sample shows
The RPI^I01 in MSH-9 marks a return of insurance information. The MSA segment carries acknowledgement code AA (Application Accept) and echoes the original RQI's message control id MSG00047 in MSA-2, confirming which request this response addresses. The first PRD carries role code RP (referring provider) and identifies Dr. Carol Smith with NPI 1234567890; the second PRD carries role code RT (referred-to provider) and identifies Dr. Robert Jones with NPI 0987654321. PID returns Mary Johnson's demographics with identifier PAT98765 as held by the responding system. GT1 confirms Mary Johnson as her own guarantor. The IN1 group returns her BlueCross PPO plan with group number GRP12345, active from 20260101 through 20261231. IN2 supplements with the subscriber's SSN. IN3 returns a pre-certification record CERT20260604 certified through 20261231 by BlueCross BlueShield of Illinois.
Working with RPI messages
Correlate the response to the request using MSA-2
When MSA is present, MSA-2 echoes the message control id of the originating RQI. Use this value — not MSH-10 of the RPI — to match the response to the open request in the requesting system's workflow. A missing or mismatched MSA-2 means the response cannot be correlated and the requesting system must treat the request as unanswered.
Check the acknowledgement code before processing the payload
MSA-1 carries the acknowledgement code. Process the patient and insurance payload only when MSA-1 is AA (Application Accept). An AE (Application Error) or AR (Application Reject) indicates the responding system could not fulfil the request; surface the error to the user rather than treating the response as a successful lookup with empty data.
Read PRD-1 to confirm provider roles
The PROVIDER group repeats, and PRD-1 in each PRD segment carries the role code. Confirm that the RP-role PRD matches the referring provider the requesting system sent and that the RT-role PRD matches the referred-to provider. A mismatch — for example, the responding system returning a different NPI in PRD-7 — may indicate a provider identity resolution issue that needs investigation before the referral proceeds.
Handle multiple insurance plans
The INSURANCE group repeats, so a patient with primary and secondary coverage produces two or more IN1 segments. Process each plan independently, preserving the coordination-of-benefits order in IN2. Discarding a secondary plan silently can cause downstream authorisation failures when the primary plan pays only a portion of the claim.
Vendor variance. The presence of
MSAvaries: some systems include it on every RPI, others omit it entirely and rely on the standard HL7 acknowledgement exchange to confirm receipt. Confirm a partner's acknowledgement behaviour against their interface specification rather than assuming the base standard.
FHIR equivalent
A return of patient information conceptually corresponds to a FHIR Patient resource for the demographic data and a Coverage resource for each insurance plan returned, with the coverage referencing the Patient as the beneficiary. For a messaging exchange, a MessageHeader would head a Bundle containing the Patient and Coverage resources.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RPI and no ConceptMap for the PRD provider data segment. A FHIR Patient and Coverage produced from an RPI message is therefore mapped manually, deriving the patient from PID, the primary coverage from the first IN1 group, and any additional coverages from subsequent IN1 groups, with pre-certification data from IN3 mapped to Coverage extension fields or a CoverageEligibilityResponse resource.
Common pitfalls
Pitfall. Processing the patient and insurance payload without first checking
MSA-1. AnAEorARacknowledgement code means the responding system returned an error, not data. Treating the absence ofIN1segments as "no coverage found" rather than as an error condition causes the requesting system to proceed with an incomplete record.
Pitfall. Using
MSH-10of the RPI as the correlation key. The RPI's own message control id identifies this message for deduplication purposes, but it does not link back to the RQI. UseMSA-2, which echoes the RQI's control id, to correlate the response to the open request.
Pitfall. Assuming the NPI is always in
PRD-7. Some senders populatePRD-7with internal identifiers and place the NPI in a different component or repetition. Validate the identifier type component withinPRD-7rather than assuming the first value is the NPI.
How Vorro handles RPI messages
Vorro receives RPI messages over MLLP or another transport, deduplicates on MSH-10, and correlates each response to its originating RQI using MSA-2. Vorro reads MSA-1 before processing the payload, routing error responses to an alert queue rather than to the downstream workflow. The RP- and RT-role PRD segments are parsed to confirm provider identity, the patient demographics are extracted from PID, and each IN1 group is processed independently to support multi-plan patients. Where a FHIR destination is configured, Vorro maps the response to Patient and Coverage resources — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message — and returns the result to the requesting system in the format it expects.
Related messages
- RQI — the Request for Patient Information message that an RPI responds to.
- REF — the patient referral message that initiates a clinical referral, for which an RQI/RPI exchange may be a precursor.
- RPA — the return of patient authorisation, which carries the authorisation decision following a referral request.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RPI
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PRD
- HL7 Messaging Standard Version 2.5.1 product brief
