**Abstract**

mHealth apps for patient use are promising but continue to face a plateau in usage. Current apps work for a limited segment of the patient population, i.e., those who enjoy tracking for intrinsic rewards. There are many opportunities to support patient care in between health care provider visits that are not currently being met for many diseases and patient types (personas). This is an area of great potential growth for mHealth apps and could contribute greatly to patient health and wellness. In this chapter, we propose a framework for how to think about the between-visit needs of patients that would motivate continued use of mhealth apps. We view the app design process from the following perspectives: 1) disease-specific needs, 2) non-disease specific needs, 3) behavioral theoretical aspects of app usage and 4) app-intrinsic usage motivators. Myasthenia gravis serves as the use case for illustrating these perspectives and how to use them in designing a disease-specific mHealth app.

**Keywords:** mHealth, user experience, design, behavior, motivation

#### **1. Introduction**

#### **1.1 mHealth app usage remains low, in spite of increased investment**

Venture investments in mobile health app development has grown 10-fold over the last 5 years, from approximately \$200 million in 2014 [1] to over \$2 billion in 2019 [2]. Investors are hoping to cash in on the rapidly growing mhealth app market, expected to grow at a compound annual growth rate of 21% over the next 5 years to an expected US\$57 billion [3]. However, usage of mhealth apps continues to be low, especially amongst patients with chronic disease who are most likely to benefit from their use [4]. While 38% of respondents with no health condition had downloaded 1–5 mhealth apps in a recent survey, only 6.6% with hypertension had done the same. Actual usage of mhealth apps was even more abysmal, with 21% of respondents with no condition using the app 2 or more times per day compared with only 2.7% of patients with hypertension, 13% with obesity, 12.3% with diabetes and 12% with depression using the app at the same level [4]. mHealth app users are more likely to be younger and healthier with only 12% of those 55 and over using a mhealth app compared to 25% of those under 55 [5]. Interestingly, 34% of mobile users would increase their use of tracking apps if encouraged to do so by their healthcare provider (HCP) [6].

Why is app usage so low despite so much investment in the field?

#### **1.2 There are no standards for design and development of mhealth apps**

There are no standard recommendations or approaches to developing mhealth apps [7]. Several researchers and app developers have proposed design approaches, including some very generic, non-evidence-based approaches [8–10] and some based on highly respected frameworks used in other industries, such as the information systems research (ISR) framework [11, 12]. The UK government provides a thoughtful checklist of items to consider when developing an app [13].

The ISR framework recommends three cycles of iteration when designing and building an app: Relevance, Rigor and Design. Relevance speaks to what users want and need to take care of their specific health issues. Rigor implies a review of the literature to identify important information that may not have arisen during the Relevance cycle. Finally, Design speaks to user-centered design and usability evaluation. The ISR framework provides very minimal guidance around what the three cycles mean in a healthcare context. It requires starting every project using first principles, i.e., assuming nothing is known and that there are no reusable elements.

The UK government's Guide [13] to good practice for digital and data-driven technologies is a thoughtful guide to app development and includes several excellent design considerations for app publishers, including ethical considerations, defining a clear value proposition, assessing usability and accessibility, ensuring technical, clinical and data safety, regulations that should be followed, ensuring interoperability, generating evidence of impact and defining the commercialization roadmap.

These recommendations and frameworks are very generic and do not address important clinical requirements, the *raison d'etre* of mhealth app development, unless they happen to be identified during the primary research process.

All the frameworks and recommendations lack a key recommendation to improve chronic disease care: use of a behavior change theory to help drive apprelated behavior change [14, 15]. They also tend to focus solely on the patient end-user and leave out a key enabler (or barrier) to app usage: the healthcare provider (HCP) [16]. The frameworks also do not specifically address the key barriers to app use [17], such as the need to 1) adapt the language and terminology used in the app to the needs of those with lower health literacy and numeracy levels. In many cases, patients with lower health literacy and numeracy do not end up participating in user engagement sessions. This can easily bias the app and leave out an important, vulnerable segment of patients who are known to use the healthcare system more often [18] and could benefit from use of the app. 2) prevent creating a large response burden on patients, i.e., asking patients to enter too much data. 3) Make the data collection and analysis relevant and actionable for the patient. 4) Make the app very easy to use so that lack of daily use does not cause loss of skill in using the app. 5) Create incentives for using the app on a regular basis; e.g., creating opportunities for social approval, cost savings, a sense of mastery or lowered anxiety. 6) Make it easy for HCPs to see that the app is scientifically valid and that it is benefitting their patients and that therefore they should encourage its use by the patient and recommend it to other patients. 7) Make it easy for HCPs to visualize the data and provide them with valuable information that saves them time during the patient encounter so that they have an incentive to recommend the app to their other patients. 8) Make it easy for the healthcare provider to incorporate the output of the app into their electronic medical record system [17].
