Claims Status Follow-up

skill

Poll claim status, classify denials, and open per-claim board tasks with next-action notes.

Download .md

Claims Status Follow-up

Poll payer claim status, classify denials, and open one board task per problem claim with clear next-action notes so billing staff can work a prioritized queue instead of re-checking every claim by hand.

When to use

  • You need a recurring sweep of outstanding claims to catch denials, rejections, and stuck-in-process claims early.
  • Billing staff want a single task board queue of claims needing action instead of manually logging into a payer portal or clearinghouse.
  • You need lightweight status tracking between sweeps without storing any PHI (protected health information — patient-identifying health data) in shared notes.
  • You want the sweep to run on its own schedule (e.g. daily or every few hours) rather than being triggered manually each time.

Tools

  • http-get
  • http-post
  • create-task
  • update-memory
  • schedule-task

Playbook

  1. On each run, use http-get to pull the current claim status batch from the clearinghouse or payer API, e.g. GET https://api.clearinghouse.example.com/v1/claims?status=pending,denied,rejected. Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
  2. If the call returns 401/403 or there is no Integration configured for that host, stop the run and use send-message to notify a human, naming the service and the scopes needed.
  3. For each claim record returned, use the opaque claim or record ID only — never carry patient name, date of birth, or diagnosis details into any downstream step.
  4. Classify each claim's status code into one of: paid, pending (no action), denied, rejected, or needs-info. Use the payer's own denial/rejection codes as returned by the API; do not infer or guess a clinical reason for a denial.
  5. For every claim classified as denied, rejected, or needs-info, create one board task with create-task, titled using only the opaque claim ID (e.g. "Claim CLM-88421 — denied, code CO-16"), with a next-action note describing the administrative step needed (e.g. "resubmit with corrected NPI (National Provider Identifier)" or "attach missing referral authorization"). Never put PHI in the task title or body.
  6. If resolving a claim would require appending patient-record data beyond confirming an appointment, or would trigger a recall/reminder outreach campaign, do not act — create the task as a human-gated item and note in the task that it requires staff sign-off.
  7. Use http-post only to submit an already-approved, template-based status inquiry or acknowledgment back to the clearinghouse when the API supports it, e.g. POST https://api.clearinghouse.example.com/v1/claims/{id}/acknowledge. Any correction, resubmission, or deletion of claim data must go through http-request (PATCH/PUT/DELETE) once a human has approved the change — this skill does not perform those writes itself.
  8. After each sweep, use update-memory to record only aggregate, non-PHI counts (e.g. "sweep 2026-07-15: 12 pending, 3 denied, 1 needs-info") and the list of opaque claim IDs that received tasks, so the next run can avoid duplicating tasks for claims already queued.
  9. Use schedule-task to confirm or renew the recurring sweep cadence (e.g. daily at 07:00) so status polling continues without manual re-triggering.

Failure modes

  • Clearinghouse or payer API returns 401/403, or no Integration exists for the host — the run must stop and escalate to a human rather than retry with guessed credentials.
  • A claim status or note field contains a symptom, diagnosis, or treatment description — this is a hard-refuse trigger; do not summarize or act on the clinical content, escalate to a human immediately.
  • Duplicate tasks are created for a claim already queued from a prior sweep because update-memory state was not checked before calling create-task.
  • A denial requires a patient-record write beyond appointment confirmation, or would activate a recall/reminder campaign — these must never be executed automatically and must always route to human sign-off.

Done when

  • Every denied, rejected, or needs-info claim from the current sweep has exactly one board task with an opaque ID and a clear administrative next action.
  • No PHI appears in any task title, task body, or update-memory entry created by this run.
  • The recurring sweep schedule is confirmed active via schedule-task and the run's aggregate counts are recorded for the next cycle.