The Kaiser API

I’m a big fan of Kaiser and have been for a long time. I was a member for several years, spent a lot of time at a Kaiser hospital as a medical student, and my wife did her intern year at a Kaiser facility.

Kaiser is not perfect, far from it. But it’s good, and that’s more than I can say for most of my experience as a patient or the family member of a patient. I also use the Kaiser Health Manager, which is basically a PHR with messaging and scheduling capabilities.

I’m a big fan of APIs and anything that breaks down barriers to building health apps. We’re starting to see more and more of this in healthcare. EMR vendors like athena, Allscripts, Greenway, and several others are starting to open up access to data.

When I say access to data, I don’t mean any developer can write an app and instantly have access to all patient data in an EMR. The goal is to allow third-party app developers to build apps for patients and providers that utilize that EMR data, or maybe data from other systems.

There are lots of security and privacy issues. Third parties need permission from data owners to access the content. It’s really not that hard technically, but it can be hard politically. Sometimes in healthcare it’s not easy to define data owners and those who need access to their data.

Think of Facebook or Twitter. When you sign up, you have to grant permission to that third-party app to access your contact list, post in your stream, etc. The same should be the case with third-party health apps, which require permission to access your medical record (or maybe even granular parts of your medical record), send messages to your provider, and access your list of appointments.

This week at Datapalooza, Kaiser announced it was opening up an its own API called Interchange. It also released a white paper that discusses the API in its current state and into the future.

My first reaction, and still my sentiment after digging deeper and spending more time on it, is that this is a very important step by Kaiser. Similarly to Aetna’s CarePass, Kaiser is acknowledging the power and creativity of the collective technical and HIT community to build health tools powered by data. It is opening the door, or at least sending a message that it’s opening the door (more on that later, but the data offered by the API is limited) to the outside world to build apps for its members.

Kaiser is taking lessons from outside of health and applying them. That’s all very great! It’s also super to see a provider throw a hat into the world of APIs, competing with payers like Aetna that are already trying to move this direction.

I signed up yesterday for the Kaiser API and received approval and an API key. I haven’t really done much except play around in the sandbox that Kaiser provides. It’s a little rough around the edges, but it’s a great start, and Kaiser does offer a sample iOS app to help developers get going. I’ll be messing around more with the sample mobile app and data soon.

The API only offers location information for Kaiser facilities. This is a very limited data set as a starting point. The next steps are to add in wellness data — which I’m assuming is both activity and nutrition — and internal Kaiser research data.

Just to be clear, Kaiser states that "personal health information will not be made available externally via API technology," so the data will simply be a unified end point for things like wellness trackers (Fitbit and Jawbone as the likely first two.) There are some other companies trying to unify the different fitness apps and sensors, but Kaiser has some serious pull to get the vendors to the table.

The wellness data is the most interesting and the most valuable to consumers, and by extension, to developers building apps for consumers (in this case, “consumer” means Kaiser member.) It will be interesting to see what developers build and what Kaiser puts out as example apps. I’m hopeful we see some very cool apps that combine data from various sources and provide individualized insight.

The major limitation is the lack of PHI. I understand and appreciate the privacy concerns, especially for a health system. Obviously Kaiser can’t allow any app to access any and all PHI. But if users can be matched, say using Kaiser’s Health Manager logins that already have access to PHI, then why not allow users to grant apps permission to access data? I’m sure this is a compliance and legal minefield; I just wish it weren’t.

Ultimately if Kaiser is going to "support hyper-personalized care and service" (from the new Interchange website), which is a pretty good way of saying that I wrote about last week, it will need to open up some of the PHI data it makes available through its Health Manager. Maybe it could start by opening up appointment scheduling via the API.

Despite the limitations on the types of information available in Kaiser’s new Interchange API, this is a great first step. It can ideally serve a model for other similarly advanced systems.

Does anybody else out there share my excitement?

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

  • kylesamani


    In my view, they need to adopt a policy similar to Android’s play store. When you go to download an app, the play store enumerates all of the security provisions and clearances that app requires. Those are automatically generated because Google scans the .apk files that developers upload the to Android developer console.

    Similarly, Kaiser should off offer similar transparency and accessibility to patients, and thus developers too. Every API call – medical history, lab data, allergies, vitals, problem list, etc – needs to be automatically listed based on API calls that developers use.

    Do you know how they’re doing this from a technical perspective? Everyone knows Kaiser runs the most pimped-out version of Epic on the planet… Perhaps they’re using an existing Epic data feed, transforming the data using their own custom back end, and making the data available to developers as RESTful calls? I don’t think the Epic technology stack supports anything that resembles modern programming APIs out of the box

↑ Back to top

Founding Sponsors

Platinum Sponsors