As we’ve discussed at length in another article, choosing the right EHR will impact everything from your product roadmap to the quality of your end user’s experience. This choice can affect how fast you launch, the extent of your tech capabilities as you scale, and the security of the sensitive patient data you manage.

A decision with stakes this high can be overwhelming. Basic questions about platform capabilities can quickly spiral into conversations about API endpoints, accessibility, and browser compatibility. 

You’ll want to make sure your EHR vendor is adaptable and willing to move at the pace of the customers it serves, or, ideally, faster. New health products are being created, new clinician and patient use cases are being discovered, and new regulatory guidelines are being established on what feels like a daily basis. 

Our team has lived through the EHR selection process several times, and experiencing the same challenges and uncertainties with multiple clients has taught us a thing or two about making this decision well.

We’ve synthesized our learnings here to create the resource we wish had existed when we needed it. We’ve cataloged these lessons into questions and considerations, grouped by the functions or teams that will be most impacted by your EHR decision. 

Some of these questions may seem trivial or oddly specific. Because they are. We created this list based on real experiences and edge cases we've encountered when building with various EHRs.

Hopefully, it can help you avoid a few dumpster fires we’ve lived through.

Founder considerations

• Do you need a certified EHR? If the answer is yes, you can start the elimination process with this Certified HealthIT Product List.
• Are you starting an actual medical practice, or do you only need to manage patient data?
• If a practice:
  
  - How many physicians will be on staff? 1 to 10, 10 to 100, or more?
  ‍
  - Are you looking for an EHR for physician providers, non-physician providers, or both?
  ‍
  - What other staff roles (physicians, nurses, office admins, etc.) will be part of the practice?
  ‍
  - Will there be a physical location for your practice, or will all care be delivered virtually?
  ‍
  - Are you managing labs or imaging in-house with your equipment or referring out?
  ‍
  - Will you be using generic pharmacies or pharmacy white-labeling services for fulfilling prescriptions?
• What other integrations specific to your business do you need with your EHR?
• How quickly does the sales team respond to your emails? Is there a single sales contact dedicated to your account? Are their answers direct?
• Can you ask questions to non-salespeople—like engineers, designers, or product managers? Or does the EHR gatekeep and limit conversations?
• What is the estimated timeline from the first conversation, through sales, to implementation? (Double this for your own internal buffer.)
• How does the EHR price itself? Does it bill by the number of physicians, practices, patients, or do they use another model? Do they have one-time installation fees or annual service fees? Do they charge hourly rates for additional custom development?
• Do they bill monthly or annually? Do they have alternative strategies for pricing, such as revenue sharing?
• How would you justify this specific EHR to your board? To your internal stakeholders? What is their unique value proposition?
• Will you ever need to integrate with multiple EHRs, and if so, what relationships has this one established with others?
• What is the opportunity cost of your decision? Does the EHR have the features to support your long-term product roadmap? Are you prioritizing the right tradeoffs?
  

Product considerations

• Does a product roadmap exist? Is it publicly available?
• Does the EHR already support your must-have features, or are you banking on unfulfilled roadmap projections?
• Is the EHR designed for a niche medical practice or specialty?
• What is the learning curve for your clinicians / users?
• Is it a traditional EHR or an EHR bundled with other offerings like a CRM or task management tool? Investigate if it has B2B SaaS-like capabilities.  
• If so, what are these capabilities? Is it an API-first EHR? Does it allow for standard workflows such as registration, scheduling, insurance, payments, clean data exchange, and labs and other orders? 
• What other tools are available within the EHR’s ecosystem for admin users? Does it allow for reporting, dashboarding, and platform analytics?
• Is the EHR aligned with standardizations such as HIPAA, TEFCA, or HL7's FHIR (including the recent Cures Act update)? 
• Is the EHR open about sharing the most- and least-used features? What are customers most excited about? Do they talk openly about known legacy debt and growth opportunities of the platform and company? 
• Do any public reviews exist on the web? What are the most common complaints and benefits? How does the EHR respond when asked about these concerns?
• Do they share feedback from other customers and allow you to speak with references before purchasing?
• If needed, how easily can this EHR and your patient data be migrated to another? Are there costs associated with switching?
• What hospitals and other Health Information Exchanges (HIEs) integrate with the EHR? How interoperable is the actual data? 
• What does patient data look like when received from another EHR? 
• Given many EHRs were designed for insurance companies and billing at first, how does insurance affect the EHR's workflows? Does the EHR integrate with insurance at all?
• Have you discussed your choice with your general counsel or law firm? Have you discussed data governance, privacy, liability, data breach scenarios, overall security, and general service level agreement points?
  

Designer considerations

• What level of design customization does the EHR support? 
• Does it have interfaces for all your user personas, and can these be white-labeled? To what extent can your brand assets and voice be integrated to preserve a consistent user experience? 
• If white-labeling exists, what is the quality of UX and UI? What design principles do they follow? Are they just functional, or behavioral and user-centric? Do they go a step further and allow for personalization?
• How easily can users access their most sought-after data, such as appointment times, medical history and imaging, and payments?
• What accessibility standards, such as WCAG, do they follow? Can they be accessed in other languages if needed?
• Is the EHR designed specifically for one type of user persona? Is it the one you care most about? Will this tool positively impact their existing workflow?
• What reports and data visualizations are available for physicians and any admin team members? How will you measure if your EHR has been successful for you?

Developer considerations

• Does EHR documentation exist? Is it publicly available?
• Is it organized well? Is it versioned, and does it have a change log?
• What is the quality of documentation? Are there any typos, formatting issues, or inconsistencies? 
• Does an API exist, and are its endpoints publicly available? Is there a CLI or SDK interface?
• Does it support a headless strategy, and was it built with an API-first approach vs. being shoehorned in later?
• Is it DRY? Are you forced to build out basic features on top of it? Is the metadata returned across similar endpoints the same? Do the response statuses conform to HTTP?
• Does the EHR use their own API? (Yep, we’ve seen companies opt not to use their own tools.)
• Does the API make permissions (read and write access) clear? If multiple user personas need tiered access to sensitive data, knowing the permissions structure is critical.
• Is access and authorization clearly documented? Does the API tell you about any expirations on its issued tokens?
• What languages, frameworks, and data exchange formats does it support?
• How would the EHR pull and push data, such as patient records, from outside organizations?
• How are the download speeds? This is important to clinician workflow and data entry.
• Which features were built in-house, and which depend on third party vendors?
• Does it support any tooling integrations you need? Will those continue to be supported?
• Which app architecture does the EHR support? What's it built on? Is it microservices or monolithic?
• What are the primary data models, and how important are they? Which are considered first-class, second, etc.? Do they align with your application's data model?
• What are the supported platforms: desktop, tablet, and mobile?
• What are the supported operating systems: iOS, Android?
• What are the supported browsers: Chrome, Safari, Firefox, Edge?
• Is the EHR cloud-based, or does it offer on-prem services?
• Find out more about the app architecture. Where do images such as doctor or patient profile images get stored? 

Final thoughts

If you’d like to read more about how these questions and considerations should impact your decision, check out the companion post to this checklist here: A builder’s guide to picking the right EHR.

This list is not exhaustive, nor is it meant to cause "analysis paralysis." Our goal is to organize the ambiguity around the EHR selection process and help you think deeply about the key factors influencing your decision-making process. 

Don’t hesitate to reach out if you have any additions, questions, or grievances. We literally help startups select and implement EHRs for a living and would love to add other perspectives.