HL7 RPA messages return a payer's authorization decision — the response that tells a requesting provider whether a proposed treatment is authorized, for how many units, and for what period. An RPA message is the answer to an RQA request for treatment authorization: the payer or utilization-management system receives the request, makes its determination, and returns it in an RPA. This page explains what an RPA message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RPA authorization response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RPA message represents
An RPA message — RPA stands for Return Patient Authorization — communicates a payer's authorization decision for a requested treatment. The core of the message is the AUT segment, which carries the authorization data itself: the authorizing payer and plan, the authorization number, the effective and expiration dates, the number of authorized treatments or units, and the authorization status. The RPA is structured as a response — it acknowledges the originating request and then returns the determination the payer reached against it.
The sender is the payer or utilization-management system, and the receiver is the provider system that asked for authorization. RPA sits one step downstream of the request: an RQA request for treatment authorization tells the payer what treatment is proposed, and the RPA message returns whether — and on what terms — it is authorized. Because the authorization is what gates payment and scheduling, the AUT — not the original request — is the authoritative record of what the payer actually approved.
When an RPA message is sent
An RPA message is sent when a payer has reached a determination on a treatment-authorization request. The same message structure carries the response across the authorization lifecycle, not just the initial grant, so a provider can receive a sequence of RPA messages for one authorization as it is modified, resubmitted, or cancelled.
Trigger event
The RPA message type carries a family of trigger events that all share this structure:
RPA^I08– Request for treatment authorization (the response returning the decision).RPA^I09– Request for modification to an authorization.RPA^I10– Request for resubmission of an authorization.RPA^I11– Request for cancellation of an authorization.
Because these trigger events share one message structure, the receiver's handling turns on the contents of AUT — the authorization number, the status, the authorized units, and the effective dates — together with the trigger code in MSH-9 that names which point in the authorization lifecycle the response addresses.
Integration topology
The diagram shows the payer system emitting an authorization decision through the integration engine to the provider systems that scheduled and submitted the request.
{{diagram: payer / utilization-management system → RPA message → integration engine → provider / referral management / scheduling / billing}}
Typical senders: payer authorization system, utilization-management platform, third-party benefit administrator.
Typical receivers: provider referral-management application, scheduling, and billing / charge capture.
Direction: response from the payer back to the provider system that issued the originating RQA request.
Segments in an RPA message
The RPA_I08 message opens with the header and acknowledgement, then carries one or more PROVIDER groups, each opening with PRD and carrying the patient, guarantor, insurance, diagnosis, and one or more PROCEDURE groups that end with the authorization. Within a procedure the AUT segment carries the decision. 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 RPA message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RPA^I08 and its I09/I10/I11 siblings), 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 Acknowledgment. Acknowledges the originating RQA request — the acknowledgment code in MSA-1 and the control id of the request being answered in MSA-2. Optional and repeating, this is what ties the returned authorization back to the request that asked for it. |
[{ERR}] | Error. Reports any error against the request being answered — the error location and code. Optional and repeating; present when the request could not be processed as submitted. |
[{QRD}] | Query Definition. Echoes the query that drove the request when the exchange was query-based — the query date, format, and what was asked for. Optional and repeating, with the optional QRF filter below. |
[QRF] | Query Filter. Refines the QRD query with date ranges and other filter criteria. Present only when a QRD precedes it. |
PRD | Provider Data. Opens each provider group and identifies a provider involved in the authorization — the provider role in PRD-1 (RP referring provider, RT referred-to provider, PP primary care provider), the name in PRD-2, and the identifier in PRD-7. Required, and the provider group repeats once per provider on the authorization. |
[{CTD}] | Contact Data. Contact details for the provider in the group — contact role, name, address, and communication numbers. Optional and repeating. |
PID | Patient Identification. Identifies the patient the authorization is for — the identifier list in PID-3, the name in PID-5. Required within the provider group. |
[{NK1}] | Next of Kin / Associated Parties. The patient's next of kin or associated parties relevant to the authorization. Optional and repeating. |
[GT1] | Guarantor. The party financially responsible for the treatment — name, address, and relationship to the patient. Optional. |
[{IN1}] | Insurance. Opens the optional, repeating INSURANCE group and carries the coverage the authorization is sought under — plan id, company, group number, and the insured's relationship to the patient. |
[IN2] | Insurance Additional Information. Supplements IN1 with employment, eligibility, and additional insured data. Present only within an INSURANCE group. |
[IN3] | Insurance Additional Information, Certification. Certification and pre-authorization detail for the coverage — certification number, agency, and dates. Present only within an INSURANCE group. |
[ACC] | Accident. Accident detail when the treatment relates to an accident — accident date, code, and location. Optional. |
[{DG1}] | Diagnosis. The diagnoses supporting the authorization — diagnosis code, description, and type. Optional and repeating. |
[{DRG}] | Diagnosis Related Group. The DRG assigned for the encounter, when grouping applies. Optional and repeating. |
[{AL1}] | Allergy Information. Patient allergies carried with the authorization. Optional and repeating. |
[{PR1}] | Procedures. Opens each procedure group and identifies the procedure being authorized — procedure code, description, and date. Optional and repeating; the procedure group repeats once per authorized procedure. |
[{ROL}] | Role. The role of a person against the procedure — provider, performer, and the period of the role. Optional and repeating within the procedure. |
[{OBX}] | Observation/Result. Clinical observations supporting the authorization — value type, identifier, and result. Optional and repeating. |
[{NTE}] | Notes and Comments. Notes relative to the observation or the procedure. Optional and repeating. |
AUT | Authorization Information. The core of the message and the segment carrying the decision. It records the authorization as the payer determined it: the authorizing payer plan id in AUT-1, the authorizing payer company name in AUT-3, the authorization effective date in AUT-6, the authorization number in AUT-7, the number of authorized treatments or units in AUT-8, and the authorization status in AUT-10. |
[CTD] | Contact Data. Contact details associated with the authorization in AUT. Optional, following the authorization. |
[ ] = optional, { } = repeating
The provider group from PRD onward repeats once per provider, and within it the procedure group repeats once per authorized procedure, so a single RPA message can return authorizations for several procedures across several providers. The canonical segment pages carry the full field-by-field detail.
Sample RPA message
Note. Constructed for illustration. Patient identifiers, authorization numbers, dates, and names are fictional.
MSH|^~&|PAYER|BLUECROSS|REFMGMT|MERCYGEN|202006040900||RPA^I08^RPA_I08|MSG00045|P|2.5.1
MSA|AA|REQ00031
PRD|RP|SMITH^JANE^M^^^^MD|123 MAIN ST^^METROPOLIS^IL^60601||||NPI1234567^^^NPI
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
IN1|1|PLAN789^Preferred PPO|BC001^Blue Cross|Blue Cross PPO||||GRP456
DG1|1||M54.5^Low back pain^I10|||F
PR1|1||72148^MRI lumbar spine without contrast^C4|202006100800
AUT|PLAN789^Preferred PPO|BC001|Blue Cross|202006040000|202007040000|AUTH998877|2||AP
What this sample shows
The RPA^I08 in MSH-9 marks a returned treatment authorization. MSA acknowledges the originating request with AA and the request control id REQ00031, tying the response back to the RQA that asked for it. PRD carries the referring provider (role RP), PID carries the medical record number MR12345, IN1 names the coverage, and PR1 names the procedure being authorized (an MRI of the lumbar spine). The AUT returns the decision: authorizing plan PLAN789 and company Blue Cross, effective 202006040000, authorization number AUTH998877 (AUT-7), 2 authorized treatments (AUT-8), with an authorization status of AP — approved (AUT-10).
Working with RPA messages
Read the decision from AUT, not the request
The authorization terms live in AUT, not in the echoed request. AUT records what the payer actually approved on this determination — the authorization number, the authorized units, the effective and expiration window, and the status. A partial approval shows up as an AUT-8 smaller than the units requested. Act on AUT rather than assuming the payer approved the request as submitted.
Match the response to its request
Use MSA to correlate the RPA back to the RQA that prompted it — MSA-2 carries the control id of the request being answered, and MSA-1 carries the acknowledgment code. Pair this with the authorization number in AUT-7 as the durable business key, so later modify, resubmit, and cancel responses for the same authorization can be threaded together.
Authorization status and the lifecycle
AUT-10 records the authorization status, and the trigger event in MSH-9 names which point in the lifecycle the response addresses — I08 the initial decision, I09 a modification, I10 a resubmission, I11 a cancellation. Surface the status and effective dates on the referral record rather than treating every RPA as a fresh grant; a cancellation or a modified unit count changes what the provider may schedule and bill.
Effective and expiration dates
AUT-6 carries the authorization effective date and the companion expiration date bounds the window in which the authorized treatment must occur. Track both, because an authorization that has lapsed no longer gates payment even though the authorization number is unchanged.
Vendor variance. The INSURANCE group (
IN1and its companions) and the supporting clinical segments are optional, so some payer systems return the full coverage and diagnosis context on every RPA while others return only the provider, patient, and authorization. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
An authorization response corresponds conceptually to the FHIR CoverageEligibilityResponse or ClaimResponse resource (in its preauthorization role), with 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 RPA_I08 and no ConceptMap for the AUT authorization segment. A FHIR CoverageEligibilityResponse or ClaimResponse produced from an RPA message is therefore mapped manually, taking the authorization number, authorized units, effective dates, and status from AUT, the coverage from the INSURANCE group, and the procedure from PR1, and referencing the originating request derived from the RQA.
Common pitfalls
Pitfall. Recording or billing from the requested units instead of the authorized units. What the provider may deliver follows
AUT-8, the number of authorized treatments, not the quantity in the request; reading the request overcounts a partial approval.
Pitfall. Treating every RPA as an approval. Ignoring
AUT-10, the authorization status, lets a denial or a pended determination flow through as if it were a grant — read the status, not just the presence of an authorization number.
Pitfall. Assuming a fixed date-time precision. Some senders stamp the dates in
AUTasYYYYMMDDand others as a full timestamp with an offset; do not assume a timezone — normalize on ingest.
How Vorro handles RPA messages
Vorro ingests the RPA feed over MLLP or another transport, deduplicates on MSH-10, and routes each authorization to every subscribed destination in the format that system expects — referral management, scheduling, and billing. Vorro reads the authorization number, authorized units, effective dates, and status from AUT, links each response back to its request through the acknowledged control id in MSA, and, where a FHIR destination is configured, maps the decision to a CoverageEligibilityResponse or ClaimResponse resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- RQA — the request for treatment authorization that an RPA message responds to.
- REF — the patient referral message that carries the same provider, patient, and insurance structure.
- RQI — the request for insurance information that opens the patient-referral exchange.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RPA_I08
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for AUT
- HL7 Messaging Standard Version 2.5.1 product brief
