AI Receptionist for Epic: Booking and Routing

At a hospital running Epic, one published number sits in front of dozens of departments. The caller does not know whether they need cardiology, the anticoagulation clinic or their primary care physician, and they should not have to. The hard part of an Epic front desk is not booking an appointment. It is working out, from a sentence about a symptom, which of forty schedules the appointment even belongs in.

That routing decision is where a generic voice agent falls down and where an Epic deployment either earns its place or becomes another phone tree. This is how 2care handles it.

The phrase covers a wide range, so it is worth being exact. 2care connects to Epic through its official API, including FHIR resources for scheduling and patient access, set up by an onboarding specialist during go-live. There is nothing to install on your side and no screen being scraped behind the scenes.

Two things follow from using the sanctioned interface. Availability is read from Epic at the moment the caller asks, so the slot offered is one that exists in the live schedule rather than in a copy pulled overnight. And every write is a first-class Epic appointment, logged and reversible, not a note left for someone to key in later.

How the write reaches Epic, in FHIR terms

"Official API" hides a lot, so it is worth being concrete. Underneath the plain description is a specific set of FHIR R4 interactions.

Authentication is SMART on FHIR backend services: 2care holds a client registered in Epic's vendor programme and exchanges a signed JWT for a short-lived OAuth2 access token, scoped to only the resources it needs and refreshed before it can expire in the middle of a call. There is no shared password and no human login behind the connection.

Availability is a search over the Slot and Schedule resources, filtered by the mapped department, visit type and provider, so the times offered are Epic's own open slots. Booking is an Appointment write, through Epic's scheduling resources where the site enables them, which Epic validates server-side against its own templates and double-book rules. That server-side check is why a slot taken mid-call fails cleanly: Epic rejects the write and the agent hears the rejection, rather than the agent deciding for itself that the slot was probably still free.

Identity resolves through a Patient search on identifier and demographics, and the $match operation where the site exposes it, so the appointment lands on the existing MRN rather than a new one. Rate limits and token lifetimes are handled by the connection, not the conversation, so a busy Monday looks the same to the caller as a quiet Tuesday.

Reading the schedule live, not from a mirror

A cached copy of an Epic schedule is stale the instant a clerk books someone at a desk, and on a busy hospital line that is minutes, not hours. 2care queries the live schedule on the call, parameterised by provider, visit type, duration and location, which is the same reasoning set out in how write-back works. The cost is that a slow Epic response makes the call slightly slower. The benefit is that the agent never offers a slot that has already gone.

Routing from a symptom to the right clinic

This is the Epic-specific problem. Intent, provider, urgency and identity are resolved from natural speech before anything is booked. A caller who says they have had chest tightness since the morning is not offered the next open primary care slot; the description is matched to the right destination, and if it crosses a red-flag line it leaves the booking path entirely.

Routing runs on the practice's own rules: by department, by provider, by location and by urgency. A described emergency reaches a human in about 3 seconds, a question that turns on clinical judgement in about 4, and everything routine is resolved on the line. The configuration of those lanes lives in triage and routing, not in a model's opinion of the call.

Consider a single caller: "I saw Dr Okafor about my knee, and now it has swollen up again." That one sentence carries a provider, a body site, a returning-patient signal and a change in condition. The agent resolves the existing record, recognises this as a follow-up rather than a new complaint, checks whether the swelling crosses an escalation trigger, and if it does not, offers Dr Okafor's next suitable slot. A menu tree asks the caller to classify all of that themselves, which is exactly what a caller with a swollen knee is least equipped to do.

The booking rules Epic already enforces

Epic encodes a great deal that a booking has to respect: which providers may see which visit types, how long each type runs, the intervals between visits in a course of care, and the templates that block certain slots. 2care applies these on the call, before it confirms anything.

The effect is that a booking Epic would reject is never spoken to the patient as done. If a visit type is not permitted for a clinician, or an interval rule bars a slot, the agent finds an allowed alternative rather than creating something wrong. A booking that respects the rules on the way in is worth more than a fast one that Epic bounces after the caller has hung up believing they are seen.

On an Epic call	A read-only bolt-on	2care
Availability	Stale synced copy	Live read from Epic
Department routing	Caller picks from a menu	Resolved from the symptom
Booking rules	Applied later, by staff	Applied on the call
Write-back	A summary email to key in	Real appointment on the MRN
Ambiguous patient	A new chart is created	Escalates, no duplicate

Booking a whole course of care in one call

Much of hospital scheduling is not a single visit but a series: a procedure and its follow-ups, a pre-op and a post-op, a course spaced at set intervals. Epic knows the prerequisites, the provider eligibility, the durations and the spacing rules for these, and a booking that ignores them creates work rather than saving it.

2care books the series in one call where Epic supports it, placing each visit at the correct interval and against an eligible provider, rather than booking the first and leaving the rest to a callback that may never happen. On a specialty line, a course booked correctly in a single conversation is the difference between a plan of care that holds and one that falls apart between visits three and four.

Identity, the MRN and the duplicate chart

Before a word about an appointment, the caller is resolved against the existing Epic record, with identity confirmed against a date-of-birth match. The appointment is written against that MRN, not a new one, so a returning patient does not acquire a second chart. Where two records are genuinely plausible, the call is handed to a person rather than resolved on a guess, using the logic in patient matching.

This runs alongside MyChart rather than against it. A patient who self-schedules online still resolves to the same MRN, and a call the agent cannot safely complete lands with a person who is looking at that same chart. The phone and the portal stay one record, not two, which is the whole point of writing against the identity Epic already holds instead of a copy the agent keeps to itself.

Write-back, and the audit trail Epic expects

The confirmed appointment is written back into Epic in real time, with the visit type, provider, reason and a source marking it as voice-booked. Only after Epic accepts the write does the agent read the date, the time and the clinician back to the caller, and a text or WhatsApp confirmation follows with reminders before the visit.

Because the system reads, matches and writes protected health information, it is a business associate rather than a conduit. Under HHS guidance the conduit exception covers only transient access, and none of these steps is transient.

2care signs a BAA, encrypts data with AES-256 at rest and TLS 1.2 or better in transit, does not use patient data to train shared models, and logs every write so it can be found and reversed. What that covers is on the compliance page.

The outbound side, written back to Epic

An Epic front desk is not only inbound. The same connection runs outbound work from your rules: appointment reminders timed to the visit, recall and reactivation for patients due for follow-up, and waitlist backfill that offers a slot freed by a cancellation to the next suitable patient within minutes. Each outcome is written back to Epic, so a filled slot updates the schedule and a completed recall updates the record, with no separate list for anyone to reconcile against the chart.

What 2care does on an Epic site that a bolt-on cannot

The case for 2care here is specific to a multi-department Epic deployment. A bolt-on that reads a calendar and emails a summary leaves the routing, the rule-checking and the write-back to your staff, which on an Epic site is most of the work.

2care does the routing before the booking, applies Epic's own rules on the call, and writes the result back against the right record, all inside one native pipeline rather than a chain of tools handing PHI between them. On a hospital line where the alternative is a clerk triaging a symptom against forty schedules, that is the difference between a front desk that scales at three in the morning and one that queues. See how the pieces fit on the platform and the Epic setup.

Where this is right for an Epic site

The Epic deployments that get the most from it share three things, worth checking before go-live.

One number fronting many departments. The more schedules a single line routes across, the more the symptom-to-clinic routing earns its place. A multi-specialty site or a hospital front desk gains the most from it.

Scheduling rules encoded in Epic. The agent enforces what Epic holds: provider eligibility, visit types, durations and intervals. Sites that keep those rules in Epic rather than in staff memory get the full benefit from the first day the line goes live.

A destination for clinical calls. The design routes anything clinical to a nurse or provider queue, so a site that already runs that queue is ready to switch the line over straight away, with the escalation lanes mapped to the people who already take those calls.

Going live on Epic

Go-live is three steps and takes weeks, not quarters. First, authorise the connection so the agent can read schedules and write appointments through Epic's API. Second, map your rules: departments, providers, visit types, durations and the escalation paths for each lane. Third, test against a test environment with your team listening, then switch the line over and monitor the first days closely.

The monitoring in those first days is where the routing rules get tuned. A trigger that fires on too many ordinary calls is widened; a department receiving calls it should not is remapped. Because every escalation records what set it off, that tuning runs against evidence rather than impressions, and it settles within the first weeks rather than dragging on. Nothing about the number the patient dials changes: the agent sits in front of the phone system you already run, so there is no porting and no new hardware.

The speed behind the routing

Underneath the routing, the numbers are what decide whether a caller stays on the line. The agent replies in about 480 milliseconds, with the ninety-fifth percentile under 700, on a native voice pipeline rather than a wrapper over a third-party service, so the live FHIR read happens inside that budget instead of stretching it. The platform runs at 99.9% uptime and carries 1000+ concurrent calls, and turn-taking waits on both silence and a finished thought, so a caller reciting a date of birth is not cut off mid-number.

Frequently asked questions

Does it write real Epic appointments or just leave a message?

Real appointments, written through Epic's official API against the patient's MRN, and confirmed to the caller only after Epic accepts the write. Message-taking dressed up as booking is exactly the failure this is built to avoid.

How does it decide which department a caller needs?

From the description, not a menu. Intent, provider and urgency are resolved from natural speech and matched to your routing rules, and anything that crosses a red-flag line leaves the booking path and reaches a human in seconds.

Will it create duplicate charts in Epic?

No. The caller is resolved against the existing record before anything is written, and an ambiguous match escalates to a person rather than creating a second chart. Identity is confirmed against a date-of-birth match first.

Is patient data used to train models?

No. Patient data is not used to train shared models, it is encrypted in transit and at rest, and the whole flow runs under a signed business associate agreement covering the call content 2care creates and stores.

How does it stay reliable if Epic has a brief blip?

It captures the full request and confirms only what Epic has actually accepted, so nothing false is ever promised to a patient. The moment the connection is back, the booking completes against the live schedule, with no parallel copy for anyone to reconcile later.

See it route a live call

The fastest way to judge an Epic front desk is to hear it handle the calls that are not simple: a symptom that needs routing, a rule that blocks a slot, a record that is ambiguous. Ask to hear all three.

Read how the same flow runs on other systems across integrations, or hear it route and book on a live Epic-style call when you book a demo.