EDI 278 Prior Authorization: HIPAA 5010 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, 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 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 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 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 lists the federally mandated sets as eligibility and benefits, claim status, and payment and remittance, which matches the rules CMS lists as adopted
• 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.

Request or Response? Reading BHT and HCR

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.
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.
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.

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) 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~

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~

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~

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 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

Common 278 Errors and How to Prevent Them

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 covers envelopes and segments, and 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, 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