Payer Policy Research

Research and parse public payer (health insurance company) medical policies and fee schedules so billing staff can confirm coverage rules, documentation requirements, and reimbursement rates before submitting claims.

When to use

• A biller needs to confirm whether a payer's medical policy covers a specific procedure or requires prior authorization.
• Staff need the current fee schedule (published reimbursement rates) for a CPT (Current Procedural Terminology) code from a payer's public site.
• A policy document (PDF or web page) needs to be parsed into a plain-language summary of coverage criteria.
• Findings need to be saved for the billing team to reference, without exposing any patient information.

Tools

• browser-navigate
• browser-extract
• fetch-file
• parse-document
• write-file

Playbook

1. Confirm the request is administrative: a payer name, policy topic, CPT/HCPCS (Healthcare Common Procedure Coding System) code, or fee schedule lookup. If any symptom, diagnosis, or treatment question appears, stop immediately and escalate to a human via send-message — do not respond with clinical content.
2. Identify the payer's public policy portal (e.g., the payer's "medical policy" or "provider" site) and open it with browser-navigate, for example navigating to https://www.examplepayer.com/provider/medical-policies.
3. Use browser-extract to pull the list of policy titles, effective dates, and links relevant to the requested topic or code.
4. When a policy is published as a downloadable file, use fetch-file to retrieve it (e.g., https://www.examplepayer.com/policies/policy-1234.pdf).
5. Run parse-document on the fetched PDF/DOCX to extract the policy text, including coverage criteria, prior authorization requirements, exclusions, and effective/review dates.
6. For fee schedule lookups, use browser-navigate and browser-extract on the payer's public fee schedule page or tool, capturing the code, description, and allowed amount only — no patient data is involved at this step.
7. Summarize findings in plain language: policy name, effective date, coverage conditions, documentation requirements, and any prior authorization steps required.
8. Save the summary with write-file, naming the output by payer and policy topic (e.g., examplepayer-mri-lumbar-policy-summary.md) — never include patient names, dates of birth, or condition details; if a specific record must be referenced, use only the opaque record ID supplied by the requester.
9. If the policy portal requires login credentials you don't have, or the request calls for anything beyond research (e.g., submitting an appeal, updating a patient record, or activating a recall/reminder campaign), stop and hand off to a human via send-message, naming the payer and the gap.

Failure modes

• Treating a payer's general benefit summary as a binding coverage determination — always note the policy's effective date and flag that final coverage is confirmed by the payer at claim time.
• Pulling more than the fee schedule or policy text needed, including any incidental patient-identifiable content encountered on a page — extract only the requested administrative fields.
• Missing a policy update: fee schedules and medical policies revise periodically, so always confirm the extracted document's effective date before relying on it.
• Attempting to answer a symptom, diagnosis, or treatment question embedded in the request instead of escalating it untouched to a human.

Done when

• The relevant payer policy or fee schedule has been located, parsed, and summarized in plain language with effective dates noted.
• The summary is saved via write-file using only opaque record IDs, with no PHI (protected health information — patient names, dates of birth, or conditions) present.
• Any item outside research scope (credential gaps, record updates, campaign activation) has been escalated to a human via send-message.