Should you build or buy the EMR?

This is the first in a multi-part series that explores the foundational question of whether startups should build or buy the EHR. For these posts, I’ve tapped tapped operators in my network, asked them the question, and let’s just say the responses came in fast and furiously! The next column’s author is Jake Cooper, CEO of Grow Therapy. If you’d like to submit, don’t hesitate to reach out!

I also wanted to call out that Scrub Capital is hosting a dinner in Chicago with our LPs Dr. Ali Khan (Oak Street) and Dr. Asima Ahmad (Carrot Fertility) on May 15, featuring a fireside chat with a VIP special guest. If you’d like to attend, please reach out via email ASAP as spots are limited.

“Should we build our own EHR?” is a question many health care start-ups wrestle with.

Many companies have asked this question - and many have tried building their own solutions. Before we get into my perspectives on it, as a longtime health-tech operator, let’s rewind for a moment.

I’ve worked in Health IT for 30 years - the first roughly 15 of those in the domain of Electronic Health Records. When the first batch of EHRs was developed, they were built by physicians as digital instantiations of the paper record. The user experience even mirrored manila folders with tabs, prescription “pads” that looked like paper, etc. There were no standards or government requirements for how they worked, and the tools one would use to build them were the same tools that were used to build other software: a database tied to a “front-end” user experience. The products took years to build, evolved slowly, and (sadly) were neither interoperable (they couldn’t communicate with each other easily) nor uniformly safe or easy to use.

In 2009, as part of the American Reinvestment and Recovery Act, CMS established programs that paid providers and hospitals to “meaningfully use” certified electronic health records. As some of Second Opinion’s readers may recall, this program distributed over $2 billion as incentives for these organizations to migrate from paper to digital tools - based on the hypothesis that the use of interoperable software would improve efficiency, reduce cost, and improve health outcomes.

“Certified” was important — and remains so — because it defines a minimum subset of capabilities that software must have to be certified, such as recording allergies in a standardized format or transmitting clinical data to other systems. For example - a system would need to be able to capture allergies using a certain standard nomenclature so that if a patient’s record is transmitted to another facility, the allergies could be imported and no human would have to re-enter them - thereby preventing providers from prescribing medications to which that patient was allergic. Before certification - there was no assurance that both systems would be using the same standards.