# EDI 278 Prior Authorization: HIPAA 5010 Guide
> EDI 278 prior authorization explained: 005010X217 requests and responses, the UM, HCR, HI and SV1 segments, live examples and common errors.
The EDI 278 is the X12 Health Care Services Review transaction used for prior authorizations, referrals and admission reviews. A provider sends a 278 request describing the patient, diagnosis and requested services, and the health plan or utilization management organization answers with a 278 response that certifies, modifies, pends or denies it. HIPAA uses the 005010X217 guide.
**The EDI 278 is the electronic version of the prior authorization fax.** A provider asks a health plan to approve a service before it happens: an MRI, a surgery, an inpatient admission, a specialist referral. The plan's utilization management team reviews it and sends back a decision with a certification number. The same transaction set number covers both directions, so the first thing to learn is how to tell a request from a response.
This guide covers what the 278 carries, its six-level hierarchy, the segments that hold the request and the decision, live request and response examples built from fictional data, how the 278 relates to the newer FHIR-based prior authorization APIs, and the errors that cause pended or rejected reviews. It describes the X12 structure only. It is not legal, clinical or compliance advice; coverage and medical necessity decisions belong to the health plan and its clinical reviewers.
## What Is an EDI 278?
**An EDI 278 is the Health Care Services Review transaction set defined by [ASC X12](https://x12.org/examples/005010x217), used to request a review of health care services from a health plan or utilization management organization (UMO) and to return the result.** For HIPAA covered entities, [45 CFR 162.1302](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-M/section-162.1302) adopts the X12 Technical Report Type 3 "Health Care Services Review: Request for Review and Response (278)," report `005010X217`, with its April 2008 errata `005010X217E1`, as the standard for the referral certification and authorization transaction. The identifier in `GS08` and `ST03` is `005010X217`, and the functional group code in `GS01` is `HI`.
Authoritative references for 278 work:
- The [X12 005010X217 examples](https://x12.org/examples/005010x217) walk through a referral, an admission with surgery, a behavioral health emergency admission, home health care and other cases, request and response, with the TR3's explanations
- [CMS's Interoperability and Prior Authorization final rule (CMS-0057-F) fact sheet](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f) describes the Prior Authorization API that impacted payers must implement and HHS's enforcement discretion for the X12 278 when an all-FHIR API is used
- CAQH CORE publishes Prior Authorization and Referrals operating rules. Its [operating rules page](https://www.dataspring.com/core/operating-rules) lists the federally mandated sets as eligibility and benefits, claim status, and payment and remittance, which matches the rules [CMS lists as adopted](https://www.cms.gov/priorities/key-initiatives/burden-reduction/administrative-simplification/operating-rules)
- Each health plan's companion guide lists the services that need review, the review types and service type codes it accepts, and its required fields
**Who sends the request?** The provider who orders or performs the service (the requester), or a clearinghouse or vendor for it.
**Who sends the response?** The health plan or the UMO that manages reviews for it.
**When is it sent?** Before scheduled services that the plan requires review for, at or after an urgent admission, or when extending or revising an existing authorization.
**Why does it matter?** A claim for a service that needed authorization and did not get one is likely to be denied. The certification number from the 278 response is what you carry onto the [837 claim](/guides/edi/837-health-care-claim).
## Request or Response? Reading BHT and HCR
| Clue | Request | Response |
|---|---|---|
| **`BHT02`** | `13` (request) | `11` (response) |
| **`BHT06`** | Not used in the X12 request examples | `18` in the X12 response examples (response, no further updates to follow) |
| **`TRN01`** | `1`: the requester's trace number | `2`: the requester's trace number echoed back |
| **`HCR` segment** | Absent | Present: the decision and the review identification number |
X12 also publishes 278 guides for inquiries about existing reviews (`005010X215`) and for notifications (`005010X216`). Payers that use them publish separate companion guides, and they are not the standard adopted in 45 CFR 162.1302. This guide covers `005010X217`.
## How a Prior Authorization Works in X12
1. **The order is placed.** A physician orders a service. The practice checks the plan's rules, or sees `EB11` = `Y` (authorization required) on a [271 eligibility response](/guides/edi/271-eligibility-benefit-response).
2. **The practice sends a 278 request.** It names the UMO, the requester, the patient, the review type, the diagnosis, the service and the servicing provider.
3. **The clearinghouse validates and routes it.** A file that fails validation comes back as a [999](/guides/edi/999-implementation-acknowledgment).
4. **The UMO reviews it.** Some requests are approved automatically; others go to clinical review and may be pended for records.
5. **The UMO sends a 278 response.** `HCR01` carries the decision, `HCR02` the review or certification number, and `DTP` the dates the certification covers.
6. **The practice schedules and bills.** Staff record the certification number, schedule within the certified dates, and put the number on the claim.
## Interactive Example: 278 Request for an Outpatient MRI
A fictional family practice requests a health services review for a lumbar spine MRI without contrast (CPT `72148`) for JOHN SAMPLE, with ICD-10-CM diagnosis `M54.16` (radiculopathy, lumbar region) sent as `M5416` without the decimal point. The patient event level carries the review type, diagnosis and the imaging facility; the service level carries the procedure and requested date. Every name, member ID, payer ID and NPI is fictional, the clinical scenario is invented for illustration, and `ISA15` is `T` (test).
Use the **Plain English** tab for a readable summary, or click any segment to break it down element by element.
## Interactive Example: 278 Response Certifying the MRI
The fictional plan approves the request in full. The response repeats the request's detail, as the X12 examples do, adds `HCR*A1` with the review identification number at the event and service levels, and gives a certification date range in `DTP*AAH`.
## 278 Structure at a Glance
`BHT01` value `0007` declares the hierarchy: information source, information receiver, subscriber, dependent, event, services.
| Loop | Segment | Name | Notes |
|---|---|---|---|
| Header | **ST** | Transaction Set Header | `ST01` = `278`, `ST03` = `005010X217` |
| Header | **BHT** | Beginning of Hierarchical Transaction | Structure `0007`; `13` request or `11` response |
| 2000A / 2010A | **HL / NM1** | Utilization management organization | `HL03` = `20`, `NM101` = `X3` |
| 2000B / 2010B | **HL / NM1 / PER** | Requester | `HL03` = `21`, the provider asking, with a contact |
| 2000C / 2010C | **HL / NM1 / DMG** | Subscriber | `HL03` = `22`, member ID and demographics |
| 2000D / 2010D | **HL / NM1 / DMG** | Dependent | `HL03` = `23`, when the patient is a dependent |
| 2000E | **HL** | Patient Event Level | `HL03` = `EV` |
| 2000E | **TRN** | Patient Event Tracking Number | The requester's trace |
| 2000E | **UM** | Health Care Services Review Information | Review type, certification type, service type, place of service |
| 2000E | **HCR** | Health Care Services Review | Response only: decision and review number |
| 2000E | **DTP** | Event dates | Such as admission date (`435`) or certification period (`AAH`) |
| 2000E | **HI** | Patient Diagnosis | ICD-10-CM codes |
| 2000E | **HSD / CL1 / MSG** | Quantities, institutional data, messages | Situational |
| 2010E | **NM1 / N3 / N4 / PER** | Patient event providers | Servicing provider, facility, attending physician |
| 2000F | **HL** | Service Level | `HL03` = `SS`, one per requested service |
| 2000F | **TRN / UM / HCR / DTP** | Service review data | Same roles as at the event level, per service |
| 2000F | **SV1 / SV2** | Professional or institutional service | The procedure requested; the TR3 defines other service segments for other service types |
| 2010F | **NM1 / PRV** | Service providers | Provider for this service |
| Trailer | **SE** | Transaction Set Trailer | Segment count and control number |
## Key Segments Explained
### HL: Event and Service Levels
```
HL*4*3*EV*1~
HL*5*4*SS*0~
```
The first three levels (UMO, requester, subscriber) work like the 270 and 276. The 278 adds two: `EV`, the patient event, holding what applies to the whole episode, and `SS`, one per service. An X12 interpretation ([RFI 1371](https://x12.org/resources/requests-for-interpretation/rfi-1371-278x217-service-loop-count)) confirms that every `SS` level points to the `EV` level as its parent in `HL02`, not to the previous service.
### UM: Health Care Services Review Information
```
UM*HS*I*62*11:B~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **UM01** | Request Category Code | `HS` | `AR` admission review, `HS` health services review, `SC` specialty care review (referral) |
| **UM02** | Certification Type Code | `I` | The X12 code list includes `I` initial, `S` revised, `R` renewal, `4` extension, `3` cancel, `1` and `2` appeal (immediate, standard) and `N` reconsideration; the TR3 and payer guide say which apply |
| **UM03** | Service Type Code | `62` | MRI/CAT scan. Others include `2` surgical, `3` consultation, `42` home health care, `73` diagnostic medical |
| **UM04** | Health Care Service Location Information | `11:B` | Facility code `11` with qualifier `B` (place of service code, here office); qualifier `A` means a UB facility type code |
| **UM05-UM10** | Related causes, level of service, condition, prognosis, release of information, delay reason | | Situational |
Payers restrict these values. One major payer's companion guide, for example, accepts only certain `UM03` and `UM04` combinations for authorizations. Check the companion guide before building your map.
### HI: Patient Diagnosis
```
HI*ABK:M5416~
```
Each `HI` element is a composite: a code list qualifier and a code. For ICD-10-CM, `ABK` marks the principal diagnosis and `ABF` other diagnoses, and payer guides also list `ABJ` (admitting). Codes are sent without the decimal point. The X12 example set predates ICD-10 and shows `BF` (an ICD-9-CM qualifier); current transactions use the ICD-10 qualifiers.
### SV1 and SV2: The Service Requested
```
SV1*HC:72148**UN*1~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **SV101** | Composite Medical Procedure Identifier | `HC:72148` | `HC` (HCPCS, which includes CPT) and the procedure code |
| **SV102** | Line Item Charge | | Optional on a review request |
| **SV103** | Unit or Basis for Measurement | `UN` | Units |
| **SV104** | Service Unit Count | `1` | One study |
Institutional services use `SV2`, with the procedure in `SV202` (the X12 admission example uses `SV2**HC:33510`). Request the specific code you plan to bill. A certification for one procedure code does not automatically cover a different one on the claim.
### HCR: The Decision
```
HCR*A1*TESTAUTH00042~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **HCR01** | Action Code | `A1` | The decision (see below) |
| **HCR02** | Review Identification Number | `TESTAUTH00042` | The certification or authorization number to keep and bill with |
| **HCR03** | Review Decision Reason Code | | Why the plan did not certify in full, when it says |
| **HCR04** | Second Surgical Opinion Indicator | | When a second opinion is required |
| HCR01 | Meaning | What to do |
|---|---|---|
| `A1` | Certified in total | Schedule within the certified dates and quantities |
| `A2` | Certified, partial | Check what was certified; it may be fewer units or days |
| `A3` | Not certified | Read `HCR03`; follow the plan's reconsideration or appeal process |
| `A4` | Pended | The review is not finished; the plan may need records |
| `A6` | Modified | Approved with changes, such as a different setting or length of stay |
| `C` | Cancelled | The review was cancelled |
| `CT` | Contact payer | Call or use the plan's portal |
| `NA` | No action required | The plan says no review is needed for this service |
The X12 admission example shows why `HCR` can appear at both levels: the surgery is certified in total (`A1`) at the service level, while the inpatient stay is modified (`A6`) at the event level from seven days requested to five certified.
### DTP: Dates
```
DTP*AAH*RD8*20261105-20270203~
DTP*472*D8*20261112~
```
`AAH` is the certification effective period on a response: the window in which the service is authorized, as in the X12 referral example. `472` is the service date requested, and `435` the admission date on an admission review. Schedule inside the `AAH` range; a service outside it may not be covered by the certification.
### HSD and CL1: Quantities and Admissions
`HSD` states how much is requested or certified: `HSD*VS*1` for one visit, `HSD*DY*7` for seven days. `CL1` carries institutional admission data; in the X12 admission example `CL1*2` is an urgent admission. Compare request and response quantities, because the response may certify less than you asked for.
## Prior Authorization APIs and the 278
CMS's [Interoperability and Prior Authorization final rule](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f) requires impacted payers, which include Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and qualified health plan issuers on the federally facilitated exchanges, to implement a FHIR-based Prior Authorization API beginning January 1, 2027 (exact dates vary by payer type). CMS also states that covered entities with an all-FHIR Prior Authorization API that do not use the X12 278 will not be enforced against under HIPAA Administrative Simplification, and that covered entities may still offer an X12-only prior authorization transaction.
In practice, the X12 278 remains the HIPAA standard for this transaction, and many payers and clearinghouses continue to support it alongside portals and APIs. Check each payer's current options; the rule's text and CMS's guidance govern who must do what and when.
## 278 vs 270/271, 837 and 277
| Document | When | What it does |
|---|---|---|
| **[270](/guides/edi/270-eligibility-benefit-inquiry) / [271](/guides/edi/271-eligibility-benefit-response)** | Before ordering or scheduling | Confirms coverage and can flag that authorization is required |
| **278 request / response** | Before the service (or soon after an urgent admission) | Requests and returns the review decision and certification number |
| **[837 claim](/guides/edi/837-health-care-claim)** | After the service | Bills it, carrying the prior authorization number |
| **[276](/guides/edi/276-claim-status-request) / [277](/guides/edi/277-claim-status-response)** | After billing | Tracks the claim's status |
| **[835](/guides/edi/835-health-care-claim-payment-advice)** | After adjudication | Explains payment and any denial for missing authorization |
## Common 278 Errors and How to Prevent Them
| Error | What happens | Prevention |
|---|---|---|
| **Wrong `UM01` for the service** | Rejected or routed to the wrong review queue | Map review types from the payer's guide: `AR` for admissions, `HS` for services, `SC` for referrals |
| **`UM03`/`UM04` combination not accepted** | Rejection with an `AAA` code | Follow the payer's list of accepted service types and places of service |
| **`SS` levels chained to each other** | Validation errors or misread services | Point every `SS` level's `HL02` to the `EV` level |
| **Diagnosis missing, or sent with a decimal point** | Pended or rejected | Send ICD-10-CM codes without the decimal, principal first (`ABK`) |
| **Procedure requested differs from the one billed** | Claim denied for no authorization | Request the exact code you will bill; send a revision (`UM02` = `S`) if it changes |
| **Response trace not matched** | Decision attached to the wrong patient | Match on `TRN02` returned with `TRN01` = `2` |
| **Only `HCR01` = `A1` handled** | Partial, modified and pended decisions missed | Route every `HCR01` value to a work queue |
| **Certification dates ignored** | Service performed outside the `AAH` window | Schedule from the returned dates, not the requested ones |
| **Certification number not carried to the claim** | Claim denied even though the service was approved | Store `HCR02` with the order and map it into the 837 |
## 278 Implementation Checklist
- Confirm each payer accepts `005010X217` 278s, and whether it answers in real time, batch, by portal or by API
- Get each payer's companion guide and list of services that require review
- Map `UM01`, `UM02`, `UM03` and `UM04` from the order type and setting
- Send ICD-10-CM diagnoses with the right `HI` qualifiers and procedure codes in `SV1` or `SV2`
- Build the `EV` and `SS` levels with correct `HL02` parents
- Store `TRN02`, `HCR01`, `HCR02` and the `DTP*AAH` dates with the order
- Route `A2`, `A3`, `A4`, `A6` and `CT` decisions to staff with clear next steps
- Carry the certification number to the 837
- Test approval, partial approval, modification, pend, denial and revision scenarios
New to X12? Our [essential guide to EDI](/blog/essential-guide-to-edi) covers envelopes and segments, and [EDI vs API](/blog/edi-vs-api) compares batch EDI with API-based exchange.
## Where OrderSync Fits
OrderSync's product is built for supplier order flows: it reads inbound purchase orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches customers, items and units, and outputs ERP data or valid X12.
For healthcare EDI teams, the useful piece is the [free EDI inspector](/edi-inspector), which parses any X12 file, 278 requests and responses included. Paste a test 278 to see the event and service levels, review type, diagnosis, procedure and decision explained, and get structural errors flagged. Follow your organization's policies on protected health information before pasting a production file; test files with fictional data work just as well for checking structure.
## Frequently Asked Questions
### What is an EDI 278?
The EDI 278 is the X12 Health Care Services Review transaction. Providers use it to request prior authorization, referral or admission review from a health plan, and the plan or its utilization management organization uses it to send back the decision.
### What does 005010X217 mean?
It identifies the HIPAA implementation guide for the 278 request for review and response: X12 version 005010, technical report X217. It appears in GS08 and ST03. The 2008 errata, 005010X217E1, did not change that identifier.
### How do I tell a 278 request from a 278 response?
Check BHT02: 13 is a request and 11 is a response. A response also contains HCR segments with the decision, and its TRN segment uses TRN01 = 2 to echo the requester's trace number.
### What does HCR*A1 mean?
A1 is the action code for "certified in total." HCR02 carries the review identification number, which is the certification or authorization number you keep and put on the claim.
### What is the difference between UM01 codes AR, HS and SC?
AR is an admission review, for inpatient stays. HS is a health services review, for procedures and other services. SC is a specialty care review, typically a referral to a specialist.
### Is the X12 278 being replaced by FHIR prior authorization APIs?
CMS's Interoperability and Prior Authorization final rule requires impacted payers to offer a FHIR-based Prior Authorization API, and HHS announced enforcement discretion for all-FHIR implementations that do not use the X12 278. The 278 remains the HIPAA-adopted standard and is still widely supported.
### Why was my 278 pended?
A pended response (HCR01 = A4) means the review is not complete. The plan may need clinical records or more information, or the request is in clinical review. Its companion guide and any AAA or MSG content explain what to send.