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.