Picture a clinic group whose clinicians work in the electronic health record all day. Everything a patient does before and after the appointment — booking it, moving it, filling in forms, finding out what their insurance covers — arrives on a phone line that only answers during clinic hours.
An electronic health record is built to hold the chart. It is not built to be the thing a patient uses at nine in the evening. So booking, rescheduling, intake forms, insurance questions and repeat prescription requests all end up as phone calls, taken by the same people who are checking patients in.
Intake forms arrive on paper and are re-typed into the chart, which is both slow and a place for mistakes to enter the record. Insurance cover is checked by hand or not at all, so claims are denied weeks later for something that could have been caught at booking. And patient information moves around in email inboxes, which is the last place it should be.
Nothing replaces the record system. Every piece reads from it and writes back to it over the standard interfaces, through a dedicated system login the clinic controls and can switch off, with every access written to an audit log.
Connects using whichever healthcare data standard the record system supports — FHIR or HL7 — through a dedicated login, never anyone’s personal account.
Patients book against real availability read from the record system, not a parallel calendar. Reminders and recall go out by text and email, and a missed appointment prompts a rebooking.
Forms completed on a phone before arrival and saved into the patient’s record as proper data fields, not filed as a scanned PDF nobody can search.
Cover checked at the point of booking, so the patient knows what they will owe and the claim is not denied a month later.
Names and other identifying details are removed before data reaches the reporting warehouse, so the team can look at no-show rates, clinic utilisation and payer mix without touching identifiable records.
Answers admin questions, books and moves appointments, and routes a repeat prescription request to the right queue — day or night.
A patient sees their own record and nobody else’s, and the assistant inherits the same limits staff already work under. Identifiable patient data stays in the record system; the reporting warehouse only ever receives a de-identified copy.
This is the standard patient access pathway, and every step of it usually needs a person on a phone. The design question at each one is the same: what can be settled before the patient arrives, and what is the least data needed to settle it.
The patient picks a real slot read live from the record system, by app or by talking to the assistant. The appointment is written back immediately.
Eligibility and benefits are run against the payer before the visit, so the patient is told the cost and the front desk is not finding out at check-in.
History, consent and demographics are completed on the patient’s own phone and land in the chart as fields a clinician can actually use.
Reminders go out ahead of the visit. A no-show triggers a rebooking, and a follow-up interval schedules the recall rather than relying on someone remembering.
The assistant books, moves, reminds and files. It does not read results to a patient, does not answer clinical questions and does not give advice — those go to a clinician, with the conversation attached. Every record it opens is written to an audit log, which is what the rules require in any case.
A patient books, reschedules, completes their forms and asks an admin question at any hour without reaching a person. Intake data arrives in the chart as structured fields rather than being re-typed from paper. Cover is confirmed before the visit instead of being discovered after the claim is denied, and patient information stays inside systems designed to hold it rather than in an inbox.
Healthcare data standards supported — FHIR and HL7 — so it fits whichever the record system offers.
Front desk jobs moved off the phone: booking, rescheduling, intake, eligibility and repeat prescriptions.
Clinical decisions made by software. It books, reminds and files; a clinician decides.
This case study is an illustrative example of how we build this kind of system. It does not describe or identify a specific client, and the details are representative. Product and company names are trademarks of their respective owners, mentioned only to describe compatibility; no partnership or endorsement is implied.