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.

But the products of the 1990’s and 2000’s were generally built (and marketed) before ARRA - before Meaningful Use and before certification - and the way they were marketed (I remember this vividly) was: make more money, spend less time. I remember a histogram that an EHR salesperson put in front of me when we were evaluating EHRs to purchase in ~ 2000.  It depicted the average e/m code pre-implementation (99213) and the average post (99214). The pitch: $30/visit extra with just a few clicks. Bottom line: These products were built to maximize revenue.

Did those EHRs maximize health outcomes, too?  Maybe. Maybe not. Revenue was the focus, and therefore the products were built with the revenue-generating item - the encounter - as the foundation of the technical architecture.  This core strategic decision makes sense: if revenue is your raison d’être, you’ll build the system around the thing that generates revenue. Even today - the byproduct of this flawed decision persists in many systems:  do you want to document a conversation you had on the phone with a patient?  Create an encounter - because no documentation can exist that’s not tied to the thing at the center: encounters. Everything else was (and in many cases still is) bolted on top of the encounter: medications, problems, allergies, orders, results, and decision support.

Value Based Health Care and the rise of “homegrown”

Then two creative healthcare thinkers came along. Allow me to introduce them, if you’re not already aware based on their reputation alone:

The first, Dr. Rushika Fernandopulle, started Iora Health with the idea that if he focused first on healthy patients, he could significantly reduce cost, and in so doing share risk with the health plans. His team therefore needed an EHR that had the patient at the center - not the encounter - since they would be doing many things with/for their patients without in-person encounters! They needed something different.

So they built their own system and (for years) explicitly decided initially not to get it certified.

Similarly, Dr. Tom Lee at One Medical decided that the existing products were crap - and while he wasn’t value based, the early business model was focused on memberships and optimal user experience - not maximizing encounters.  Did any of the existing products do this for him? Nope. So he built his own.

Another example of a company, and not an individual, is ChenMed, whose value based payment model was similar to Iora’s. This team did the same thing. Internal team. Big investment of time and money.  Home-grown EHR. They built around their needs, where it mattered most and to have the greatest impact. These are just three examples, but there are more. Marshfield Clinic and Partners are obvious examples of incumbent health systems that built their own. Home-grown was a thing - but it was hard and took both time and money.

Which brings me to my next point: Many of the home-grown systems weren’t certified because there was really no reason to do so.

It wasn’t important until 2017 - when CMS started requiring the use of a certified EHR for any provider participating in an advanced alternative payment model (the “VBP” models).

It took Iora and One Medical five years to do the re-work of their products to get them certified, as one can see by looking up their products in the Certified Health IT Product List here.

A final note about certification. In 2014, ONC (now ASTP) changed the certification model and nomenclature.  EHRs are no longer certified. Rather, capabilities are certified. While this may seem like just semantics - it has real-world implications.  Providers need to use certified tools to do the subset of things required by CMS (see below).  Depending on the program, penalties can be fiscal (forfeiture of incentives or annual fee increases) or administrative (program exclusion).

• Electronic Prescribing
• Health Information Exchange
• Provider to Patient Exchange
• Public Health and Clinical Data Exchange

So if you invest in health information technology (built or bought - one product or twelve different products) - and the capabilities you need to satisfy the CMS requirements are certified - you’re good!  This is very different from the requirements of 2011 - when the EHR itself was certified.

So now - you can buy (or build) different certified parts.

Summary of what we’ve covered so far

a) EHRs were built to maximize revenue and were built around the encounter, not the patient.

b) Certification assures the buyer that they are getting a thing with the capabilities we expect it to have.

c) Home-grown systems were built to meet the needs of organizations that were doing things differently - but certification was an extra burden they generally sidestepped until it became necessary.

d) ASTP/ONC certification is not of a product, but of a product’s capabilities.  If you put together a suite of capabilities from different developers (or some of your own and some commercial products) like a giant puzzle, you are using certified health IT.

Now it’s 2025

So what’s different?

a) Value Based Payment models are everywhere.  Most care providers (beyond pediatricians) have some that contract to pay providers to keep people healthy rather than payments for every visit.  The encounter is less important now.

b) Many start-up healthcare companies do things differently from how things were done before - whether it’s a DTC approach, or risk sharing or telehealth-only or hybrid ... and therefore the traditional EHRs may be unacceptable - both because they’re expensive and because they were built to solve different problems (see above).

c) Technology is better.  There are now products purpose-built as platforms rather than complete EHRs that will accelerate the development time from years to (perhaps) only months. AI is now a thing, and it’s making the pace of development a lot faster.

Vendors Say They’ll Flex (They Don’t)

Most commercial EHR vendors will tell you, “Yes, we can support your unique workflows.” And maybe they technically can. But if your care model is even a little nontraditional—group visits, asynchronous care, VBP-first workflows, interdisciplinary care teams—you’ll discover that “yes” means “for a customization fee and a UX that your users will tolerate” or “go ahead and build on top of our product.  Here’s our API documentation” but never “sure - here you go - three weeks ahead of schedule!”

Which brings us to the real question founders and care leaders are asking: If I’m going to need to build something anyway... should I just build the whole thing?

Actually, maybe you should

Today, building is radically easier than it was even five years ago. Between composable architectures, FHIR-native platforms like Medplum or Ottehr, cloud-first frameworks from Google, Salesforce and others, and the unbundling of health IT certification, it’s no longer absurd to consider building the core components of your own system—especially if those components are where your clinical and business differentiation lives.

Add in the emergence of AI scribes, agents and operators that will soon (and in some cases already do) sit atop or at the core of these systems to streamline charting, triage, and task management? Yeah—this ain’t 2003 anymore.

So Should You Build?

• If your care model is conventional, and your differentiation comes from access, branding, or operations: buy. Don’t waste cycles reinventing the same patient portal and chart note templates, revenue cycle tools, quality dashboards, and clinical decision support capabilities that every other practice uses. Look at platforms like Athenahealth, Elation Health, Veradigm, etc. for solid options.
• If your care model is the differentiator—if the way your team delivers care requires workflows, reimbursement models, and logic that don’t exist elsewhere—then yes, consider building.

Just don’t build everything.

Build what’s unique. Own the core workflows that define how you deliver care. Then plug into best-in-class tools for everything else: Twilio for communications, Truepill or Photon for pharmacy fulfillment, Stripe for payments, Zoom for telehealth, Ribbon for directory + referrals, Redox for integrations, Avo for decision support, Navina for population health, etc.

Your EHR doesn’t need to do it all—it needs to do your thing well. Build the pieces that power your differentiation. Compose the rest from what the ecosystem already offers. That’s how you move fast without creating a lifetime of tech debt.

And if you don’t yet know who you are—if your model is still forming—then don’t build yet. Start light. Use configurable tools. Focus on learning what matters.

Decision Tree: Should You Build or Buy?

Here’s a way to evaluate a build-vs-buy decision for your team.

(source chart here)

Buy vs. Build Comparison Table

Buy if...

Build if...

Your model is conventional: 15-min visits, FFS, traditional revenue models.

Your model is the product: team-based, VBP-first, or asynchronous care.

You need to be live in weeks, not months.

You can afford a few months to get the core experience right.

You lack in-house dev/product resources.

You have a product team or strong engineering partner.

Compliance and certification are priorities from day one.

You're starting in a non-regulated space or using a certified headless backend.

Customization = minor tweaks.

Customization = core workflows.

You’re optimizing for cost and simplicity.

You’re optimizing for experience and differentiation.

That’s it for this week’s edition from Jacob Reider. I’ve broken out the popcorn for the next installment and I’m eager to hear your reactions and personal experiences! Chime in at christina@secondopinion.media

Not already a Second Opinion subscriber?

Get weekly insights on health‑tech delivered straight to your inbox. Join the mailing list for free

Or copy & paste this link into your browser:
https://secondopinion.media/subscribe