EHR APIs Are Hard

I’ve been thinking a lot about healthcare interoperability lately. I’ve long argued that it’s one way we can really lower the costs of healthcare. Plus, I’m a true believer in the value of doctors having all the information possible in the right place at the right time. I’ve also advocated strongly for EHR vendors to create APIs that allow other entrepreneurs to build really amazing functionality on top of the EHR.

This last point is the one I want to address now. I still think an EHR API is going to be essential to the future success of an EHR vendor. The reality is that the EHR isn’t going to do everything for everyone. My favorite example is genomic analysis. EHR vendors are not going to do this. Some other company is going to take care of the genomic analysis and then they’re going to need to want to have to integrate with the EHR for their to be a beautiful workflow for everyone involved. This integration is going to best be done by an API. Plus, genomics is just one example of hundreds of integrations that might be needed.

To me the case is clear why there’s a benefit to having an open EHR API. Why then, don’t we see more of them in the EHR world? The simple answer seems to be that APIs are hard!

I found a great description of the challenge of creating a quality API on the WordPress developer blog:

Developing APIs is hard.
You pour your blood, sweat, and tears into this interface that bares the soul of your company and of your product to the world. The machinery under the hood, though, is often a lot less polished than the fancy paint job would lead the rest of the world to believe. You have to be careful, then, not to inflict your own rough edges on the people you expect to be consuming your API because…

Using APIs is hard.
As an app developer you’re trying to take someone else’s product and somehow integrate it into whatever vision you have in your head. Whether it’s simply getting a list of things from another service (such as embedding a reading list) or wrapping your entire product around another product (using Amazon S3 as your primary binary storage mechanism, for example), you have a lot of things to reconcile.

You have your own programming language (or languages) that you’re using. There’s the use case you have in mind, and the ones the remote devs had in mind for the API. There’s the programming language they used to create the API (and that they used to test it). Finally, don’t forget the encoding or representation of the data — and its limitations. Reconciling all of the slight (or major) differences between these elements is a real challenge sometimes. Despite years of attempts at best practices and industry standards, things just don’t always fit together like we pretend that they will.

He also offers 3 recommendations when you choose to provide an API:
#1 You want people to use your API.
#2 You have no control over what tools others are using.
#3 Your API is a promise.

Let’s also be clear that a WordPress API is much simpler than what a quality EHR API would require. The principles still apply, but the complexity makes it even harder. I think this is a major reason why many EHR vendors haven’t yet done an API to their EHR. An EHR API is not a one time job where you set it and forget it. It’s an ongoing project that has to be updated and improved with every release. Plus, you have to make those changes and additions without breaking things for your partners who use the API. That’s not a simple job.

Despite being hard, I still believe that EHR APIs are going to be the future of EHR. Plus, an EHR vendor should be glad that EHR APIs are hard. That means that if they put in the effort to do one the right way, they’ll have an advantage over the others who don’t. There are hundreds of healthcare startup companies that would love to tap into a quality EHR API. If you build it, they will come.

About the author

John Lynn

John Lynn is the Founder of 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.

2 Comments

  • In the financial Market Data world, API’s are particularly critical, and they must be able to work with very low latency. As a result, a vendor may have had multiple generations and types of API’s, with each new generation having new capability and complexity – and programmers who can keep up with it tend to be in high demand. One of the biggest issues is that periodically, users of the API’s may have to partially or completely start again from scratch

  • […] This really resonated with me and no doubt resonates with doctors and hospitals who have an interface with some other medical organization. You know how easy it is for your interface to break. It’s never intentional, but these software are so large and complex that someone will make a change and not realize the impact that change will have across all your connections. As I wrote on Hospital EMR and EHR, API’s are Hard! […]

Click here to post a comment
   

Categories