The API Landscape in Healthcare

Kyle wrote a great post last  this week on APIs, specifically looking at Greenway vs. athena. He also gave a high-level overview of why RESTful APIs and the preference developers have to work with JSON as a data structure. I touched on APIs earlier this week as well when I wrote about "digital omnivores" and the use of the same service, Gmail for example, across different devices and using apps from different vendors to access the same data (Google Gmail).

APIs are powerful and are leveraged to build many of the tools that we use today on mobile and web. APIs are just starting to emerge in healthcare, or at least are starting to get some traction. Or maybe my perception is off because I’m entrenched in this world. Are you seeing and leveraging more APIs?

Kyle covered Greenway and athena. Other EMRs are starting to open up as well. I’d love to hear about experiences that others have had with EMR APIs. But this post isn’t really about EMRs opening up their APIs, though I think Kyle is right that EMRs need to start moving faster or they are going to see hacks to APIs and interfaces, like CCDA.

For better or for worse, if we are waiting on most of the larger EMR vendors to open up their data silos, we are going to be waiting longer than the market is going to allow. I’m talking about bigger vendors now, because I think smaller EMR vendors like Practice Fusion, drchrono, and CareCloud will meet the market demands. These vendors are all cloud-based, a distinct advantage for scaling an API. But EMRs are really only one source of data — albeit a very big source of healthcare data — and one source of API.

In addition to accessing EMR data and trying to create value-add tools based on that data, APIs are also a great way to add data to an EMR. The data models behind the API don’t matter. Applications and developers just need to send data to the API in the format accepted and the API server can parse and direct that information to the EMR data store, or potentially some intermediate data store. This could be powerful for developers of applications — and enterprises that want to use those applications — that collect data such as patient-reported or continuous monitoring data.

It’s also important to realize that APIs are not only end points for data. While APIs are probably the ideal way to allow easy access to different sources of remote data, which is desperately needed in healthcare, APIs can also provide logic, or access to algorithms. It’s possible to use APIs for decision support — pass along a set of symptoms or other variables and get back a formatted list of next steps, diagnoses, meds, follow-up questions, or whatever else you want to feed back to the application making the request. The API in this use case is enabling a third-party tool and developer to access custom logic. This logic and IP can reside on a remote server and only be accessible via well-documented API. You can imagine APIs empowering decision support, smart forms, or smart EMRs.

And then there are analytics that APIs enable. It’s very easy using APIs to run metrics, analytics, and quality checks on data going through the API.

The main point is that APIs are powerful, are what many modern web applications rely on, and can be secured. Most if not all modern APIs are accessible over SSL, so all data in transit is encrypted. It’s also relatively easy to encrypt from API to database or next hop, supporting encryption end to end.

5368B011-C668-4AB9-8A46-7B35A8B83E1A

Here’s a recent, non-healthcare example of an API-powered app that I now use on a daily basis. The app, called FindIt, connects to Gmail (and Google Apps email), Google Drive, and Dropbox via APIs. It indexes all of these services and gives a very clean and powerful way to find things. For me, finding things is a problem because I use multiple Gmail accounts, multiple Google Drive accounts, and Dropbox. If FindIt adds support for Evernote I’ll be even happier.

I store stuff in different places and other people send or share things with me all the time. It’s hard to keep track and I often spend time searching across multiple services — usually on web and not mobile — to find what I’m looking for. FindIt helps with this and I love it.

7F525208-8200-43BE-8A8E-B8D8BFCCF83A

FindIt isn’t competitive with any of the huge services from Google and Dropbox to which it connects. It actually adds value to them in my opinion. It was a lot cheaper and faster to build than Gmail, Dropbox, or Google Drive. It’s a value-add service that neither Dropbox nor Google would likely ever build, in large part because it runs across different, competing services.

The same holds true of EMR vendors. If EMRs opened up access, obviously only to approved developers and applications, they could become more valuable to individual users and enterprises. What about some of the EMR vendors that are having their lunch eaten by Epic? Worth a try, right? I don’t think CommonWell will accomplish this. Building an EMR from the ground up requires a lot more work than creating bolt-on apps or experiences for users. Selling an EMR is a much more expensive and time consuming endeavor than building an add-on for an EMR.

I said this wasn’t about EMRs, yet I can’t avoid making these very obvious points. APIs aren’t a panacea for all that pains healthcare and healthcare tech, but they are certainly a huge help to bringing health technology into the modern era, both in terms of performance and experience.

One side note I wanted to mention about creating APIs in the face of the API fanfare is that planning is just as essential as in other forms of tech development. Like everything in technology, thought needs to go into creating and exposing APIs before just "API-enabling" something. Tools like Mashery and Apigee that help athena, Kaiser, and Aetna create APIs for their applications are great, but just making data available via API is not the whole solution. Architecting permissions, routes, parameters, and a host of other requirements is imperative to assure that data and application owners understand how data can be used by third parties and how it can’t be used by third parties. This shouldn’t be a roadblock, however.

I embarked on a mission to document healthcare APIs, both those available today and those coming soon. There are the obvious ones like Kaiser Interchange, Aetna CarePass, and the National Library of Medicine (Pubmed, for example), but there are also many more. Some I know and I’m sure there are many more that I either haven’t heard about or maybe haven’t actually been launched. Health 2.0 has a site  devoted to APIs in healthcare and has over 2,000 APIs listed, yet I couldn’t find some of what I think are the more relevant APIs. ProgrammableWeb, which lists APIs across all industries, can be searched for "health," Both are good starting points, but aren’t broken out in a way that makes much sense to me.

I’d love help, so if you know of APIs or are building then, drop me a line.

TGphoto

Travis Good is a MD/MBA involved with health IT startups. More about me.

  • Mobile Man

    Very strong! I read a couple of points here (and in some other recent posts) that should definitely kick off some additional (and continued) thought and conversations…

    Not to veer too much, but this whole concept of the application “owning” the data is one of the largest roadblocks to enabling IT to really make a difference in healthcare. Last time I checked, me (the patient) owned most of the data, with perhaps the provider and/or facility owning the rest… Protectionism at it’s best!

  • William

    Great read, thanks Travis. It would be interesting to read a follow up one year later.

↑ Back to top

Founding Sponsors

Platinum Sponsors