AI Receptionist for Medical Office (HIPAA Guide)

Every vendor selling an AI receptionist into a medical office tells you they're HIPAA-compliant. Almost none of them show you what that actually means in their stack — where Protected Health Information lives at each layer of the call, which subprocessor holds what, and which Business Associate Agreements have to be in place for the answer to be true.

This guide is the work a competent in-house compliance officer would do on a free afternoon. It traces PHI through every layer of an AI receptionist's call path, names which vendors sign BAAs and through which contract path, gives you the audit-log specifics HIPAA actually requires, walks through the breach-response timeline, and overlays the state laws that sit on top of HIPAA. It also tells you when not to deploy an AI receptionist in a medical office at all — something no vendor page will.

What an AI receptionist for a medical office actually does

An AI receptionist is a voice agent that answers your practice's phone line and handles the routine calls a human front desk handles: new-patient inquiries, appointment booking and rescheduling, prescription refill requests, billing questions, and routing urgent calls to the on-call clinician. It picks up every call, including the ones that arrive after-hours, during lunch, or while your team is already on another line. For a deeper walkthrough of the mechanics, see our explainer on how AI receptionists work.

The PHI surface starts the moment the caller says more than "hello." A new-patient call collects a name, date of birth, chief complaint, insurance details, and appointment reason — all of those are Protected Health Information under 45 CFR 160.103. Even a refill call ("I'm calling for Margaret Reyes, her usual atorvastatin prescription") is PHI: it ties an identifiable person to a medication. The HIPAA question for a medical office is not whether the AI receptionist touches PHI — it does, immediately. The question is whether every layer that processes that PHI is covered by a BAA, whether the audit trail meets the Security Rule, and whether you'd survive an OCR audit if the call recordings were subpoenaed.

Why "HIPAA-compliant" on a vendor page is not a yes/no answer

HIPAA compliance is a property of a deployment, not a product. A vendor can be a HIPAA-capable building block — meaning their architecture supports a compliant deployment if you sign the right contracts and configure them correctly — but no vendor can make your office compliant on their own. The covered entity (your practice) carries ultimate responsibility under 45 CFR 164.

The Office for Civil Rights at HHS enforces three rules that matter here:

• The Privacy Rule (45 CFR 164.500–534) — what PHI is, who can access it, what uses and disclosures are permitted without authorization.
• The Security Rule (45 CFR 164.302–318) — the administrative, physical, and technical safeguards required for electronic PHI (ePHI). This is where audit logs, access controls, and encryption requirements live.
• The Breach Notification Rule (45 CFR 164.400–414) — what counts as a breach, who has to be notified, and on what timeline.

A vendor's "HIPAA-compliant" claim usually means two things: (1) they will sign a BAA with your practice, and (2) their own subprocessor BAAs are in place. A vendor whose marketing page says "HIPAA-compliant" but who can't show you the chain in writing is selling you a posture, not a program.

How PHI flows through an AI receptionist call

This is the diagram nobody in the top of the search results publishes, and it's the most important thing for a medical-office buyer to understand. A typical AI receptionist call passes PHI through six discrete services. Each one needs a BAA in place.

Patient phone
     │
     ▼
[1] Telephony provider (Twilio / Telnyx / Bandwidth)
     │ — receives audio, often records the call
     │
     ▼
[2] ASR / Speech-to-Text (Deepgram / Whisper / Transcribe Medical)
     │ — converts audio to text; transcripts contain PHI
     │
     ▼
[3] LLM (OpenAI / Anthropic / Gemini / self-hosted Llama)
     │ — reads the text, decides the response; sees full PHI
     │
     ▼
[4] TTS / Text-to-Speech (ElevenLabs / Cartesia / Azure / Polly)
     │ — converts response back to audio
     │
     ▼
[5] Storage (S3 / Azure Blob / GCS — vendor's or yours)
     │ — call recordings, transcripts, structured fields
     │
     ▼
[6] Analytics / dashboards (vendor-hosted or third-party)
     │ — call volume, quality scores, transcripts for review
     │
     ▼
Your EHR / PMS — Epic, athenahealth, eClinicalWorks, etc.

At each numbered layer, three things matter for HIPAA: who runs it, what they retain, and whether you have a BAA. A vendor that signs a BAA at layer 1 but uses an LLM at layer 3 that doesn't have one — for example, the standard OpenAI API instead of Azure OpenAI — has a broken chain. The "conduit exception" in 45 CFR 164.502(e) is narrow: it covers pure transmission (a phone carrier moving bits) but does not cover services that process, store, or analyze PHI. Any vendor citing the conduit exception for an ASR or LLM layer is wrong; ask for the legal opinion in writing if they push back.

Which vendors sign BAAs (and through which path)

The most important table in this guide. The status column reflects each vendor's published terms as of late May 2026. "Indirect" means the BAA exists only through a specific contract path — the vendor's public API tier does not include one.

Layer	Vendor	BAA status	How to get it
Telephony	Twilio	✅ Direct	Sign Twilio BAA addendum; enable PHI logging controls
Telephony	Telnyx	✅ Direct	Request BAA via support; available on standard contracts
Telephony	Bandwidth	✅ Direct	Request BAA; standard for healthcare deployments
ASR	Deepgram	✅ Direct	BAA available on enterprise tier
ASR	AWS Transcribe Medical	✅ Direct	Covered under AWS HIPAA BAA
ASR	AssemblyAI	✅ Direct	BAA on enterprise plans
ASR	OpenAI Whisper (hosted API)	⚠️ Indirect	Standard OpenAI API does not sign BAAs; access Whisper via Azure OpenAI Service or run open-source Whisper self-hosted
LLM	OpenAI (standard API)	❌ Not signed	OpenAI's public terms exclude BAAs for the standard API
LLM	OpenAI via Azure OpenAI Service	✅ Direct	Covered under Microsoft Azure BAA; the only Microsoft-sanctioned path for HIPAA
LLM	OpenAI Enterprise (direct)	✅ Direct	Available through OpenAI Enterprise sales contract
LLM	Anthropic Claude (standard API)	⚠️ Indirect	Standard API does not sign BAAs
LLM	Anthropic via AWS Bedrock	✅ Direct	Covered under AWS BAA when accessed through Bedrock
LLM	Anthropic Enterprise (direct)	✅ Direct	Available through direct enterprise contract
LLM	Google Gemini via Vertex AI	✅ Direct	Covered under Google Cloud BAA
LLM	Self-hosted Llama / Mistral	✅ No third-party BAA needed	You're running the model; only the hosting layer (your AWS/Azure/GCP account) needs a BAA
TTS	ElevenLabs	⚠️ Enterprise	BAA on enterprise tier only
TTS	Cartesia	⚠️ Enterprise	BAA available on enterprise contract
TTS	Azure Neural	✅ Direct	Covered under Azure BAA
TTS	Amazon Polly	✅ Direct	Covered under AWS BAA
Storage	AWS S3 / Azure Blob / GCS	✅ Direct	Covered when account-level HIPAA BAA is signed with the cloud provider

The two cells that catch buyers off-guard most often are OpenAI standard API and Anthropic standard API. A vendor that says "we use the latest GPT-4" or "Claude powers our agent" without specifying Azure OpenAI, Bedrock, or an enterprise contract has an uncovered LLM layer. That's a chain break, and chain breaks are how OCR audits start.

A separate point worth stating clearly. Your BAA is between your practice and your AI receptionist vendor. The vendor's BAAs with their subprocessors — Twilio, Deepgram, Microsoft, AWS, ElevenLabs — are their problem to maintain. But you should ask to see written confirmation that those subprocessor BAAs exist, name them in the subprocessor list, and verify the list is updated when subprocessors change.

The audit log: what HIPAA actually requires

HIPAA Security Rule §164.312(b) requires the covered entity to "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." That's the formal text. What it means in practice for an AI receptionist deployment:

A 14-point audit-log checklist, drawn from the Security Rule's "Information System Activity Review" requirement (§164.308(a)(1)(ii)(D)) and common OCR audit findings:

1. Caller identifier and timestamp — phone number (or hashed identifier), call start, call end.
2. Call recording — audio file, stored encrypted at rest.
3. Transcript — text version, time-aligned to the audio.
4. Structured intake fields — what data the agent collected (DOB, insurance, chief complaint, etc.).
5. Outbound actions — what the agent wrote to the EHR/PMS, what messages it sent.
6. Internal access log — every time a staff member opens this call's recording or transcript, with their user ID and timestamp.
7. External access log — any export, download, or API access to this call's data.
8. Retention schedule — when this record is scheduled for deletion (the vendor must enforce, not just document).
9. Immutability guarantee — once written, logs can't be edited by anyone, including admins.
10. Cryptographic integrity — logs hashed or signed so tampering is detectable.
11. Subject of consent — was the caller told they were talking to an AI? (Some state laws require this; HIPAA itself doesn't.)
12. System-event log — agent failures, fallback handoffs, vendor system updates.
13. BAA-event log — when the vendor adds or removes a subprocessor, the timestamp of that change.
14. Export format — ability to produce logs in a format an OCR auditor can ingest (typically CSV or JSON, dated, signed).

The retention requirement under §164.316(b)(2) is 6 years from the date of creation or last effective date, whichever is later. Sales engineers occasionally quote 1 year or 3 years, which is wrong. Get the 6-year retention commitment in writing.

The breach response timeline

If a breach happens — a misrouted recording, a subprocessor incident, a credential leak — the clock starts immediately. HIPAA's Breach Notification Rule gives you these deadlines:

Trigger	Who must be notified	Deadline	Source
Any breach affecting any number of records	Affected individuals	60 days from discovery	45 CFR 164.404
Breach affecting 500+ residents of a state	Prominent local media	60 days from discovery	45 CFR 164.406
Breach affecting 500+ individuals overall	HHS (via online portal)	60 days from discovery	45 CFR 164.408
Breaches affecting fewer than 500 individuals	HHS (via online portal)	Within 60 days of the end of the calendar year	45 CFR 164.408
Breach by business associate	Covered entity	"Without unreasonable delay," not later than 60 days from discovery	45 CFR 164.410

State-level deadlines often run shorter or apply to smaller breach thresholds. California's Confidentiality of Medical Information Act has historically required reporting within 15 business days for unauthorized access incidents, with additional consumer-notification timelines under California's data-breach statutes. Verify the current California Department of Health Care Services and California Attorney General guidance for your specific incident type. The New York SHIELD Act requires breach notification "without unreasonable delay" with specific AG and consumer-credit-reporting agency notifications.

The question to ask your AI vendor's sales engineer: "What is your incident-response SLA between detecting an issue and notifying me as the covered entity?" A vendor that can't answer in days (not weeks) has not built a real incident-response program.

State law overlay: what sits on top of HIPAA

HIPAA is a floor, not a ceiling. Five state laws regularly catch medical offices off-guard:

State	Law	What it adds beyond HIPAA
California	Confidentiality of Medical Information Act (Civil Code §56)	Broader definition of "medical information," private right of action for individuals, stricter consent for some disclosures
California	California Consumer Privacy Act / CPRA	Some PHI categories carry CCPA rights when not subject to HIPAA
New York	SHIELD Act (GBL §899-aa, §899-bb)	Reasonable-security requirement applies even to non-HIPAA data held by healthcare entities; broader breach notification triggers
Texas	HB 300 (Health & Safety Code §181)	Extends "covered entity" definition beyond HIPAA; requires biennial employee training; allows state AG enforcement
Washington	My Health My Data Act (RCW 19.373)	Applies to "consumer health data" beyond HIPAA; explicit consent and right-to-delete; private right of action
Illinois	Genetic Information Privacy Act / BIPA (for voiceprints)	Voice biometrics may trigger BIPA; written consent before voiceprint collection

A relevant note for AI receptionists specifically. Illinois courts have applied the Biometric Information Privacy Act to voiceprints collected by call-center technology. An AI receptionist that stores a voiceprint (not just an audio recording, but a derived biometric template) may need to obtain prior written consent under BIPA. Most current AI receptionist deployments do not store voiceprints — they store audio and text — but a vendor selling "voice authentication" or "voice biometrics" features for returning callers should be asked the BIPA question explicitly.

Due-diligence checklist: 16 questions for the vendor's sales engineer

Walk through these in a discovery call, before signing anything. A green-light answer is concrete and verifiable. A yellow-flag answer is hedged or routes you to "our legal team will be in touch." A red-flag answer is incorrect, dismissive, or contradicts something published on the vendor's site.

1. Will you sign a BAA with my practice that covers your full call path, including subprocessors?
2. Name every subprocessor that touches PHI, layer by layer. (Expected: telephony, ASR, LLM, TTS, storage, analytics.)
3. For each subprocessor, show me the BAA you've signed with them.
4. Which LLM do you use, and through which contract path? (Look for "OpenAI standard API" — red flag — versus "Azure OpenAI" or "Bedrock" — green.)
5. Where is call audio stored, in which AWS / Azure / GCP region?
6. What's your retention policy on audio, transcripts, and structured intake fields? Can I configure shorter retention?
7. What's the export format and process for audit logs? Can I retrieve a date range in CSV or JSON?
8. How long are audit logs retained? (Expected: 6 years minimum.)
9. Are audit logs immutable, and how is integrity verified?
10. What's your breach-response SLA — from internal detection to notifying me as covered entity?
11. Do you have a SOC 2 Type II report? Can I see the latest one under NDA?
12. Do you have a HITRUST certification? Which assessment level?
13. What's the process for me to terminate the agreement and have my PHI purged? Will you provide a purge confirmation in writing?
14. Do you store voiceprints or any voice-derived biometric template? (Relevant for BIPA compliance.)
15. Does your platform support patient AI-disclosure consent capture at call start? (Useful in California and Washington.)
16. What happens during a US-region outage — does the call fail over to another region, and does that region have the same BAA coverage?

A vendor who can answer 12+ of these cleanly has an operational HIPAA program. A vendor who hedges on more than 4 is selling marketing posture, not a program.

When not to deploy an AI receptionist in a medical office

Vendor pages will tell you AI receptionists are right for every medical office. They're not. Four scenarios where a managed human receptionist or a hybrid model is the more defensible choice:

Pediatric practices — parental-consent and minor-confidentiality rules around contraception, mental health, and substance use vary by state and are operationally complex for an AI to handle correctly. The cost of mis-routing a 16-year-old's confidential call is high.

Substance use disorder (SUD) treatment — 42 CFR Part 2 is materially stricter than HIPAA. It requires specific patient consent for almost any disclosure, has narrower BAA frameworks, and limits the redisclosure of records. Most general AI receptionist platforms have not been designed against Part 2 requirements. If your practice is SUD-only or has a dedicated SUD program, the deployment work is materially larger.

Behavioral health crisis lines and suicide-prevention intake — every empathy-collapse failure mode is consequential here. Hardcoded escalation to a trained human within seconds, not minutes, is the minimum. Most off-the-shelf AI receptionists do not meet this bar.

Government / VA / military medicine — FedRAMP layers on top of HIPAA. Most commercial AI receptionist vendors are not FedRAMP-authorized, so a VA hospital cannot deploy them on the government cloud side. A commercial-side intake line is sometimes feasible; the government-cloud side usually isn't.

For practices in any of these categories, our preference would be to build a hybrid model — AI handles after-hours overflow and routine scheduling, human covers the sensitive flows — rather than deploy AI as the front line. If that fits your operation, the AI voice agent service page covers our build-and-run model. If you want a vendor-by-vendor comparison rather than a HIPAA framework, see our voice AI for patient intake comparison.

FAQ

Is OpenAI HIPAA compliant?

Standard OpenAI API access (chat.openai.com, api.openai.com) does not include a BAA. To use OpenAI models in a HIPAA-covered deployment, you must access them through Microsoft Azure OpenAI Service (covered under Azure's BAA) or via an OpenAI Enterprise contract. A vendor that uses GPT-4 through the standard API in a HIPAA deployment has an uncovered LLM layer.

Does the AI vendor need to be HITRUST-certified?

No, but HITRUST is one of the strongest evidence signals. SOC 2 Type II is a weaker signal that's still meaningful. Neither certification replaces a BAA — they are independent. A vendor with both a signed BAA and a current HITRUST report has done the work.

Can the AI receptionist read out PHI to family members?

Only with proper authorization on file. HIPAA's minimum-necessary rule and the patient's existing authorizations control what can be disclosed. A well-designed AI agent should default to "I can confirm an appointment exists; I can't share details until I verify the caller's identity." Vendors that ship with open disclosure defaults need to be reconfigured before go-live.

What happens to call recordings if I terminate the vendor?

This must be in your BAA. Typical clauses require the vendor to return or destroy all PHI within 30 days of termination and provide written confirmation. A vendor whose BAA is silent on termination handling is a procurement risk.

Does the patient need to be told they're talking to an AI?

HIPAA itself does not require AI-disclosure consent. Some state laws and emerging regulations (California's AB 2013, Washington's My Health My Data Act in some interpretations) point toward explicit disclosure being required or strongly encouraged. The defensible default is to disclose at call start ("This is the automated assistant for Dr. Smith's office; I can help with scheduling and routing").

Are there terms the AI shouldn't say back?

Diagnostic statements ("you have diabetes"), specific medication doses ("take 20 mg of lisinopril"), and clinical advice ("you should go to the ER") should never be generated by the AI receptionist — those are clinical decisions, not reception tasks. Most well-designed agents have these as hardcoded refusals; verify it during the demo.

---

If your practice is past the framework stage and wants this built and operated end-to-end with the BAA chain, audit logging, and breach-response plan in place, our AI voice agent service is the engagement. If you're earlier and still picking vendors, the voice AI for patient intake comparison walks through the ten vendors most often considered for medical-office deployments.