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.