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

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.

Become a paid supporter to see more