You run six clinics. Each one has a front desk, each front desk answers its own line, and when the person at that desk is checking in a patient the call rolls to voicemail or to whoever happens to pick up at another site. A patient seen at your north location calls Tuesday to move a Thursday visit, and the staff member who answers cannot see that provider's template. Meanwhile someone in the group has been asked to "look at AI phone agents," and every article they find was written for a single dental office with one doctor and one calendar.
That advice is not wrong. It is answering a smaller question. A group has three constraints a solo practice does not. Protected health information moves through a vendor's stack, so a Business Associate Agreement and real audit logging stop being nice-to-have. The agent has to write back into the practice management or EHR system that already runs your front desk, not into a side calendar. And routing has to work across locations, providers, and appointment types that differ by site. Here is what to check on each, in the order I would check it.
Why a multi-location group is a different problem than a single practice
In a single office, the phone agent needs one calendar, one set of hours, and one escalation path. In a group, every one of those becomes plural, and the plurals interact.
One patient, several places. If a PT patient is on a three-times-a-week plan of care and your Naperville site is booked solid, can the agent offer Aurora? Only if it knows which providers are credentialed where, which equipment lives at which site (the site with the X-ray unit, the site with the traction table), and whether the patient's plan permits the switch. That is a rules problem before it is an AI problem.
Two systems pretending to be one. Groups that grew by acquisition often run two practice management instances, or one instance with duplicate charts for the same human being. A voice agent will not fix that. It will surface it loudly, on the phone, in front of the patient, on day one. Decide in advance whether the agent books only when it matches a single unambiguous chart, and hands everything else to a person.
Aggregate volume changes the math. A handful of missed calls at one site looks like noise on that site's report and disappears entirely from the group rollup, but the group is the level where the loss adds up. Before you evaluate a vendor, pull the last 90 days of call detail records from your phone system: total inbound by DID, answered, abandoned, average time to answer, and volume by hour. That report is the baseline you will judge the pilot against, and it costs nothing but an hour.
Does an AI voice agent need a Business Associate Agreement? Yes, and here is the test
Under the HIPAA Privacy Rule, a vendor that creates, receives, maintains, or transmits protected health information on your behalf is a business associate and requires a written agreement (45 CFR 164.502(e) and 164.308(b)). A scheduling agent hears a name, a date of birth, a phone number, a reason for visit, and a provider. That is PHI. It is not a close call.
Vendors sometimes reach for the conduit exception, the carve-out that keeps the postal service and telecom carriers out of business associate status. HHS narrowed that exception in the 2013 Omnibus Rule to entities that merely transmit and do not access content other than incidentally. A voice agent transcribes the call, reasons over the transcript, and usually stores both. It is not a conduit.
The harder part is the chain behind the vendor. A voice stack typically has four or more links: telephony, speech-to-text, the language model, text-to-speech, plus storage and any CRM in the path. PHI passes through each. Ask for the full subprocessor list by name and confirm a BAA exists at every link. Major cloud providers (AWS, Google Cloud, Microsoft Azure) sign BAAs as a matter of course. Smaller model and speech vendors vary. "We use enterprise-grade providers" is not an answer.
There is no such thing as a HIPAA-certified voice agent. HHS does not certify or endorse products. What exists is a signed BAA, a named subprocessor list, and an audit log you can pull yourself. Everything else is a badge on a website.
The audit log and retention questions most vendors have not been asked
The HIPAA Security Rule requires audit controls: mechanisms that record and examine activity in systems containing electronic PHI (45 CFR 164.312(b)). For a voice agent, that means a per-call record you can export without opening a support ticket. At minimum: timestamp, the DID dialed, how the caller was identified, what the agent read from the practice management system, what it wrote back, whether it transferred, and to whom.
Recordings and transcripts are PHI too, which puts retention on the table. Set the retention window yourself rather than accepting a default of forever. Confirm role-based access with named users and MFA, confirm deletion on request, and get contract language prohibiting training on your call data. Then check your states: some states require all-party consent for call recording and others do not, and the rules differ enough that a group operating across state lines needs its disclosure handled per line rather than globally. Confirm the current rule for each state you operate in with your counsel.
One clause people skip: breach notice timing. You have 60 days from discovery to notify affected individuals (45 CFR 164.404). If your BAA gives the vendor 60 days to tell you, you have already lost. Ask for five business days or less.
| What to verify | The question to ask | A failing answer |
|---|---|---|
| Business Associate Agreement | Will you sign our BAA before the pilot starts, not after? | "We're HIPAA compliant" with no contract offered |
| Subprocessor chain | Name every vendor in the call path and confirm a BAA with each | "That's proprietary" |
| Audit logging | Can we export a per-call log of what was read from and written to the PM system? | Logs exist, but only their support team can pull them |
| Retention and deletion | How long are recordings and transcripts kept, and can we set that number? | Indefinite retention, or no deletion process |
| Model training | Is training on our call data contractually prohibited? | "We anonymize it," with no contract language |
| Breach notice window | How many days until you notify us of a suspected breach? | Anything at or near 60 days |
| Number ownership | Do our phone numbers stay with our carrier? | Porting the numbers to the vendor is required |
What "integrates with your EHR" actually has to mean
Three levels hide behind that phrase, and vendors rarely say which one they mean.
Level 1: read availability.
The agent can see open slots by provider, location, and appointment type. This is the minimum for the agent to say anything useful about Thursday. Watch for stale caches: if slot data refreshes every 15 minutes, the agent will offer times that are already gone.
Level 2: write-back.
The agent creates, moves, or cancels the appointment in the system of record. This is where most integrations die. The ONC Cures Act Final Rule pushed certified EHRs to expose standardized HL7 FHIR APIs, and FHIR R4 does define Appointment and Slot resources, but the certified data classes center on patient record access, not scheduling writes. Support for booking varies by vendor, by product line, and by whether you are on their cloud or a self-hosted instance. The specialty systems that actually run these clinics (WebPT, Prompt, Raintree in PT; ChiroTouch and Jane in chiropractic; Experity in urgent care; athenahealth, eClinicalWorks, NextGen, Epic in multi-specialty) each have their own partner program, rate limits, and sandbox rules. Ask for the API documentation for your version, and ask who owns the credentials. The answer should be you.
Level 3: reconciliation.
What happens when the agent and a front desk staffer grab the same 2:15 slot four seconds apart? You want idempotent writes, a conflict rule, and an alert when a write fails. Without it you get double bookings that nobody notices until the waiting room does.
If write-back is not available for your system, the honest design is a queue: the agent collects everything, creates a structured task for the front desk, and texts the patient a confirmation only after a human books it. That is a real deployment, not a failure, as long as you measure how fast the queue clears. Assume nothing about insurance eligibility either. That is a separate integration and usually a separate vendor.
Where the agent sits relative to the phone system you already own
You do not replace your phone system. You put the agent behind it. In practice that means conditional forwarding per location: forward on busy, forward on no answer after four or five rings, forward after hours. Each site keeps its own DID, and the agent routes on which number was dialed, so a caller to the Elgin line hears Elgin's hours and gets transferred to Elgin's desk.
Two things to test before go-live. First, failover: if the AI provider has an outage, the forward has to fall back to your hunt group rather than dead air. Ask the vendor to describe that path, then simulate it. Second, the 4:45 pm case: clinic B has closed, a patient of clinic B calls, and the agent needs to know whether anyone at clinic A can take a warm transfer. Write that rule down before the vendor writes the prompt. And keep your numbers with your carrier. A vendor holding your DIDs is a vendor you cannot leave.
Outbound follow-up calls change the legal picture
Inbound is the easy half. The patient called you. Outbound recall, no-show recovery, and plan-of-care dropoff campaigns put you under the TCPA as well as HIPAA. The FCC's 2015 TCPA declaratory ruling created a narrow exemption for certain healthcare-related calls and texts to wireless numbers, with frequency caps and content limits (no telemarketing, no debt collection). Appointment reminders can sit inside it. A "we miss you, come back for a wellness visit" campaign is a different animal. Confirm the current state of that exemption with your counsel before you turn on any dialer, and keep consent and revocation records you can produce.
Voicemail deserves its own rule. HHS guidance permits limited appointment reminder messages, and minimum necessary (45 CFR 164.502(b)) is the standard: practice name, callback number, the fact that it is a reminder. Not the provider's specialty, not the reason for the visit. Configure the voicemail script explicitly. Left to defaults, a chatty agent will say more than you want on a shared family answering machine.
On no-shows: pull your own baseline from the PM system by site and by appointment type before anyone quotes you a percentage improvement. I am not going to hand you an industry average, because the ones circulating rarely name a source you can check, and your Monday 8 am new-patient slot behaves nothing like your Thursday afternoon follow-up.
What voice AI is genuinely good at here, and what it is not
The strongest, most repeatable win is coverage outside business hours. Our published deployments are single-site, which is exactly the case this post says is different, so read these as the shape of demand rather than a group benchmark. At an HVAC company we work with, 79% of AI-handled calls arrive after hours (measured). At a Miami dental practice we work with, the agent has answered 3,381 calls in twelve months, and more than 900 of those calls came in outside office hours (measured). At a multi-site dental group we work with, 113 of the 550-plus calls answered in the first four months were after-hours (measured). Different industries, same pattern: a meaningful block of demand shows up when nobody is at the desk.
What it is not good at: clinical triage of any kind, quoting benefits or out-of-pocket cost, restructuring a twelve-visit plan of care around a patient's work schedule, and de-escalating an angry caller. Scope those out and route them to a human on the first turn. The other failure mode is quieter: a voice agent is a mirror. If your scheduling rules live in the heads of three long-tenured schedulers and nowhere else, the agent will book things they never would have booked. Writing those rules down is the actual project. The agent is what runs them afterward.
A pre-deployment checklist you can run in about a week
Days 1 to 2: get your baseline.
Export 90 days of call detail records by DID: volume, answered, abandoned, time to answer, hour of day. Export no-show and cancellation rates by site and appointment type. You cannot evaluate a pilot without these.
Day 3: the paperwork gate.
Request the signed BAA, the subprocessor list, the retention policy, the breach notice window, and a sample audit log export. Any vendor that stalls here is telling you something.
Day 4: the integration gate.
Confirm in writing whether write-back to your PM version is read-only, full booking, or task-queue only. Ask for a sandbox and a named reference running the same system you run.
Day 5: write the rules.
Hours per site, escalation targets per site, cross-location booking policy, identity verification standard (two identifiers), voicemail script, and the list of call types the agent must hand off immediately.
Then pilot on two locations, after hours only, for 30 days. Read every transcript for the first week. Expand when the transfer accuracy and the booking error rate are boring.
If your group is still upstream of that, at the stage where nobody agrees on which process to fix first or whether to build or buy, the sequencing work is its own engagement. Our four-week AI consulting engagement is $5,000 fixed, maps how the group actually runs, and hands over a roadmap you keep regardless of who builds it. Voice builds ship in 14 to 21 business days once the rules above are settled. If you would rather just talk through your PM system and your phone setup, book a call.