Billing companies
Nightly claim status sweep into your PM system
Every unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you.
Build this with AIA brief with this use case's endpoints, events and rules, ready for your assistant to build it in your stack.
How it works
Each night, export open AR from your PM system and send it to Daybook as a worklist.
A rule checks every claim with no answer after 30 days.
Daybook runs the 276/277 checks and sends claim.status_changed only when a status moves.
Your handler writes the new status onto the claim in your PM system, and denied claims go to your denial queue.
Replaces A biller working the aging report claim by claim.
Built on
POST
/v1/worklistsCreate a worklistPOST/v1/rulesCreate a rulePOST/v1/claim-status/checksCheck claim status| Event | Sent when |
|---|---|
claim.status_changed | A claim's status differs from the last check. |
claim_status.completed | A batched check finished. |
The prompt
Paste it into Claude, Codex, Cursor or ChatGPT. It links the docs pages it needs, so your assistant builds against the real API.
I'm building on the Daybook API (healthcare billing: payer calls, payer portals, 270/271 eligibility, 276/277 claim status, 835 remits, denials and appeals). Help me build this end to end. Use case: Nightly claim status sweep into your PM system For: Billing companies Outcome: Every unpaid claim checked over 276/277 overnight, and only the claims that moved come back to you. What to build: A nightly job that exports open AR from my PM system to a CSV at a signed URL, creates a worklist with POST /v1/worklists that applies a rule made once with POST /v1/rules (no response after 30 days runs claim_status.check), and a webhook handler that takes claim.status_changed and writes the normalized status (paid, denied, pending, in process, returned or not on file) onto the matching claim. Denied claims also go to our denial queue. claim_status.completed, sent as each batched check finishes, goes in a log so the night's progress can be counted. How it works: 1. Each night, export open AR from your PM system and send it to Daybook as a worklist. 2. A rule checks every claim with no answer after 30 days. 3. Daybook runs the 276/277 checks and sends claim.status_changed only when a status moves. 4. Your handler writes the new status onto the claim in your PM system, and denied claims go to your denial queue. Read these docs first (Markdown): - https://daybookhealthcare.com/docs/workflows/claim-status.md - https://daybookhealthcare.com/docs/api-reference/worklists/create.md - https://daybookhealthcare.com/docs/api-reference/rules/create.md - https://daybookhealthcare.com/docs/api-reference/claim-status/create-check.md - https://daybookhealthcare.com/docs/worklists-and-rules.md - https://daybookhealthcare.com/docs/webhooks/verifying-signatures.md - https://daybookhealthcare.com/docs/idempotency-and-errors.md Endpoints (base https://api.daybookhealthcare.com/v1): - POST /worklists: Create a worklist - POST /rules: Create a rule - POST /claim-status/checks: Check claim status Webhook events: claim.status_changed, claim_status.completed Ground rules: - Authenticate with the header Authorization: Bearer <key>, the key read from DAYBOOK_API_KEY. sk_test_ keys open a sandbox and sk_live_ keys reach real payers. Never hard-code a key. Details: https://daybookhealthcare.com/docs/authentication.md - Send an Idempotency-Key on every POST: a fresh UUID per operation, reused only to retry that operation. A key reused with a different body answers 409 idempotency_conflict. - Verify every webhook signature before trusting the event, answer 2xx at once and do the work after. - Keep my own ids beside Daybook's, and pass them in metadata where an endpoint takes it. - Money is integer cents. - Tests and fixtures use made-up data only: the sample payers bayline, keystone and meridian, NPI 1999999984, member W000000001, claim ids like clm_8Hq2Lm. Never real patient data. - Use only the fields, endpoints and events in the docs. If something is missing, ask me rather than guess. Ask me which PM system we run and how it exports open AR, then sketch the CSV columns and the job schedule before writing code.
Related use cases
A Claude agent that works your AR listClaude checks each claim, reads the payer's last answer and the denial, and drafts the appeal for a person to approve.Recheck silent claims by phone until they moveClaims with no 276/277 answer get a payer call that repeats every few days and stops once the claim is paid.

