HL7 AUT Authorization Information
HL7 field reference AUT fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| AUT.1 | Authorizing Payor, Plan ID | No | No | CE | 0072 |
| AUT.2 | Authorizing Payor, Company ID | Yes | No | CE | 0285 |
| AUT.3 | Authorizing Payor, Company Name | No | No | ST | |
| AUT.4 | Authorization Effective Date | No | No | TS | |
| AUT.5 | Authorization Expiration Date | No | No | TS | |
| AUT.6 | Authorization Identifier | No | No | EI | |
| AUT.7 | Reimbursement Limit | No | No | CP | |
| AUT.8 | Requested Number of Treatments | No | No | NM | |
| AUT.9 | Authorized Number of Treatments | No | No | NM | |
| AUT.10 | Process Date | No | No | TS |
AUT is the HL7 Authorization Information segment. This segment represents an authorization or a pre-authorization for a referred procedure or requested service by the payor covering the patient's health care.
Patient administration segments often look optional until an ADT, referral, consent, or problem workflow needs one very specific detail to be carried safely.
The v2.5.1 structures show AUT in REF_I12 (Patient referral), RPA_I08 (Request for treatment authorization information), RQA_I08 (Request for treatment authorization information), RRI_I12 (Patient referral). That tells you where it can appear, but the local implementation guide still decides which optional fields are meaningful.
For patient-administration work, HL7 Soup Web is a simple way to inspect the message before a value reaches the wrong record, and Integration Soup is where I would make identifier mapping and routing decisions visible.
So this page stays intentionally practical: what each field is for, what shape the generated v2.5.1 data gives it, and where I would be careful before mapping it.
AUT-1 identifies the payor plan, AUT-2 identifies the payor company, and AUT-3 carries the payor company name. Keep plan and company separate. A commercial insurer, a specific plan, and the display name printed on a letter are not the same thing.
AUT-2 is required in the base v2.5.1 segment, so do not rely on the company name alone. If the receiver uses plan and company IDs for eligibility, authorization matching, or claim routing, preserve the code system and local mapping exactly.
AUT-4 and AUT-5 are the effective and expiration dates of the authorization itself. They are not appointment dates and they are not a promise that scheduling has happened. HL7's referral chapter is explicit about that separation: authorization can be obtained before scheduling is handled elsewhere.
Use the precision supplied by the payor. If authorization expires at the end of a date, at a timestamp, or after a timezone-specific business day, the interface agreement needs to say so.
AUT-6 is the payor or coverage application's authorization tracking identifier. It is often absent when authorization is being requested and present when the payor has responded with an authorization decision.
Treat this like a real business key. It may be needed later for referral messages, claim follow-up, cancellation, or modification. Do not strip off the assigning authority if multiple payors or authorization systems can issue similar-looking numbers.
AUT-7 carries the authorized reimbursement limit, using the CP price datatype. That means currency, amount, and price details matter. A naked number is not enough when the receiver has to decide whether the value is dollars, local currency, a cap, or a per-treatment amount.
AUT-8 is what was requested. AUT-9 is what the payor authorized. They are deliberately separate because the payor may approve fewer visits, sessions, procedures, or treatments than the placer requested.
Make sure the unit of "treatment" is defined by the procedure, referral, or local profile. Ten physiotherapy sessions and ten treatment days are not interchangeable just because both are numeric.
AUT-10 is when the authorization was processed by the payor or authorization system. It is useful for audit and reconciliation, especially when the response arrives later than the original request.
Do not confuse it with the effective date in AUT-4. A request can be processed today, effective next week, and expire months later.
Related links
- PID - Patient Identification
- PD1 - Patient Additional Demographic
- PV1 - Patient Visit
- PV2 - Patient Visit - Additional Information
- MRG - Merge Patient Information
- PRB - Problem Details
- GOL - Goal Detail
- ROL - Role
- REF_I12 - Patient referral
- RPA_I08 - Request for treatment authorization information
- RQA_I08 - Request for treatment authorization information