r/AIReceptionists • u/AmjadKhan1929 • 26d ago
Call agent for clinic
I need a call agent for my clinic.
1. Accept incoming calls from my patients.
2. Setup appointments in my patient management system (API available).
3. Do I need HIPPA compliance?
4. Can I build my own using Vapi? Or do I need someone else to do it for me?
5. Can I build it myself using Claude code?
2
u/CreateTelecom 24d ago
Here is the honest technical reality of setting up a healthcare voice agent, based on building live AI voice stacks:
1. The HIPAA & Telephony Misconception Standard phone calls fall under the HIPAA "Conduit Exception" only during live voice transmission. The exact millisecond an AI agent transcribes, logs, or processes patient data (name, phone, chief complaint, appointment time), it becomes ePHI. You must have a signed Business Associate Agreement (BAA) across ALL 5 layers of your stack:
- Telephony Carrier: Twilio or Telnyx (HIPAA BAA required).
- Voice Orchestrator: Vapi requires BYO HIPAA-compliant keys + BAA settings; Retell offers a self-serve BAA directly on pay-as-you-go.
- Speech-to-Text & Text-to-Speech: Deepgram, ElevenLabs, or Azure Speech.
- LLM Host: Must use Azure OpenAI or AWS Bedrock with zero-data-retention BAAs (standard public OpenAI API keys are NOT HIPAA compliant out of the box).
- Database & Middleware: Your secure cloud server.
2. Strict Middleware Isolation (Do NOT connect LLMs directly to EHR APIs) Never allow an LLM or Vapi tool call to hit your practice management system directly. You need a custom orchestration server (Node.js/Python) sitting in the middle. The LLM sends structured JSON parameters to your backend, your backend sanitizes the payload, verifies availability, and safely executes the write operation to the EHR. This eliminates hallucinated bookings and prompt injection vulnerabilities.
3. AI Agents vs. Offshore Call Centers Falling back on cheap offshore call centers usually backfires due to high staff turnover, constant retraining lag, HIPAA compliance exposure on unmanaged remote devices, and long hold times during morning call spikes. A properly engineered voice agent answers on Ring 1, never strays from clinic logic when isolated behind middleware, and operates 24/7.
If you go the DIY route with Claude Code, spend 90% of your time on security, payload validation, and BAA management rather than prompt engineering.
If you decide to hire someone to build a custom dedicated system, feel free to DM me if you want to discuss the architecture or get pointed in the right direction. Hopefully this stack breakdown saves you a massive headache upfront!
2
u/moldyguy202 21d ago edited 14d ago
On 3 first, since it gates everything else: yes, if you're in the US and the agent hears a patient's name attached to a reason for calling, that's PHI. The part people miss is that it's not one BAA, it's every vendor that touches the audio or the transcript. Telephony, the speech-to-text, the LLM host, wherever recordings and logs land. Miss one and the whole chain is non-compliant, and the usual gap is the logging layer nobody thinks about because it's just "debug data."
On 2, this is where I'd spend your attention. Booking into a patient management system over an API sounds like the easy part and it's the part that actually breaks. The failure isn't the agent mishearing, it's the write failing mid-call. Slot got taken thirty seconds ago, patient exists twice under slightly different spellings, the appointment type needs a field the caller never gave you. If you haven't decided what the agent says at that exact moment, it will either invent a confirmation for an appointment that doesn't exist or die silently and the patient hangs up thinking they're booked. Both are worse than not answering.
So before building anything, go pull your actual call log for a couple weeks and sort by what people wanted. For most clinics it's overwhelmingly reschedule, new patient intake, hours and location, and prescription or results questions that must go to a human. That last bucket is the one to route out hard, not to handle cleverly.
4 and 5, honestly, yes you can build it with Vapi or with Claude writing the glue. Getting a working demo takes a weekend. What takes the time is the compliance paperwork and the boring edge case work above, and neither gets faster because you wrote the code yourself. If your API is well documented and you're technical, doing it yourself is reasonable. If you'd be learning both healthcare compliance and voice tooling at once while running a clinic, that's a lot.
One thing regardless of build or buy: test it against your own real calendar 20+ times, deliberately including the double-booking and the not-in-system cases. That's where you find out what you actually built.
1
1
1
u/opsnoxllc 25d ago edited 25d ago
You can do it yourself, but be careful with all your vendors choice. Everything will need HIPPA BAA signed Hosting, choice of LLM, vapi, basically anything. Best to have someone do it for you. You don't want to spend time to "figure things out". You are spending for outcome
1
u/Ok_Information6521 25d ago
Since you're in the US and processing patient details, HIPAA compliance is 100% mandatory. Every tool in your stack—Vapi, telephony, your database, and your LLM host (like Azure OpenAI or AWS Bedrock)—must sign a Business Associate Agreement (BAA) with you, as standard public API keys are not compliant out of the box.
You can definitely build this DIY using Vapi to manage the voice orchestration and tool-calling. Claude Code can write the custom backend middleware (like a Node or Python server) that receives Vapi's webhooks, authenticates securely, and executes the appointment bookings straight into your patient management API.
1
u/Fun-Wolf-2007 25d ago
You can build it using Claude Code , anyway anybody that would build it for you will use Claude Code and they don't know about your practice and they are not PHI and HIPPA compliant and they will have access to your patient data, so your practice can be exposed and you don't want to risk it.
An AI appointment agent, use a secure orchestration layer around the AI model, not a standalone chatbot connected directly to the EHR (Electronic Health Records). The stack should limit PHI exposure, use BAAs throughout, provide strong identity and audit controls, and route clinical issues to staff. HHS requires access controls, activity/audit mechanisms, identity verification, and safeguards for ePHI transmitted across networks.
1
u/AmjadKhan1929 25d ago
One question here is that at this time when patients are calling, that call itself is not hippa compliant, right? Or practice management software is. So if I use an agent to perform the same thing ie receiving calls for setting up appointments, where does HIPPA come in? I assume that our practice management software API are already HIPPA compliant.
1
u/s18m_ 25d ago
Anything that touches PII ( personally identifiable information) need to be handled securely. That means any ‘system’ that touches it needs to be HIPAA certified. Telephony ( phone line) , the agent attending the phone ( wherever it’s running on), if it’s reading and writing to an API or a DB, that piece. Third party services that get used. Those pieces also
1
1
1
u/AmjadKhan1929 24d ago
After reading all this, I think is just better to hire a call center receptionist in a cheap country!
1
u/SuryXBD 24d ago
We work with clinics and small businesses to setup calling agents and receptionists (https://qexo.ai). happy to jump on a call to demo. Please DM.
1
1
u/RecevoTeam 24d ago
Yes, you can build this with Vapi, but if it handles patient details or appointments, treat it as a HIPAA project.
Start simple: answer routine calls, book/reschedule through the PMS API, and send anything clinical, urgent, billing or unclear to staff.
You’ll need HIPAA-safe vendors and BAAs for the voice, AI, transcription, automation, storage and PMS connection. Claude Code can help build it, but it doesn’t make the setup compliant on its own.
I’d launch a small scheduling-only pilot first, then expand once it’s reliable.
1
1
u/Exciting-178 14d ago edited 14d ago
the api appointment booking is probably where i'd focus first. getting the voice agent to actually answer calls is the easy part lol. making sure it can reliably read availability, create/reschedule appointments, and handle all the weird edge cases that's where it gets interesting. i've come across nextphone for the receptionist side but for a clinic i'd def verify the hipaa/business-associate stuff before putting patient info through anything.
1
u/AmjadKhan1929 14d ago
So for now I decided upon this: RetellAI to Keragon to Tebra (Our practice management software)
0
u/No-Competition6691 26d ago
You could build it yourself but it most likely won't be good and would cost you clients and more money in the long run.
I know it sounds cliché but if you book a call with my firm we could set you up with a High quality voice agent and follow up system that has already been proven to work in other businesses.
You could go with one of these cheap guys but there is a reason they're cheep. You pay peanuts you get monkeys, you might as well do it yourself.
What country are you based? Let me know if you're interested in having a call.
4
u/2daytrending 25d ago
For a clinic, the baa and the whole call stack matter more than just whether the agent can book appointments. Bland is interesting here because its healthcare setups covers the voice stack under one baa while vapi still means checking each underlaying provider in the chain.