HL7 RQA messages request, modify, resubmit, or cancel a payer authorization for treatment — the prior authorization exchange that sits between a referring or treating provider and the insurer before a procedure, specialist visit, or other covered service can proceed. An RQA message is sent from the provider side to the payer or authorization clearinghouse, and the payer replies with an RPA response that carries the authorization decision. This page explains what an RQA message represents, the four trigger events it carries, every segment the message can contain and what each one holds, and how an RQA request relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RQA message represents
An RQA message — RQA stands for Request for Treatment Authorization Information — communicates a provider's request to a payer for authorization to deliver a specific treatment or service to a patient. The core of the message is the AUT segment, which carries the authorization details: the authorizing payer plan and company, the authorization number once assigned, the number of requested treatments, the authorization status, and the requested effective date. Every other clinical and demographic segment in the message exists to give the payer the context it needs to evaluate and respond to that authorization request.
The sender is typically a physician office system, EHR, or referral management platform, and the receiver is the payer's authorization system or a clearinghouse intermediary. RQA sits at the gateway between clinical decision-making and payer approval: it transmits the patient context, the insurer's identity, the treating and referring providers, and the diagnosis and procedure information that together constitute a prior authorization request.
When an RQA message is sent
An RQA message is sent whenever a provider initiates or manages a treatment authorization with a payer. The initial request carries the full patient, insurance, diagnosis, and procedure context. Subsequent messages modify, resubmit, or cancel an authorization already on file, and each carries the existing authorization number in AUT so the payer can locate the original record.
Trigger events
The RQA message type carries four trigger events:
RQA^I08— Request for treatment authorization. The initial request for a new authorization.RQA^I09— Request for modification of an authorization. Updates or amends an existing authorization.RQA^I10— Request for resubmission of an authorization. Resubmits a previously denied or expired authorization.RQA^I11— Request for cancellation of an authorization. Cancels an authorization that is no longer needed.
The trigger code in MSH-9 drives receiver routing: an I08 initiates a new authorization workflow, while I09, I10, and I11 reference an authorization already identified by number in AUT-7.
Integration topology
The diagram shows the provider system emitting an authorization request through the integration engine to the payer authorization system, which replies with an RPA message.
{{diagram: provider system → RQA message → integration engine → payer authorization system → RPA response}}
Typical senders: physician office system, EHR referral module, referral management platform, clearinghouse.
Typical receivers: payer authorization system, utilization management platform, clearinghouse intermediary.
Direction: request-response — the provider sends RQA and the payer replies with an RPA carrying the authorization decision.
Segments in an RQA message
The RQA_I08 message is organised into functional groups. An optional MSA acknowledgment echoes a prior response. An optional QRD query definition carries query parameters for authorization lookups. A repeating PROVIDER group opens with PRD (role, name, address, identifier) and optional CTD contact data. After the providers come the patient demographics and clinical context: PID, optional next-of-kin and guarantor segments, a repeating INSURANCE group, and optional accident, diagnosis, DRG, allergy, procedure, observation, and note segments. The message closes with the AUT authorization segment and an optional trailing PRD. 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 RQA message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RQA^I08, RQA^I09, RQA^I10, or RQA^I11), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 to determine whether this is a new, modified, resubmitted, or cancelled authorization. |
[{MSA}] | Message Acknowledgment. When the RQA is sent in response to a prior interchange, the MSA echoes the original message control id and carries an acknowledgment code. Optional and repeating. |
[{QRD}] | Query Definition. Carries query parameters when the RQA is structured as an authorization inquiry. Optional and repeating. |
{PRD} | Provider Data. Opens each iteration of the PROVIDER group. Carries provider role (RP for referring provider, RT for referred-to provider, PP for primary care provider), provider name, address, and identifier. The PROVIDER group repeats to accommodate all providers involved in the authorization — the referring, treating, and primary care providers each appear in their own iteration. |
[{CTD}] | Contact Data. Supplements the preceding PRD with contact persons, phone numbers, and communication addresses for the provider. Optional and repeating within the PROVIDER group. |
PID | Patient Identification. Identifies the patient for whom authorization is requested — the identifier list in PID-3, the name in PID-5, date of birth in PID-7, and sex in PID-8. Required for the payer to match the patient to a member record. |
[{NK1}] | Next of Kin / Associated Parties. Carries next-of-kin relationships relevant to the authorization. Optional and repeating. |
[{GT1}] | Guarantor. Identifies the financial guarantor for the patient when relevant to the authorization. Optional and repeating. |
[{IN1}] | Insurance. Opens each iteration of the INSURANCE group. Carries the insurance plan ID, company name, group number, and member ID that identify the coverage under which authorization is requested. Required when insurance information is present; the INSURANCE group repeats for multiple coverages. |
[IN2] | Insurance Additional Information. Supplements IN1 with additional insurance detail such as coordination of benefits, employment, and COBRA status. Optional within the INSURANCE group. |
[IN3] | Insurance Additional Information — Certification. Carries certification and pre-authorization detail already held by the insurer, including the certifying entity and the certified dates. Optional within the INSURANCE group. |
[ACC] | Accident. Carries accident date, location, and type when the authorization relates to an accident-related service. Optional. |
[{DG1}] | Diagnosis. The diagnosis codes (ICD) supporting the medical necessity of the requested treatment. Optional and repeating — a request may carry multiple diagnoses. |
[{DRG}] | Diagnosis Related Group. The DRG assignment when relevant to the authorization. Optional and repeating. |
[{AL1}] | Allergy Information. Patient allergies relevant to the treatment being authorized. Optional and repeating. |
[{PR1}] | Procedures. Opens each iteration of the PROCEDURE group. Carries the procedure code (CPT, ICD-PCS) and description for the treatment being requested. Optional and repeating — a single authorization request may cover multiple procedures. |
[{ROL}] | Role. Associates a provider role with the preceding procedure, identifying the performing provider for that specific procedure. Optional and repeating within the PROCEDURE group. |
[{OBX}] | Observation/Result. Clinical observations supporting the authorization request — clinical notes, lab values, or other evidence of medical necessity. Optional and repeating. |
[{NTE}] | Notes and Comments. Free-text narrative notes accompanying the authorization request. Optional and repeating. |
[AUT] | Authorization Information. The key segment of the RQA message. Carries AUT-1 authorizing payer plan ID, AUT-2 authorizing payer company ID, AUT-3 authorizing payer company name, AUT-7 authorization number (assigned on prior authorizations; blank on initial requests), AUT-8 requested number of treatments, AUT-10 authorization status, and AUT-11 requested effective date. Together these fields define what is being requested, from whom, and for how long. Optional at the segment level — present in virtually all RQA messages but technically omittable in pure inquiry exchanges. |
[PRD] | Provider Data (trailing). A trailing provider segment after AUT, used to carry the provider who is the intended recipient of the authorization response. Optional. |
[ ] = optional, { } = repeating
The PROVIDER group from PRD through CTD repeats once per involved provider, and the PROCEDURE group from PR1 through ROL repeats once per requested procedure, so a single RQA message can carry a multi-provider, multi-procedure authorization request. The canonical segment pages carry the full field-by-field detail.
Sample RQA message
Note. Constructed for illustration. Patient identifiers, authorization numbers, dates, and names are fictional.
MSH|^~&|REFMGMT|WESTCLINIC|PAYERAUTH|BLUESHIELD|20260604083000||RQA^I08^RQA_I08|MSG00451|P|2.5.1
PRD|RP|SMITH^ROBERT^A^^^DR|123 WEST CLINIC DR^^BOSTON^MA^02101^USA|||1234567890^NPI
PRD|RT|JONES^PATRICIA^B^^^DR|456 SPECIALIST AVE^^BOSTON^MA^02102^USA|||0987654321^NPI
PID|1||MRN88421^^^WESTCLINIC^MR||JOHNSON^MARY^E||19720315|F|||789 PATIENT ST^^BOSTON^MA^02103
IN1|1|BSBS-HMO-100|BLUESHIELD|Blue Shield of Massachusetts||||||GRP998877||20260101|20261231|||JOHNSON^MARY^E|SELF|19720315|789 PATIENT ST^^BOSTON^MA^02103||||||||||||||||MEM112233
DG1|1||M54.5^Low back pain^ICD10|||W
PR1|1||27096^Injection, sacroiliac joint^CPT|Sacroiliac joint injection|20260610
OBX|1|ST|59408-5^Oxygen saturation^LN||98|%|95-100||||F
NTE|1||Patient has failed 6 weeks of conservative therapy including physical therapy and NSAIDs.
AUT|BSBS-HMO-100^Blue Shield HMO 100|BLUESHIELD^Blue Shield of Massachusetts|||||||1|20260610|20261210||PA-PENDING
What this sample shows
The RQA^I08 in MSH-9 marks an initial request for treatment authorization. The first PRD carries the referring provider (role RP) Dr. Robert Smith at West Clinic, and the second carries the referred-to specialist (role RT) Dr. Patricia Jones. PID identifies the patient Mary Johnson with medical record number MRN88421. IN1 carries the Blue Shield HMO 100 plan with group GRP998877 and member ID MEM112233. DG1 carries the ICD-10 code M54.5 (low back pain), and PR1 requests CPT 27096, a sacroiliac joint injection, to be performed on 20260610. The OBX carries a supporting clinical observation, and the NTE provides the free-text medical necessity narrative. The AUT segment closes the message: AUT-1 names the payer plan (BSBS-HMO-100), AUT-2 the payer company (BLUESHIELD), AUT-8 requests one treatment, AUT-11 sets the requested effective date to 20260610, and AUT-10 shows PA-PENDING as the current authorization status.
Working with RQA messages
Route on the trigger event, act on AUT
The four trigger codes (I08–I11) drive routing: an I08 opens a new authorization workflow while I09, I10, and I11 reference an existing one. After routing, read AUT-7 for the authorization number on modification, resubmission, and cancellation requests — this is the key that links the RQA to its original authorization record and to the corresponding RPA response.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the authorization number in AUT-7 together with the trigger event and the payer identifiers in AUT-2 as the natural business key for an authorization transaction. Authorization feeds are replayed after outages; a repeated control id must be treated as a duplicate to prevent submitting a second authorization request to the payer.
Map all providers and their roles
The PROVIDER group repeats, and each PRD carries a role code that distinguishes the referring provider (RP), the referred-to or treating provider (RT), and the primary care provider (PP). Payers often require all three to appear and reject requests that omit the primary care provider. Validate that the expected role codes are present and that each provider's NPI is populated before forwarding to the payer.
Diagnosis and procedure alignment
Payers match the diagnosis codes in DG1 against the procedures in PR1 to assess medical necessity. A procedure code without a supporting diagnosis, or a diagnosis that does not align with the procedure in the payer's coverage policy, is a common cause of authorization denial. Validate the DG1–PR1 pairing before transmission rather than relying on the payer to surface the mismatch in the RPA response.
Vendor variance. The
QRDquery definition segment and the trailingPRDafterAUTare included only when the sending system uses them; many implementations omit both. TheMSAacknowledgment loop at the top of the message is likewise implementation-specific. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A treatment authorization request corresponds conceptually to two FHIR resources depending on the use case: CoverageEligibilityRequest for eligibility-oriented prior authorization inquiries, and Claim (with use set to preauthorization) for the formal preauthorization submission. Either resource would reference the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RQA_I08 and no ConceptMap for the AUT authorization segment — the referral and authorization message family (I01–I15) is absent from the published v2-to-FHIR mapping work. A FHIR CoverageEligibilityRequest or Claim (preauthorization) produced from an RQA message is therefore mapped manually, taking the payer, plan, and authorization details from AUT, the coverage details from IN1, and the diagnosis and procedure information from DG1 and PR1.
Common pitfalls
Pitfall. Sending a modification or cancellation (
I09,I10,I11) without populatingAUT-7with the existing authorization number. The payer cannot locate the authorization to modify or cancel without the number assigned on the original approval; the request will be rejected or processed as a duplicate new request.
Pitfall. Omitting the primary care provider (
PP) role from the PROVIDER group. Many payer systems require the primary care provider to appear in a dedicatedPRDiteration for gatekeeper-model plans; its absence is a common cause of silent rejection at the payer's intake layer.
Pitfall. Mismatching diagnosis and procedure codes. A procedure code in
PR1that does not align with the diagnoses inDG1under the payer's medical necessity policy will result in denial. Validate DG1–PR1 pairing before transmission.
How Vorro handles RQA messages
Vorro ingests the RQA feed over MLLP or another transport, deduplicates on MSH-10, and routes each authorization transaction to the correct payer endpoint based on the payer identifiers in AUT-2 and the coverage data in IN1. Vorro reads the trigger event from MSH-9 to distinguish new requests from modifications, resubmissions, and cancellations, links each transaction to its existing authorization record through AUT-7, and validates the provider role codes in PRD and the DG1–PR1 alignment before forwarding to the payer. Where a FHIR destination is configured, Vorro maps the request to a CoverageEligibilityRequest or Claim (preauthorization) resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message family.
Related messages
- RPA — the payer's response to an RQA authorization request, carrying the authorization decision.
- RQI — the request for insurance information message, which requests patient insurance details from a payer.
- REF — the patient referral message, which initiates the referral workflow that often precedes an RQA authorization request.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RQA_I08
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for AUT
- HL7 Messaging Standard Version 2.5.1 product brief
