What a Real Open EHR API Should Accomplish

There’s been a lot of talk in the EHR world about APIs and most of the time they talk about it as an open API. The problem is that there’s been a lot of talk about EHR APIs and not a lot of action. Having an open API is more than just giving a couple people access to some really small subset of your EHR. We need truly open EHR APIs that are more than just a nice press release.

A successful EHR API requires two core elements: Access to EHR Data and a User Base.

The first element is the obvious one and the one that everyone focuses on. An API needs to have access to the data in the EHR. This includes accessing that data for display in an outside application. Plus, it requires that an EHR accept data from an outside application. EHR APIs seem to fall short on both of these areas. Most only give you access to some really small portion of the EHR data. Even fewer let you write any sort of data to the EHR.

If you don’t give an outside application the ability to access the EHR data and write data to the EHR, there are very few applications you can build on top of it. Is it any wonder that the third party EHR developer community isn’t doing more things with EHR software? If they had these two things, EHR vendors would be amazed at what they’d build. I love Jonathan Bush’s idea of “every surface area” of athenahealth being available in an API. If he achieves this vision, third party developers will flock to that EHR and enhance it in ways that would have never been possible for athenahealth to do on their own.

The second piece is just as important to an API. EHR API developers need to get access to your existing EHR user base. This doesn’t mean you have to give them a list of all your clients. It does mean you need to feature the work of these third party developers to your existing user base. This can be in your application, in an email list, at your user conference, etc.

Think about the message you’re sending to your developer community and your existing user base when you do this. The developer community wants to build even more functionality into your product. Your EHR users get more value out of your EHR application thanks to the development efforts of an outside party. Plus, ambitious EHR users can even create their own functionality using the EHR API.

I can’t wait for the day that EHR vendors fully embrace the idea of a third party EHR API. There are so many outside companies that would benefit from an EHR API, but the EHR vendor will benefit just as much. Plus, the real winners will be the EHR users and patients who get the functionality they’ve been wanting from their EHR that the EHR vendor couldn’t deliver.

About the author

John Lynn

John Lynn

John Lynn is the Founder of the HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

6 Comments

  • howdy John

    you’re comments have one key implication: oligopoly. If EHRs need a minimum viable user base, then there can only be so many EHRs.

    I 100% agree with that assessment. In fact, I’d go further and argue that there shouldn’t be 400 EHRs… there should be maybe a few dozen. Instead of diversification at the EHR layer, there should be diversification and experimentation at the EHR app layer

  • For a third party application program to be successful it needs to have a minimum viable user base. It’s not that others can’t enter the space, but that they won’t likely be able to leverage the third party ecosystem if they don’t have a user base. The irony is that it’s hard to build an API into software if you’re not thinking about it from the beginning. It’s a constant balance.

    I do think we’ll see some consolidation like you describe. I’m not going below 100, but at least that would be a step in the right direction. Sadly I don’t see enough EHR vendors interested in diversifying the EHR app layer yet.

  • Howdy John

    You are probably right. It won’t fall below 100, and yes, we need better APIs yesterday

    Even Athena and Greenway – the 2 most open systems – aren’t that open. Greenway is far more paternalistic than Apple, and Athena’s platform just isn’t ready for prime time yet.

  • Absolutely agree! Real world example – a site was told by the EHR vendor they would have to enter medications into the EHR, not a Hemodynamic system in cardiology. This meant placing an EHR terminal next to the Hemodynamic station and forcing the nurse to enter meds in the EHR, not the Hemodynamic system! A brute-force and unproductive solution that could have been easily addressed via an API. The reason given? The EHR vendor only accepts medications entered in a certain manner!

  • Joseph,
    Great real world example. I wish that EHR vendors could see how these little things will make an enormous difference in the lives of their customers.

Click here to post a comment
   

Categories