Eligibility Verification

Run batch insurance eligibility checks against clearinghouse APIs and hand staff a clean exception list instead of a pile of raw responses.

When to use

• A batch of upcoming appointments needs insurance eligibility confirmed before check-in.
• Staff need a short list of exceptions (inactive coverage, mismatched plan, missing response) instead of scanning every record.
• A recurring pre-visit eligibility sweep needs to run automatically on a schedule.

Tools

• http-post
• http-get
• shell-execute
• create-task
• send-message

Playbook

1. Pull the day's or week's scheduled-appointment list from the practice management system with http-get (e.g. GET https://api.practicemgmt.example.com/v1/appointments?date=2026-07-16). Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
2. For each appointment, extract only the fields needed for an eligibility check: opaque patient record ID, insurance payer ID, member ID, and date of service. Do not pull or carry diagnosis, condition, or other clinical fields.
3. Submit each eligibility inquiry to the clearinghouse with http-post (e.g. POST https://api.clearinghouse.example.com/v1/eligibility/inquiry with payer ID, member ID, and date of service in the body).
4. Poll or retrieve each inquiry's result with http-get (e.g. GET https://api.clearinghouse.example.com/v1/eligibility/inquiry/{inquiry_id}).
5. Use shell-execute to run a local script that normalizes the batch of clearinghouse responses and filters for exceptions: inactive coverage, plan/payer mismatch, missing or timed-out response, or any 4xx/5xx from the clearinghouse.
6. For each exception, create a task with create-task referencing only the opaque record ID and the exception type (e.g. "Record ID 4471: coverage inactive") — never the patient's name, date of birth, or condition.
7. Send the compiled exception list to the front-desk or billing staff channel with send-message, summarizing counts by exception type and linking the created tasks.
8. If any clearinghouse or practice-management call returns 401/403 or the org has no Integration configured for that host, stop and send-message a human naming the service and the scopes needed — do not retry with guessed credentials.
9. If a patient-facing eligibility or coverage question requires an outbound message beyond an org-approved appointment confirmation template, or if a patient mentions a symptom, treatment, or medication, stop immediately, do not draft a clinical reply, and escalate via create-task and send-message to a human.

Failure modes

• Clearinghouse returns an ambiguous or partial eligibility status (e.g. "pending") — treat as an exception, never assume active coverage.
• Practice management system's appointment feed includes fields beyond scheduling (e.g. clinical notes) — discard them before any further processing; never forward them into tasks or messages.
• Bulk activation of a recall or reminder campaign, or any write back to the patient record beyond a routine appointment confirmation, is requested — this is human-gated; escalate rather than execute.
• Integration/auth for the clearinghouse or practice management host is missing or expired — halt the batch and escalate instead of skipping affected records silently.

Done when

• Every scheduled appointment in the batch has a completed eligibility check or a logged exception with an opaque record ID.
• The exception list has been delivered to staff via send-message with corresponding tasks created for follow-up, and no PHI (protected health information — patient names, dates of birth, or conditions) appears in any task title or memory note.