prior-authorization-clinical-policy

Overview

Guides structured evaluation of prior authorization (PA) clinical policies, coverage determinations, step therapy protocols, and appeals. The skill encodes payer policy logic so the agent can assess whether a requested service meets authorization criteria, identify documentation gaps, and recommend an appeal strategy. It produces an informational recommendation with cited criteria, not a binding coverage determination.

Workflow

<Workflow - Evaluate Authorization Request description="Assess whether a requested service meets prior authorization criteria and classify the outcome." tools=[file_read, web_search, url_fetch, get_current_time] triggers=["User asks to evaluate a prior authorization request", "assess medical necessity", "check step therapy", "determine Medicare LCD or NCD coverage", "classify a PA outcome"]

1. [Agent] Identify the service type (drug under a pharmacy benefit, procedure, DME, or imaging) and the payer type from the request. Validate: Both service type and payer type are determined. If fails: [Ask user] Request the missing service type or payer type.

2. [Agent] Establish the applicable policy source: formulary for pharmacy, NCD/LCD for Medicare, or internal clinical criteria for commercial and Medicaid. If the current policy is not supplied, use web_search and url_fetch against the payer or the CMS Medicare Coverage Database, preferring official sources. Validate: A specific policy source is identified, or the assumption is stated per Rule 4. If fails: State that the payer's published policy must be confirmed and continue with clearly labeled general criteria.

3. [Decide] For Medicare requests, read references/cms-coverage.md and check for an applicable NCD first (Rule 6).

   • NCD exists and criteria met -> classify as approvable, cite NCD compliance.
   • NCD exists and criteria not met -> classify as deniable, cite the NCD.
   • No NCD -> evaluate the LCD or plan policy using the LCD checklist in references/cms-coverage.md. Validate: NCD status is resolved before any LCD or plan evaluation. If fails: Re-check the Medicare Coverage Database for a superseding NCD.

4. [Agent] Evaluate medical necessity by matching diagnosis and clinical evidence to the five-part test in references/clinical-criteria.md. Validate: Each of the five medical necessity elements is addressed as met, unmet, or undetermined. If fails: List the elements that cannot be assessed and the documentation needed to close them.

5. [Agent] Check step therapy using the rules and sequences in references/clinical-criteria.md: confirm required prior treatments were tried for the adequate duration, or that a documented failure, intolerance, contraindication, or step-skip exception applies. Validate: Step therapy is satisfied, unsatisfied with a specific missing step, or exempt via a documented exception. If fails: Identify which step is missing and what documentation would satisfy it.

6. [Agent] Assess documentation completeness against the criteria identified above, then call get_current_time to check any PA expiration or turnaround deadline referenced in references/denials-and-timelines.md. Validate: Every required supporting element is marked present or missing, and relevant deadlines are computed against the current date. If fails: List each missing element explicitly.

7. [Decide] Classify the outcome by applying the master decision tree in references/cms-coverage.md internally (Rule 5): approvable, deniable with a cited reason, or pend for additional information. Validate: The classification names the deciding criterion, threshold, or code. If fails: Return to the step that produced the ambiguity and resolve it.

8. [Agent] Present the recommendation using <Template - Recommendation>, including the Rule 2 disclaimer and any Rule 9 escalation. Validate: The response leads with the classification, cites specific criteria, and includes the disclaimer. If fails: Rewrite to match <Template - Recommendation>.

</Workflow - Evaluate Authorization Request>

<Workflow - Plan Appeal or Escalation description="Build an appeal strategy or peer-to-peer plan for a denied prior authorization." tools=[file_read, web_search, url_fetch, get_current_time] triggers=["User asks to plan a PA appeal", "appeal a denial", "prepare for a peer-to-peer review", "request a formulary exception", "respond to a denial reason code"]

1. [Agent] Obtain the specific denial reason and any CARC code from the denial letter. Map it to a category and recommended action using references/denials-and-timelines.md. Validate: The denial reason is mapped to a specific category and action. If fails: [Ask user] Request the denial letter or the exact reason code.

2. [Decide] Determine the payer track (commercial or Medicare Part C/D) and select the correct appeal ladder and timelines from references/appeals-and-formulary.md. For a non-formulary drug, evaluate the formulary exception path instead. Validate: The correct appeal ladder or exception path is chosen for the payer type. If fails: Confirm the payer type, then reselect. Do not apply commercial timelines to Medicare (Rule 8 on accuracy).

3. [Agent] Call get_current_time and compare against the denial date to confirm the appeal deadline and whether an expedited timeline applies, using the urgency rules in references/denials-and-timelines.md. Validate: The applicable deadline and standard-versus-expedited track are stated. If fails: Flag that the deadline cannot be computed without the denial date and request it.

4. [Agent] Assemble the appeal package: address each unmet criterion from the denial with targeted evidence, and build the documentation set from the checklist in references/appeals-and-formulary.md. Validate: Every cited denial reason has a corresponding piece of evidence in the plan. If fails: List denial reasons that lack supporting evidence.

5. [Decide] Does the task require peer-to-peer preparation, an experimental determination, or medical record review (Rule 9)?

   • Yes -> Note the peer-to-peer best practices from references/appeals-and-formulary.md and escalate to the treating physician or a compliance professional.
   • No -> proceed. Validate: Escalation need is explicitly resolved. If fails: Default to recommending human expert review.

6. [Agent] Present the appeal strategy using <Template - Recommendation>, leading with the recommended level and deadline, and including the Rule 2 disclaimer. Validate: The response names the appeal level, deadline, evidence to submit, and the disclaimer. If fails: Rewrite to match <Template - Recommendation>.

</Workflow - Plan Appeal or Escalation>

<Template - Recommendation> Structure every response as follows. Lead with the direct recommendation or classification in no more than three sentences, then justify, then caveat. Use tables for comparisons and bullets for criteria lists. Omit background the user already knows. Target 200 to 400 words unless the user requests exhaustive detail.

1. Recommendation: the classification (approvable, deniable, pend, or appeal at level X) in plain terms.
2. Justification: the specific criteria, thresholds, codes, or policy sections that drive it.
3. Gaps and next steps: missing documentation and the action to close each gap.
4. Caveats and disclaimer: state that this is informational only, that an individual coverage determination requires a licensed clinician, and that appeals or regulatory questions may require a healthcare compliance professional or attorney. Note any escalation required per Rule 9. </Template - Recommendation>

When NOT to use this skill: making coverage determinations for individual patients, situations where a payer-specific contract overrides published policy, or adjudicating appeals that require medical record review. These require a licensed professional.