Verifying Patient Identity Before a Voice Agent Shares PHI

A healthcare voice agent should verify the caller before it says anything about their care. Greet without health details, ask the questions your policy sets, and check the answers against your own system through an endpoint that replies only verified or not. Fetch details after a pass. After failed tries, offer a callback or a person.

Key Takeaways

• A phone number finds a record, but it never proves who is calling.
• Keep the record out of the agent until your endpoint confirms the caller.
• Family callers and failed checks go to staff, not to the agent.

Anyone holding a patient's phone can answer a call meant for them. We show why the number proves nothing, how to hold back the record until a check passes in Dograh, and what to do with failed tries and family callers. It sits within our guide to voice AI in healthcare privacy.

Why the phone number is not proof

A matching phone number tells you which record to look at, not who is holding the phone. The verification requirement in the Health Insurance Portability and Accountability Act (HIPAA) asks a provider to verify the identity of anyone requesting PHI, and their authority to receive it, before disclosing it. Asking for a name does not meet that, because a name is easy to know.

Caller ID can be faked, and attackers use the phone because it works. In an 8-K filing with the U.S. Securities and Exchange Commission, Astrana Health described attackers "impersonating Company personnel and spoofing the Company's main corporate telephone number" to contact its employees. In February 2026, Hims & Hers said attackers used social engineering against a third-party customer service platform and took customer names and emails, as Healthcare Dive reported.

A voice agent answers every call the same way, with no instinct that something is off. The check has to live in the design.

Keep the record out of the agent until it passes

The safest verification design gives the agent nothing to leak before the check passes. The order is greet, verify, then disclose. The greeting plays before the agent knows who is on the line, so the Greeting Text names the practice and nothing about care.

For calls that start with a lookup, Pre-Call Data Fetch asks your system for data as the call connects, sending the caller's and called numbers. Return a record reference, such as a patient reference ID, and nothing else. Fields your prompts use reach the model, and every field is stored with the call record. Our post on pre-call data fetch covers the setup.

Outbound calls need the same care. The columns in a campaign file become call data too, so keep appointment details and results out of any column the greeting reads.

The verify step in Dograh

The check itself is one tool call to an endpoint you own. Create an HTTP API tool named, say, verify_patient. Its parameters are the caller's answers, such as date of birth and the last four digits of an account number, which the model fills from the conversation. Add the record reference as a Preset Parameter with {{initial_context.patient_ref}}, so the endpoint knows which record to compare against.

The endpoint compares the answers with your records and returns verified true or false, never the record itself. While it runs, the tool's Messages can play a short line such as "One moment while I check that." The tool waits 5 seconds by default, and a 4xx or 5xx reply comes back to the agent as an error, so tell the agent in the prompt what to say when the lookup fails.

After a true result, a pathway moves the call to the node that can fetch and discuss details through a second tool. Choosing that pathway is the model reading the condition you wrote rather than a hard switch. Write the condition plainly, such as "verify_patient returned verified true", and have QA review flag any call where details were spoken before that result.

Open Source Alternative to Vapi / Retell

Self-hosted voice agent platform — no per-minute fees

dograh-hq/dograh

Star on GitHub

When verification fails

Decide what happens after a failed check before the first call. A good default is two tries. After the second failure, the agent says it can't share details by phone and offers a callback from staff or a transfer to a person, then ends the call. How many tries to allow is your policy, written in the prompt.

The closing line can be the End Call tool's End Message, which plays before the line drops: "I'm sorry, I can't share details over the phone right now. Someone from our team will call you back." A Webhook node can then send the outcome to your system, so staff see which calls failed and can follow up.

Never let a failed caller retry forever or hint at the right answer. "That doesn't match" is enough.

Family members, caregivers and testing

A parent, spouse or caregiver calling about a patient raises a different question, and it belongs to staff. HIPAA lets a provider share relevant information with family and friends involved in a patient's care when the patient agrees or does not object, and in some cases on professional judgment. That judgment is a person's call. Tell the agent to offer a transfer or callback whenever the caller is not the patient.

Skip voice biometrics. A voice print is one of HIPAA's identifiers, so storing one creates more PHI to protect, as our post on voice data and biometric risk explains. Knowledge checks against your own records do the job with less data.

Test the whole path before go-live: right answers, wrong answers, a slow endpoint, a caller who gives details unprompted, and a family member. Each test call leaves copies like any other, which our post on PHI on voice agent calls maps. Your verification policy is a compliance decision, so treat this as general guidance and have your privacy officer or counsel approve the questions.