HL7 AUI Data Type: Authorization Information

The AUI (Authorization Information) data type was introduced in HL7 v2.3 to carry an insurance pre-authorization reference inside an insurance segment. It is a small three-component composite — authorization number, date the authorization was granted, and the source that issued it — designed for the single high-traffic field IN1-14 Authorization Information. Despite its small size, AUI is one of the most operationally important data types in HL7 v2 billing flows: claims submitted without a valid pre-authorization number against services that required one are rejected by payers.

Purpose

AUI exists so that the pre-authorization reference travels with the insurance policy data on every order, encounter, or claim message. The payer's adjudication engine matches the authorization number (AUI.1) against its authorization-management system; the date (AUI.2) confirms the authorization is in force at the time of service; the source (AUI.3) names the payer department or system that issued it. Without all three, the authorization is effectively unverifiable, and many payer interfaces will reject the message.

Components

Source: HAPI HL7v2 v2.8.1 javadoc (AUI). Length is not published in v2.8.1 javadocs (—).

Comp	Name	Sub-type	Length	Req	Description
AUI.1	Authorization Number	st	—	R	The payer-issued pre-authorization reference. Payer-specific format — alphanumeric, typically 8–20 characters.
AUI.2	Date	dt	—	O	Date the authorization was issued (DT, YYYYMMDD). Often required by payer-side validation even when the v2.x spec marks it optional.
AUI.3	Source	st	—	O	Free-text identifier of the issuing source (payer name, department, or system that granted the authorization).

Most-used components

AUI.1 Authorization Number — the only structurally required component and the load-bearing field. Almost every payer rejects claims when this is empty against authorization-required services.
AUI.2 Date — date the authorization was issued. Many payers compute the authorization window relative to this date and reject claims for services rendered before it.
AUI.3 Source — free-text source. Useful for human-readable trace but rarely parsed by adjudication engines.

Where it's used

IN1-14 Authorization Information — the canonical home of AUI, present on every ADT, ORM, DFT, and BAR message that carries IN1.

The field is not repeating in IN1-14: one authorization per insurance line. Patients with multiple pre-authorizations across different policies carry one IN1/AUI pair per policy.

Version differences

v2.3 — AUI introduced as a three-component composite specifically for IN1-14. Earlier versions used a flat ST field for the authorization number, with no place for date or source.
v2.4 — minor documentation cleanup; no structural change.
v2.5–v2.6 — no structural changes.
v2.7 — no structural changes; some realm profiles began mandating AUI.2 even though the v2.x spec keeps it optional.
v2.8 / v2.8.1 — no structural changes; HAPI v2.8.1 javadoc shows the same 3 components.

Common mistakes

Packing payer name and authorization number together in AUI.1. Some senders emit Anthem AUTH-99812 in AUI.1 with AUI.3 empty. The correct form puts AUTH-99812 in AUI.1 and Anthem (or the specific department) in AUI.3 — otherwise the payer's auth-lookup parses the wrong string.
Emitting AUI with AUI.1 empty and the data in AUI.3. AUI.3 is descriptive free text, not an identifier — payer engines do not query against it.
Using DTM precision in AUI.2. AUI.2 is DT (day-precision); appending a time component (e.g. 20260601120000) is silently truncated by many engines and rejected by strict validators.
Sending the authorization number in AUI.3 to bypass length limits on AUI.1. AUI.1 has no formal length in v2.8.1; truncating the auth number to fit a perceived limit corrupts the reference.
Reusing an old authorization number from a prior policy. AUI is tied to the IN1 it sits in; an authorization issued by Aetna does not become valid on a Cigna policy by being copied into a different IN1's AUI.

Examples

Minimal value

AUTH-99812

Only AUI.1 populated. Wire-legal, but most payers require AUI.2 in practice.

Populated value

AUTH-99812^20260601^Anthem PreAuth Dept

All three components populated. AUI.1 carries the payer-issued reference, AUI.2 the issuance date, AUI.3 the source department.

Annotated breakdown

AUTH-99812                                     AUI.1   Authorization Number (ST)
^20260601                                      AUI.2   Date (DT, day precision)
^Anthem PreAuth Dept                           AUI.3   Source (ST, free text)

In-context excerpt — IN1-14 carrying AUI on an ADT^A01 admit

IN1|1|BCBS|BCBS-PLAN-PPO|Anthem BCBS|PO Box 1234^^Saint Louis^MO^63101||1-800-555-0100|GRP-99812|EMP-12345||||||AUTH-99812^20260601^Anthem PreAuth Dept|||1|SMITH^JOHN^Q^^^^L|SEL|19720315|123 Main St^^Saint Louis^MO^63110|N|||||||||||||||MEM-7741|||||||M

IN1-14 is the 14th field on IN1; here it carries the pre-auth reference for the inpatient admission described by the surrounding ADT.

In-context excerpt — IN1-14 on a DFT^P03 charge submission

IN1|1|MCARE|MCARE-A|Medicare Part A|||||||||||AUTH-MED-77412^20260520^CMS Regional MAC

Common pitfall snippet

^20260601^Anthem PreAuth Dept

AUI.1 left empty; the receiver has a date and a source but no actual authorization number to match against the payer's auth system. Most payer interfaces silently drop this message or queue it for manual rework.

FHIR mapping

There is no per-datatype ConceptMap published in the v2-to-FHIR IG for AUI. In practice mappers split AUI across two FHIR resources: the authorization number anchors to Claim.insurance.preAuthRef (the field the FHIR Claim resource reserves for exactly this purpose), while the issuance date lands on ClaimResponse.preAuthPeriod.start (or as an extension on the Claim itself when no ClaimResponse exists yet), and the source becomes a Coverage.payor.display extension or a note on the Claim.

AUI	FHIR
AUI.1	`Claim.insurance.preAuthRef` (and `ClaimResponse.preAuthRef` on the response side)
AUI.2	`ClaimResponse.preAuthPeriod.start` (or Claim extension when no response)
AUI.3	`Coverage.payor.display` extension or `Claim.supportingInfo` note

For prior-authorization request workflows that use the FHIR CoverageEligibilityRequest/CoverageEligibilityResponse resources rather than Claim, AUI.1 anchors to CoverageEligibilityResponse.preAuthRef on the response.

Engine considerations

DT vs DTM in AUI.2: engines must not auto-upgrade AUI.2 to DTM. Many payer validators reject AUI.2 values that include a time component.
No repetition: IN1-14 does not repeat. Senders with multiple authorizations per encounter emit multiple IN1 lines, one per coverage, each with its own AUI.
Case sensitivity in AUI.1: payer-issued auth numbers are case-sensitive at most national payers. Engines that uppercase or lowercase AUI.1 in normalization break the lookup.
Trim semantics: leading and trailing whitespace in AUI.1 is significant only when payer formats include it (rare). Strip cautiously and log every modification.
Privacy: AUI.1 is a payer-issued identifier and is treated as PHI under HIPAA in most jurisdictions; logs and traces must mask it the same way they mask member IDs.

How Vorro parses and produces AUI

On inbound, Vorro materializes AUI as a Claim.insurance.preAuthRef plus, when AUI.2 is present, a ClaimResponse.preAuthPeriod.start (or Claim extension when no ClaimResponse exists). AUI.3 is captured as a structured source note attached to the Coverage. AUI.1 is preserved verbatim — no case normalization, no whitespace trimming beyond the wire delimiters.

On outbound, Vorro emits AUI.1 from the authoritative Claim.insurance.preAuthRef for the policy, AUI.2 from the issuance date when known, and AUI.3 from the source field on the issuing payer record. We refuse to emit AUI with AUI.1 empty; if no authorization number is known, IN1-14 is left empty rather than populated with a partial AUI.

Sources

← Back to HL7 v2 Guide