Why mHealth guidelines are a solid starting point for tool developers

Recently a set of draft guidelines on responsible use of mobile health tools was published by a coalition that includes Microsoft, Vitality Institute and the University of California San Diego.

Adam C. Powell, Ph.D, president of Payer+Provider Syndicate, a management advisory and operational consulting firm focused on the managed care and healthcare delivery industries, said in an exclusive interview with FierceMobileHealthcare that the guidelines give developers a number of considerations to keep in mind during the development process. 

The draft wearables guidelines offer six recommendations, calling on innovators to: 

  1. Protect the privacy of a user's health data
  2. Clearly define who owns a user's health data
  3. Make it easy for users to accurately interpret their data
  4. Integrate validated scientific evidence into product design
  5. Incorporate evidence-based approaches to health behavior improvement
  6. Be accessible to marginalized populations

Providers and developers can go through each guideline and think about how they are addressing it, Powell said. However, he added that "there is a large potential gradient in how strongly each guideline is being addressed. It might be helpful for the guidelines to be revised to clearly define what it means to weakly versus strongly address them."

Powell also discussed the role patients should have in the process, and if a standard in mHealth can be a reality.

FierceMobileHealthcare: What is your view on this guideline effort?

Adam Powell: My initial take is that it is hard to make a counter-argument against all but two of them. The first two recommendations [Protect the privacy of a user's health data and clearly define who owns a user's health data] strike me as the most controversial. While it is often useful to utilize insights from behavioral economics when designing personal health technologies and apps, not every technology seeks to drive behavioral change. Some simply seek to capture data for the purpose of driving long-term inferences, while others exist to facilitate communication. This recommendation is useful in the case of apps that seek to drive behavioral change, but not in all cases.

Likewise, promoting equitable accessibility across diverse populations may result in technologies which fail to adequately serve any population. Some populations are best served by text messaging-based tools and others are best served by tools with app interfaces. Attempting to serve everyone may cause the development of tools that do not fully serve anyone.

The final four recommendations strike me as harder to dispute as thoughtful privacy controls, user-centric design, reliance on evidence-based practice and transparency regarding data stewardship all make for better technologies.

FMHC: What role, besides the public comment aspect, should patients have in this process?

Powell: Patients can assist by suggesting additional guidelines which are of interest. In my research on mHealth app evaluation, I have identified 22 dimensions on which apps can be evaluated. There are a number of other guidelines that could be made, such as that tools should have explicit advertising/monetization policies, and should disclose potential risks to patients. Patients can likewise provide assistance in prioritizing the guidelines, as it may be beneficial to limit the quantity of guidelines to a manageable number.

FMHC: Is one true standard in mHealth tool development a reality?

Powell: Given the rapid pace of change, it is wise for the guidelines to be technology agnostic. HIPAA, likewise, is relatively technology agnostic, and instead is focused on the objectives to be achieved.

FMHC: What would be the best scenario with a mHealth standard?

Powell: One thing that might be really useful would be a toolkit to support the implementation of the guidelines. For example a flowchart could assist developers in selecting means for driving behavioral change. Likewise, they could release a pack of transparent, easy to read data stewardship policies. While the developer would have to select the appropriate policy, a pack of prewritten policies would enable them to do so without having to think about the best verbiage to use in the policies.

Read more on