A Builder’s Guide to Picking the Right EHR

As a healthcare technology founder, creating an exceptional product experience depends on the EHR you select. How they’re built, what features they have, and how customizable they are all impact your product and startup’s outcome. 

However, there’s a problem with this evaluation process. Shit gets complicated, quickly.

How do you distinguish one EHR company that says ‘we do everything’ from another who says the same? And, how can these companies with products that do everything seemingly maintain all of it?

Imagine bundling your startup's most essential tools into a singular product. Take Gmail, Slack, Zoom, Salesforce, Stripe, and others for payroll, HR, and security—now cram all of those and dozens more into a single product —and expect the same quality of usability, speed, uptime and customer service.

There’s a reason a product this bad broad doesn’t exist—it wouldn’t work. 

Unfortunately, that’s what most EHRs attempt to do. And there exist some very colorful opinions about these attempts. EHR’s need to be unbundled, but we aren’t fully there yet.

So what are you supposed to do as a founder of a modern health-tech startup? (You’re probably thinking you should just build one yourself. You shouldn’t. We’ll write that rant in a later post.)

You need to pick the least bad EHR. This is a critical decision that will impact your startup's product roadmap, scalability, and patient experience.

As an attempt to help you navigate the endless feature list and healthcare jargon that is the EHR decision-making process, we created a checklist of considerations. 

These are the most important ones to think about, grouped by startup team user personas.

Developer Considerations

Designers will care most about each user's experience, whether they're a patient, provider, or another persona. They'll think through brand and platform implications depending on the EHR's architecture and access to data. They'll also be inclusive of all users, ensuring accessibility and surfacing how design impacts user behavior. 

  • Documentation: Does the EHR have publicly available documentation? In other industries, leading tech companies like Stripe, Twilio, and MailChimp are known for the quality of their documentation. Their documentation is so good that it often becomes the subject of discussion, rather than the product itself. Product evangelists at tech companies know this and prioritize documentation hygiene. Documentation tells you how well the rest of the product is maintained.EHR and health-tech companies are no different. Versioning, last-edit dates, languages supported, data formats, and even typos communicate the company's priorities.
  • App Architecture: A forward-thinking EHR will support a robust development platform while acknowledging the realities of its technical debt and legacy issues. All software has problems. These could be legacy code, weak integration or data exchange infrastructure, or an improperly structured app architecture. A mature EHR recognizes and owns its faults, and doubles down on the features that customers love.
  • Third-Party Integrations: Third-party integrations are a strong selling point of any EHR, but they are only as strong as the platform's ability to support them. Developers should understand the nature of each integration and why. For example, if an EHR uses Zoom's healthcare offering for telehealth appointments, why was Zoom chosen over another video provider? What implications does this have for your design and development teams if they build a custom app using this EHR? Tying up these digital loose ends should start as early as possible in the EHR sales process. 
  • Compatibility: As a developer, you may know how difficult debugging cross-browser CSS issues can be. Couple this with legacy health IT operating systems, a mix of Android, iOS, and Microsoft devices, and you have a perfect storm of technical debt to pay for years. Ensure the EHR you're considering supports the operating systems, devices, and browsers you need.  
This is a figure caption example.

Designer Considerations

Designers will care most about each user's experience, whether they're a patient, provider, or another persona. They'll think through brand and platform implications depending on the EHR's architecture and access to data. They'll also be inclusive of all users, ensuring accessibility and surfacing how design impacts user behavior.

  • Interface Customization: Your EHR choice impacts your design team's ability to customize its UX and UI, along with any other tech platforms which rely on its data. Depending on the product you're building, some EHRs only allow for mild white labeling of the platform. Patients must access their data on the EHR's platform, and your company's brand only comes through your logo and a few custom colors. Customers know they're on another company's EHR and platform, and it shows. Other EHRs allow for more modular experiences, custom design, and development. Some even offer API access to build a unique experience with your EHR's data. You could build a custom platform where the code is all your company's while still using the EHR data hosted on your provider's servers. 
  • Design Principles: EHRs don't have the best reputation for being user-friendly. When selecting your EHR, look at its interfaces and assess the design team's approaches when building them. Most legacy EHRs apply functional design principles. Modern ones are more behavioral and user-centric, especially for patient-facing applications. Others choose to innovate on the provider side, allowing for easier adoption by physicians across an organization. Know which persona your product needs to prioritize. 
  • Accessibility: 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). The EHR should be designed and built with accessibility in mind, but it's worth double-checking.

Product Considerations

Product Managers on your team can look holistically at both engineering and design decisions and weave together a narrative of how your EHR choice will impact long-term business growth. They’re the strategists who can think creatively and flexibly, while balancing the time and cash pressures that founders lose sleep over.

  • Differentiation: Because of the complexity, EHR companies have "niched down" to build software tailored to specific healthcare verticals or patient conditions. By specializing, designers and developers can build features, views, and workflows with more specific user personas in mind. Many EHRs also choose to differentiate with branding and features resemblingB2B SaaS products. For example, Welkin brands itself as "Care Management Software." Having built unique workflows to manage patient discovery and intake, Welkin blends EHR and CRM capabilities better than others. On the other hand, Dr. Chrono is incredibly developer-focused. As an API-first EHR, it allows for advanced customizations to workflows and data. Overall, niche EHRs lead to a higher NPS, adoption of the product, and patient and physician satisfaction. More edge cases emerge as the target audience of the software narrows. 
  • EHR Ecosystem: In addition to an EHR’s features, you’ll want to evaluate the suite of tools that come with it and whether they’re built in-house or integrated as a third party. Beyond storing patient data, many EHRs now bundle other software products and services for hospitals, physicians, and those working in or near health. Athena doesn't just offer an EHR— it provides Revenue Cycle Management, Patient Engagement, Population Health, and Advisory Services. 
  • Product Roadmap: A sophisticated EHR will have a public roadmap for its product, demonstrating that the company is forward-thinking  and willing to incorporate customer feedback. Sales reps will undoubtedly tell you a specific feature will "be released soon" or in time for your product launch, but this rarely happens in practice. A public roadmap allows you to validate each EHR you vet—if you can't find one, ask for it. The lack of a roadmap, or their willingness to share it, shows how transparent a business partner they'll be. 
  • Standards Upheld: Knowing what standards your EHR practices (and to what fidelity) are essential for long-term interoperability needs. Many EHRs are building towards HL7's FHIR specifications, while some are choosing not to. [Greg]
This is a figure caption example.

Founder Considerations

As a founder, you’re probably thinking about cash, timelines, and scalability. You understand that a rudimentary workflow might mean a 10x difference in cost or time to market. But then you might need to switch vendors later, which is sure to be a nightmare. In reality, all options might seem sub-optimal. But you need to make a final decision. What does your gut tell you?

  • Practice Model and Cost: As a founder, knowing exactly why you need an EHR matters, especially for cost. Your EHR may be different if you have physicians on staff vs. if you need to manage patient data coming from another app or integration. EHR companies can bill by practice size, features used, expected number of patients, or even through a revenue share model that measures encounters. Your EHR will often be your single greatest SaaS cost— understanding how and why you will be billed is critical. 
  • Sales Experience: What has been your experience with the customer success or sales team? 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 customer shouldn’t be overlooked. 
  • Opportunity Cost - 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 have a terrible experience while those of your patients are optimal? Which features can you live without? You’ll need to meditate heavily on questions like these.

Conclusion

Choosing an EHR isn’t easy or a casual decision. The EHR you choose impacts your product roadmap, company growth, and patient experience. To make the best decision you can with the information you have:

  1. Consult everyone on your team. There are plenty of personas not listed here. Ask them too.
  2. Give them 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, but do your own homework too. Have your developers, designers, and product managers fully vet EHR claims and see how well their offerings align with your goals. There’s even more considerations in this checklist too (+ template you can copy).

Opt for a transparent, forward-thinking EHR that values your time and business. This decision is just the beginning—you’ll have to work together on implementation, feature updates and releases, and patient support.

Next Post
Next post arrow

Approaches to Pricing Software Projects