The transaction set: 270, 271, 278, 275, 837, 835

3 min read

HIPAA names a set of standard electronic transactions for healthcare administration. Six of them touch prior authorization. Most practices interact with all six without ever seeing one, because portals and practice management systems hide them. When something breaks, knowing which transaction failed is the difference between a five-minute fix and a week of phone calls.

Transaction	Name	Direction	What it does
270	Eligibility, Coverage or Benefit Inquiry	you to plan	Asks whether this member is covered and what the benefit looks like.
271	Eligibility, Coverage or Benefit Information	plan to you	Answers it. Active coverage, plan, copay, deductible, and sometimes whether authorization is required.
278	Health Care Services Review	both ways	The authorization request and the response. One transaction set, two directions.
275	Patient Information / attachments	you to plan	Carries clinical documentation attached to a review.
837	Health Care Claim	you to plan	The claim. Carries the authorization number so the plan can match it.
835	Health Care Claim Payment/Advice	plan to you	The remittance. Tells you what was paid and, if it was not, why.

#The sequence

270 / 271
Confirm coverage is active and learn the benefit. Do this first, always. An authorization built on stale coverage is wasted work, and a large share of authorization denials are really eligibility problems wearing a different hat.
278 request
Ask the plan to review the proposed service. The request identifies the payer, the requesting provider, the subscriber and patient, the diagnosis, the procedure, the place of service and the dates.
275, if required
Attach clinical documentation. Many payers still want this by portal upload or fax even when the 278 itself is electronic.
278 response
The plan answers: certified, certified in part, pended, modified, or not certified. Pended is extremely common and is not a decision.
837
After the service, the claim carries the authorization number so the plan can match the payment to the approval it already gave.
835
The remittance either pays or explains. A claim denied for no authorization on a service that had one is almost always a break between the 278 response and the 837.

The gap that costs the most money

The authorization number has to travel from the 278 response into the 837 claim. In many practices that journey is a person reading a letter and typing a number into a billing system. It is the least automated step in the whole chain and the one where the revenue actually leaks. See From authorization number to paid claim.

#Where clearinghouses sit

Most practices do not connect directly to each payer. A clearinghouse sits in the middle, holds the trading partner relationships, and normalises the connection. The practice sends one format to one endpoint; the clearinghouse routes to hundreds of payers and handles their individual quirks.

This matters for troubleshooting. A rejection can come from the clearinghouse (the transaction was malformed, or the payer is not reachable on this network) or from the payer (the request was received and refused). They look similar and mean completely different things. A clearinghouse rejection usually means fix the data and resend. A payer rejection means the plan looked and said no.

#Version

The current mandated version for these transactions is 5010. Where you see references to 4010 in older documentation, that is history. The forthcoming move in this space is not a new X12 version but a parallel rail: FHIR-based prior authorization APIs, which CMS requires impacted payers to implement beginning 1 January 2027. Both rails will run at once for years. See CMS-0057-F.