IDN Identity
Can the payer match the patient, subscriber, member ID, date of birth, and relationship facts?
Lesson 0006
Eligibility Is Not a Payment Promise
The practical product skill: use a 270/271 eligibility check to reduce preventable claim failure without pretending the payer has guaranteed payment.
Your Tangible Win
After this lesson, you should be able to triage an eligibility response into four product buckets: IDN, ACT, BEN, or OOP.
Primary source to read after the lesson: CMS Health Plan Eligibility Benefit Inquiry and Response.
The Core Idea
A 270 asks a health plan about an enrollee's eligibility and benefits. A 271 is the health plan's response about eligibility and coverage. CMS says the transaction is used to obtain benefit-plan information for an enrollee, including eligibility and coverage under the health plan (CMS eligibility transaction overview).
That makes eligibility a pre-claim risk check, not claim adjudication. CMS describes Medicare HETS 270/271 as intended for preparing accurate claims, determining beneficiary liability, or determining eligibility for specific services (CMS Eligibility Inquiry). It does not mean the future claim will be paid.
The Four Buckets
ACT Active
Was coverage active for the service date you plan to bill?
BEN Benefits
Does the response include coverage for the service type, plan, or network context?
OOP Out of Pocket
What patient responsibility signals are returned, such as deductible, copay, or coinsurance?
Operating Rules
CMS says eligibility operating rules require real-time responses with financial information, including deductibles, copays, coinsurance, and coverage for specific service types (CMS eligibility operating rules).
Boundary
Eligibility can explain coverage risk. It does not replace coding validation, authorization workflows, payer edits, timely filing checks, or adjudication.
Mini Case
Registration runs eligibility and receives an active response. The product marks the visit as "payment guaranteed." The claim is later denied because the service required prior authorization or was not covered under that benefit category.
Product diagnosis: this is an eligibility semantics bug. The response should update coverage confidence and patient responsibility estimates, not promise claim payment.
Design Rule
Store eligibility as a dated payer response attached to coverage and service context. Use it to drive warnings, estimates, and next-step tasks. Do not collapse it into a single boolean named willPay.
| Signal | Bucket | Product Action |
|---|---|---|
| Payer cannot find the member. | IDN | Fix patient, subscriber, member ID, or relationship data. |
| Coverage ended before the service date. | ACT | Collect updated insurance or choose another coverage record. |
| The plan has service-type coverage details. | BEN | Show benefit context and route missing authorization if needed. |
| Response returns deductible or copay information. | OOP | Estimate patient responsibility without guaranteeing the final allowed amount. |
Retrieval Practice
Type the bucket code from memory: IDN, ACT, BEN, or OOP.
What to Ask Me Next
Ask follow-up questions whenever the boundary feels fuzzy. Good next questions: "What fields should an eligibility response store?", "How does eligibility relate to authorization?", or "How should a clearinghouse expose 270/271 results?"
For review, keep the eligibility triage card nearby.