Picking an EHR for your digital health company can feel like an overwhelming and endless saga.

Legacy platforms have technical debt, feature bloat, and terrible UX/UI. It takes weeks to even see a demo from their sales team, and pricing always feels baited.

Newer players are more flexible but still relatively unproven, with feature roadmaps that could change based on the company’s latest round of funding or their largest customer.

Colorful opinions exist about both routes, with most takes suggesting that EHRs should be unbundled. Unfortunately, no off-the-shelf tool will cover 100% of the functionality you need.

In the face of all this friction, you might be thinking you should just build your own EHR. But unless this will be your key differentiator, the consensus among vets in the space is that you’d be better off buying than building. Don’t make the mistake of thinking you’re a true technology company when, in reality, your business model is tech-enabled services.

For those who are buying, we’ve outlined the most important questions to ask during the process. (There are some helpful perspectives in this tweet thread from Dhruv Vasishtha, too.) If you are one of the brave few who has decided to build rather than buy, this article isn’t really for you... but we’ll keep you in our thoughts and prayers.

We’ve grouped these by the user personas most commonly found at digital health startups, because this is not a decision to make in a silo—each team leader should be bought in.

The personas we've included are:

• Founders
• Product Leaders
• Designers
• Developers

This is not by any means an exhaustive list–just the considerations we’ve observed to be the most influential while navigating dozens of EHR integrations and vendors. You can also find a more extensive list of our questions here. If you have opinions on these thoughts, we’d love to hear them: hello@lightmatter.com.

Founder considerations

As a founder, you're the ultimate decision maker. It’s your responsibility to ask the most thoughtful and prying questions. A mistake choosing this partner could lead to a 10x difference in cost or time to market. Or a contractual inability to de-platform and select a new vendor in the future.

We’ve found the following topics to be most important for your role:

• Do you (really) need a certified EHR?
  Certification isn't obligatory, and there are multiple non-certified EHRs on the market. That said, having a certified EHR is mandatory for any provider that works with Medicare and/or Medicaid and hopes to benefit from CMS' EHR incentive programs. If that's you, you can start the process of elimination here, and this tool can help. Otherwise, what you might actually be looking for is a HIPAA-compliant CRM or a lighter-weight care operations platform (like Welkin).
• Does the EHR’s pricing structure match and fairly scale with your startup’s business model?
  EHRs have a variety of ways in which they price their product, and likely multiple tiers of fees. Most charge per user, whether that user is a provider, PA, nurse, admin user, front desk, or other form of staff. There may also be one-time implementation fees, revenue sharing fees, and others for tiers of support and training. Some also gate features by plans, such as offering API access or not. As a founder, the EHR’s pricing model must align with yours. Your EHR will likely be your single largest SaaS cost; understanding how and why you will be billed is critical. One additional tip: everything is negotiable.
• How have you been treated throughout the sales cycle? 
  Second to pricing is an instinct-based question. What does your gut say about working with the vendor? How has your experience with the customer success or sales team been? Are they punctual? Do they answer your questions directly? Have they given timelines for both their sales cycle and implementation? What level of support do they offer during integration and beyond?
  
  The way you’re treated as a prospect can tell you a lot about what to expect as a customer; if the experience has been sub-par thus far, it isn’t likely to improve after that confirmation email from DocuSign lands in their inbox.
• What is the opportunity cost of working with this EHR, and now?
  As a founder, it’s your responsibility to ask what am I giving up by making this decision? Is it the ability to easily migrate your patient data at a later date? Are you compromising on a robust set of developer tools? Will physicians just have to deplore another new piece of technology while your patients enjoy a seamless digital health experience? Which features can you live without? This might be the most important question of all—and one that the sales rep likely won’t spell out for you.
  
  Ask the EHR vendor for references. Ask each reference about the biggest regret they have, if any, working with the vendor. 

Choosing the wrong EHR can have immense path dependency and painful switching costs. Choosing the right EHR decreases time to patient impact and discovering your unique tech / operational IP.

-Dhruv Vasishtha, SVP Product @ firsthand

Product considerations

Product Managers balance your team’s ambitious vision with the constraints of reality, like the timeline and cash pressures that founders lose sleep over. They look holistically at workflows across engineering, design, clinical, and ops to weave together a cohesive narrative forecasting how your EHR choice could impact your product roadmap and long-term business growth.‍

• ‍What differentiators does each EHR offer?
  Founders may not have the bandwidth to thoroughly compare every feature across EHR options, so it's usually delegated to their PMs. The complexity and range of requirements needed often leads to EHR vendors specializing in order to stand out from larger players (e.g. athenahealth). EHRs have "niched down" to build software tailored to specific healthcare verticals or patient conditions (Osmind for mental health, Modernizing Medicine for other specialties, etc.). These specialized EHRs empower designers and developers to build features, views, and workflows with more specific user personas in mind.
  
  In the same way founders need to align the EHR’s pricing with that of their business model, PMs should do so for core capabilities and requirements. Some platforms brand themselves as CRM or scheduling focused (e.g. Welkin), while some focus on provider experience (like Elation or DrChrono). Others are merely revenue cycle management tools. Some EHRs expose partial functionality in their APIs for access and convenience (like Canvas or Healthie), and some are even open source (like Medplum) to provide developers with access to React components, advanced authentication options, and more for system integrations.
  
  Overall, niche EHRs lead to higher NPS scores, increased product adoption, and greater patient and physician satisfaction.‍

• Does the EHR support your most critical features today? Tomorrow?
  Comparing feature lists across EHRs is painstakingly tedious, but it pays to get as granular as possible. (Know which product requirements are your must-haves and which are your nice-to-haves ahead of time, and make sure you don’t neglect buy-in from the providers or teams that will actually be using your product.)
  
  You don't want to select a vendor based on promises. When asked about a particular feature, sales reps will undoubtedly tell you it will be released "soon" or “in time for your product launch”, but this rarely happens in practice. That is, unless it is already documented as part of the company’s product roadmap.
  
  If you can't find a roadmap on their website, ask for it. A public roadmap demonstrates that the company is forward-thinking and that they're in the habit of soliciting and incorporating customer feedback.
  
  You'll also want to gauge how extensible the EHR is. Understanding the foundation and its abstractions (like data model, identities, ability to subscribe to events/notifications, clarity into their data infrastructure for compliance) can give you a better sense of how much friction you might encounter with the EHR in the future.

• ‍Which security and interoperability standards does the EHR uphold?
  ‍Knowing which standards your EHR practices (and to what fidelity) is essential for protecting your PHI as well as your long-term interoperability needs.
  
  Interoperability standards enable multiple healthcare systems, practices, and providers to capture and surface information about a single patient and their care, which improves care coordination, delivery, and, ultimately, patient outcomes.
  
  Many EHRs are building toward the specifications outlined in HL7's FHIR, the most widely recognized standard in healthcare interoperability. And with the recent update to the ONC Cures Act, EHRs are now mandated to have a standardized API for patient and population services.
  
  Other standards include those that speak to healthcare terminology and messaging, frameworks, architecture, and more. Especially prescient to digital health startups and hospitals looking to decouple from their legacy EHRs, your new choice should allow for a rich data environment that can support analytics, reporting, dashboarding, and other segmenting of data for public and private consumption.
  
  Healthcare regulations are constantly changing, so make sure your EHR can speak to how their platform will support interoperability, HIPAA, etc. both today and in the future. (For a better understanding of the latest health tech policy and regulatory developments, check out this primer piece by Marissa Moore and Brendan Keeler).

Designer considerations

Healthcare technology isn't exactly known for its beauty or simplicity. Designers face an uphill battle (see Jakob's Law) and often hear pushback from development teams who can’t fathom even minute aesthetic tweaks.

The EHR's architecture and access to data has implications on your product's user experience and interface (UX/UI), regardless if your users are patients, providers, or other user personas who support them. Designers carry a burden in pushing the thinking of what’s possible with design, while considering the constraints of the platform.

• ‍What level of design customization does the EHR support?
  Depending on the available platforms your product offers (patient and/or provider) and the freedom of interaction each user persona has on those, your EHR choice impacts your design team's ability to customize UX and UI, along with any other tech platforms relying on its data.
  
  Why should you care about this? Because even simple improvements to UX and UI have the potential to massively improve patient education, care navigation, engagement, adherence, and more.
  
  Some EHRs only allow for light white-labeling of their platform. In these cases, users must access data on the EHR's platform, and your company's brand only comes through in your logo and a few custom colors. Customers will know that they’ve left your ecosystem and entered another, which is never an ideal user experience. (Especially if the EHR’s own branding and design is less than desirable.)
  
  Other EHRs allow for more modular experiences by offering API access (we like Welkin and Healthie for their customizability). Some are even fully headless (like Medplum), which means your developers and designers could build a bespoke, fully-custom platform that pulls in the EHR’s data hosted on your provider's servers, removing the risk of disorienting your users.
  
• ‍Which EHR will provide the best experience to your users?
  No EHR has a reputation for being particularly user-friendly, but some are better than others. When selecting your EHR, look at its interfaces and assess their design team's approaches when building them.
  ‍
  Many of the big name legacy EHRs were built before behavioral design became ubiquitous, which means they fall very short when it comes to user experience, especially in comparison to modern, user-centric startups who have invested heavily in UX/UI.
  
  Some EHRs choose to innovate on the provider side, allowing for easier adoption by physicians across an organization, while others focus more on the patient experience. Putting in the work upfront to understand your target personas and their most pressing needs will help you prioritize product and EHR requirements.‍
• Will the EHR enable you to meet accessibility requirements?
  Does your EHR need to support multiple languages? Or a higher accessibility rating? Does it account for end users with audio or visual impairments?
  ‍
  The US Department of Health and Human Services (HHS) requires a minimum level of accessibility compliance with the Web Content Accessibility Guidelines (WCAG 2.0) Level A. (Source). So, in theory, the EHRs you’re evaluating should be designed and built with accessibility in mind. That said, when building in such a highly regulated industry, it's worth double-checking to avoid making a catastrophically expensive mistake.‍

Developer considerations

As a developer, you have the largest responsibility on your shoulders of all the user personas. You have to confirm technically what the EHR’s sales team said is true, communicate this to your own team’s designers and product managers, and finally summarize this for your founder to make a decision. Looped process. No pressure.

When kicking off your conversations with the EHR, topics on documentation, infrastructure and architecture, third party integrations, native vs. non-native features, and the development roadmap of the EHR should all be discussed.

Throughout vetting calls, we’ve noticed a pattern that happens: conversation talking points slowly shift away from the features currently supported by the EHR, and toward those not yet supported. As this happens, questions around the EHR’s technical debt, interoperability, and more sensitive topics surface.

This is a good thing. It’s the EHR’s responsibility to be candid about their roadmap and product. For all discussions, we suggest driving the conversation toward this full transparency.

• Does the EHR have clean and well-organized documentation? 
  Leading software companies in other industries (think Stripe or Twilio) are known for the quality of their technical documentation. Often, the documentation becomes the product itself, and it reveals the company’s intentions. Versioning, last-edit dates, languages and frameworks supported by their API, data formats, and even typos communicate priorities and forecast what you can expect from their product. It’s a massive red flag if the EHR’s documentation doesn’t align with claims made on sales calls, has technical errors, or is poorly maintained.‍
• How much time is spent on the roadmap addressing technical debt?
  A great metric of a healthy Software Development Life Cycle (SDLC) is the consistency and percentage of time dedicated to addressing technical debt. EHR platforms should track this like any other software company. Whether it’s infrastructure and architectural debt, deprecated features, lack of test coverage, an undocumented deployment process, or many of the other forms of invisible debt, a forward-thinking EHR will acknowledge this and dedicate time to address known issues.
  
  Asking about this reveals the true technical maturity of the EHR and their ability to support you as you encounter product issues.‍
• How API-driven is the EHR, and what level of third party integrations are supported? 
  Most EHRs have some form of API. If not, we wouldn't even consider them. A deeper question is how API-driven is their EHR, and how extensible is the overall product with third party integrations?
  
  An EHR’s third party integrations are only as strong as the company’s ability to support them. No software is truly self-serve, and a human relationship exists behind every form of integration. If the EHR has a long standing relationship with multiple vendors and case studies to support those integrations, that’s a good indicator that the integration will continue to be supported.
  
  Make sure you know your product’s core capabilities and requirements and if/how they are supported. Each customization or third party integration will add to the development timeline, so weigh those considerations with your Product Manager as well.

‍Final thoughts‍

The decision process is plagued with never-ending feature lists and healthcare jargon, but choosing an EHR will impact so many facets of your company—from product roadmap and company growth to user experience and retention.

You can take the headless approach and pick an API-driven EHR, using the service only as a backend with a fully custom patient and provider experience you build yourself. You can do the opposite and rely fully on the EHR vendor for patient and provider platforms, integrations, and all other services out of the box. Or, you can pick something in between. That’s why making this choice is so nuanced, as the choice is truly custom to what's best for your team and product.

Here’s a few final tips for making the best decision possible with the information you have:

1. Solicit multiple perspectives. There are plenty of personas not listed here, like ClinOps. Ask them for their thoughts and feedback too.
2. Give your team time to research your options and space to express their perspectives. This decision could take a few weeks to a month.
3. Trust what you read and hear from others, but do your own homework too. Fully vet EHR claims and see how well their offerings align with your goals. 
4. If you want to dive deeper, we’ve outlined even more considerations in a checklist, our favorite form of palliative productivity.

Our biggest piece of advice? Don’t rush or trivialize this decision. The desolation that is due diligence might seem like a surefire way to suck out any of your remaining joy as a founder, but it will be even more agonizing (not to mention costly) if you have to do it a second time.