AI Adoption GuideHealthcareAccess
Conversational scheduling agent
Voice or chat agent handles booking, rescheduling, and routing to the right provider via NLP across phone and web channels, using tools like Hyro or Rasa.
Healthcare processAccessIntakeAssessDiagnoseTreatDischargeBillFollowup
By Don, DoneThat’s AI coach · updated
Treat the transcript as a draft, not a booking
A conversational scheduling agent earns its place when the booking action it writes cites three records the scheduling system already knows: the slot, the provider, and the patient. Until those cites exist, and a scheduler has confirmed them, the phone call or chat is intake. It is not a held visit.
Voice and chat NLP across phone and web can collect a reason for visit, a campus preference, and a time window. That is useful context. It is not a booking. A booking is a schedule record whose slot identifier, provider identifier, and patient identifier match charts and openings the clinic already trusts. If a required cite is missing, the field stays empty. The agent does not invent a wait time, a substitute clinician, or a next-available opening that was not returned as an open slot.
Conversation platforms such as Hyro or Rasa, sitting in front of systems of record such as Epic or athenahealth, belong in one place in this workflow. They talk, they call tools, they propose. They do not close the calendar. A person in access still confirms.
Load identity and open slots before you offer a time
Start every session by loading two sources of truth. Do not improvise from the caller's wording.
Load identity first. Resolve the speaker to a patient record the practice already has: medical record number, date of birth, and the name as stored, not as the speech engine heard it. If two charts could match, do not pick one. Leave the patient field empty and send the session to a scheduler. If the caller is new, do not create a chart from the chat.
Load the schedule second. Query open slots for the requested service, location, and, when the caller named one, provider. Offer only slots the query returned. Do not paraphrase availability into "Thursday morning" unless that phrase maps to a concrete slot ID. If the schedule call fails, say the schedule is unavailable. Do not guess from a template you saw on an earlier call.
If a specialty visit cannot be booked until coverage is known, hand off to real-time eligibility verification instead of promising a slot the payer will later refuse. If the caller has a vague symptom and needs a specialist, run smart referral matching before you offer times. If the caller is not working in the clinic's default language, let a multilingual patient navigation agent own comprehension before this workflow owns the calendar.
One illustrative path, not a measured result: a parent calls at 7:40 a.m. asking for Dr. Patel on Friday for a cough. The agent matches the child's chart, pulls Friday pediatric slots for that provider ID, and reads back two times that exist in the book. It does not add a third time because the parent sounded urgent. It does not swap in another pediatrician because Patel's Friday list is short. If Patel has no Friday openings, it says so and asks whether another named provider or another day is acceptable.
Write the booking with cites, or leave it empty
When the caller accepts a time, write a booking action, not a polite summary of the chat.
Cite the slot: the scheduling system's slot ID, or the appointment-slot key your interface receives from Epic or athenahealth, plus the start timestamp in the clinic timezone. Cite the provider: the provider ID or NPI that owns that slot, not the name the caller used if that name does not resolve. Cite the patient: the MRN or enterprise patient ID that identity resolution returned.
Then stop filling. Reason for visit, interpreter need, and a callback number can be attached when the caller gave them and your schema requires them. If a required field was never collected, leave it blank. Empty stays empty. A blank insurance field is safer than a guessed payer. A blank visit type is safer than mapping "cough" onto a long new-patient physical because that is what the template expected.
The write is a hold request or a proposed appointment, depending on how your scheduling API is set up. It is not confirmation to the patient. The agent may say that a scheduler will confirm, and that the time is not held until they hear back. It may not say the patient is booked.
Opening or closing templates from predicted no-shows is a separate control loop, described in no-show demand forecasting.
Reject writes that look finished in chat and unfinished in the EHR
Three failures produce a clean transcript and a dirty schedule.
A booking with no slot ID. The agent stores "Friday at 2" as text and posts an appointment that is not bound to an open slot. Two callers can receive the same Friday at 2. Reject any write that lacks a slot cite. If the slot was taken between offer and write, do not keep the old time in the message. Reload the schedule and offer what is open now.
Treating the chat as confirmed. The patient hears that they are down for 2:00 with Dr. Patel and stops calling. The scheduler never sees a task, or sees a note with no actionable IDs. Only the scheduler's confirm, or an explicit API confirm after human review, moves the appointment to scheduled.
Inventing a provider. The caller asks for "the knee doctor" or mispronounces a name. The model fills a well-known orthopedist, or the first provider on the department roster. The held slot belongs to the wrong clinician, or to a clinician who does not take that visit type. If the provider does not resolve to an ID that owns an open slot for the requested service, leave provider empty and do not book. Offer a transfer or a callback instead of picking a name to keep the conversation moving.
Callers will also ask how long until they can be seen. The agent should not invent a wait time from training data or from a stale average. If the schedule load returns a next-open timestamp, you may read that timestamp. If it does not, say you do not have a wait time, and keep the field empty.
Keep a scheduler on the confirm step
Human confirmation is the quality gate, not a courtesy.
The scheduler's queue should show the proposed booking with the three cites visible: slot, provider, patient. They confirm that the slot is still open, that the provider is appropriate for the visit type, and that the patient is the right chart. They also catch what NLP will miss: a protective order, a split household with two charts, or a provider who is out while the template still shows holes.
Only after that confirm does the patient enter a scheduled state, with reminder language, a portal message, or outbound SMS according to your existing access policy. If the scheduler rejects, staff tell the patient the time is not held and offer the next real options from a fresh schedule load.
New patients, returning patients, reschedules, and cancellations all produce a booking action with cites, or they produce blanks. Reschedule means release the old slot by ID, then write a new booking with new cites. Routing to the right provider is a resolved provider ID on an eligible slot, not a department name left in the transcript.
When you choose tooling, treat Hyro, Rasa, Epic, and athenahealth as a stack, not as a ranking. The conversation layer and the system of record must share identifiers. If they cannot pass slot, provider, and patient IDs in both directions, the agent cannot meet this outcome, no matter how fluent the voice sounds.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first