HL7 RQI_I01 Request for Insurance Information

A provider-to-provider request for a patient's coverage details.
HL7 message structure RQI_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
RQI_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
RQI_I01.GUARANTOR_INSURANCE
 Guarantor Insurance group No No
GT1
 Guarantor No Yes
RQI_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

RQI_I01 is used when one healthcare provider asks another party for insurance information about a specified patient. In the older patient referral family, the requester sends the question as RQI and expects the application-level answer as RPI_I01.

This is not a general eligibility API in disguise. It is a structured HL7 v2 request that carries who is asking, which patient is involved, and which insurance or guarantor context the receiver should confirm.

A small RQI I01 example

MSH|^~\&|REFERRAL|CITYCLINIC|PAYERHUB|CITYHOSP|20260718100000||RQI^I01^RQI_I01|RQI010001|P|2.5.1 PRD|RP|Nguyen^Mara^^^Dr^MD|88 Clinic Road^^Auckland^^1010^NZ|^^^CITYCLINIC|555555 CTD|PR|Care^Cara|88 Clinic Road^^Auckland^^1010^NZ|^WPN^PH^^64^9^5551000 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 NTE|1||Please confirm active coverage and subscriber details.

What workflow it represents

The sender is usually a provider application, referral system, practice-management system, or integration engine acting on behalf of a provider. The receiver is the party believed to hold the insurance data: another provider, a payer-adjacent service, or an organization that already has the patient's coverage on file.

Downstream systems use the response to decide whether registration, referral, billing, or authorization work can proceed. A missing or stale insurance answer can send people back to manual phone calls, which is why the patient and requester identity should be unambiguous.

How to read the structure

MSH identifies the request. The required provider group starts with PRD and can repeat when more than one provider role is relevant. CTD adds contact details for the provider or organization.

PID identifies the patient. NK1, GT1, and the insurance group with IN1, IN2, and IN3 give the receiver enough context to locate or verify coverage. NTE is useful for a short human note, but it should not carry data that really belongs in insurance fields.

Implementation traps

The easy mistake is sending only a patient name and hoping the receiver can find the right person. Use trusted identifiers in PID-3 when you have them, and keep assigning authorities with the identifiers.

Also be clear about whether you are asking for current coverage, historical coverage for a date of service, subscriber details, guarantor data, or certification information. Those are different questions, and a vague RQI tends to produce a vague RPI.

Reference notes

The HL7 v2+ patient referral material describes I01 as a request for insurance information for a specified patient, sent from one healthcare provider to another. The message structure includes MSH, provider data, PID, optional next-of-kin and guarantor/insurance groups, and notes.