A browser-using agent checks tomorrow's patients against each payer portal overnight and writes benefits back to the chart, so the front desk starts the day with exceptions instead of a hold queue.
Benefits verification is the front-desk task nobody budgets for and everybody does: for every new patient and most recalls, someone logs into a payer portal or sits on hold to confirm coverage, deductible status, remaining annual maximum, frequency limits, and waiting periods — one payer at a time, each with a different login and a different screen. It is repetitive, it is time-boxed to the day before the visit, and when it is skipped the practice finds out at checkout. Until 2026 automating it meant buying a vertical vendor or paying an integrator to script each portal, and the scripts broke whenever a portal changed. Browser-using agents changed the build cost: Anthropic launched its browser toolset on August 19, 2026 (the same day computer use left beta), and comparable capabilities are available through the OpenAI API, which means a small integrator can now hand the agent a login and a checklist and have it drive the portal the way a human would, with the model absorbing layout changes instead of a script failing on them. The workflow: pull tomorrow's schedule from the practice management system, run each patient through the right payer portal, write the eligibility result back to the patient record, and route anything ambiguous to a human. The constraint that shapes the whole design is HIPAA. The agent vendor and the model vendor both need a business associate agreement, the data stays in the practice's tenant, and the HIPAA Security Rule in force today is the one you comply with — the final rule updating it carried a July 2027 target on OMB's Unified Agenda as of early 2026, and will come with a 240-day implementation window when it lands. If the practice is in Texas, HB 149 also requires disclosing AI use to patients no later than the first date of service.
Pull 90 days of appointments and rank payers by patient volume. Most practices find a handful of payers cover the large majority of visits. Note for each whether verification runs through a web portal, a clearinghouse API your practice already pays for, or a phone call. Automate portals and APIs; leave phone-only payers to humans. The agent is for the portals; the clearinghouse connector, where you have one, is cheaper and should be used first.
Three agreements before any PHI moves: with the model provider (the Claude API and the OpenAI API both offer business associate terms on qualifying plans — confirm in writing, not from a sales deck), with any browser infrastructure provider, and with the automation layer if it is hosted. Self-hosting n8n and running the browser inside your own environment keeps the surface small. Disable training on your data in writing. Set retention to zero wherever the vendor allows it.
Define exactly what the agent must come back with per patient: active coverage yes/no, plan type, deductible met/remaining, annual maximum remaining, frequency limit on the scheduled procedure codes, waiting period status, coordination of benefits flag, and the portal screenshot as evidence. Make every field required and allow UNABLE_TO_DETERMINE as a value. An agent that guesses a remaining maximum is worse than one that says it could not read it.
Use the browser toolset through the Claude API or the OpenAI API, or the open-source Browser Use library if you want the loop in your own code. Run tomorrow's patients for your highest-volume payer. Compare every field against a human verification of the same ten. You are measuring two things: field accuracy, and how often the agent correctly says UNABLE_TO_DETERMINE rather than inventing. Fix the checklist and the per-payer instructions until the agent is as accurate as your best front-desk person on that payer, then add the next payer.
The result lands in the patient record in your practice management system — a med spa on Zenoti writes to the client profile; a dental office writes to the eligibility note in its PMS through whatever write path it exposes, or into a Weave or Airtable staging table the front desk reviews if there is no write API. Attach the portal screenshot and the timestamp. Six months from now, when a claim is denied, the question will be what the portal showed on the day, and the screenshot is the answer.
Anything flagged UNABLE_TO_DETERMINE, any inactive coverage, any coordination-of-benefits flag, and any patient whose payer is phone-only goes to a morning exceptions list. The front desk works that list in the first hour. Everything else is already done. Keep a weekly count of exceptions by payer and by reason — a payer whose exception rate climbs usually changed its portal, and the per-payer instructions need a revisit.
If you are in Texas, add the AI-use disclosure to the new-patient paperwork now; HB 149 requires it no later than the first date of service. Then track two numbers monthly: front-desk minutes spent on verification (time one week before and one week after), and claims denied for eligibility reasons. The first falls immediately. The second is the number that pays for the project, and it takes a billing cycle to show.
Use these templates as-is or customize for your business.
{
"patient_id": "PMS record id",
"appointment_date": "YYYY-MM-DD",
"payer": "payer name as shown on the card",
"portal_or_source": "portal | clearinghouse_api | phone_human",
"checked_at": "ISO timestamp",
"coverage_active": "yes | no | UNABLE_TO_DETERMINE",
"plan_type": "PPO | HMO | indemnity | discount | UNABLE_TO_DETERMINE",
"effective_date": "YYYY-MM-DD | UNABLE_TO_DETERMINE",
"deductible_total": "number | UNABLE_TO_DETERMINE",
"deductible_remaining": "number | UNABLE_TO_DETERMINE",
"annual_max_total": "number | UNABLE_TO_DETERMINE",
"annual_max_remaining": "number | UNABLE_TO_DETERMINE",
"scheduled_codes": ["D1110", "D0274"],
"frequency_limits": [ { "code": "D1110", "limit": "2 per 12 months", "last_paid": "YYYY-MM-DD | UNABLE_TO_DETERMINE", "eligible_on_visit_date": "yes | no | UNABLE_TO_DETERMINE" } ],
"waiting_period_blocks_visit": "yes | no | UNABLE_TO_DETERMINE",
"coordination_of_benefits": "none | secondary_on_file | UNABLE_TO_DETERMINE",
"evidence_screenshot_ref": "storage id of the portal screenshot",
"needs_human": true,
"needs_human_reason": "inactive | cob | unreadable | portal_changed | phone_only | other"
}
RULE: needs_human is true if ANY field is UNABLE_TO_DETERMINE or coverage_active is not yes.You are verifying dental/medical benefits on the [PAYER] provider portal for one patient. Follow these rules exactly. 1. Log in with the stored credentials. If the login page has changed, stop and return needs_human_reason = portal_changed. Do not try alternative pages. 2. Search by member ID first; if not found, by name and date of birth. If not found either way, return coverage_active = UNABLE_TO_DETERMINE. 3. Read the eligibility, deductible, maximum, and frequency sections. Copy numbers exactly as displayed. Never calculate a remaining amount yourself — if the portal does not display it, the value is UNABLE_TO_DETERMINE. 4. For each scheduled procedure code, find the frequency limit and the last paid date. If the portal does not show history for that code, the value is UNABLE_TO_DETERMINE. 5. Take one screenshot of each section you read and attach the references. 6. Fill every field of the output schema. Do not infer, estimate, or round. Do not add fields. 7. Do not navigate to any page that is not needed for this patient. Do not open other patients. Do not download files. 8. Log out when complete. If anything on the screen is ambiguous, prefer UNABLE_TO_DETERMINE. A human will resolve it in under four minutes; a wrong number costs the practice a denied claim.
MODEL PROVIDER (Claude API / OpenAI API) [ ] Business associate agreement signed — a copy in the compliance folder, not an email saying it exists [ ] Training on our data disabled in writing [ ] Data retention set to the minimum the provider allows; retention period recorded [ ] Region of processing recorded BROWSER / INFRASTRUCTURE [ ] If using a hosted browser service: BAA signed, or run the browser inside our own environment instead [ ] Session recordings and screenshots stored in our tenant, encrypted, access-logged [ ] Portal credentials in a secrets manager; never in the prompt, never in the workflow JSON AUTOMATION LAYER (n8n or equivalent) [ ] Self-hosted, or hosted under a BAA [ ] Execution logs scrubbed of PHI or retained under the same controls as the chart PRACTICE SIDE [ ] Risk analysis updated to include the agent (comply with the current HIPAA Security Rule; the updated final rule carried a July 2027 target as of early 2026) [ ] Workforce trained on what the agent does and how exceptions are worked [ ] Texas practices: AI-use disclosure added to new-patient paperwork (HB 149, no later than first date of service) [ ] Payer portal terms of use reviewed for automated-access clauses; payers that prohibit it are routed to humans or to the clearinghouse
Get a new AI workflow every week. Prompts, tool stacks, and ROI math included.
Single agent with function-calling: one LLM with a defined toolbox (CRM, calendar, knowledge base) decides which tool to invoke at each turn. Easiest to debug; appropriate for most well-scoped business workflows.
Learn the agentic glossary →Where this workflow tends to break in production — and what to put in place before you ship it.
Agent invents or calculates a benefit figure the portal did not show
Mitigation: Every field allows UNABLE_TO_DETERMINE and the instructions forbid inference; any such field routes the patient to a human; weekly spot-check of 10 records against the screenshots.
Payer changes its portal and the agent navigates somewhere wrong
Mitigation: Instructions stop on an unrecognized login or layout and return portal_changed; exception rate by payer reviewed weekly.
PHI reaches a vendor without a BAA or ends up in automation logs
Mitigation: BAA checklist completed before go-live; logs scrubbed or retained under chart-level controls; credentials in a secrets manager only.
Portal terms of use prohibit automated access
Mitigation: Terms reviewed per payer during setup; prohibited payers routed to the clearinghouse or to humans.
Front desk trusts the chart and stops reading the exceptions list
Mitigation: Exceptions list is a daily first-hour task with a named owner; denial-for-eligibility count tracked monthly as the quality signal.
Skip this if you already pay a clearinghouse whose eligibility API covers your top payers — use that, it is cheaper and more reliable than driving a portal, and point the agent only at the payers it misses. Skip it if you cannot get a BAA from every vendor in the chain; there is no volume of saved front-desk time that justifies unmanaged PHI exposure. Skip it if your practice is small enough that verification is under an hour a day, because the setup and monitoring effort will exceed the time recovered. Do not use it on payers whose portal terms prohibit automated access, and do not let the agent estimate or calculate a benefit figure the portal did not display — the entire value of this workflow is that the number in the chart is the number the payer showed.
A phased approach to get this workflow running and delivering ROI.
Days 1–30
Foundation
Days 31–60
Optimization
Days 61–90
Scale
Three AI receptionists targeting the same SMB market but built for different niches. Here is an honest comparison of Goodcall, Rosie, and Smith.ai based on production deployments.
Both sell an AI receptionist, reviews and texting to the same office manager. Only one publishes a starting price, neither publishes an overage, and the number that decides your bill is the bulk-text allotment.
Half the dental AI vendors marketing "HIPAA compliance" cite a Security Rule update that has not been finalized. Here is what to ask for in writing, and the one design choice that makes most of the problem disappear.
One practical AI workflow per week. No fluff.
Get the full guide with step-by-step setup, workflow templates, and copy-paste assets.