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 Data.gov 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.