The Battle for mHealth – And the winner is…!
It’s been said that we are at a time in our digital lives when we should stop using the term “mobile” as a means of differentiating between the cubicle-bound confines of desktop- and laptop-based computing and the untethered alternative offered by various mobile devices. Mobile is everywhere and everything, meaning there is no mobile — it just is. With the explosive growth of the mobile health marketplace (estimated to grow from $1.95B in 2012 to $49B by the end of 2020), we might soon need to retire the term “mHealth” and just use “health” to describe a similar phenomenon. This growth trend is powered by the development of mHealth-focused aggregation platforms that allow for the convergence of device, sensor and data. I’m talking about a handful of specific platforms here that have received a lot of press in the last couple of months: Apple Healthkit, Google Fit and Samsung S.A.M.I.
I won’t cover these platforms in detail here; that’s already been done. My goal instead is to compare and contrast the platforms and predict where all of this is headed, especially as it relates to pharma. So let’s start with a quick overview of each flavor just to refresh the memory.
GET TO KNOW THE PLATFORMS
Apple debuted its entrant into the mHealth platform space — HealthKit — at its 2014 Worldwide Developers Conference on June 2 . We know that HealthKit will be bundled with the upcoming fall release of Apple’s iOS 8 and that it will collect a variety of health-related data points, including number of steps, calories burned, blood pressure, heart rate, length of sleep cycle, etc. — the typical elements collected by standalone activity/sleep trackers. The API also provides various built-in statistical functions to help with things like the average number of steps per day over a week, month, etc. HealthKit’s aptly named companion app, Health, will collect various health data that also can be aggregated within the HealthKit database. There are also rumors that the much-anticipated iWatch will provide some level of integration with HealthKit.
An important thing to note is that HealthKit does not provide access to all of its data by default; the user must authorize third-party apps to access specific data types within the HealthKit database. The security model also suggests that third-party apps without specific access to certain types of data — say, blood pressure readings — cannot even attempt to guess at whether or not certain types of data are collected. This should be a particularly comforting notion for scenarios in which the existence of certain tracked data could imply that an individual has some specific indication. Can you say, built-in PHI protection?
Apple has confirmed a partnership with the Mayo Clinic with the intent to “find the ideal way to present compact bits of information, suitable for display in a mobile app, with links to further information where appropriate.” Obviously, this relationship will also serve to validate the significance of the marketing impact of the new HealthKit brand for potential Mayo Clinic patients. A partnership with Epic Systems was also announced in early June, with an eye towards EHR integration. Similar partnerships are under investigation with Mount Sinai, Cleveland Clinic, Johns Hopkins and EHR provider Allscripts.
On June 25, at the Google I/O Conference, Google Fit made its debut. Reportedly, Google Fit will be part of the upcoming Android L OS release sometime later in 2014. Through an API design that focuses on sensor recognition and data capture, Google Fit provides to the ability to capture and view real-time data from various sensors and store this data in the cloud for future review and use. Much like Apple HealthKit, Google Fit will deal with many standard fitness data types out of the box, but also supports the creation of custom types. Unlike Apple HealthKit, Google Fit does not have a companion app to provide direct health data entry on Android mobile devices; it relies entirely on receiving information from third-party devices and apps.
This last point is critical in understanding Google Fit’s major difference from Healthkit. Googie Fit is all about passive data collection from third-party devices and apps, as opposed to a previous attempt at a similar service — the ill-fated Google Health — which required patients and their healthcare providers to manually enter data. Google has already developed relationships with Motorola, Fossil, LG, Intel, RunKeeper, Basis, Polar, Adidas, Nike and even Samsung, ensuring a very open platform. Whereas Apple is wanting to rely on its highly bankable brand to bring in data, Google is taking an open-source approach to data collection and third-party integration. To borrow from Nirvana’s Kurt Cobain, Google Fit is a “come as you are” model.
As far as the Google Fit security model is concerned, this seems to be somewhat on par with Apple’s. Google states that user consent is always required before a given app can read or write fitness data. In addition, this access is tied to a specific scope which can represent only certain types of health data. That said, the Touch ID of newer iPhones® adds an element of biometric security to Apple’s HealthKit model that Google does not (yet) provide.
Ironically, the “oldest” kid on the block has had the least amount of press. On May 28, during a press event in San Francisco, Samsung made a perhaps quieter, but no less important announcement regarding its Samsung Architecture for Multimodal Interactions (S.A.M.I.) platform. S.A.M.I. is similar to Google Fit in terms of its main function — to provide aggregation services for devices and sensors — but is not specifically limited to health data. However, it one-ups Google, perhaps, by adding cloud-based algorithms to support the analysis of uploaded data and the output of insights drawn from this data. In addition, Samsung announced the release of a somewhat-companion device: the Simband, a sensor-filled watch of sorts that will leverage the S.A.M.I. platform natively.
So it’s clear that S.A.M.I.’s differentiation is the Simband itself. This device will be considered an open-source hardware platform; Samsung has noted that it might actually provide VC money for startups to leverage the Simband. This may lead to cloud-based data storage of health data via S.A.M.I. and Simband, as well as developer API and web service access (and associated monetization). Samsung is also working with University of California, San Francisco to determine clinical aspects of S.A.M.I., especially as it relates to the use of the health insights provided by its cloud-based algorithms. In effect, Samsung is tying its mHealth platform offering to the Internet of Things, as well as the democratization of mHealth data access. Not much is yet known about S.A.M.I.’s security profile other than that Samsung claims the data is personal, private and secure.
SO WHICH IS WHICH?
It’s easy to get these three platforms confused as they all address mHealth monitoring devices, health apps, data integration and the quantified self movement overall. The key differences, though, are important to understand and summed up in the below chart.
So if I had to sum this up: Apple Healthkit is a typical closed offering that requires vast adoption and integration for success; Google Fit is an open model that seems to appeal to many existing wearables players already; and Samsung S.A.M.I. represents a novel approach to incorporate digital insights into health data tracking, but will require a lot of consideration for user opt-in for even blinded data. The reality is that we are looking at pre-beta technologies, which means anything can happen between now and the release parties.
WHAT DOES IT MEAN FOR PHARMA?
It’s easy to understand the excitement around these mHealth platforms. They may actually finally deliver on the promise of the “quantifiable self” concept through seamless data integration of a myriad of sensors, devices and apps. But what does this mean to pharma?
An mHealth platform can provide yet another set of data points to build the full patient view, especially in cases where this data can be collected (with the patient’s consent) without requiring the patient’s interaction or input. Imagine a pharma-sponsored patient support program in which a patient advocate representative can review up-to-date health information for a given, opted-in patient to help augment the quality of the conversation. And best of all, this data will have been provided via a passive mechanism. With 40,000+ health apps on the market, the best app we can install on an individual’s mobile device is the app she never has to touch, but that serves its purpose all the same.
Probably an even more intriguing use case is the ability to collect this health data (passively and de-identified where possible) and use it to analyze trends in specific patient profiles or demographics. This information could be leveraged by an HCP or an entire health system as support data for treatment planning.
“… key to the success or failure of the promise of mHealth: to support the aggregation of real health data collected in the midst of everyday activity.”
CONCLUSION AND RECOMMENDATION
All three mHealth platforms are clearly very different even in this early stage of discovery. The big question now is on which of these three should we in pharma focus our attention? All certainly have their unique strengths, and all three companies have their own strong user bases. Only time will tell the real winner.
In the meantime, at the risk of upsetting the Apple fan club, my bet is on Google Fit. Here’s why:
Google’s focus on an open and collaborative model in which existing device manufacturers can play, data can be aggregated in the cloud, and the cost of entry is low speaks to the shortest path to passive health data aggregation. I believe this is key to the success or failure of the promise of mHealth: to support the aggregation of real health data collected in the midst of everyday activity. It doesn’t hurt that Android powers more than 77 percent of mobile devices as of Q4 2013.
While Apple seems more interested in the EHR and premium clinic relationship (which may seem like a good idea in support of “meaningful use”), Google’s approach really does help to move toward a democratization of health data in a way that can benefit all players, patients, HCPs, payors and pharmas. There will certainly be some hills and maybe even mountains to climb for Google, perhaps related to data security and general Android platform compatibility. That being said, Google Fit may actually right the wrongs made by Google Health by seamlessly improving the quality and timeliness of patient health data without requiring a lot of care and feeding by the patient. That’s certainly a goal worth Fitting — I mean, hitting.