EHR Integration: How to Connect a Voice Agent to Your EHR

EHR integration for a voice agent means the agent can read from and write to your electronic health record during and after a call: find open appointment slots, confirm or book a visit, and record what happened. Retell AI has no native connector for any EHR. You connect one through a custom function that calls an API your organization controls, usually FHIR endpoints, an interface engine or middleware, or through a healthcare automation platform such as Keragon that already connects to both sides.

That distinction matters for planning. The voice side is configuration in the Retell dashboard. The EHR side runs through your EHR vendor's access program and your own integration team, and it needs their approvals before anything is built.

What can a voice agent do with EHR access?

Most healthcare teams start with administrative calls, because they are high in volume and low in clinical risk:

• Scheduling: look up open slots, book, reschedule or cancel a visit, then confirm it back to the patient.
• Confirmations and reminders: read an upcoming appointment and confirm the date and location.
• Intake: collect demographics, insurance details or the reason for a visit, and write them to the record or a staging table for staff review.
• Routing: identify the patient and hand clinical questions to staff with context, using a warm transfer to your human team.

These are the same front-desk workflows behind an AI medical receptionist. Each one maps to a small number of API calls, which keeps the integration scope narrow.

Which EHRs have a documented integration path?

The large EHR vendors publish developer APIs, and FHIR (Fast Healthcare Interoperability Resources), the HL7 standard for exchanging health data, is the common thread. Access is always granted through the vendor and the healthcare organization, not by Retell.

• Epic: What is published: FHIR APIs (DSTU2, STU3, R4), incl. Appointment search and $find/$book. Route to Retell: Custom function via your Epic integration team.
• Oracle Health (Cerner): What is published: FHIR R4 and DSTU 2 APIs on Millennium. Route to Retell: Custom function via your API layer.
• athenahealth: What is published: Appointment profile: read, search, create, update. Route to Retell: Keragon or a custom function.
• eClinicalWorks, Open Dental, Dentrix Ascend: What is published: Listed as Keragon connections. Route to Retell: Keragon workflow.

Epic says Epic on FHIR offers APIs across DSTU2, STU3 and R4, including Appointment read and search and $find and $book operations (STU3). Oracle Health documents FHIR R4 and DSTU 2 APIs on its Millennium Platform. athenahealth publishes an Appointment profile with read, search, create and update capabilities for its athenaPractice and athenaFlow products. Retell's own Epic integration page describes the same route: a custom function against your organization's Epic API layer, with scope and PHI handling approved by your Epic team first.

Three ways to connect Retell to an EHR

A custom function against your FHIR or API layer

This is the most direct path for health systems with an integration team. Your team exposes a small, purpose-built endpoint (for example "find open slots for this patient and visit type"), and the agent calls it mid-call. Keep the endpoint narrow. It should return only the fields the agent needs to say out loud.

An interface engine or middleware

Many organizations already route EHR data through an interface engine. Point the custom function at that layer instead of the EHR directly, so PHI handling, logging and access rules stay where your compliance team already governs them.

A healthcare automation platform

Keragon lists a Retell connector with a "New event" trigger and actions such as Send SMS, and connects to EHR and practice systems including athenahealth, eClinicalWorks, Open Dental and Dentrix Ascend. It suits clinics without engineers: a Retell call event triggers a Keragon workflow that writes the booking into the practice system. Keragon states it signs BAAs on all plans. See the Retell and Keragon integration page for the setup outline.

Build the scheduling lookup as a Retell custom function

In the agent, open the Functions section, click + Add and choose Custom Function. Then set it up like this:

• Name it with letters and underscores, for example find_open_slots
• Write a description that tells the agent exactly when to call it
• Pick the method (GET, POST, PUT, PATCH or DELETE) and enter the API Endpoint URL
• Set Timeout (ms) between 1,000 and 600,000; the default is 120,000
• Add auth headers; values can use dynamic variables such as {{token}}
• Define the body parameters the agent fills in from the conversation
• Save response fields as dynamic variables under Store Fields as Variables
• Turn on Talk While Waiting so the caller hears a line like "Let me look that up"

Retell signs every request with an X-Retell-Signature header, so your endpoint can verify the call came from Retell before touching patient data. The endpoint must be publicly reachable over HTTPS; Retell blocks requests to localhost and private IP ranges, so expose a gateway rather than an internal EHR host. The custom function docs list the full request and response spec.

Return only what the agent should say. Function results are capped at 15,000 characters by default, and everything you return reaches the model. Send back the slot times and location, not the whole patient record.

Identify the patient before the agent reads anything back

On an inbound call, Retell knows the caller's number as the dynamic variable {{user_number}}. You can run a lookup on that number as a pre-call function on the agent's Workflow page, and the agent starts the call with whatever it found; inbound calls wait up to 1 minute for pre-call functions (as of August 2026). A phone number alone is not proof of identity, though. Many households share a line. Have the agent confirm identity using whatever your organization's policy requires before it reads back any appointment details.

Write the outcome back after the call

Two mechanisms close the loop. A post-call function on the Workflow page runs after the call ends and can be gated on a condition, for example only when a booking ID exists. Post-call functions are capped at 5 minutes in total. Alternatively, register a webhook for the call_analyzed event and let your own system decide what to write. Retell's webhooks time out after 10 seconds and retry up to 3 times, so key your writes on the event plus the call ID to avoid duplicates.

Use post-call analysis to extract structured fields such as visit type or callback requested, so the write-back is a clean record rather than a transcript dump.

Keep PHI handling inside your HIPAA program

Retell states it is HIPAA compliant and that a signed Business Associate Agreement (BAA) is required before you send protected health information through it. The BAA is self-serve at click-agreements.retellai.com, with no additional fee. This follows the HIPAA Privacy Rule, which lets a covered entity disclose PHI to a business associate only after obtaining satisfactory assurance that it will safeguard the information (45 CFR 164.502(e)). Retell explains its position in Do Retell AI's voice agents have HIPAA compliance and BAAs?, and our HIPAA guide for AI phone agents covers the wider requirements.

After signing, set three controls per agent under Security & fallback settings: Data Storage Settings (Everything, Everything except PII, or Basic Attributes Only), a data retention period from 1 day up to 2 years, and signed recording URLs. Your EHR vendor and any middleware or automation platform need their own BAAs too. This section is general information, not legal advice; confirm your obligations with your compliance or legal team.

If the clinic should keep the main number patients already call, route it to Retell with a SIP connection that keeps your existing phone number.

The fastest way to scope the EHR work is to build the call flow first against a test endpoint. Open the Retell dashboard to build the agent while your integration team prepares the API.