HIPAA Compliance for Voice AI: What WFW Handles, What You Handle

This post is for informational purposes only and is not legal advice. Consult qualified HIPAA counsel before deploying voice AI in healthcare settings.

"HIPAA compliant" is one of those phrases that gets used as a binary when it's really a spectrum of specific obligations. "This product is HIPAA compliant" doesn't mean much on its own. What matters is: which specific obligations does the product meet, which ones remain with you, and how do you document all of it?

Here's the breakdown for WFW-powered voice AI in dental and healthcare settings.

What "HIPAA Compliant Voice AI" Actually Requires

Four things:

1. A signed Business Associate Agreement (BAA) with every vendor that touches PHI on your behalf. WFW is a Business Associate if your agents handle PHI. You need a BAA with WFW. If you're a SaaS vendor building on WFW, your customers need a BAA with you.

1. PHI handling controls — how PHI is transmitted, stored, and protected at rest and in transit. Encryption standards, access controls, audit logs.

1. Breach notification procedures — what happens if PHI is exposed, and how you notify affected individuals and HHS.

1. Minimum necessary standard — only collect and use the minimum PHI required for the purpose. Storing full call transcripts that include insurance details for 7 years when you only needed to know whether the caller booked an appointment is a compliance risk.

HIPAA doesn't care whether you're using AI or a human receptionist. The obligations are the same. The technical controls are different.

What WFW Handles

BAA availability. WFW offers a standard BAA for healthcare operators. Request one through the partner portal. It covers WFW's role as a Business Associate for PHI processed through the voice platform.

Transcript encryption. All call transcripts are encrypted at rest (AES-256) and in transit (TLS 1.3). Transcript storage is isolated per business account with access controls enforced at the API layer.

PHI redaction in tool calls. When the agent makes a tool call (to check availability in Dentrix, for example), PHI in the call parameters is redacted before logging. The tool call log stores operation type and outcome, not the patient's date of birth or insurance ID that was passed as a parameter. This is enforced by the wwcompliancerules layer at enforcedAt: 'tool_call'.

Audit log. Every access to a transcript, every configuration change, every API call that touches a call record is logged with actor ID, timestamp, and action. The audit log is available via GET /v2/audit-log and is retained for 7 years.

HIPAA-phrasing compliance rules. The dental VIL includes compliance rules that enforce specific phrasing requirements before PHI collection. The agent cannot proceed to collect a caller's date of birth or insurance information without the required verification disclosure. These rules run at enforcedAt: 'response_generation' — they intercept the agent's output before it's spoken.

Access controls. API access is scoped. A read-only service account cannot access transcripts from businesses it's not authorized for. Multi-tenant isolation is enforced at the data layer, not just the application layer.

What You Handle

BAA with your customers. If you're a SaaS vendor building on WFW, you are a Business Associate to your healthcare customers. You need your own BAA with each of them. WFW's BAA with you covers WFW's obligations; it does not cover your relationship with your customers.

User access management. Who at the dental practice can log in to your dashboard and access call transcripts? That's your access control system, not WFW's. HIPAA requires that access to PHI is limited to workforce members who need it. Implement role-based access in your product and enforce it.

Downstream data handling. If you pull transcripts from the WFW API and store them in your own database, your database's PHI handling is your responsibility. WFW's encryption and access controls stop at the API boundary. What you do with the data after GET /v2/calls/{id}/transcript returns is governed by your own compliance posture.

Breach notification. If PHI is exposed through your system (not WFW's), the breach notification obligation is yours. Know your timeline: 60 days from discovery for individual notification, 60 days from discovery to HHS. Your incident response plan should cover AI-specific scenarios (prompt injection that caused PHI disclosure, transcript data in logs, etc.).

The minimum necessary standard for transcript retention. Do you need to retain full call transcripts forever? Probably not. Define a retention policy — 90 days, 1 year, whatever is appropriate for your use case — and implement automated deletion. The DELETE /v2/calls/{id}/transcript endpoint deletes the transcript while retaining the call metadata (duration, outcome, extractions).

The Compliance Layer in Code

The wwcompliancerules table stores rules that the compliance layer enforces at specific points in the call lifecycle:

-- Examples from the dental_receptionist template
SELECT rule_type, enforced_at, description
FROM ww_compliance_rules
WHERE template_id = 'dental_receptionist';

-- rule_type                  | enforced_at           | description
-- phi_collection_disclosure  | response_generation   | Requires verification phrase before collecting DOB/insurance
-- no_diagnosis_disclosure    | response_generation   | Blocks any phrasing that could be interpreted as diagnosis
-- phi_in_tool_params         | tool_call             | Redacts PHI from tool call logs
-- transcript_encryption      | transcript_storage    | Enforces encryption at storage time

Rules at responsegeneration are the most protective — they run before the agent speaks, not after. Rules at transcriptstorage and tool_call handle data handling. The compliance layer is additive: you can add rules to your agent's configuration, but the base HIPAA rules in the dental template cannot be removed without explicit partner-level authorization.

Specific Dental Flows: What PHI Stays in the Call

When a caller asks to schedule an appointment, the agent may need to verify their identity. This involves collecting PHI: name, date of birth, possibly insurance member ID. Here's how the flow handles PHI:

• Name and appointment purpose: extracted into wwcallextractions for scheduling use. Retained per your retention policy.
• Date of birth (for identity verification): used in the tool call, redacted from the tool call log, not stored in extractions. The outcome of the verification (pass/fail) is stored; the DOB itself is not.
• Insurance member ID: same as DOB — used in the Dentrix tool call, redacted from logs, not stored in extractions.
• Appointment details (date, time, provider): extracted and stored. This is needed for confirmation and scheduling workflow.

The design principle: extract what downstream systems need, discard what they don't. The transcript itself is encrypted and retained per policy; the extractions table contains structured data without unnecessary PHI.

The Review Queue as a Compliance Tool

Configuring the review queue to flag high-risk calls creates documented evidence that AI-handled calls are subject to human oversight. This isn't legally required by HIPAA, but it creates an audit trail that demonstrates reasonable safeguards.

Flag for review: calls where PHI was collected, calls over a certain duration, calls that triggered escalation. A reviewer can confirm the agent handled PHI correctly and mark the call reviewed. The review record is logged in the audit trail.

---

Next in this series: Build vs. Buy: Adding AI Calls to ServiceTitan (The Real Math) — TCO analysis for HVAC operators evaluating custom voice AI integration.