HL7 RQA_I08 (Request for Treatment Authorization) | Integration Soup HL7 Reference Guide

HL7 RQA_I08 Request for Treatment Authorization

A payer or authorization request wrapped in clinical and referral context.

HL7 message structure RQA_I08 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

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
RF1	Referral Information	No	No
RQA_I08.AUTHORIZATION	Authorization group	No	No
AUT	Authorization Information	Yes	No
CTD	Contact Data	No	No
RQA_I08.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
RQA_I08.GUARANTOR_INSURANCE	Guarantor Insurance group	No	No
GT1	Guarantor	No	Yes
RQA_I08.INSURANCE	Insurance group	Yes	Yes
IN1	Insurance	Yes	No
IN2	Insurance Additional Information	No	No
IN3	Insurance Additional Information, Certification	No	No
ACC	Accident	No	No
DG1	Diagnosis	No	Yes
DRG	Diagnosis Related Group	No	Yes
AL1	Patient Allergy Information	No	Yes
RQA_I08.PROCEDURE	Procedure group	No	Yes
PR1	Procedures	Yes	No
RQA_I08.AUTCTD_SUPPGRP2	Autctd Suppgrp2 group	No	No
AUT	Authorization Information	Yes	No
CTD	Contact Data	No	No
RQA_I08.OBSERVATION	Observation group	No	Yes
OBR	Observation Request	Yes	No
NTE	Notes and Comments	No	Yes
RQA_I08.RESULTS	Results group	No	Yes
OBX	Observation/Result	Yes	No
NTE	Notes and Comments	No	Yes
RQA_I08.VISIT	Visit group	No	No
PV1	Patient Visit	Yes	No
PV2	Patient Visit - Additional Information	No	No
NTE	Notes and Comments	No	Yes

RQA_I08 asks for treatment authorization information. In practical terms, the sender is trying to justify or request approval for a service, procedure, referral, admission, or treatment plan. The expected response is RPA_I08.

This message can carry a lot because authorization is not only a yes/no transaction. The receiver may need patient identity, insurance, providers, diagnosis, procedures, observations, visit context, and any existing authorization details before it can decide what to do.

A small RQA I08 example

MSH|^~\&|REFERRAL|CITYCLINIC|PAYERHUB|CITYCARE|20260718110000||RQA^I08^RQA_I08|RQA080001|P|2.5.1 RF1|A|R^Routine^HL70280|ORTHO^Orthopedic referral^L|20260718110000|20260801100000 AUT|1|PAYERHUB|CITYCARE|REQ20260718|20260718110000|MRI^MRI knee without contrast^L|PEND^Pending review^L CTD|PR|Auth^Ava|PO Box 77^^Auckland^^1140^NZ|^WPN^PH^^64^9^5557070 PRD|RP|Nguyen^Mara^^^Dr^MD|88 Clinic Road^^Auckland^^1010^NZ|^^^CITYCLINIC|555555 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F IN1|1|PLAN77|CITYCARE|CityCare Health Plan|PO Box 77^^Auckland^^1140^NZ|||||Smith^Jane^Anne|SEL DG1|1|I10|M25.561^Pain in right knee^I10|Pain in right knee|20260717103000|A PR1|1|CPT|73721^MRI lower extremity without contrast^CPT|MRI knee without contrast|20260801100000 OBR|1|IMG1001^REFERRAL||KNEE-MRI^Knee MRI authorization support^L|||20260717110000 OBX|1|TX|CLINHIST^Clinical history^L||Persistent knee pain after injury, conservative therapy attempted.||||||F PV1|1|O|ORTHO^CLINIC^1^CITYCLINIC NTE|1||Please review authorization before scheduled imaging.

What workflow it represents

The sender is often a provider, referral application, scheduling system, or authorization module. The receiver is commonly a payer, utilization management system, or authorization service that decides whether the requested service is approved, denied, pending, or needs more information.

Downstream workflows usually need both the decision and the reason. A pending response might hold scheduling. A denial might route to review. An approval might be stored with the referral or order so claims can later connect to the authorization number.

How to read the structure

MSH identifies the request. RF1 can frame the referral or authorization status. AUT and CTD carry authorization details and contacts.

The provider group uses PRD and CTD. PID, IN1, IN2, and IN3 identify the patient and coverage. Clinical support can include DG1, PR1, OBR, OBX, and visit context in PV1/PV2.

Implementation traps

The main trap is sending only the procedure code and expecting the receiver to infer medical necessity. Authorization workflows usually need diagnosis, service date, provider, coverage, and supporting notes or observations.

Another trap is mixing requested authorization with approved authorization. Use the response to carry the decision and identifiers the payer assigned; do not invent an approval number on the request side.

Reference notes

HL7 terminology identifies I08 as the RQA/RPA request for treatment authorization information. The v2.5.1 structure includes referral, authorization, provider, patient, insurance, diagnosis, procedure, observation, visit, and note content.