HL7 RPI_I01 Return Insurance Information

The insurance answer that comes back after an RQI_I01 request.
HL7 message structure RPI_I01 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

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
MSA
 Message Acknowledgment Yes No
RPI_I01.PROVIDER
 Provider group Yes Yes
PRD
 Provider Data Yes No
CTD
 Contact Data No Yes
PID
 Patient Identification Yes No
NK1
 Next of Kin / Associated Parties No Yes
RPI_I01.GUARANTOR_INSURANCE
 Guarantor Insurance group No No
GT1
 Guarantor No Yes
RPI_I01.INSURANCE
 Insurance group Yes Yes
IN1
 Insurance Yes No
IN2
 Insurance Additional Information No No
IN3
 Insurance Additional Information, Certification No No
NTE
 Notes and Comments No Yes

RPI_I01 is the application response to an RQI_I01 insurance request. It returns the receiver's answer with acknowledgment context, provider details, patient identity, and the guarantor or insurance information that the requester asked for.

In real interfaces, this message is only useful when the requester can tell which request it answers and how confident the receiver is about the returned coverage. That means MSA, patient identifiers, insurance identifiers, and notes all matter.

A small RPI I01 example

MSH|^~\&|PAYERHUB|CITYHOSP|REFERRAL|CITYCLINIC|20260718100003||RPI^I01^RPI_I01|RPI010001|P|2.5.1 MSA|AA|RQI010001 PRD|RT|CityCare^Eligibility^^^Dept|PO Box 77^^Auckland^^1140^NZ|^^^PAYERHUB|CITYCARE CTD|PR|Eligibility^Team|PO Box 77^^Auckland^^1140^NZ|^WPN^PH^^64^9^5557070 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F GT1|1|G123|Smith^Jane^Anne||12 High Street^^Auckland^^1010^NZ|^PRN^CP^^64^21^5551234 IN1|1|PLAN77|CITYCARE|CityCare Health Plan|PO Box 77^^Auckland^^1140^NZ|||||Smith^Jane^Anne|SEL|||||20260101|20261231 IN2|1||EMP7788 IN3|1|AUTH20260718|ACTIVE^Active coverage^L NTE|1||Coverage active for requested patient as of 20260718.

What systems do with it

The receiver sends RPI_I01 after matching the patient and insurance context from the original request. The requester may update a referral record, registration worklist, claim-prep workflow, or manual follow-up queue.

MSA-2 should point back to the original message control ID. If the receiver could parse the request but could not find coverage, say that clearly in the returned insurance data or notes instead of sending a technically successful but empty message.

How to read the structure

MSH and MSA frame the response. The provider group identifies the responding party in PRD and optional CTD. PID still matters because the receiver may normalize or enrich the patient identity.

The optional guarantor/insurance group carries GT1 and one or more insurance groups. IN1 is the core plan/subscriber segment; IN2 adds more subscriber or employer detail; IN3 carries certification-style details when the workflow needs them.

Implementation traps

Do not treat MSA-1 AA as "coverage is approved." It only says the request message was accepted. The actual coverage answer lives in the insurance content and any local status fields or notes.

Another common trap is losing date context. Coverage can be active today and not active for the requested service date. If the request was about a date of service, make that date visible in the request and preserve the effective dates in the response.

Reference notes

The HL7 v2+ I01 material describes the RQI/RPI pair for provider-to-provider insurance information requests. RPI_I01 adds MSA to the request-like structure so the receiver can return an application answer tied to the original RQI.