4 Proposals To Accelerate The Growth of mHealth

By Nicholas Araujo, Design Science

At an estimated $2.8 trillion, or roughly one-fifth of the U.S. gross domestic product (GDP), the U.S. healthcare industry is enormous — and it’s experiencing an equally enormous transition. The same information technology revolution that has transformed nearly all other aspects of modern life has finally made its way to healthcare.

mHealth — the use of mobile devices (e.g., smartphones) to support healthcare — is a hotly anticipated driver for healthcare’s transformation.

In a recent white paper, PricewaterhouseCoopers (PwC) listed do-it-yourself healthcare and the proliferation of digital health products as two of its top 10 health industry issues for 2015. mHealth is central to both trends and plays a key part in what PwC calls the “New Health Economy.” According to the World Health Organization (WHO), mHealth has “the potential to transform the face of health service delivery across the globe.”

But so far, mHealth has generated more buzz than impact. Compared to the million-plus apps in each major app store, only about 100 mobile apps have been reviewed by the FDA — over the past 10 years! According to market research company research2guidance, revenues from all mHealth apps only amounted to about $4 billion in 2014 — less than the revenues for a single, large medical device manufacturer.

So how can app developers, traditional medical device and pharmaceutical companies, and regulators accelerate the growth of mHealth? Here are 4 proposals:

1.  Don’t claim to be a mobile medical app if you’re not.
Houston-based DermApps was once the maker of alleged acne-fighting medical apps AcneApp and AcnePwner. These apps claimed to “kill ACNE” using intermittent flashes of red and blue light from a smartphone’s screen. In 2011, the company settled a complaint filed by the FTC that alleged that DermApps marketed the apps on the basis of health claims that were not substantiated by “competent and reliable scientific evidence.” The settlement effectively banned the sale of the apps and required DermApps to forfeit all profits. Not surprisingly, DermApps is now nonexistent.

This case highlights the many consequences of claiming that your app serves a medical purpose when it, in fact, does not. These consequences may include fines, bans on the sale of such apps, and product liability lawsuits. Such apps may also undermine the promise of mHealth by confusing consumers and eroding their confidence in health apps.

Recent guidance documents have significantly clarified the responsibilities of companies developing “mobile medical apps.” In a nutshell, regulators in the U.S. and EU will treat mobile medical apps as they would any other medical device.  That is, if the app claims to diagnose, cure, mitigate, treat, or prevent a specific medical condition, or act as an accessory to a device that does so, then developers will need to follow existing medical device regulations. The FDA has also indicated that it will exercise “enforcement discretion” by not regulating certain mobile medical apps that are considered low-risk, such as apps that promote general wellness. The key is that the determination of “mobile medical app” is up to the manufacturer, based on labeling claims.

But regulators have not clarified rules for mHealth apps that try to avoid being classified as a regulated “mobile medical app.” Such apps may attempt to temper claims by adding a disclaimer to the end of the description of their app. For example, consider the description for Sleep Apnea: A Sleep Analyzer, the first result for “sleep apnea” in the Google Play store (note: app since removed from the Google Play store). After claiming to be a “screening tool” that patients can use to “determine the degree of OSA [obstructive sleep apnea] they have,” the developer adds, “Please note this application is not FDA approved and any further decision about your health should be done with the consent of your doctor.”

To us (and a few lawyers), such statements are deceptive. For mHealth to be successful, users should have no doubt whether or not they can trust the medical value of an app.

To reduce confusion, we recommend that nonregulated mHealth app developers:

• Restrict claims so that they do not imply diagnosis, cure, mitigation, treatment, or prevention of disease or other conditions.
• Provide disclaimers in multiple, prominent locations (e.g., the description of the app in the app store, the splash screen, results screens, etc.) that explicitly acknowledge that the app does not diagnose, cure, mitigate, treat, or prevent disease or other conditions.

Regulators can provide support by standardizing language for a disclaimer and issuing rules for how to include such a disclaimer in a health-related app (either as guidance or as regulation). This approach is similar to how the FDA currently regulates dietary supplements.

2.  Strive to be a mobile medical app if you can.
“Cr‘apps’ far outweigh the apps.”

Dr. David Levin, chief medical information officer at the Cleveland Clinic, delivered this bleak assessment when speaking at HealthBeat2013. He went on to suggest that many healthcare apps fail because they are just not very good.

In order to ensure reimbursement as U.S. healthcare shifts towards a pay-for-performance model, healthcare products and services, including mHealth, will increasingly need to focus on providing real value by positively affecting health outcomes. For mHealth, this means developing apps that actually support treatment or prevention of disease — precisely the kinds of apps that require regulatory review.

Many apps skirt regulatory requirements by providing data rather than diagnosis. If you want to know how useful data is at affecting health outcomes, just ask users of wearable activity trackers — a third of whom tend to abandon these devices after about 6 months, according to a 2013 survey by Endeavor Partners. While there are many factors associated with the early abandonment of wearable devices, the authors of the survey and others agree that distillation of data without actionable insights will not promote the sorts of long-term behavioral changes often required to improve health.

To fully realize the promise of mHealth, app developers should strive to utilize mobile technology to truly improve health outcomes, even if that means jumping though regulatory hurdles.

Why not embrace regulatory approval to certify that a mobile medical app can actually improve healthcare? Patients and healthcare professionals are likely to notice. As PwC notes, “regulatory approval may provide a competitive edge, setting one firm apart from others in a crowded field.”

3. Apply proven design strategies, including usability testing early and often.
Last October, Apple abruptly disabled the ability to enter and view blood glucose results in its popular Health app. The reason? A bug that prevented users from manually entering blood glucose values in the correct units. Evidently, the Health app only allowed for manual input in mg/dL (the units used in countries like the U.S.), which are an order-of-magnitude larger than the mmol/L units used in many other countries (e.g., the U.K., Australia). The difference is enough to make normal and high blood glucose readings appear critically low, if interpreted without context. Worse still, if acted upon, these misinterpreted readings could lead to inappropriate treatment of diabetes, with serious health consequences. Fortunately, we are not aware of any reported safety-related repercussions, so Apple appears to have gotten off the hook with only some bad publicity and potential user confusion.

The irony of this blood glucose blunder, caused by a major tech firm so highly regarded for its attention to detail and thoughtful design, underscores a reality of developing mHealth apps:

The release-early-update-often development approach that is popular with normal apps is incompatible with mHealth apps, where even minor bugs can result in real safety consequences. mHealth apps must be designed properly the first time. They don’t have to be perfect; but, as a rule, they have to be much closer to perfect than is typical of consumer apps.

In our experience, a bug like Apple’s would have been caught before release by applying proven design strategies during development. FDA has released a draft guidance that describes a few methods that are routinely used for medical device development, including:

• Contextual inquiry to gather “real-world” information about users, uses, and use environments (and potentially latent needs), providing a foundation for good user-centered design.
• Risk analysis to systematically anticipate, assess, and track potential safety-related hazards, especially those that are serious but unlikely.
• Expert or heuristic evaluations to benchmark products against good design principles and industry-specific pitfalls.
• Iterative, simulated-use usability testing to ensure that products will be safe, effective, and usable when released to actual users (or to uncover problems that you might not have otherwise anticipated).

These methods, familiar to medical device developers, are not being consistently applied in app development. However, developers of mobile medical apps will be required to incorporate at least some of these methods into their development processes. In truth, most of these methods should be applied by all mHealth app developers — and app developers, in general — regardless of regulatory requirements. Again and again, we have seen that doing so inevitably produces products that are safer, more effective, easier to use, and far more likely to be adopted by users.

4. Make the good ones easy to find.
The best-designed mHealth app is only useful if a user downloads it. With tens of thousands of apps already in the “Medical” category of the Google Play store and Apple App Store, finding quality mHealth apps is becoming increasingly difficult.

One type of attempt to solve this problem is creating specialized app databases. The U.K.’s National Health Service (NHS), for example, maintains a registry of over 200 apps that have been reviewed by NHS to ensure that they are “clinically safe and relevant for people living in England.”

But the reality is that most users still turn to their smartphone’s primary app store rather than a specialized store when searching for apps. As the primary distributors of apps, Apple and Google can accelerate the growth of mHealth by making mHealth apps easier to find — especially those that are well-designed, safe, and capable of improving health outcomes. Google’s and Apple’s approaches should acknowledge the fact that mHealth apps are different from other apps and require an organizational structure that more closely resembles a pharmacy than a department store.

Through a combination of filters, tags, categorized search results, and other means, app stores should help users zero-in on mHealth apps that will be useful and appropriate for them. Key parameters may include:

• Prescription vs. “over-the-counter”
• Disease-specific vs. general wellness
• Healthcare professional use vs. consumer use
• Approved by regulatory bodies vs. not regulated
• Location-restricted vs. unrestricted

Improving mHealth app discoverability would help all involved. Users benefit for obvious reasons. Developers, Google, and Apple all profit from the sale of more apps, while Google and Apple also stand to benefit from the perception that their respective mobile ecosystems are poised for the growth of a coming mHealth revolution.

There is no doubt that additional factors (e.g., data security, reimbursement, etc.) will still challenge mHealth’s future. But by creating health apps that are well-designed, easy-to-find, capable of truly improving health outcomes, and differentiated from apps that won’t, we will go a long way toward ensuring that the mHealth apps of today transform the healthcare of tomorrow.

What do you think will help to accelerate the growth of mHealth? Which challenges have you faced while developing an mHealth app? Let us know in the Comments section below! We may address comments in a follow-up article.

About The Author
Nicholas Araujo holds a B.S. in mechanical engineering and an M.S.E. in integrated product design from the University of Pennsylvania. As an account director at Design Science, he is involved in business development and client management, in addition to directing and conducting projects involving usability testing and the user-interface design of medical, industrial, and consumer products. Nick has extensive experience leading interdisciplinary research teams, identifying innovative design solutions, and developing product-service combinations. He also contributes to innovating Design Science’s approaches to contextual inquiry and prototype testing research. He has worked with a diverse range of product categories, including injection/drug delivery devices, infusion systems, LVAD pumps, manufacturing equipment, and smartphone keyboards.