Prior auth tracker

Active authorizations on file + their state machine. Lives at /admin/prior-auths.

What it tracks

Every prior authorization the practice has filed:

Column	Notes
Patient	The auth holder
Payer + plan	One auth is payer-specific
Service type	CPT / NDC / service category the auth covers
Effective from / to	Active range
Visits remaining	Counted down from the auth’s grant
Status	`pending` / `approved` / `denied` / `expired` / `exhausted`
278 reference id	X12 278 round-trip identifier

State machine

pending  ──► approved  ──► (active until expiry or exhaustion)
            └──► denied  ──► open appeal task
            └──► expired
            └──► exhausted (visits remaining = 0)

State transitions trigger:

approved → write auths_on_file row that the scrubber consults on every subsequent claim.
denied → open task in /admin/denials for appeal.
expired / exhausted → flag in the recall worklist (treatment continuity risk).

How it differs from the AI Prior-Auth Drafter

	Tracker (this page)	PA Drafter
What	Persistence + state of every auth	AI-generated packet to submit a new auth
When	Long-lived state	One-shot generation at submission time
Who reads	Billing + scheduling	Provider + biller drafting the packet

Integration with scheduling

When booking an appointment, Pollen8 surfaces:

Whether the planned visit type has an active auth.
Visits remaining on that auth.
Whether the auth expires before the appointment date.

Front desk sees this at check-in too, so PA gaps surface before the visit not after the claim.

X12 278

Real-time auth requests + responses through the configured 278 provider. Auto-creates the tracker row on submission; updates state on response. Polls inquiry-type messages where the payer doesn’t return real-time approval.