SprigganSpriggan

Building · case study

Why we built an EHR from the ground up for AI

Sep 1, 2026 · 8 min read · Spriggan team

All posts

01The problem

Ask a practice manager what the EHR does and the answer is always a version of the same word: it records. The visit, the call, the fax, the claim. Someone still has to do the visit, take the call, read the fax and work the claim. The record is a receipt for the work, not the work itself.

The first wave of AI features accepted that frame. A button to summarise a note, a button to draft a message, a sidebar that answers questions about the chart. Helpful, and yet the shape of the day did not change. The phone still rang. The fax tray still filled. A person still carried every task from one screen to the next, because the software could describe the work but could not do it.

02What we saw in clinics

We spent the first year of Spriggan sitting at front desks. The pattern was the same in a three-physician primary care practice and in a busier multi-specialty group: a small number of people doing a very large number of small tasks, each one dependent on information that lived in three places.

A reschedule needs the schedule, the provider’s rules and the eligibility check. A fax needs the patient, the document type and the physician who should see it. A claim needs the note, the codes and the payer’s edits. None of these tasks are hard. All of them are interruptions, and the interruptions are the job.

Marcus · (628) 555-0188RescheduleDana · (415) 555-0142Refill · Prior authBoth answered in 2 sno hold · no voicemail
Two calls, one moment. In most clinics the second caller waits. Here both are answered, sorted and routed while the desk is free.

03How Spriggan handles it

We started from the other end. If an agent is going to answer the phone, it needs the schedule, the eligibility check and the chart in one place, with the permissions a receptionist has. If an agent is going to file a fax, it needs to know the patient, the document type and where that document belongs. None of that is a feature you add to a record. It is the record, designed so that software can act on it.

So every agent in Spriggan is a member of staff with a computer. The voice receptionist books inside the provider’s rules. The fax agent files into the chart. The billing agent builds the claim from the signed note. Each action is logged under a name, each answer is cited to the chart, and anything that leaves the clinic waits for a person’s OK.

Triage agentclassifies on the spotReschedule · MarcusSmart SchedulingRefill · DanaStaff inboxPrior auth · DanaPrior Auth agent
The triage agent classifies every request on the spot: refills to staff, prior auths to the prior-auth agent, appointments to scheduling.

04What AI made possible

Reading was the missing ability. Software could always move structured fields around; it could not read a three-page fax, a payer’s denial letter or a physician’s dictation and understand what they asked for. Language models can. Once the reading problem is solved, the rest of the workflow is ordinary engineering: permissions, queues, audit logs and the discipline to keep a human on every decision that matters.

That is why this could not have been built five years ago, and why it should not be built as a plug-in today. The reading has to happen inside the system that holds the record, or every answer becomes a copy-and-paste job.

The agents are not visitors in the chart. They are staff, with a login, a log, and a job.

05What changed

In the clinics running this way the front desk did not disappear; it stopped being a call center. Calls are answered at once, reminders go out on their own, intake is done from the car. Faxes are in the right chart before anyone has read them. Claims go out from the note on the day of the visit.

The people at the desk have time for the human part again: the confused patient, the family at a hard diagnosis, the specialist who wants to talk about a case. The rest of this blog is about those workflows one at a time, starting with the fax.

Share this case study