Lesson 0009

Separate Eligibility from Authorization

The practical product skill: keep active coverage, authorization requirements, authorization approvals, and claim denials in separate model lanes.

Your Tangible Win

After this lesson, you should be able to classify payer evidence into four lanes: ELG, REQ, AUT, or CLM.

Primary source to read after the lesson: CMS MLN Insurance and Authorization.

The Core Idea

A 271 eligibility response can say coverage appears active and still not say whether a specific service required prior authorization. CMS describes eligibility inquiry/response as information about eligibility and coverage under a health plan (CMS eligibility transaction overview).

Prior authorization is a different workflow. CMS says prior authorization workflows request authorization for medical items and services, and electronic prior authorization can provide coverage and documentation requirements (CMS Electronic Prior Authorization). CMS MLN separately treats prior authorization numbers as payer-assigned values for the current service (CMS MLN Insurance and Authorization).

The Four Lanes

Lane Question Example Evidence Do Not Store As
ELG Does coverage or benefit information appear to apply? 270/271 response, active status, copay, deductible, service-type benefits. Authorization approval or final payment decision.
REQ Does this service require authorization or documentation? Payer rule, API response, companion guide, plan policy, service-specific requirement. Approval number.
AUT Did the payer approve, pend, deny, or issue a reference for the request? Authorization number, status, valid dates, approved units, service scope. Eligibility response or claim denial.
CLM What happened after claim submission? Claim rejection, denial, payment, adjustment, or remittance outcome. Pre-claim authorization state.

Important Combinations

Active + Missing Auth

Coverage can be active while a specific service still needs authorization. This is the exact bug from Lesson 0008.

Auth Approved + Claim Denied

An approval can still fail later for coding, timely filing, provider enrollment, place of service, or policy edits.

Inactive + Auth Exists

An old or transferred authorization does not prove coverage is active for the service date.

Mini Case

Eligibility returns active coverage and therapy benefits. The product auto-marks the visit as ready to bill. The claim later denies because the plan required prior authorization for that therapy service after the first visit.

Product diagnosis: eligibility was modeled as authorization. The product needed a separate authorization requirement lane and an authorization decision lane before claim submission.

Design Rule

Do not let one boolean like insurance_ok hide multiple payer questions. Use separate states for eligibility, requirements, authorization, and claim outcome.

Unsafe Field Safer Replacement
insurance_verified = true eligibility_status = active_for_date
authorization_ok = true auth_requirement = required and auth_status = approved
will_pay = true claim_status = not_submitted until a payer adjudicates or rejects.

Scenario Practice

Choose the lane that should own the fact: ELG, REQ, AUT, or CLM.

1. A 271 says the member is active for the service date and has therapy benefits. Which lane owns this?
2. A payer rule says therapy needs prior authorization after the first visit. Which lane owns this?
3. The payer issues approval number A123 for six therapy visits from March 1 through April 15. Which lane owns this?
4. The claim denies with a payer reason that prior authorization was missing. Which lane owns the denial result?
5. Eligibility is active. Requirement says authorization required. No authorization exists. What is the safest claim-prep decision?
6. Product design review: someone proposes one table column named payer_ok for eligibility, auth, and claim outcome. What should you recommend?

What to Ask Me Next

Ask follow-up questions when you want to turn this into schema design. Good next questions: "What tables do I need for prior auth?", "How do I model auth status changes?", or "How do I block claim submission safely?"

For review, keep the eligibility authorization boundary nearby.