Your EHR was designed by a committee, and it shows

I stopped recommending practice management software to colleagues about two years ago. Not because I ran out of opinions, but because every honest recommendation came with a caveat long enough to be its own article. "Try this one, but the scheduling module hasn't been updated since 2019." "This one's decent, but you'll need a separate tool for intake, and the two don't talk to each other." I got tired of my own asterisks.

Every practitioner I've spoken with in the last eighteen months, every single one, has some version of the same complaint. The software they use to run their practice feels like it was built for someone else. Because it was.

The committee problem nobody names

Here's what happened to most of the EHR and practice management software on the market right now. A product team proposed a feature. That proposal went to a committee. The committee included compliance, legal, IT leadership, a billing representative, a senior administrator, and, if the clinicians were lucky, one physician who got pulled from patient care for a two-hour meeting they didn't ask to attend.

The committee's job was to reach consensus. And consensus, in a room with seven competing priorities, means satisfying the least common denominator. The feature that ships isn't the one the practitioner needed. It's the one that didn't make anyone in the room uncomfortable. The interface doesn't flow because nobody in that meeting was optimizing for flow. They were optimizing for sign-off.

The KLAS Arch Collaborative's 2025 research found that clinicians who feel excluded from EHR-related decision-making report significantly lower satisfaction and higher intent to leave their organizations. That finding sounds obvious when you read it. But think about what it means: the people who use the software eight hours a day are being left out of the room where the software gets shaped.

A dietitian in Austin I spoke with last year put it more bluntly. She said her clinic's EHR felt like "a spreadsheet someone put a logo on." She had fourteen tabs open to complete a single patient encounter. Fourteen. She'd been using the system for three years and still discovered screens she didn't know existed. Not because the software was deep, but because the navigation was incoherent. Features had been bolted on by different teams, each satisfying a different committee request, and no one had ever gone back to make them fit together.

I keep coming back to this: the problem with most healthcare software isn't what is being built. It's how the building gets decided. Committee-driven design increases complexity, inflates cost, extends timelines, and systematically strips out the innovation, performance, and personalization that would make the product worth using.

The rest of the world moved on

Open Notion. Build a workspace in an hour. Open Linear. Track a project without reading a manual. Open ChatGPT. Have a conversation with a machine that understands context. Open Ramp. Approve an expense in two taps. Order a car on Uber. Order dinner on DoorDash. Every one of these tools was built with the same underlying principle: the person using the product is the person the product should serve.

Healthcare software didn't get this memo. Or maybe it did, and the committee lost it.

The gap between what practitioners experience in their personal technology and what they tolerate at work has become absurd. A physio in Denver, same person who told me about the fourteen-tab dietitian (they're in the same network), showed me his morning routine. He opens Slack, checks two channels, replies to a message. Takes ninety seconds. Then he opens his EHR, clicks through a login screen, waits for a dashboard that loads modules he's never used, navigates to the scheduler, and discovers that yesterday's notes didn't auto-save because he was on the wrong template. Twenty minutes gone before his first patient.

The ratio is the part that bothers me. Not that EHRs take time, because documentation takes time and that's fine. But the ratio of productive work to navigation and re-entry and clicking through sub-menus that could have been one screen. That ratio is broken, and it's been broken for so long we've normalized it.

The consumer software industry had its own version of this problem fifteen years ago. Enterprise tools were clunky and hated. Then Slack replaced email threads. Notion replaced wikis and project boards and internal docs, all at once, in one product. Linear replaced Jira for teams that cared about speed. The pattern was always the same: someone looked at the existing tools, asked "why does this have to be painful?", and built something that wasn't.

Health tech is only now starting to ask that question. We build at Oli Health with a specific rule: before we design a feature, we research the best solution to that problem from any industry, not just healthcare. Scheduling shouldn't be worse than Calendly. Note-taking shouldn't be worse than Notion. Intake shouldn't be worse than a well-made Google Form. If a consumer app solved the interaction pattern better, we study what they did and apply it to clinical context, with the compliance and privacy and clinical rigor intact but without the seventeen unnecessary clicks.

What "paper to screen" left behind

Most of the EHR interfaces in clinical use today were designed during a specific era. The U.S. HITECH Act of 2009 poured $27 billion into EHR adoption, and the mandate was clear: get patient records off paper and into a database. The design paradigm that emerged was simple and, in retrospect, limiting. Take the paper form. Put it on a screen. Add a few dropdowns.

That paradigm is the reason your intake form looks like a government application. It's the reason your SOAP note template has twelve fields when you regularly use four. It's the reason scheduling, charting, and billing feel like three different products stitched together with a shared login.

The original sin of EHR design wasn't malice. It was urgency. The first generation of digital health records had to solve one problem: "does this information exist in a computer?" They solved it. But nobody came back to solve the next problem: "can a human use this without wanting to throw the computer?"

That's the dietitian in Austin again. She used her phone timer for five consecutive workdays, logging every moment she spent clicking between screens without entering any clinical information. Just moving through the software to get to the place where she could do her work. Forty-one minutes daily. Over a year, that's roughly 170 hours of her life spent navigating, not documenting, not treating, not thinking. Navigating.

What we're doing differently (and why it's hard)

I want to be careful here because I work with the team at Oli Health, and anything I say about our approach could sound like a pitch. I don't want it to. I want it to sound like what it is: a description of how a small team is trying to build software the way software should be built in 2026, and a frank admission that it's harder than it sounds.

Every feature we ship starts with research outside healthcare. If we're building a scheduling interface, we study how Calendly, Cal.com, and Linear handle time selection. If we're building clinical notes, we look at how Notion handles structured content and how Otter.ai handles transcription. We ask: what did these teams figure out about the interaction that we can adapt for a clinical setting?

Then we observe. Not surveys, not feedback forms, though those matter. We watch practitioners work. We sit behind them (with permission, obviously) and notice where they pause, where they double-click out of frustration, where they switch to a sticky note because the software made the digital version harder than paper. We watch a chiropractor in Calgary pull up her schedule and sigh before clicking. That sigh is data.

The thing that slows this down, and I didn't expect this when we started, is the temptation to fall into the same committee trap. As soon as you have five customers, you have five opinions. Feature request A contradicts feature request B. The easy path is to build both and let the user toggle between them. The hard path, the one we try to stay on, is to figure out what both requests are really asking for, design one solution that's better than either, and ship that instead.

We also don't do annual release cycles. We ship micro-improvements continuously. A button that was three clicks deep gets moved to one click. A template that defaulted to the wrong specialty gets context-aware routing. These aren't features you'd put in a press release. They're the kind of changes that make a practitioner's Tuesday 4% less annoying, and then the next Tuesday 3% less after that, compounding quietly until the software stops being something you fight and starts being something you barely notice.

That last part matters to me. The best software is invisible. You don't think about Uber's interface when you're getting a ride. You don't think about Slack's interface when you're replying to a message. The tool vanishes and you're left with the task. Clinical software should work the same way: you should be thinking about the patient, not about which menu the lab results are hiding behind.

The personalization gap

Here's a thing most EHR vendors won't say out loud: their software treats a solo acupuncturist the same way it treats a twelve-physician orthopedic group. Same interface, same templates, same scheduling logic, same reporting dashboard. Maybe you can hide a few modules you don't use. Maybe you can rename a field. But the bones of the product assume you're a medium-sized practice with a front desk and a billing department, and if you're not, you adapt to the software.

Personalization in healthcare software should mean more than "choose your color theme." It should mean the interface reshapes itself based on how you work. A naturopath in Mississauga doesn't need the same intake flow as a speech-language pathologist in Phoenix. The system should know that. Not after eighteen months of configuration, but within the first week of use, based on observing what the practitioner does and doesn't touch.

We're working toward this at Oli. We're not there yet, I want to be honest about that. But the architecture is built to support it because we designed for personalization from day one rather than trying to retrofit it onto a system built for the largest common denominator. Every practitioner should feel like the software was built for them, specifically, for their specialty and their workflow and their pace. Not for the committee that approved the requirements document.

In 2026, there is no technical reason for bad software to exist. The design patterns are established. The infrastructure is mature. The AI capabilities to reduce documentation burden are real and shipping. The only reason bad practice management software persists is that the incentive structures haven't caught up. Vendors who sell to committees will keep building for committees. Vendors who sell to practitioners will build for practitioners. The market is splitting, and if you're reading this, you probably already know which side your current software is on.

The dietitian in Austin switched platforms four months ago. She told me last week that she finishes her notes before she leaves the clinic now. Not every day. Most days. And on the days she doesn't, she's behind by ten minutes, not ninety. She said something I keep thinking about: "I forgot software could feel like it was helping me."

That's a low bar. And the fact that clearing it feels like a revelation tells you everything about where we've been.