RCM and EHR vendors
Catch terminated coverage on open claims
When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm.
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
Run eligibility checks for patients with open claims or upcoming visits.
A re-check that finds different coverage sends coverage.changed.
Flag the patient's open claims and upcoming visits in your product.
Where the 271 leaves it unclear, start a payer call with call_type eligibility.
Built on
| Event | Sent when |
|---|---|
coverage.changed | A re-check found different coverage than the last one. |
eligibility.completed | A batched check finished. |
call.completed | The call ended with a structured answer, your metadata echoed. |
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: Catch terminated coverage on open claims For: RCM and EHR vendors Outcome: When a patient's coverage changes, your product flags their open claims and visits, and can call the payer to confirm. What to build: A coverage watch inside our product: scheduled eligibility checks with POST /v1/eligibility/checks for every patient with an open claim or an upcoming visit, a handler for coverage.changed that flags those claims and visits for the billing team, and a button on the flag that starts a payer call with POST /v1/calls (call_type eligibility) whose call.completed answer is shown on the patient. How it works: 1. Run eligibility checks for patients with open claims or upcoming visits. 2. A re-check that finds different coverage sends coverage.changed. 3. Flag the patient's open claims and upcoming visits in your product. 4. Where the 271 leaves it unclear, start a payer call with call_type eligibility. Read these docs first (Markdown): - https://daybookhealthcare.com/docs/workflows/eligibility.md - https://daybookhealthcare.com/docs/workflows/payer-calls.md - https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.md - https://daybookhealthcare.com/docs/api-reference/calls/create.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 /eligibility/checks: Check eligibility - POST /calls: Start a call Webhook events: coverage.changed, eligibility.completed, call.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 how patients, claims and visits are stored in our product, then propose the flag and where it shows before writing code.
Related use cases
Call the payer from your denial queueEvery denial a phone call settles gets one, and the rep's answer lands back on the same ticket.Verify coverage before every visitTomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives.Post finished payer calls to SlackYour team sees each payer's answer in a channel as a call ends, and a ping when a live rep is ready for a biller.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.

