Insurance Eligibility Verification: The 270/271 Nobody Reads

Every practice I talk to about denials tells me they verify eligibility. They are almost always telling the truth, and it is almost always still where their denials come from.

That contradiction bothered me for a long time before I understood it. The verification is happening. The technology is in place, it has been standardized for well over a decade, and the staff are running the checks they were trained to run. And yet when we trace denial volume back through the workflow, the largest single contributor keeps landing at the front desk.

The explanation turns out to be simple and slightly embarrassing for the industry. The eligibility response we all receive contains most of what would prevent the denial. Most workflows ask it one question and discard the rest of the answer.

If you want the broader picture before the detail, our revenue cycle management services page covers the full cycle and the 13 steps of the revenue cycle is the plainer version.

What the 270 and the 271 Actually Are

Two standardized electronic messages. The 270 is the Eligibility, Coverage or Benefit Inquiry, sent by a provider to a payer. The 271 is the Eligibility, Coverage or Benefit Information Response, sent back. Together they are how a practice asks an insurer about a patient’s coverage and gets a structured answer.

They are X12 transaction sets, adopted under the HIPAA administrative simplification standards in 2008 and mandated by 2012. That date matters for the rest of this article, so it is worth sitting with: this has been a required, standardized, universally available capability for more than a decade.

Payers publish companion guides describing exactly how they implement the pair, and UnitedHealthcare’s 270/271 companion guide is a representative example of what one looks like. If you want to know what a specific payer will and will not return, that document is where it is written down, and very few revenue cycle teams have read the ones that matter to them.

Mandated for Over a Decade, and Still the Top Denial Source

Hold those two facts next to each other.

The transaction has been required since 2012. Every clearinghouse supports it, every practice management system exposes it, and running a check costs a trivial amount. By any reasonable expectation, eligibility should be a solved problem.

Across the specialty work in this cluster we kept finding the opposite. Tracing denials backward through the workflow, expecting to land on coding, the largest single contributor kept turning out to be eligibility: coordination of benefits errors and wrong plan selection, captured at registration, before the patient was seen.

When a solved-on-paper problem stays unsolved in practice, the interesting question is not “why don’t they have the technology.” They have it. The question is what the technology is being asked to do, and there are exactly two answers, both of which are workflow decisions rather than software gaps.

Failure One: When the 270 Fires

The first is timing, and it is the cheaper of the two to fix.

Plenty of practices run eligibility. They run it at billing, as part of preparing the claim, or as a batch at some point after the encounter. At that point the check is doing something genuinely useful: it stops a claim going out that would certainly be rejected.

What it cannot do is prevent the cost. The patient has been seen. The clinician’s time is spent, the room was used, the supplies were consumed. Discovering at billing that coverage was not what you thought converts an unpaid claim into a slightly-faster-to-write-off unpaid claim.

The cluster’s own foundation work puts the alternative bluntly: firing the 270/271 at scheduling rather than at billing kills the largest single denial category before the visit. That is not a small refinement. It is the difference between prevention and documentation.

A check that runs after the service is an audit. A check that runs before it is a control.

Failure Two: Asking a Rich Response: A Yes-or-no Question

The second failure is the one almost nobody talks about, and it survives even when the timing is right.

A 271 comes back. The workflow looks at it, extracts a coverage status, and displays a green tick or a red cross. Staff see “active” and proceed. The rest of the response is parsed into a field nobody reads, or not parsed at all.

The trouble is that “is this patient covered?” was never the question that determined whether the claim would pay. Coverage is usually active. What varies is which plan, in what order, with what patient responsibility, under which product. Those are the variables that generate denials, and they are sitting in the response that was just reduced to a tick.

I find this genuinely striking as a systems problem. It is rare to encounter a situation where the data required to prevent a loss is already arriving, on time, in a structured format, at no additional cost, and is being deliberately discarded because the interface was designed around a simpler question.

What is Actually in the 271, and What Each Part Prevents

Worth going field by field, because the mapping from response content to prevented denial is direct.

1. Coverage status and dates of coverage. Prevents the obvious one, service delivered outside an active coverage period. This is the part everybody already uses.
2. Member identifier as the payer holds it. Prevents the identifier mismatch rejection, which is high volume and entirely mechanical. The number on the card and the number in the payer’s system are not always the same thing after a plan change.
3. Plan and product detail. Prevents wrong-plan selection, which is one of the two biggest contributors found across this cluster. A patient may be covered by an insurer under a product your system has not distinguished from three similar ones.
4. Copayment and year-to-date deductible balance. Does not prevent a denial as such, but it determines what you should collect at the desk, and point-of-service collection is materially cheaper than chasing a balance afterwards.
5. Coordination of benefits information, where applicable. Prevents the other biggest contributor. If a secondary coverage exists and the claim goes to the wrong payer first, it denies, and it denies for a reason that looks administrative rather than clinical.

Read that list back and notice how much of it is being thrown away in the average workflow. Two of the five map directly onto the denial drivers this cluster found repeatedly, and neither is exotic or optional. They arrive in the standard response.

Coordination of Benefits, the Specific Killer

Worth its own section because it accounts for a disproportionate share and because it is badly understood.

Coordination of benefits is the rule set determining which payer pays first when a patient has more than one coverage. It is common: a patient with employer coverage and a spouse’s plan, a Medicare patient with a supplement, a child covered by both parents. The rules for who is primary are not intuitive and they are not the patient’s to know.

Working with a multi-location specialty group, we traced denial volume backward expecting coding problems and found the largest contributor was coordination of benefits errors and wrong managed care plan selection, both captured at eligibility verification, before the patient was seen.

Here is what makes it pernicious. The claim goes to the wrong payer, denies, and lands in the denial report tagged with a reason code that reads like a billing problem. The billing team, who did their job correctly, works it. Nobody upstream ever learns that the error was made at check-in, because the feedback never travels back that far. The organization concludes it has a billing accuracy problem and invests accordingly.

The 271 frequently carries the coordination of benefits information that would have prevented this, and it is one of the fields most commonly parsed into nothing. That is the whole argument of this article in a single example. This is also why denial management built purely on the back end plateaus, and why how to improve revenue cycle management argues that where a denial is recorded is not where it was created.

What Your Systems Have To Do

Four things, and none of them requires anything you do not already have access to.

1. Fire the 270 at scheduling, and again close to the date of service. Coverage changes. A check run three weeks ago against an appointment today is a check against stale information, and a re-check costs approximately nothing.
2. Parse the whole 271, not the status flag. This is the substantive one. The response is structured, so extracting plan detail, deductible balance and coordination of benefits information is parsing work, not intelligence work.
3. Surface conflicts as exceptions rather than as data. Nobody reads a full benefit response for every patient, and they should not have to. What staff need is a short queue of the cases where the response disagrees with what is on file: a secondary coverage the system does not know about, a plan that does not match the one selected, a coverage period that ends before the appointment.
4. Write back into the system the staff already work in. A verification result that lives in a separate portal gets consulted when someone remembers. One that updates the record where the scheduler already is gets consulted every time.

The engineering caution, since I would rather say it than have you discover it: connecting to a clearinghouse or a payer for eligibility is well-trodden. The difficulty is in the last mile. Payer companion guides differ in what they return and how they populate it, the same field can be reliable with one payer and empty with another, and getting a result to land usefully inside a scheduling workflow that was not designed to receive it is where the schedule goes. Anyone describing that part as routine has not done it. Our automated eligibility verification capability covers what that looks like in practice, and claims processing configuration covers where the downstream rules live.

What Good Looks Like Operationally

Less abstract, because the pattern is fairly consistent across the practices that have this working.

1. A batch the day before, and a second pass the morning of. The day-before run gives staff time to act on problems. The morning-of run catches same-day changes and add-on appointments.
2. An exception dashboard, not an all-clear report. The output staff work from should contain only the cases needing a human. If the report lists every verified patient, it will not be read.
3. A re-check triggered by rescheduling. An appointment moved by three weeks is a new appointment for eligibility purposes, and this is a common gap.
4. Point-of-service collection informed by the response. If the 271 returned a deductible balance, the front desk should know before the patient reaches the counter.
5. And a feedback loop from denials back to registration. Whatever else you build, if eligibility-caused denials are not reported back to the people making the eligibility decisions, the error rate will not fall. This is the loop that breaks most often, and closing it is mostly an organizational decision rather than a technical one.

In the order I would run them.

1. Find out when your 270 actually fires. Not when policy says it fires. Pull a sample of last week’s encounters and check the timestamp against the appointment time.
2. Ask what your system does with the 271 beyond coverage status. If the answer is a coverage flag, you have found the largest available improvement in this article.
3. Check whether coordination of benefits information is parsed at all. This is a yes-or-no question your vendor or your integration team can answer today.
4. Sample 50 recent denials and trace each to the stage where it was created, not the stage where it was recorded. Expect the distribution to surprise you.
5. Confirm a reschedule triggers a re-check. It commonly does not.
6. Ask whether eligibility-caused denials are reported back to registration. If nobody at the front desk sees the consequences of a plan-selection error, the error rate is not going to move.

Every one of these is diagnostic and costs time rather than money. Checks 2 and 3 are the ones that most often produce a genuinely surprised silence.