The EDI 278, Decoded: Prior Authorization Is a Conversation, Not a Form

Short answer: The EDI 278 · Health Care Services Review Information is the standard X12 transaction for asking a payer whether a planned service is authorized — and for the payer to answer, ask for more information, or revise an earlier decision. It is not a claim, not an eligibility check, and not a guarantee of payment. Most 278 failures are not syntax failures: they are missing clinical context, a mismatched patient or provider identifier, or a request sent to the wrong review organization.

If the 270/271 answers "is this person covered for this kind of care?", and the 276/277 answers "what happened to that claim?", the 278 answers a question that has to be asked before the care happens: "will you authorize this specific service, for this patient, from this provider, on these dates?"

What does a 278 actually carry?

A 278 request identifies the patient, the subscriber, the requesting provider, the servicing provider or facility, the diagnosis, and the service being requested — procedure, level of care, dates, and quantity — in a loop structure built around who is asking, who it is about, and what is being reviewed.

The response uses the same transaction set with a different intent: certified as submitted, modified, denied, or pended for additional information. That last outcome is the one teams underestimate. A pended 278 is not a soft denial; it is the payer saying the conversation is incomplete. Treating "pended" as a terminal state is how authorizations quietly expire while a procedure date approaches.

How is a 278 different from a 270/271 and a 276/277?

Eligibility (270/271) is about coverage in the abstract. Claim status (276/277) is about a claim that already exists. The 278 sits between them in time and in logic: the service is planned but not yet delivered, and the answer is specific to that service — not a general statement that the member has benefits.

That specificity is why copying an eligibility workflow into an authorization workflow breaks. An eligibility check can succeed with a name, a date of birth, and a member ID. A 278 with the same thin data will pend or deny, because the reviewer — human or automated — needs the clinical and administrative detail that justifies the service.

What breaks most often in 278 flows?

Wrong destination. The payer on the card is not always the organization that reviews the service. Behavioral health, radiology, pharmacy-adjacent services, and transplant reviews are frequently carved out to a separate utilization-management organization. A perfectly built 278 sent to the health plan instead of the review organization goes nowhere useful.

Identifier drift. The request has to agree with the enrollment record on member identity and with the provider record on NPI and taxonomy. A servicing facility identified one way in the 278 and another way in the eventual 837 · Claim is a denial looking for a date.

Missing or vague service detail. "Outpatient services" is not an authorizable request. Reviewers authorize specific procedures, levels of care, units, and date ranges. Vague requests get pended for information that should have been in the first submission — and every pend cycle costs days the schedule may not have.

No follow-through on the response. Teams poll for claim status religiously and then file 278 responses in a queue nobody owns. An authorization that comes back modified — fewer units, a different level of care, a shorter window — has to change the plan, not just the record. If the delivered service does not match the authorized service, the claim that follows will deny no matter how clean it is.

Treating authorization as payment. Certification means the payer agrees the service is reviewable and approved as described. It does not override eligibility at the date of service, timely filing, coding rules, or medical-necessity documentation in the chart. The 278 removes one reason to deny; it does not remove the others.

What does a reliable 278 workflow look like?

Route by service, not by payer name — maintain the carve-out map and check it before building the request. Validate identifiers against the most recent 271 response you have, not against a spreadsheet from intake. Require the specific procedure, diagnosis, units, and dates before submission, and treat a pend response as a task with an owner and a clock, not as a status to observe. Finally, carry the authorization reference forward so the eventual claim and the authorization can be reconciled line by line.

That reconciliation step is where we focus at SignalEDI (https://signaledi.com?utm_source=devto&utm_medium=article&utm_campaign=2026-11-13) — healthcare sets like the 278 only work when the request, the response, and the claim that follows stay linked as one conversation instead of three unrelated files.

FAQ

Is a 278 the same as a referral?

No. A referral is a provider directing a patient to another provider. A 278 is a formal services-review request to a payer or review organization asking whether a specific planned service is authorized.

Does an approved 278 guarantee the claim will be paid?

No. It means the service as described was certified. Eligibility on the date of service, accurate coding, documentation, and timely filing still decide payment.

What should you do when a 278 comes back pended?

Treat it as a request for the specific missing information, assign it an owner immediately, and respond before the review window closes. A pend left alone becomes a denial by default.

Can a 278 be revised after it is submitted?

Yes — the transaction supports changes to a previously submitted request, which is how you correct dates, units, or service detail without starting a second, competing authorization.

I'm Chris, founder of SignalEDI. We build EDI and API integration for teams that would rather reconcile authorizations than chase them — including the healthcare sets (837/835/270/271/278) in every plan.