Confirm eligibility

Outcome

A member's coverage is current as of the date of service, the coverage_required validation rule passes, and the COB ladder (primary → secondary → tertiary) is correctly ordered for this DOS.

Prerequisites

Scope	What it lets you do
member.read	View the member detail page
eligibility.read	View the cached 271
eligibility.refresh	Trigger a 270 inquiry
member.coverage.write	Edit a coverage policy when the 271 is wrong (or missing)

A trading partner with 270/271 capability for the payer in question, or your tenant has the Manual eligibility fallback enabled.

The eligibility model

Each member has one or more coverage policies. Each policy carries the cached 271 (eligibility evidence) with a valid_at timestamp. The platform considers a coverage active on a DOS when the 271's benefit window contains the DOS and the cache hasn't aged past your tenant's eligibility_freshness_days setting (commonly 30 or 60).

Looking up a member

/members/:id (deep-link from any charge or claim). The page shows:

Tab	Contents
Overview	Demographics, primary payer, COB summary.
Coverage	All policies with priority, dates, and freshness chips.
Eligibility	Most-recent 271 per policy, in human-readable form + raw.
Authorizations	Active and historical auths.
Claims	All claims for this member.
COB	Waterfall preview — see 3.5 — COB.

The Coverage tab carries a freshness chip per policy:

Chip	Meaning
Green Fresh	271 cached within freshness window.
Yellow Stale	Within window but past half-life; refresh proactively.
Red Expired	Past window; charge will fail coverage_required.
Grey Manual	Coverage entered by hand (no 271 evidence).

Refreshing eligibility (270)

1. Open the member's Coverage tab. Find the policy whose freshness chip is yellow or red.

2. Click Refresh eligibility. The platform builds a 270 inquiry, sends it to the trading partner that handles 270/271 for the payer, and waits for the 271. The Eligibility tab updates within seconds for real-time partners; minutes for batch.

3. Read the response. The Eligibility tab shows:

   Section	What it tells you
   Eligibility status	Active, Inactive, Pending, etc. (271 EB segment).
   Plan info	Plan name, group number, network.
   Benefit details	Deductible / OOP max / coinsurance per service category.
   Service-line eligibility	Per-procedure detail, where supplied.

4. Re-validate the charge. Back on the charge or claim, click Re- validate. The coverage_required rule should now pass.

When the 271 disagrees with reality

If the 271 says inactive but the member's card says otherwise:

• The payer's enrollment file may be behind. Try a 270 again in a few hours.
• The plan may have changed. Edit the coverage policy with the new plan info and re-run.
• Manual override (with audit trail): Coverage tab → Edit policy → Override active. Use sparingly; your tenant may have a policy requiring supervisor approval.

When there is no 270/271 for a payer

Some Medicaid programs and small commercial payers don't support real-time 270/271. Two fallbacks:

1. Manual entry: enter the coverage by hand on the Coverage tab. The freshness chip shows Manual; the validator still passes.
2. Portal screenshot: attach the screenshot as proof of coverage under Documents on the policy. Some tenants require this for audit.

Validation

Check	Expected
Refresh eligibility produces a fresh valid_at	Yes.
coverage_required clears after refresh	Yes.
COB waterfall preview reorders if you flip primary/secondary	Yes.
Audit log carries a row for every override	Yes.

Troubleshooting

Symptom	Cause	Fix
Refresh eligibility fails	270 partner credentials expired or partner is down	EDI manual → trading partner detail → Test connection.
271 returns AAA reject (e.g. AAA*Y**42*N — unable to respond)	Payer system error; transient	Try again in 15 minutes.
Coverage policy ordering is wrong (Medicaid showing primary)	MSP rules need the patient context	See 3.5 — COB; Medicaid is always last-resort.
Refresh greyed out	You lack eligibility.refresh	Ask your admin.

Where to next

• 2.5 — Attach or request auth — the next prereq.
• 3.5 — Secondary & tertiary COB — how COB shapes claims downstream.