Custom EHR for a Medical Practice: McHur Care

What we found

McHur Care runs on an electronic health record system it owns. The practice ran on a SaaS EHR it paid for by subscription and did not control, fitting its workflows around the product's limits. We built a custom EHR the practice runs on every day, replacing the SaaS product. McHur Care reports six figures a year saved on software costs against the SaaS product it replaced. The exact dollar figure stays between us and the practice, so "six figures" is the public form. This is the record of that build.

The figure and the quote below belong to McHur Care and are published with their permission, confirmed by their COO. They describe one practice and one system. Another practice with another product will have its own arithmetic, and we say so before anyone carries these numbers into their own budget meeting.

The rented EHR

The practice ran on a SaaS EHR it paid for by subscription and did not control. An EHR is the system a medical practice works in all day. Patient records sit in it. The routine around those records lives there too, including what gets written down, in what order, and what a staff member does to move a chart to the next person.

When that system arrives as a subscription, two things follow. The vendor bills the practice every year for as long as it uses the product. The vendor also decides what the software does, so the practice fits its work to the product.

Fitting the work to the product takes staff time every day. Staff complete a form in an order that does not match how the visit went, keep a list outside the system when there is no field for it, and teach every new hire the same set of quirks.

The build

We built a custom EHR the practice runs on every day, replacing the SaaS product. The practice's own way of working is the specification. Before writing code, we sat with the people who use the system and wrote down each step of the day, who does it, and what they do when the software gets in the way.

The workarounds people had learned around the old product were the first thing we wrote down, because each one shows where staff worked around the product. A workaround is a small, specific request for a feature, and the person doing it can usually describe it in one sentence.

A practice cannot stop seeing patients while its main system is replaced, so we paced the work around the practice's schedule and kept the old product running until the new one was doing the job.

An HR portal is in progress. The EHR came first because it is the system the practice touches most, and the rest of the stack follows in the order McHur Care decides.

The savings line

The saving is annual. McHur Care stopped paying the subscription for the SaaS EHR, and that saving repeats for every year the practice runs the system it owns. It is money the practice keeps rather than time it gets back, which makes it easy to check on a bank statement.

Owning software has its own costs, and we say them plainly. The practice pays to host the system and pays for the work of fixing what breaks and building what it asks for next. The six figures a year is what is left after that, measured against a bill the vendor sent every year whether or not the product fit.

What ownership changed

The practice owns the system and it fits how it works. Here is how Sydni Hayward, McHur Care's COO, describes it:

"Our EHR was a subscription we didn't control. It cost six figures a year and we still built our workflows around its limits. Plainpath built us our own EHR, and the practice runs on it every day. We own it, it fits how we care for patients, and the savings show up every year."

McHur Care decides what the software does next. The HR portal now in progress is one of those decisions, made by the practice and scheduled with us. When the staff asks for a change to the EHR, that request becomes work with a date on it.

Limits

These figures belong to one practice and one system. Three things have to be true before replacing a subscription with software you own is worth the effort.

• The annual bill has to be large enough that the arithmetic works. A small subscription will not pay for a build.
• The practice has to know its own workflows well enough to describe them, because that description is the specification.
• Someone inside has to own the system after we leave, ask for changes, and get them. When nobody owns it, people go back to their old steps and nobody asks for the changes that would make the software fit. We wrote about that in why most AI pilots fail.

A build can also be much smaller than a whole EHR. At Genesco Sports Enterprises, a month-end reconciliation that took the CFO about 4 days by hand now runs in about 60 seconds, and the record of that build is on this site.

To see where your own stack stands, write down each product you pay for every year, what it does, and the steps your team performs because the product will not do them. Our guide to that walk-through is how to run your first AI audit in an afternoon. If you want a person to check that list and write a build plan against it, that is Discovery.

Frequently asked questions

What did Plainpath build for McHur Care?

We built a custom EHR the practice runs on every day, replacing the SaaS product it used before. An HR portal is in progress.

How much did McHur Care save?

Six figures a year on software costs against the SaaS product it replaced. The exact dollar figure stays between us and the practice, so "six figures" is the public form.

Does replacing a SaaS product with custom software make sense for every business?

No. The annual bill has to be large enough that the arithmetic works, the team has to know its own workflows well enough to describe them, and someone inside has to own the system after the build. When one of those is missing, a smaller build on a single process is the better first step.

Who owns the software Plainpath builds?

The client does. McHur Care owns its EHR and decides what changes get made to it. Hosting and upkeep are real costs, and we name them before a build starts.

How do we find out whether our software is worth replacing?

Start by listing every product you pay for each year, what it does, and the steps your team performs because the product will not do them. The free audit is a short chat with our agent that scores your processes. Discovery is where a person checks that work and writes the build plan.