Practices
Verify coverage before every visit
Tomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives.
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
Pull tomorrow's appointments from your scheduling system.
Send one check per patient with POST /v1/eligibility/checks, or up to 1,000 at once with POST /v1/eligibility/checks/batch.
Real-time checks answer in the response; batches send eligibility.completed per patient.
Flag the appointment for the front desk when coverage is not active.
Replaces Front desk staff checking each patient on a portal the morning of the visit.
Built on
| Event | Sent when |
|---|---|
eligibility.completed | A batched check finished. |
coverage.changed | A re-check found different coverage than the last one. |
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: Verify coverage before every visit For: Practices Outcome: Tomorrow's schedule checked over 270/271 tonight, with inactive coverage flagged before the patient arrives. What to build: An evening job that reads tomorrow's appointments, sends a 270/271 eligibility check per patient as one batch with POST /v1/eligibility/checks/batch (up to 1,000 checks in a checks array; service type codes from the appointment type, provider NPI from the schedule), stores the answer next to the appointment, and flags every appointment whose coverage is not active on the front desk's list. A webhook handler takes eligibility.completed for batched checks and coverage.changed when a later re-check finds different coverage. How it works: 1. Pull tomorrow's appointments from your scheduling system. 2. Send one check per patient with POST /v1/eligibility/checks, or up to 1,000 at once with POST /v1/eligibility/checks/batch. 3. Real-time checks answer in the response; batches send eligibility.completed per patient. 4. Flag the appointment for the front desk when coverage is not active. Read these docs first (Markdown): - https://daybookhealthcare.com/docs/workflows/eligibility.md - https://daybookhealthcare.com/docs/api-reference/eligibility/create-check.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 Webhook events: eligibility.completed, coverage.changed 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 scheduling system we use and which appointment types map to which service type codes, then show the data model before writing code.