In-Depth: Digital health APIs every health startup should know

By Brian Dolan
Share

KP LocatorIn 2013, Kaiser Permanente joined the API game with Interchange, an open API that initially just gave developers access to information like location data and hours for KP facilities. Future plans for Interchange, though, involve making a lot more data available to consumers.

“We’re excited to see what developers come up with as we open up secure, public data sets,” Phil Fasano, executive vice president and chief information officer at Kaiser Permanente said in a statement last year. “Imagine being able to download a mobile app so customized that it shows you nearby restaurants that cater to your healthy lifestyle and offers food suggestions based on the amount of activity you have completed in the last week, your nutrition plan and friends’ reviews. Once you’ve finished your meal, a device synced to your app reports your blood-sugar levels and reminds you to pick up insulin, then tells you the nearest Kaiser Permanente pharmacy where you can pick it up. Interchange by Kaiser Permanente is the beginning of that possibility.”

Also in 2013, on the provider side, EHRs started to talk more and more about APIs. Mobile-based EHR drchrono opened an API to allow developers to build apps that would work within its mobile offerings. Practice Fusion promised an expanded API to connect its EHR to more health devices, and one of the first fruits of that API, an integration with AliveCor, debuted last month. And Allscripts CIO Stanley Crane boasted to MobiHealthNews last year that they were the only major EHR company to open an EHR to third-party developers.

“We’re allowing third-party developers to do things that our competitors would sue them for,” he said. “Can I say ‘blinging out our EHR?’”

How open is open?

Of course, whenever there's data sharing, there's a question of how much data to share and what kind of conditions to put on the sharing of data. There's another question of what the data sharer gets out of it, and this answer is different in different cases.

shineMisfit Wearables, maker of the Misfit Shine activity tracker, is planning to open its developer API, which may or may not be free, by the end of Q2 2014, CEO Sonny Vu told MobiHealthNews in a recent interview. He said the company is working on both an API and a software development kit (SDK). While an API allows integration between two apps (and requires the user have both apps on their device) an SDK can facilitate data sharing directly from the Shine to a third party app.

"With the SDK, which is private, basically what we do is we select one partner in each industry. Healthcare, weight loss, fitness, fashion. We don't need a lot of partners, we need one or two that are really special. Basically, these are the folks that have amazing digital experiences already. And users can just use that -- they don't need us to get in the way."

Vu said that most fitness devices are opening APIs to third party developers because they allow companies to retain more control over what data they share and how it's used. He thinks that way of thinking about people's data will change as more and more integration occurs.

"For relatively straightforward reasons, people want to control data and access the data," he said. "I think it's unfortunate that some folks take the position of 'We're going to collect this data, we're going to keep it all, but you're going to have to pay us to get it.' That's kind of what we see happening now, but I have a feeling over time that's going to change. I have a feeling that even the notion of data ownership might change, and it might just come down to access levels, and the question is who gets to be the granter of those access levels."

In different API use cases, there are different motivations for opening up data. Fitbit or Jawbone might want you to be able to do as much as possible with the data you collect with their device, but they also might want you to have to interact with their app (and their advertising and branding) when you do. Drchrono and Nike's APIs offer developers a trade: you get the exposure of being on our platform, while we get new features and functionalities to offer our users. Walgreens, which opened up the API for its prescription refill service last February, explained the proposition pretty well.

“[Mobile apps] are just one way for us to interact with our customers. And we woke up to the fact that it may actually be even more lucrative to take that connectivity and open it up as an SDK, an API to third-party developers,” Abhi Dhar, group vice president and CTO for the e-commerce division of Walgreens, told MobiHealthNews at the time. “We have a rather popular mobile app, but in addition to that we want to offer the creativity of the developer community."

Other API plays, like Aetna's and Kaiser's, have more of a bigger picture return on investment. Aetna and Kaiser are both healthcare payers, so they benefit from giving consumers tools to better take care of their own health, because those tools could potentially reduce preventable hospitalizations or readmissions. If they can do that by releasing their own data to developers, that's an end in and of itself for them.

Still other groups are taking advantage of the trend toward integration and data sharing and building whole business models on streamlining that integration. One of the most high profile companies is Validic, which helps wellness companies, healthcare providers, pharmaceutical companies, and health plans get access to the data from apps and devices that have open APIs, essentially aggregating them into one stream. Validic made news in November when high-profile investor Mark Cuban participated in the company's seed round.

Digital health data sharing is still in its early days. The future will lead to more sharing, more open architecture, and data collaborations we can't even imagine now. Once everything from your Fitbit to your doctor's EHR to IBM's Watson can work together digitally in your pocket, the sky's the limit for connected consumer health.

Read on for a list of digital health APIs (and those coming soon), that every digital health startup should know.