Speaking from experience: arguments for & against building a homegrown EHR

Editors’ Note: One of the most frequent questions for health-tech operators in my network is whether to build or buy the EHR. So I’m continuing to ask the operators in my network what they personally decided to do - and why - and what the outcomes looked like for them. They were more than happy to oblige. If their experience helps other operators make a better decision, all the better! So in that spirit, Grow Therapy’s CEO Jake Cooper and former CityBlock and Included Health GM Gil Kazimirov shared their perspectives below.

The case for build - it’s a “significant investment” but worth it

Building an EHR goes against all the canonical startup truisms of “focus on driving direct value”, “minimize complexity”, and “preserve resources”. Yet, I increasingly believe that in the context of vertical-focused healthcare, it is necessary to deliver care with step-change improvements in effectiveness at scale (venture-backed healthcare’s goal & reason for existence). And, while it is a significant investment, the implicit costs of renting software are even higher.

This is a question we grappled with for months while building our company - Grow Therapy - and other founders ask me about it regularly. I’m excited to share why we made that decision in 2020, and the impact it’s had since.

The reasons why traditional EHRs may not be the right choice for care delivery businesses can be boiled down to:

• narrow functionality
• limited interoperability
• challenging UX

Starting with narrow functionality… Outpatient EHRs are, by and large, record-keeping systems for compliantly billing insurance. Functionality beyond that is limited. For instance, on the provider side, there is limited support for practice administration, such as demand insights to adjust scheduling or marketing, customized triage flows to support a complete patient journey decision-tree, or clinical insights around practice outcomes and intervention recommendations to improve care quality. Additionally, most outpatient EHRs have invested minimally on the patient side to support scheduling, payments, or access to care beyond the initial clinician. We realized pretty quickly that we would need to invest significant resources in building out these functionalities anyway, and came to the conclusion that buying an EHR isn’t really a shortcut.

The second consideration is interoperability. At our company Grow Therapy, which we started in 2020, our end-to-end EHR serves as the foundation for everything we build; we are able to build more functionally, faster, more effectively, because we have this strong foundation. As an example, after seeing enormous potential for AI to support care, we launched our own AI scribe for providers to create clinical note drafts and after-visit summaries for patients. In just a few months we were able to natively embed consent preferences into provider and patient dashboards and Grow-hosted telehealth sessions, securely integrate AI scribe output into our EHR, and distribute outputs to the provider EHR and patient portal. If we had used a rented EHR we would be stuck with using whatever AI scribe vendor they worked with (if any), have to spend quarters integrating it with a necessarily homegrown patient-facing solution, and see lower usability/uptake from integration limitations: The efficacy ceiling is lower, and there is ongoing execution drag.

The last consideration is user experience. External EHRs need to comply with onerous regulations, accommodate a wide range of preferences, and handle massive permutation complexity stemming from payor fragmentation. The output of those conditions is that UX is generally below that of software in other categories and a far cry from consumer-level experiences. Provider groups are still subject to compliance considerations, but they can structurally avoid customization needs and payer fragmentation by building to narrowly accommodate their specific workflows and contracts, presenting an opportunity to create a highly usable EHR platform. And it’s particularly impactful for care models that partner with a high number of providers. In our case, the vast majority of our ~20,000 Grow provider partners - all behavioral health practitioners - have onboarded without the need for EHR-specific training/assistance. We chalk that up to the superior user experience that’s possible with a homegrown solution.

But… what does it take to build an EHR? In short: It depends, but a lot.

The factors that determine the size of the lift are:

1. if services are payor-reimbursed

2. the complexity of the speciality

3. the nature of the care model

As a mental health platform, Grow is on the lower “lower lift” end of each consideration. We take all forms of insurance, but have fairly limited CPT codes which limit claims complexity. We do not need integrations with testing, imaging, or medical devices. And care is mostly delivered through a 1x1 model versus a team of internal and external providers.

Even so, building our EHR was a massive lift. Counter to what I’d recommend, it was our first product - the beachhead that paved the way for our integrated platform (marketplace, client app, RCM, telehealth, and measurement system). We built and launched the first version of our EHR in ~6 months with a lean 3 person engineering team. But it was consummate bare bones, with limited structured fields and logic controls, no third-party integrations including to clearinghouses (claims needed to be submitted manually), and lack of scalable information organization systems. But launching the EHR day 1 allowed us to get immediate feedback from our incredibly patient and thoughtful provider partners, and effectively co-build the system such that we improved it 1% each day.

And improve we did. One year in, with around a 10-person engineering team dedicated to the EHR, we had most major functionalities covered. By year two, when we had around 20 teammates working on the system, we had achieved what we considered parity with third party solutions on the therapist side. By year three, we were able to then layer on our own telehealth solution custom-build for mental health. And by year four, we were able to incorporate AI scribe tooling that surpassed the out-of-the-box capabilities of any external mental health EHR vendor.

Now, we were fortunate to have the traction, resources, and provider alignment to launch a homegrown EHR day 1. For many startups, that is not going to be possible, and it will make sense to start by renting to conserve resources while proving traction. However, seeing the impact on our development slope, and now (particularly with AI tooling) efficacy ceiling, I now consider “building” inevitable to achieve above-standard outcomes at scale. And, I want to share our perspective in case it’s helpful to anyone considering this question, because building our own EHR was one of our most positively impactful foundational decisions we have made.

Not building an EHR saves money - and that’s a very big deal

There are four priorities I am focused on as an early stage digital health founder: Getting customers, delivering good care, hiring the right people and not running out of money.

The way I see it, healthcare startups earn the right to play by convincing customers – either people or organizations – to buy into a compelling vision, but we win by delivering an experience that makes patients choose to keep coming back and by showing real outcomes for those patients.

Getting customers, either B2B or D2C, isn’t easy, but is almost never dependent on your choice of EHR. You can spin a mesmerizing tale about how your homegrown EHR will enable your clinicians to resurrect Lazarus, but what customers care most about is whether you can solve their immediate problem. And if so, why should they believe you and how much will it cost?

Sure, pitching clients about your proprietary EHR may win you points on technical prowess – but they won’t buy on the back of that as they’ve probably heard a similar pitch a thousand times. The exception is if the customer’s problem is so unique that a de novo build is the only way a buyer would believe you can solve it (spoiler: it’s usually not). In fact, when resources are tight, like they are in the early stages, building your own EHR can be an existential distraction: the most common reason digital health startups fail isn’t a bad user experience, it’s lack of utilization.

What about delivering good quality care? I would argue that, in 2025, building your EHR from scratch to deliver tech-enabled services is usually a losing proposition. The opportunity costs are sky high and the off-the-shelf offerings are plentiful, even if none are perfect. The proliferation of EHRs for different use-cases means you can probably find one that fits your needs even if, as Dr. Jacob Reider mentions in a previous post in this series, you believe your care model is your product.

Over recent years, new EHRs have emerged and existing EHRs have rolled out dedicated capabilities for care collaboration, mental health, virtual care, nutrition, value-based contracting and more to support many more unique workflows than even a few short years ago. And if none of those fit, headless EHRs like Canvas offer a lot more customization without having to spend valuable resources rebuilding core features which will provide no differentiation for either clients or patients.

In fact, as someone building a virtual whole person care clinic for cancer patients, I believe we can deliver better care by using an existing EHR. We can leverage key components that are a major pain to build that are commoditized, like lab integration, insurance billing, multi-language support and cross-EHR messaging, while focusing our customization efforts on what will enable us to deliver best-in-class care, like developing proprietary risk algorithms, personalized care plans, advanced care coordination and custom analytics.

Here’s just a few more specific examples of efficiency gains we get from moving away from a homegrown EHR to an off-the-shelf good one:

Clinical and support team improvements

That includes better queue routing and robust task logic; it’s not trivial to build that. Good EHRs let teams set up custom queues so the right people can get tasked with action items at the right time. This meaningfully offsets cost of manual time spend monitoring queues and triaging for providers, RNs and other support staff. Off-the-shelf EHRs can auto-assign follow-ups, flag urgent tasks, automatically route imaging to the right provider inbox and more. These kinds of tasks are often done manually in homegrown EHR systems, which leads to a lot of elbow grease duct taping.

Visit routing

Some EHRs will allow teams to creat rules for routing visits by patient type, plus other characteristics, which allows for more efficient utilization of the provider base, such as sending lower acuity cases to an NP and higher complexity to an MD.

Revenue Cycle Management

It’s not mandatory to use the EHR for billing, as well as documentation. But those who do will benefit from lower billing overhead. At a past startup I worked at, we had a whole team dedicated to submitting claims and working denials in addition to having a separate RCM that didn’t have integration capabilities with our homegrown EHR (it was too complex to productize our RCM capabilities). By getting an EHR that included billing, we streamlined the billing process and didn’t need as many in-house billing specialists. We could redirect those we kept to working denials and other forms of high value work.

Bad debt reduction

Good EHRs have real time eligibility checks and flexible capacities around credit card verification that helps make sure patients are covered for the scheduled visits so the practice doesn’t have to write off copays or other amounts due in bad debt unnecessarily. That can make a fairly big dent.

Re-routing engineering needs

There’s a lot of engineering time involved in maintaining a homegrown system. One of the biggest gains from switching to an off-the-shelf was that was freed up engineering time spent on debugging, fixing and updating systems. Technology broke a lot because the homegrown EHR always relies on various other platforms to do things, like lab integrations or electronic prescribing. And when those bugs occurred, engineering had to drop everything to fix them. Keep those lights on took a very substantial portion of their time.

Not having to build an EHR also saves a lot of money, which is sort of important given one of the top priorities is not running out of money. Delivering care is pretty expensive already, even before accounting for engineering compensation, or those LED mechanical keyboards engineers always need. It also lets you launch, test and iterate quicker, another key contributor to figuring out what works before running out of money.

On top of that, as someone who had the dubious fortune of overseeing an RCM team, I saw first hand how difficult billing and claims infrastructure is, and how even minor issues can have massive revenue impact - which alone can break early stage startups.

There’s a bunch of other benefits too, like built-in integration with other EHRs and out-of-the-box population health tools that are fundamental to driving differentiated patient outcomes. We aren’t even talking about technical support for staff, meeting compliance requirements or the small detail of keeping clinicians satisfied, who generally prefer a clunkier but more robust UX that works than something that looks slick but doesn’t do what they need.

As the startup matures, efficiency becomes increasingly important, as does flexibility to respond to evolving market needs. That means that workflows need to get more efficient over time. Some might think this is an argument for a proprietary solution with product workflows that can be tailored to the specific needs of the team. But there are two pieces missing here: first, making existing workflows more efficient, even in a proprietary tool, is actually a pretty hard problem, especially if the proprietary platform needs to play nice with other platforms in the healthcare ecosystem. Second, I believe that the majority of back-end efficiency over the next decade will come from AI tools, and leading EHR vendors are better positioned to deliver these than most tech-enabled service businesses – built not by the vendors but delivered through a growing ecosystem of apps on their marketplaces, the integration of which is a competitive advantage and therefore a strategic priority for the EHR vendor.

And while Twitter threads can fool anyone into believing that the rise of AI coding should make building an EHR as easy as, well, writing a Twitter thread, they vastly underestimate how difficult it is to get different systems to work together, especially in a HIPAA-compliant world.

The other issue with building your own EHR is that any successful startup naturally evolves from where it started. That means it must be easy to add new capabilities as the company grows into its vision (or that vision changes), while maintaining the efficacy of existing capabilities. Given the available options on the shelf, it is much easier to rent the platform from a vendor whose entire job is to build and maintain a robust set of capabilities and customize, where needed, on top of it.

To date, I’ve worked at two successful digital health companies, both of which started by building their own EHR several years ago. They did this largely in the absence of options that could meet their requirements, but both recently chose to switch to built solutions. For instance, Doctor on Demand (now Included Health) decided to build a platform back in 2012 in the absence of good options to deliver virtual care. It built a pretty efficient mechanism to deliver transactional virtual services like urgent care, and also had some nice patient-centered features that were unique at the time. This enabled them to deliver virtual care efficiently while maintaining high patient satisfaction.

But over time, Doctor On Demand/Included Health evolved to deliver more and different types of care which no longer jibed with the core workflows built for transactional care. As we added new longitudinal care products like virtual primary care and specialty care, it became hard to keep up with the needs of the evolving product and new customer types – to say nothing about maintaining the existing infrastructure and the growing technical debt. Although it was quite painful, switching to an existing EHR that had all of these features out of the box allowed us to stop wasting time maintaining old infrastructure, drop our square pegs, and focus instead on building new and differentiated features. It’s telling that many others, like OneMedical/Iora, that touted their unique, proprietary EHR, are switching to existing vendors too.

Are there exceptions? Always. Tech-enabled providers that are doing most things differently should consider building from scratch today, or at least being at the very far end of the customization spectrum. Having a unique care model is not a high enough bar given the options out there and the opportunity costs. You are likely also using an innovative billing model, leveraging new provider types (eg. acupuncture) and integrating data in new and unique ways. Others in this bucket might be building a proprietary, innovative technology that is central delivery of the product, like a 10x better clinical decision support tool or a synchronous AI provider, which may make embedding it in an existing EHR platform difficult. Lastly, you’ll probably want your own platform if you are building multiple non-commodity workflows in one, like in-home infusions + remote monitoring + virtual care coordination, or proprietary clinical decision for pediatric prescribing + collaborative care + group/pediatric virtual visits.

If there’s anything I learned in healthcare, it is that building product is harder than it seems, even if you already assume that it’s harder than it seems (Epic’s Razor, probably). Any engineering minute spent on rebuilding commodity offerings, is a minute not spent building true differentiation. There are a lot of commodity offerings that need building for a tech-enabled service to meet even the bare minimum patient experience. And the longer it takes to build, the less time an early stage founder has to actually test and improve the offering with real providers and real patients, drive engagement in the product and demonstrate the value to customers, like payors or employers. Quality time with the greatest number of patients – that is worth optimizing for.

Where do you stand in this debate? I’m always looking for case studies from the field, or ideas for tough decisions where it would be helpful to see how others have done it! Reach out to me at Christina@secondopinion.media. Thanks again to our guest authors this week, Gil and Jake!

Interested in being a Second Opinion sponsor and reaching our audience of operators, care providers, entrepreneurs and investors? Reach out to us for a media kit.