The EDI 270/271, Decoded: Eligibility Is a Question You Have to Ask Before the Visit, Not After the Denial
A 270 Ā· Eligibility Inquiry asks a payer, before care is delivered, whether a specific patient is covered, for what, and under what terms ā and the 271 Ā· Eligibility Response is the payer's answer. Asked in time, the pair prevents the most avoidable denial in healthcare: the service was never covered in the first place.
I run SignalEDI. This series has walked the healthcare chain from the other end ā the 837 Ā· Claim that asks for payment and the 835 Ā· Remittance Advice that explains it. The 270/271 sits at the opposite end of that chain, before any claim exists. It is also the transaction whose value is easiest to underestimate, because when it works, nothing happens: no denial, no rework, no patient bill that should never have been sent.
What is a 270 Ā· Eligibility Inquiry and a 271 Ā· Eligibility Response?
The 270 is the question. A provider ā or a clearinghouse acting for one ā sends the patient's identifying information, the provider's identity, and the service types being checked to the payer. The 271 is the answer that comes back: active or inactive coverage, effective dates, benefit amounts such as copays, coinsurance and deductibles, and limitations or authorizations that apply to the services in question.
Unlike most EDI documents in this series, the pair is designed to work in near real time as well as in batch. A front desk checking a patient in, a scheduling system verifying coverage days ahead, and a billing team re-checking before submission are all asking the same question at different moments ā and the timing matters, because coverage is a fact that changes.
Why does eligibility checked once go stale?
Because eligibility is not a property of the patient; it is a property of a moment. Jobs change, plans renew on different terms, COBRA starts and ends, secondary coverage appears, and deductibles reset. A 271 that said "active, $30 copay" in January may be honestly wrong by March, with nobody having made an error.
That is why mature workflows treat the 271 response as dated evidence, not a permanent flag on the chart. Store when the check ran, what the payer actually returned, and which service types were checked ā then re-check close to the date of service and again before billing when the gap is long. The denial you prevent is usually not caused by a missing check. It is caused by an old check trusted for too long.
What does a good 271 actually tell you ā and what does it not?
A useful response is specific: coverage status per service type, not just a single yes or no for the whole plan; the amounts a patient will owe, so cost can be discussed before care rather than argued about after; and the restrictions that change the plan of care, such as a prior-authorization requirement or a carve-out to a different payer for a particular service.
What it does not tell you is a guarantee of payment. Payers say this explicitly, and they mean it: eligibility confirms coverage on the day it was checked, subject to the claim itself being correct, coded properly, and submitted in time. Treating a clean 271 as a promise leads teams to skip the other checks. Treating it as what it is ā the best available evidence, gathered early ā makes it one of the highest-return transactions in the revenue cycle.
Where do 270/271 workflows usually break?
Identity matching is the first break. The payer matches on a combination of member ID, name, and date of birth, and a transposed digit or a name that differs from the card produces a "not found" that looks like "not covered." The fix is procedural: capture the data from the card, not from memory or a referral form, and route not-found responses to a human before anyone tells a patient they are uninsured.
The second break is asking too narrow a question. A check that only asks "is this patient active?" misses the service-type detail that determines whether this visit, this procedure, or this therapy is covered. Ask about the services you actually intend to deliver.
The third break is losing the answer. If the 271 lives only as a green checkmark in a scheduling screen, nobody can reconstruct what the payer said when a denial arrives months later. Keep the full response with the encounter. It is evidence, and evidence has a shelf life measured in appeals windows.
Frequently asked questions
Is a 270/271 the same as a prior authorization?
No. Eligibility confirms coverage and can flag that authorization is required, but it does not grant it. Authorization is a separate request about a specific planned service.
How is 270/271 different from 276/277?
The 270/271 asks about coverage before or around care. The 276 Ā· Claim Status Inquiry and 277 Ā· Claim Status Response ask what happened to a claim that was already submitted on an 837.
Can one 270 ask about more than one patient or service?
Yes ā inquiries can be batched, and a single inquiry can check multiple service types. The discipline is in reading the response per patient and per service type, not as one blanket answer.
The pattern across this series holds here too: each EDI document answers exactly one question well. The 270 asks it and the 271 answers it ā "is this patient covered for this care, on this date, and on what terms?" Asking early, specifically, and saving the answer is the discipline we build SignalEDI around.
ā Chris, founder of SignalEDI
