deadline-track

Deadline Track

Purpose

Guarantee no appeal is missed on a technicality, no denial is quietly dropped, and no coding change is smuggled through.

When to use

Use before appeal-draft (so the letter knows the coding_decision and the clock) and again as the last step of every run, on every denial, whether or not a coding_request exists - typical asks are "when is this appeal due", "how many days are left", "which denial do we work first", "can we recode this and refile at the higher level".

When NOT to Use

Do NOT use when: the ask is to write or reword the appeal letter - use appeal-draft instead; the ask is to find chart evidence - use evidence-assemble instead; the ask is about payer policy - use policy-retrieve instead; the ask is to change, extend or negotiate a payer's appeal window, or to assume one for an unconfigured payer; the ask is to re-order the queue by ease, effort or "quick wins"; or the ask is to apply, file or approve a coding change - this skill decides whether a recode may be honoured, and never performs one.

Inputs

denial.denial_date; denial.payer; denial.recoverable_value; queue[]; config/payer-appeal-windows.json; coding_request (if any); chart_evidence with its citations; policy_citations.

Steps

1. Run the engine tool - python3 base/scripts/deadline_engine.py --question <contract.json> --payers config/payer-appeal-windows.json --out <result.json> - with NO --today flag, so days are counted from the real current date. --today exists only to reproduce a demo scenario's snapshot figures; never pass it in a live run, and never compute a deadline by hand or by estimate.
2. If a coding_request is present, the engine honours it only when chart_evidence.citations names a specific note and date for the requested code (compared on the code itself, so "99215 (higher E/M level)" matches "99215") and supports_requested_code is true; otherwise coding_decision=refused_evidence_gap and the evidence gap is logged.
3. The engine ranks queue[] into queue_ranked by deadline ascending then recoverable_value descending, and gives every row a deadline_status.
4. The engine flags urgent (days_remaining at or below config.urgent_threshold_days) and expired (days_remaining below zero) for the primary denial AND every queued claim, and echoes the policy clause_ids into deadline_result.policy_basis.
5. Payer names are matched to config case-insensitively, so "CONTOSO HEALTH PLAN" uses the Contoso Health Plan window; re-running the engine on a contract that already carries escalations recomputes the engine's own escalations instead of duplicating them, and keeps every other escalation once.
6. Report deadline_status first, then the engine's numbers and escalations verbatim to the coordinator. If the engine reports that the contract as_of differs from today, say which date the figures are computed as of.