Friday, December 14, 2012

mHealth and Data Liquidity

Healthcare Needs APIs More than Apps

This post was written with my colleagues Joris Van Dam, Translational Sciences Strategic Project Leader at Novartis Institutes for Biomedical Research (NIBR); and John R. Walker, director of NIBR IT for Novartis.

As frequent attendees of mobile health conferences, we’ve been excited by the momentum and creativity we’ve seen in mobile health solutions (Health Apps). But we've also been concerned.

We’re excited because of the number of Health Apps being developed for patients and consumers in different disease areas, for wellness, prevention and care. As big believers in the potential of Health Apps to improve outcomes and lower healthcare costs, we’re glad to see this market really take off.

At the same time, it seems there’s an App for everything – and anything. Yet there’s very little talk of interoperability or data exchange – heck, even about preserving my personal health data when I want to exchange my App for a new one, when I need to re-image my phone, or when I want to buy a new phone.

It seems like in the rush to capture the value of mHealth, we’re launching and creating a staggering amount of new health data silos – making health data less liquid and shareable when we need just the opposite.  This is a big concern, because in the longer term, data liquidity is the key to sparking innovation, improving outcomes, and reducing healthcare costs.

At the recent 2012 mHealth Summit, it was encouraging to see that this approach is starting to shift. It seems that more and more healthcare companies are recognizing that even though their patients or their customers need these Apps, perhaps jumping head-first into Apps development isn’t their best bet. Instead, maybe healthcare companies should let “the market” develop these Apps (they seem to know what they’re doing!) while they support the market – with funding, with infrastructure, and with content (liquid data).

Getting It Right

One of the great examples at mHealth Summit was presented by Aetna, a 160-year-old health insurance company. Rather than joining the Apps Race, Aetna has developed and published the CarePass platform. The platform provides a set of APIs that allows you to build your own Apps, plus it provides interoperability among your App and all the other Apps developed using CarePass  including the 20+ Apps that Aetna has developed and acquired itself, such as iTriage.  Update of January 24, 2013:  Check out this great video interview with Aetna Vice President Martha Wofford.

AT&T and Qualcomm Life also presented their platforms, with APIs that connect to a variety of different health and wellness devices. These APIs allow you to build Apps that connect to these devices, yet also thereby become independent of the devices. For example, you could switch from one fitness sensor to another, buy a different wireless weight scale, or use a new blood-pressure monitor while the App preserves your health data.

Joris Van Dam
Entirely in the same vein, earlier this year Athena Health, the Watertown, Mass-based provider of cloud-based Electronic Health Record (EHR) systems, launched their “More Disruption Please” program. Participants in the program receive access to the API of Athena Health’s EHR system, a platform to build Apps. They can even get access to start-up funding and launch support for their Apps in the network of Athena Health customers.

Allscripts launched a similar developer program for their EHR. And in 2009 Cerner launched its uDevelop platform, providing their customers with a platform and APIs to develop new Apps, and an App store to share these Apps with each other.

Of course, the largest, and perhaps most influential, organization to get it right is the ONC, which has been setting the tone for improving data liquidity in healthcare, and thereby stimulating healthcare innovation in Health Apps development, through an array of policies and programs. These include health information exchanges, meaningful use criteria for EHR adoption, Project Blue Button, and the Health platform – to name just a few.

Many of these programs also provide funding for you to develop Apps with their APIs. And, if not, there is always Health 2.0, which announced in May 2012 that it had already awarded more than $1 million to mobile health initiatives through its Developer Challenge series.

Where to Go from Here

There will always be a new App, a better App, an App that fits my health needs better as they evolve over time – and that’s OK. Yet all this tremendous activity and investment in Health Apps will only really and truly pay off, for individuals and their individual health needs as well as for a sustained impact on the healthcare system overall, if those Apps are built on, and contribute to, an underlying layer of liquid health data.

John R. Walker
As patients and consumers, we need to be able to switch from one device to the other, carry our health data from one provider to the other, switch insurance companies as we take new jobs, exchange one App for the other and so on – as our personal healthcare needs evolve over time. And those personal healthcare needs will really and truly only be served if our health data moves with us, as opposed to being caught in the latest fad and locked in the latest App.

For mHealth to pay off, we need APIs more than we need Apps.  It’s great to see that so many companies are getting it right. A year ago, we felt both excited and concerned at the prospect of mHealth. Today, we’re just pumped.


  1. We (Avado) share your enthusiasm for APIs. I'm particularly excited about the potential of what the ONC could do with the Automated Blue Button Initiative and the View/Download/Transmit requirements being discussed in Stage 3 Meaningful Use. Done right, I think it has the potential to have an impact similar to what HTTP did to unleash a torrent of innovation on the Web.

    On the vendor front, naturally we are believers in an EHR/insurance company neutral solution. Developers have to make bets on where to spend their finite resources. Undoubtedly, they'll choose an option that gives them the broadest footprint. With insurance and EHR markets fragmented, that will naturally limit the opportunity when APIs are tethered to those entities. To date, I'm not aware of interoperability of the APIs published by insurance & EHR companies beyond their own environment. Thus, the opportunity has to be huge within that particular silo for it to get traction. Nonetheless, they are doing the right thing by publishing APIs. It's a contrast to fully closed vendors who will eventually realize they are shooting themselves in the foot -- short-term gain coming at the expense of long-term loss.

  2. Terrific posting, and I couldn't agree with you more. I made a similar point in my recent blog posting: "just because we have apps for smartphones doesn’t mean we have real mobility in healthcare" (see My focus was on mobile workflows but the concept is the same -- apps can't and won't matter as much in the long term because real mobility isn't about smartphones, it's about mobile of workflow (and data) across numerous devices and environments.