HL7 RQI messages request patient information — most commonly insurance eligibility data — from another system as part of a patient referral workflow. An RQI message is sent by a referring provider's system to ask the receiving system to return patient or insurance details, and the expected reply is an RPI (Return Patient Information) message. This page explains what an RQI message represents, the trigger events that carry it, every segment the message can contain and what each one holds, and how an RQI request relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RQI message represents
An RQI message — RQI stands for Request for Patient Information — asks a receiving system to supply information about a patient, typically insurance eligibility or coverage data needed to complete a referral. The requesting system may not hold all the insurance or demographic details required to route and authorise the referral, so it sends an RQI to a system that does — a payer, a clearinghouse, or another provider system — and expects an RPI in return.
The core of the message is the PRD segment, which identifies the provider making the request and, in a repeating PROVIDER group, the provider being referred to. PRD-1 carries the provider role code — RP for referring provider and RT for referred-to provider — so the receiving system knows which party is asking and, where relevant, to whom the patient is being referred. The PID segment identifies the patient whose information is being requested, and the optional INSURANCE group carries whatever insurance detail the requesting system already holds, giving the receiver enough context to locate the right coverage record.
When an RQI message is sent
An RQI message is sent at the start of a referral workflow, before the referral is authorised or acted on, when the initiating system needs patient or insurance information it does not already hold. It is also used to request the display of a patient-selection list when the requesting system needs the receiving system to present matching patient records.
Trigger events
The RQI message type carries three trigger events:
RQI^I01— Request for insurance information. The requesting system asks for the patient's insurance eligibility or coverage data. This is the most common trigger in referral and pre-authorisation workflows.RQI^I02— Request/receipt of patient selection display list. The requesting system asks the receiving system to return a list of patients matching the query, intended for display so a user can select the correct record.RQI^I03— Request/receipt of patient selection list. Similar toI02, but the list is returned in a structured format for programmatic use rather than for display.
In each case the receiving system is expected to respond with an RPI message containing the requested information.
Integration topology
The diagram shows the referring provider's system sending an RQI request through the integration engine to the system that holds the patient or insurance data.
{{diagram: referring provider system → RQI message → integration engine → payer / clearinghouse / referred-to provider system → RPI response}}
Typical senders: referring provider's EHR, practice management system, or referral management application.
Typical receivers: payer eligibility system, clearinghouse, referred-to provider's EHR, or health information exchange.
Direction: request/response — the RQI message solicits data; the receiving system replies with an RPI.
Segments in an RQI message
The RQI message opens with MSH and optional acknowledgement and query segments, then carries a repeating PROVIDER group and the patient and insurance detail. The PROVIDER group — opening with PRD and optionally followed by CTD — repeats once per provider involved in the referral. The INSURANCE group is optional and repeating, accommodating patients with multiple coverages. 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 RQI message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RQI^I01, RQI^I02, or RQI^I03), 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 RQI is sent in response to an earlier request or as part of an acknowledgement exchange. Optional and repeating. |
[{QRD}] | Query Definition. Defines the query parameters — the query date/time, query format, priority, and the subject of the query (typically the patient). Optional and repeating; used when the request is framed as a query rather than a direct referral request. |
{PRD} | Provider Data. The key segment of the PROVIDER group and the most important segment in the message. 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, 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. |
[{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. Identifies the patient whose information is being requested — the identifier list in PID-3, the patient name in PID-5, date of birth in PID-7, and sex in PID-8. Required; the receiving system uses PID to locate the correct patient record. |
[{NK1}] | Next of Kin/Associated Parties. The patient's next of kin or associated persons. Optional and repeating; included when the requesting system holds this information and it is relevant to the referral. |
[{GT1}] | Guarantor. The financial guarantor for the patient's account. Optional and repeating; relevant when the referral or insurance request involves billing responsibility. |
[{IN1}] | Insurance. Opens the optional, repeating INSURANCE group. Carries the patient's insurance plan information — plan ID, company name, group number, and subscriber details — so the receiving system can locate or verify the coverage record. Optional and repeating to accommodate multiple insurance plans. |
[IN2] | Insurance Additional Information. Supplements IN1 with additional insurance data such as the subscriber's employer and the coordination of benefits order. Optional; present only when the INSURANCE group is present. |
[IN3] | Insurance Additional Information — Certification. Carries pre-certification and authorisation data for the insurance plan. Optional; present only when the INSURANCE group is present and certification data is available. |
[ ] = 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 RQI message
Note. Constructed for illustration. Patient identifiers, provider identifiers, insurance plan data, dates, and names are fictional.
MSH|^~&|REFAPP|CITYMED|PAYERSYS|BCBSIL|20260604083000||RQI^I01^RQI_I01|MSG00047|P|2.5.1
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^^^CITYMED^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
What this sample shows
The RQI^I01 in MSH-9 marks a request for insurance information. 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 identifies the patient as Mary Johnson with medical record number PAT98765. GT1 confirms Mary Johnson as her own guarantor, and the IN1 group carries her BlueCross PPO plan with group number GRP12345, coverage effective 20260101 through 20261231. The receiving system uses this context to locate and return the full eligibility record in an RPI response.
Working with RQI messages
Route on MSH-9 and read PRD-1 for provider roles
The trigger event in MSH-9 determines whether the request is for insurance information (I01), a display patient list (I02), or a structured patient list (I03). Within that, PRD-1 in each PRD segment determines which provider is the referring party (RP) and which is the referred-to party (RT). A receiving system should parse both PRD segments before processing the request, because the referring provider's identity is required for the response and for audit.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key. Referral workflows frequently involve retries — a network timeout or an acknowledgement failure can cause the same RQI to arrive more than once. Treating a repeated control id as a duplicate prevents the receiving system from issuing duplicate eligibility queries or logging duplicate referral events.
Use PID to anchor the patient lookup
The receiving system locates the patient record from PID. Use PID-3, the patient identifier list, as the primary lookup key, and fall back to demographic matching on name (PID-5), date of birth (PID-7), and sex (PID-8) when an identifier match fails. A patient not found should result in an RPI with an appropriate acknowledgement code rather than a silent failure.
Handle multiple insurance plans
The INSURANCE group repeats, so a patient with primary and secondary coverage produces two IN1 segments. Process each plan independently and return all active coverages in the RPI response — discarding secondary coverage silently can cause downstream authorisation failures.
Vendor variance. The
QRDquery definition segment is optional and its population varies widely between senders. Some systems use it to pass query parameters such as eligibility date; others omit it entirely and rely solely onPIDandIN1for the lookup. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A request for insurance information conceptually corresponds to the FHIR CoverageEligibilityRequest resource, directed at a payer or coverage source, with the patient as a Patient resource. A request for a patient selection list maps more loosely to a FHIR Patient lookup or search interaction.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RQI and no ConceptMap for the PRD provider data segment. A FHIR CoverageEligibilityRequest produced from an RQI message is therefore mapped manually, deriving the requesting provider from the RP-role PRD, the patient from PID, and the coverage detail from the IN1 group.
Common pitfalls
Pitfall. Processing only the first
PRDsegment and ignoring the second. A referral carries at least two provider segments — referring (RP) and referred-to (RT) — and the response must address both roles. Reading only the firstPRDloses the referred-to provider's identity, which may be required for routing the RPI response.
Pitfall. Treating a missing
IN1group as an error. The INSURANCE group is optional — anI01request may arrive with no insurance data when the requesting system has none to offer, asking the receiver to look up coverage from scratch using onlyPID. A missingIN1is a normal condition, not a malformed message.
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 RQI messages
Vorro receives RQI messages over MLLP or another transport, deduplicates on MSH-10, and routes each request to the appropriate destination based on the trigger event in MSH-9. For I01 insurance requests, Vorro parses the RP- and RT-role PRD segments to identify the referring and referred-to providers, extracts the patient from PID, and forwards the eligibility query to the correct payer or clearinghouse endpoint. Each IN1 group is processed independently to support multi-plan patients. Where a FHIR destination is configured, Vorro maps the request to a CoverageEligibilityRequest resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message — and correlates the RPI response back to the originating request.
Related messages
- RPI — the Return Patient Information message sent in response to an RQI request.
- REF — the patient referral message that initiates a clinical referral, of which an RQI 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 RQI
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for PRD
- HL7 Messaging Standard Version 2.5.1 product brief
