Advice from an Interoperability Expert for Young Companies Selling EHR Solutions
Trying to land your first EHR sale? It’s tough selling EHR solutions (let alone get a meeting) with physicians, hospital administrators and IT teams. They’re understandably risk averse, want data to back up claims and need a long client list and referrals. No one wants to be the first with so much on the line.
At the first sign of resistance or potential opportunity – especially with a large prospect — we’re more likely to make concessions that can work against our best interest.
But as athenahealth CEO Jonathan Bush warns, seeking big deals early on is a bad idea for young startups.
Even if you’re fortunate to land that big deal, you may “wind up creating custom functionality for one institution that no one else can use without being rebuilt again.”
Drawing the Line on Customization
So how do we sell our first EHR solutions and not undermine scalability? And where do we draw the line on customization to meet a prospect’s demands?
Young EHR companies understand the product development cycle is iterative. Solutions will evolve over the course of our product life cycle.
Customization is music to customers’ ears and and often found marketing materials. We want to help doctors maximize their healthcare practice and record management processes — cost-efficiently and effectively. We want to address their unique needs and individual quirks, but we also want to create a scalable solution.
For insight, I reached out to EHR interoperability expert, James Lloyd, co-founder & CTO of Redox. As an “API for healthcare,” Redox’s integration platform allows software systems to share data with electronic health records (EHRs).
In our far ranging conversation, James and I looked at customization, interoperability, what it takes to land the sale of EHR solutions and how do we gain credibility with medical staffs and IT teams.
Customized EHR Solutions: Workflow Vs Structured Data
James: Expect customization to happen at the user experience and workflow level.
Common customization would include the sequence of screens and the user workflow to accomplish a particular task. It’s the presentation layer of interacting with the data. I see those features being customized frequently based on how the clinic or hospital has set up its operations.
You should be more cautious about customization requests that would cause the actual structure of collected data to vary from site to site.
Make those decisions in a more holistic way. You should ask yourself if Health System A really wants us to do this, is that something we want Health Systems B, C, and D to have? If not, then it’s something to push back on or consider prioritizing other features.
Understand Why Customization is Needed
James: Understand the reason behind their request for making changes. Try to internalize it. Ask why 3 or 4 times before you reach a natural conclusion. Many feature requests at the surface are not the real solution. There is something deeper or more fundamental that you can change that addresses that request and potentially others in the future.
Be very open minded to each health system and their operational workflows. Your software solution should not change the natural operations or dynamics that employees of a health system or clinic have with each other.
Advice on Interoperability
James: Don’t boil the ocean with your integration scope. Present a phased approach on how you’ll roll out your product’s feature set.
Certain things are going to make health systems more cautious when it comes to integration and interoperability. Reading a provider’s schedule is low risk compared to an external application that’s designed to create new patients, update insurance and send out claims.
As you are going through the integration project, understand that data and security concerns are more risky to the IT team. We typically recommend you have an MVP version of your product that’s available and can be distributed with only those low risk type of things.
Once you can demonstrate your application is trustworthy and makes users happy, then you are better able to introduce more risky (in their mind) interfaces. That’s typically the path we want to go down for applications needing a wide variety of integrations.
James: Scaling your solution requires that you establish some credibility. For your first one or two sites, you probably have to effectively give it away unless you can demonstrate value in some other way.
James: Flashy graphics or buzzwords won’t win over a decision maker, but 10 academic institutions using your product will. They don’t want to miss out. Purchasing decisions made at the enterprise level are often based on group think.
I look at a lot of website resource pages. It’s quite tricky; many good companies are bad at marketing, and others that are good at marketing have bad solutions. Nothing is better than a full demo with real tangible details.
I slant pretty analytically in my evaluation process. What I really want to see is the number of implementations and average install and up times. The numbers behind the product really resonate.
And what is the return on investment? Without being able to quantify the ROI, it’s very hard to warrant the resources that go into bringing on a new solution. I don’t see getting beyond the first conversations with a health system for companies that can’t articulate that very well.
How Redox Can Help
James: A company would come to us if they needed help with an integration or getting into a health system. We have a modern API based structure so any web developer can build or develop an API and start to leverage our platform to integrate with health systems.
We essentially provide a middleware layer that helps modernize and standardize health systems. We help them scale from one site to the next and have a consistent buyer experience so any web developer can interact with it.
Partnering with Established EHR Players
James: When partnering with established EHR larger players, be aware of their different business models. Understand they have very legitimate patient safety concerns. They have responsibility for external vendors. There is a lot of work that goes into what they do.
Establish credibility with a provider first. Getting in front of an EHR provider without a mutual client is pretty ineffective.
The Value of Clinical Champions
James: I see internal champions being very effective at helping navigate the specific organizational requirements and quirks.
Each health system has different permutations for common roles. Different departments interact with one another and structure their budgets differently based on whether it’s an operational or capital expense. At one health system, for example, you may want to structure your contract that’s very heavy on the service side as part of its operational budget.
Insider knowledge can help you structure your contract in a more conducive way.