I Spent Years Watching Doctors Fight Their EHR. Here’s What Building One Right Actually Takes
I have sat behind a lot of clinicians while they used their electronic health record. Not in a usability lab with a two-way mirror and a stopwatch, but in real hallways, at real nursing stations, at the end of real shifts. And the pattern is almost always the same. There is a small, involuntary sigh before they open a chart. There is a click, then another, then a modal, then a scroll through years of someone else’s copy-pasted notes to find one lab value. By the time they have documented a fifteen-minute visit, twenty minutes have passed. The software that was supposed to give them their evenings back is the reason they are still charting at 9pm.
I want to be careful here, because it is easy to turn this into a hit piece on a few big vendors, and that is not the point. The point is that EHR software is the most-used and least-loved software in all of healthcare, and that combination is not an accident. It is the predictable result of building for the wrong person. If you are about to build, extend, or replace one of these systems, the resentment is the most useful signal you have. It tells you exactly where the work is.
The chart was never the hard part
When people picture EHR software, they picture the chart: a patient record with problems, medications, allergies, notes. And they are right that the chart exists. But the chart is genuinely the easy part. You could model a serviceable patient record in a weekend. What makes an EHR hard is everything wrapped around the chart, the parts a screenshot never shows.
An EHR has to talk to labs that speak a decades-old messaging format, to pharmacies, to imaging systems, to payers, to other hospitals that implemented the same “standard” a slightly different way. It has to enforce who is allowed to see what, log every glance at a record, and prove all of it to an auditor years later. It has to encode the specific way a cardiology clinic runs versus the way a behavioral health network runs, because those workflows are not cosmetic; they are the job. Treat the EHR as a CRUD app with a patient table and you will ship something that demos beautifully and collapses the first week a real clinic touches it. I have watched that exact failure more than once.
Why the resentment is a design failure, not a user problem
Here is the uncomfortable truth I have come to believe: when clinicians hate their EHR, the software is usually working exactly as designed. It just was not designed for them.
Most legacy EHRs were bought by administrators and billing departments, and they were optimized for what those buyers needed: charge capture, compliance checkboxes, procurement requirements. Every one of those things is legitimate. But when the buyer and the daily user are different people, the daily user loses. The clinician ends up as an unpaid data-entry clerk feeding a billing engine, and the “note” they write is contorted to satisfy a coder rather than to communicate with the next human who reads the chart.
So the first thing building differently requires is almost embarrassingly simple: design for the person with the stethoscope, not the person with the purchase order. That sounds obvious right up until you are in a room where the loudest voice belongs to whoever controls the budget.
What “building differently” actually demands
If I had to compress everything I have learned watching these systems succeed and fail, it would be this short list. None of it is exotic. All of it is routinely skipped.
- Shadow real clinicians before you write a schema. The gap between a usable and an unusable EHR is almost entirely workflow fit, and you cannot infer workflow fit from a requirements document.
- Treat interoperability as its own workstream, not a connector task. Real feeds from real hospitals behave nothing like the documentation. Budget for an integration engine, a test harness against de-identified messages, and ongoing maintenance.
- Make compliance load-bearing from sprint one. Encryption, granular access control, and immutable audit trails designed in from the start, never retrofitted after a breach scare.
- Ship a thin vertical slice, not a broad shallow one. One specialty, one complete workflow, real integrations, real compliance, proven end to end before you add breadth.
- Put AI where it removes typing, not where it demos well. More on that below, because this is where I have changed my mind.
Where AI genuinely earns its place
I was a skeptic about AI in the clinical record, and I want to be honest about why I am less skeptical now. It is not because AI writes the chart. It is because the best current uses do not touch clinical judgment at all; they attack the typing.
Get TechCirkle’s stories in your inbox
Join Medium for free to get updates from this writer.
The one that has changed clinicians’ faces in front of me is ambient documentation. A model listens to the visit and drafts a structured note that the physician reads, edits, and signs. The doctor is still fully in charge. What disappears is the hour of after-hours typing. Around that, there is real value in models that propose billing codes from the finished note, that summarize a sprawling record so a clinician can ask a question in plain language instead of scrolling, and that draft first-pass replies to the flood of patient inbox messages that quietly burns people out.
The discipline that separates a defensible feature from a liability is the same every time: a human signs off on every clinical action, the model is grounded in the patient’s actual record rather than its own memory, and every suggestion is logged so you can reconstruct what happened. That grounding, careful LLM integration tied to the real chart, is the whole ballgame. Skip it and you have built a confident, unauditable guessing machine in the highest-stakes environment imaginable.
The decision most teams get wrong
Almost every founder or CTO I talk to frames this as build versus buy, and almost every one of them is missing the option that would actually serve them. There are three doors, not two. Buy a commercial platform and configure it: fastest to compliance, least control. Build end to end: total control, and you now personally own interoperability, certification, and maintenance forever. Or extend: put your differentiated experience on top of an existing certified platform, connect through modern standards, and get the commodity chart and compliance essentially for free while owning only the part that makes you different.
The expensive mistake I keep seeing is a team rebuilding the entire commodity chart from scratch to control one workflow that a well-scoped extension would have delivered in a third of the time. If your edge is a care model or an AI-driven workflow, you rarely need to own the chart. You need to own the layer that expresses your edge. This is exactly the kind of tradeoff worth pressure-testing with an experienced custom software development partner before a seven-figure commitment.
What I’d tell a team starting today
Start by earning the right to write code. Sit with the clinicians. Watch where they sigh. That sigh is a spec. Build the smallest real thing that survives contact with an actual clinic, prove the hard parts, and only then go wide. Keep a human in the loop everywhere it matters, and keep compliance in the architecture rather than bolted onto the side.
If you want the longer, more systematic version of this argument, with the reference architecture, the cost breakdown, and the failure modes laid out in full, I put it all in TechCirkle’s complete guide to EHR software development. And if you are weighing a build, a modernization, or an AI layer over a system you already run, it is worth a real conversation about where your differentiation actually lives before you write a line of code.
Frequently Asked Questions
Why do so many doctors dislike their EHR software?
Most legacy EHRs were purchased and optimized for administrators and billing rather than for the clinicians who use them all day. That misalignment turns physicians into data-entry clerks feeding a billing engine, forces notes to satisfy coders instead of communicating care, and produces the click-heavy, after-hours documentation burden clinicians resent. It is a design failure rooted in building for the buyer, not the daily user.
Can a new EHR actually reduce physician burnout?
Yes, but not through cosmetic UI tweaks. The biggest lever is cutting documentation time, primarily with ambient clinical documentation that drafts a note from the visit for the clinician to review and sign, plus automated coding and inbox triage. When those tools keep a human in charge and are grounded in the real record, they give clinicians their evenings back rather than adding another screen to click through.
What is the first thing to do before building an EHR?
Shadow real clinicians in their actual workflow before you design a schema or write code. The difference between a usable and an unusable EHR is almost entirely workflow fit, which you cannot capture from a requirements document. Watching where users struggle turns their frustration into a concrete specification and prevents the classic failure of a system that satisfies procurement but goes unused.
Is it cheaper to build a custom EHR or extend an existing one?
For most teams, extending a certified platform is dramatically cheaper than building end to end, because you inherit the commodity chart, compliance, and core records instead of owning all of it forever. Building from scratch only makes sense when your differentiation genuinely requires control over the whole stack. The costly mistake is rebuilding the commodity chart to control a single workflow an extension could deliver faster.
Does adding AI to an EHR create legal risk?
It can, if AI is bolted on as a demo feature without safeguards. The risk drops sharply when every clinical action requires human sign-off, the model is grounded in the patient’s verified record rather than its own memory, and every suggestion is logged for auditability. Done that way, AI reduces documentation burden while keeping clinical accountability firmly with the clinician rather than the model.
How do I know if my team is designing for clinicians or administrators?
Look at whose problems your roadmap solves. If most stories serve billing, procurement, or reporting and few reduce the clinician’s clicks and typing, you are building for the buyer. A clinician-centered build measures success by workflow fit and documentation time saved, validates continuously with real users in the loop, and treats a frustrated physician as a bug rather than a training problem.
