Health Care Services Review – Request/Response
The HIPAA X12 278 requests prior authorization or a referral for a health care service, and carries the payer's determination.
In this guide
278 Prior Authorization moves from Provider / Utilization Review Organization to Payer / Utilization Management Organization (Provider → Payer (request), Payer → Provider (response)) via AS2, SFTP, API, Clearinghouse. The interactive diagram below traces every business and technical step the message passes through — press Play Flow to watch it travel, or click any step for detail.
How it works
How 278 Prior Authorization Works
Sender
Provider / Utilization Review Organization
Receiver
Payer / Utilization Management Organization
Direction
Provider → Payer (request), Payer → Provider (response)
Standard
ANSI ASC X12
Version
005010X217
Transport
AS2 / SFTP / API / Clearinghouse
Business Purpose
Healthcare
Sender — Provider / Utilization Review Organization
EDI Transmission
278
Health Care Services Review – Request/Response
ANSI ASC X12 005010X217
Receiver — Payer / Utilization Management Organization
Related transaction flows
Need help understanding this EDI flow?
Ask EDI AI →278 Prior Authorization workflow. Steps: Identify Auth Requirement, Generate 278 Request, Send to Payer, Utilization Review, Generate 278 Response, Notify Provider. Transmitted from Provider / Utilization Review Organization to Payer / Utilization Management Organization via AS2, SFTP, API, Clearinghouse, following ANSI ASC X12 005010X217.
Overview
Automates the prior-authorization process so providers can confirm a service is approved before delivering care that requires payer sign-off.
Sender
Provider / Utilization Review Organization
Receiver
Payer / Utilization Management Organization
Direction
Provider → Payer (request), Payer → Provider (response)
Standard / Version
ANSI ASC X12 005010X217
Segment structure
Key segments that make up this transaction set:
| Segment | Name | Purpose |
|---|---|---|
| BHT | Beginning of Hierarchical Transaction | Identifies request vs. response and reference numbers. |
| UM | Health Care Services Review Information | Certification type and service details being reviewed. |
| HCR | Health Care Services Review | Carries the review decision/response code. |
| HSD | Health Care Services Delivery | Service frequency, duration, or quantity approved. |
Interactive example
Click any segment below to see its business meaning.
ST
This is an envelope or control segment. Select a highlighted segment on the left (shown in green) for a full business explanation.
View raw EDI
ST*278*0001*005010X217~
BHT*0007*13*AUTH-5521*20230920*0945~
HL*1**20*1~
NM1*X3*2*Acme Health Plan*****PI*66783~
HL*2*1*21*1~
NM1*1P*2*Riverside Medical Group*****XX*1932837465~
HL*3*2*22*1~
NM1*IL*1*DOE*JANE****MI*W123456789~
HL*4*3*EV*1~
UM*HS*I*3*21::MRI Lumbar Spine~
SE*10*0001~Mapping example
A representative field-level mapping from a common source system into this transaction:
| Source | Source Field | Target Field |
|---|---|---|
| EHR Order | order.procedure_code | UM04 (Service description / procedure code) |
| EHR Order | order.setting | UM02 (Certification Type Code) |
Validation rules
- The requested procedure/service code must be one the payer's policy actually requires authorization for.
- HCR response codes must reflect a definitive determination (certified, not certified, or pended for review).
- Clinical justification (diagnosis codes) should accompany the UM segment for medical-necessity review.
Common errors & troubleshooting
278 response pends indefinitely
Cause: Required clinical documentation wasn't attached or referenced, forcing manual payer review.
Fix: Ensure diagnosis and clinical detail segments are fully populated before submission to enable auto-adjudication.
Frequently asked questions
It can be — many payers support real-time 278 transactions for straightforward, rules-based authorizations, while complex cases route to manual clinical review with a delayed response.
Still have questions about 278?
Ask EDI AI →