Open access peer-reviewed chapter

Designing Disease-Specific mHealth Apps for Clinical Value

By Karim Keshavjee, Dustin Johnston-Jewell, Brian Lee and Robert Kyba

Submitted: May 14th 2021Reviewed: August 17th 2021Published: November 30th 2021

DOI: 10.5772/intechopen.99945

Downloaded: 46


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.


  • 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, 9, 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’etreof 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 app-related 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].

1.3 App evaluation criteria are not design criteria

Many organizations and academics have developed criteria for evaluating apps, including the author of this paper [13, 17, 19, 20, 21]. However, no matter how comprehensive the criteria, they are both aspirational, incomplete and highly generic. For example, the very popular and highly cited Mobile Apps Rating Scale (MARS) assesses constructs such as engagement, functionality, esthetics, information and subjective quality. However, the MARS has nothing to say about disease-specific functions, integration with the healthcare system, value for healthcare providers, whether the app addresses important barriers to use or even whether the app uses behavioral theories to help with behavior change. The authors of the study even removed the concept of “evidence-based” because it was not assessed during the development of the tool. Interestingly, the authors claim that the MARS can be used as “a checklist for the design and development of new high quality health apps” [19]. The checklist is indeed useful as a general checklist of usability and user experience criteria to keep in mind when building the app but does not provide much guidance on how to design to achieve clinical benefits.

1.4 Human factors are necessary, but not sufficient for success

Most app design frameworks recommend using a human factors design approach [8, 9, 10, 11, 12]. These typically include 1) getting some form of input and motivations for use (user stories) from actual users and developing profiles of the different users who might use the system for a shared understanding of users (personas); some models call this the empathize step; 2) collating information from multiple sources to identify important user problems, also called the define phase in some models; 3) developing low and/or medium fidelity mock-ups and working with end users to get feedback on them; also called the ideate phase; 4) develop prototypes of the most promising ideas; called the prototype phase; 5) conducting expert usability, cognitive walkthroughs and end-user testing of the prototypes; called the test phase [22, 23].

Not surprisingly, most mhealth app developers do use human factors methods in their design process [24]. Despite using these methods, usage of mhealth apps continues to be low [4]. This is likely because human factors is only one important ingredient in a complex mix of important ingredients [17].

The International Standards Organization (ISO) has recommended a move away from user-centred design to a more human-centred design approach [25]. The name change is intended to help developers expand their focus from a single user and to start thinking more holistically about who the stakeholders of a product really are. The ISO recommends six components for human-centred design process, including: 1) documenting the needs of users and their relationships to tasks and the contexts in which they occur; 2) obtaining user involvement in all stages of design and software development; 3) obtaining on-going user feedback and conducting on-going evaluation; 4) using an iterative process for product refinement; 5) having multidisciplinary skills and diverse perspectives on the design team; and 6) ensuring the design encompasses the entire user experience (UX).

1.5 What is the role of personas in app development?

Personas have been an important part of app design for several years [26]. They enable product managers and designers to convey important information about the end-users to the development team. Personas provide product managers a structured approach to convey basic information about the different types of end-users that may use the product. What are the demographics of different users, including age, gender, geography? What are their goals, their spending habits, their needs, their pain points? What is their orientation to technology (avid, phobic or in between)? What is their attitude to the healthcare system (trusting, mistrusting, in between)? What is their relationship to their healthcare provider (want to be told what to do, want to make decisions themselves)? The persona is usually built after conducting research with users and then synthesizing a ‘typical profile’ of either a single ideal user or a few different types of users [27, 28].

Personas are particularly important in marketing, as they are typically built on well-researched market segments where the desired outcome (purchasing behavior) is well known [29]. Personas are essentially a mechanism to make an abstract segment more concrete for marketers, copy editors and advertising creatives. Personas have been adapted for app development, but they lack one important piece of information that is available to marketers, but not available to app developers: desired user behaviors.

Increasingly, personas are considered as caricatures and not enough for app development [30]. They are being augmented by a more powerful model popularized by Clayton Christenson: The Jobs to be Done [JTBD] framework [31, 32]. The JTBD framework posits that users do not purchase or use products for the product’s sake, but rather purchase them to ‘get a job done’. They ‘hire’ products to accomplish a task they need to complete and are looking for an outcome, rather than a feature or a function. The JTBD framework is an outcomes specification approach rather than a functional specification approach [33].

This framework provides better insight for developing functionality, because it immediately goes to the heart of why a user might want to use a product and generates a list of ‘jobs to be done’. In the healthcare sector, some of the job to be done includes being able to communicate information to the HCP which the HCP considers to be relevant and easy to interpret, which is not always clear from a end-user persona perspective [34, 35].

The JTBD framework also provides guidance on identifying drivers and barriers, both rational/cognitive and affective, for using a product to get the job done [33]. This assists developers and product managers to consider unspoken barriers which inhibit the use of the product, even when the product is designed to get the ‘job done’. It also assists in articulating unidentified drivers that could enhance uptake of the product but were not articulated by the end user during user-centered design sessions [33].

1.6 Apps need to follow and adapt to evidence-based guidelines for treatment and outcomes

One key reason why apps are not used is because the app makes recommendations which conflict with what HCPs communicate or believe [17]. This creates a tension for the patient: “Should I believe the app or should I believe my HCP?” Inevitably, unless the patient can find a HCP who agrees with the app, the patient realizes the app is not going to be useful, because their HCP is acting on a different set of information and therefore embarks on a different diagnostic and treatment plan than what the app recommends, rendering the app useless [36].

To make it easier for HCPs to recommend an app to patients, the HCP needs to know that the app is scientifically accurate and follows current guidelines and regulations [37]. Ideally, the app should be proven to deliver the benefits that patients desire and HCPs want to provide, however, this may be a much bigger ask than is currently possible. Our ability to evaluate apps as fast as they can change is woefully inadequate [38]. Current approaches used to evaluate drugs do not work for evaluating mhealth apps because, while drug formulations stay relatively static, mhealth apps are constantly changing.

1.7 Health behavior change is a critical component of mhealth apps

The purpose of providing patients with an mhealth app should be to improve their experiences of health care and their health outcomes [39]. If health behaviors are optimal, then adding a mhealth app may bring no additional benefit, especially if the disease has a lifestyle or behavioral component. Patients with chronic diseases which progress over time may also benefit by identifying trends earlier. mHealth apps do not have any intrinsic health properties. They, by themselves, do not lower blood pressure, treat pain or solve clinical problems. They add their value by helping patients track their relevant clinical problems, visualize their current behaviors, experiment with new behaviors and see the impact of their new behaviors on their health, including medication taking behaviors. Thus, the current short-fall in health-related behaviors (whether lifestyle or medication-related) that leads to poor health experience needs to be identified and the app needs to directly address the highest priority short-falls and those at highest risk for exhibiting poor health behaviors. It is likely that if the app is successful in addressing healthcare needs of the individual and their HCP, then the health of the user will improve, and they will no longer need the app. To maintain on-going and continuous use, app developers will need to continuously evaluate the impact of their app on patient health and add new functions to the mhealth app in future iterations.

If the app does not respond to evolving clinical needs, changes in therapy, changes in knowledge about behavior change techniques that work or changes in guidelines, the app is likely to become obsolete and lose users who increasingly experience barriers to the use of the app from their HCPs [36]. mHealth app development is a dynamic industry.

In addition to relevance and timeliness, mhealth apps need also to be built on a well-researched behavior theory. There are as many as 89 different behavior theory models that have been developed over the last several decades [15], too many to list here. However, having a theory of behavior change to underpin app features is important for several reasons: 1) you cannot change what you do not know; it’s important to know current behaviors so they can be measured and tracked through the change process. 2) Understanding the mediators of behavior change allows developers to tease out whether a lack of response was due to poor design of the intervention or whether the intervention worked properly but had no impact on the relevant behavior. 3) Theories of behavior build upon a large body of knowledge and are more likely to work than a poorly informed and poorly conceptualized intervention.

Carey et al. provide a website where app developers and change agents can find links between behavior change theories and mechanisms of action [40]. Although this is an excellent service, using behavior change theories that have already been proven for a particular disease may be a much better approach than trying to pick theories based on conjecture or putative mechanisms of action [41, 42].

1.7.1 Literature review and research trump end-user engagement

Every disease is different, and every patient experiences their disease in a unique way. For example, type II diabetes is caused by a myriad of social, environmental and physiological factors related to physical activity and nutrition. In contrast, our case study disease, myasthenia gravis is an autoimmune disease that can be triggered or worsened by social, environmental and physiological factors, but is not caused by them. These differences have profound influences on what the most effective mhealth interventions are likely to be [43, 44, 45, 46, 47, 48].

It is important to understand the range of behaviors that are detrimental for someone with a particular disease. Poor nutritional and exercise habits are important barriers for good health in diabetes [49], while poor medication adherence and exposure to exacerbating conditions are important considerations in myasthenia gravis, for example [50]. This type of information may be available from end-users during end-user engagement sessions, but typically requires systematic investigation by researchers and experts rather than by app developers who may miss important information because they lack expertise in a particular clinical topic [15]. Literature review and synthesis is a key requirement of mhealth app development.

1.7.2 Ability to change health behaviors requires an understanding of the range of ways that patients experience their disease

For a mhealth app to be effective, it needs to not only provide evidence-based advice, but also needs to capture and track relevant disease-specific patient behaviors. In diabetes, this is likely to be nutrition, exercise, stress, medication adherence, regular monitoring of biomarkers and sleep. In myasthenia gravis, it will include medication adherence, exposure to exacerbating factors, stress and potentially muscle strength.

Regardless of the relevant disease-specific behaviors, different patients with the same disease have different preferences and beliefs which also impact their choice of treatments, their health behaviors and approach to interacting with the healthcare system [51]. These differences in patient experience need to be considered during the app design and development process. These differences can be captured as part of the persona development process.

1.8 App-related behavior change is not health behavior change

How users relate to apps is very different from the way they relate to their disease. Health-related behaviors are highly dependent on the nature of the disease, while app related behaviors are dependent on characteristics of the app and the clinical setting; i.e., ease of use, user experience, getting the job done and a sense of accountability to the HCP and the healthcare team.

A significant majority of mhealth apps do not use a theoretical basis for driving behavior change [52]. Geuens et al. [53] describe a tool which links behavior change theories to mhealth app features to make it easer for developers to incorporate behavior change theories into their applications [54]. The features in the Trustworthiness and Liking section are all related to better app use. An excellent and comprehensive list of methods to improve app usability mentions many good techniques to improve app usability and the user experience, including 1) minimizing cognitive load, 2) minimizing response burden, 3) breaking down tasks into smaller sub-tasks, 4) making it easy to navigate and know where you are in the app, etc. [55].

1.9 Not all patients are alike. Patient segmentation is necessary for personalizing care

Not all patient segmentation approaches are relevant to mhealth app design. For example, the approach recommended by Brommels [56] which breaks down patients into 7 categories (healthy, incidental, chronic disease, multi-morbid, needing elective treatment, trauma, requiring hospitalization) is more suited to health delivery systems and how to segment patients for health delivery planning. The approach used by Deloitte who categorize health consumers into 4 categories (trailblazers, prospectors, bystanders and homesteaders) is more suited to understanding patients as consumers and purchasers of healthcare as opposed to as individuals who are purchasing a product to solve a problem [57].

What app developers need is a method to segment patients to enable more personalized solutions and communications for patients [51]. A Finnish organization has developed such a segmentation approach for Diabetes [58] and Sandy et al. developed one for hypertension [59]. Ideally, app developers should find a well-researched patient segmentation approach for the disease for which they are building an app.

1.10 Ecological momentary assessments and interventions are useful theoretical constructs

There’s a lot of hype about using sensors embedded in smartphones to detect changes in usage patterns which imply a worsening of disease [60] or for detection of disease [61, 62, 63]. Even very recent studies are exploratory and need additional validation before being translated into the field [64, 65]. Although the research base that makes production use of smartphone sensors is still in its infancy [66], there are some promising developments in creating architectures that are ready for conducting research. Digital (behavior) phenotyping, the ability to use wearables and sensor data to detect different behaviors, is developing rapidly and it is likely that the basic science will become more easily accessible over the next several years [67]. The developers of the geographically explicit ecological momentary assessment (GEMA) architecture claim that their approach is scalable from their study in post-partum mothers to other disease areas [68].

The use of validated patient reported measures questionnaires for conducting ecological momentary assessments is well developed and can be used with good design in terms of frequency and response burden [69, 70]. Patient reported experience and outcomes measures (PREMS and PROMS) have been developed in a variety of disease areas and are a promising way for mhealth app developers to get a jump start on ecological momentary assessments [71, 72, 73, 74]. Use of PREMS and PROMS may incur a license fee but are worth the cost since the tools are generally validated and are widely used in clinical trials. Care must be taken to select PREMS and PROMs properly, since some of them are more useful as aggregate measures (suitable for clinical trials) but are not appropriate for use on individual patients in a clinical setting [75].

Ecological momentary interventions are another promising concept, especially in the mental health field, where cognitive and affective interventions can be delivered directly through an app [76, 77, 78]. Although it is possible for apps to be used for other interventions, such as driving insulin pumps in response to readings from a continuous glucose monitoring system [79] this is still unusual and very much in its infancy.

Ecological momentary interventions are also very promising for delivering behavior change interventions at just the right time [80]. Ideally, delivery of interventions should be timed to when people are most receptive to receiving them. Timing of interventions can be predicted by use of ecological momentary assessments to know when a patient might be at their worst or at their best and deliver an intervention at just the right time [81, 82].

1.11 Effectiveness assessment requires a rapid research infrastructure and new research methodologies

Many app guidelines request app developers to test their app for clinical benefits [13, 83]. However, testing apps can be a fraught process, because typically, apps are designed and developed using an agile process, but clinical evaluation requires a more waterfall process. The methodologies for development and evaluation are somewhat incompatible and creates friction for good quality clinical trials. Philpott et al. make some recommendations about how to create a clinical trials infrastructure that is more flexible to the needs of mobile health app evaluation. They recommend a 2-phase approach. The first phase is a qualitative phase with usability and expert reviews to ensure that the app meets minimum criteria for more rigorous testing. The second phase then evaluates the app in an adaptive randomized controlled trial, which allows low quality apps to be identified and quickly removed from the study and allows high quality apps to be tested more rigorously [38]. This ensures that scarce resources are not wasted on apps that do not add value.


2. Use case: myasthenia gravis

Myasthenia gravis (MG) is a chronic autoimmune disease that targets the neuromuscular junction and causes unpredictable, fluctuating muscle weakness. Symptoms include drooping eyelids (the classical, textbook symptom), difficulty breathing, upper and lower limb weakness, difficulty swallowing and slurred speech [84]. MG affects about 20 people in every 100,000 [85]. It is twice more prevalent in women who get it in their 20s–30s than in men who get it in their 60s–80s. At one time, the mortality rate for MG was as high as 75%. However, with advances in treatment, the mortality rate is down to less than 5% [85]. Patients with MG are treated by neurologists.

We use myasthenia gravis as the use case for demonstrating a framework for designing the clinical aspects of a mobile health app.

2.1 Identifying and designing for disease-specific needs

Patient focus groups were formed before any app development activities were started to get patient input on whether an app would add value and if so, what the app should encompass. Patients agreed that an app could fill a gap that exists in care. They provided information about their experience of their disease and provided high level guidance about the features, functionality and benefits they would like to see in an app.

Clinician (neurologist) key informant interviews (N=8) were held to gather clinician experiences and gather clinician input into what they would like to see in an app for MG. Clinicians indicated that they struggle with capturing important information about the patient’s disease progression, medication use and compliance and the broad range of quality-of-life issues that patients with MG face. Clinicians are also interested in learning more about objective physical signs and not just the subjective patient experience. Key clinician-anticipated benefits from an app include getting a better, more detailed timeline of key events without the fog of recall bias and getting a better sense of medication compliance. There was no consensus on how to track patients between visits, but everyone knew about the MG Activities of Daily Living questionnaire (MG-ADL) [86]. Clinicians indicated that an app would also benefit primary care physicians, who are taking on more of the care of patients with MG.

Key neurology opinion leaders (N=7) were also interviewed to better understand the context in which the app would be introduced, what metrics the app would need to exhibit for them to support it and reasons they would need to recommend it to other clinicians.

2.1.1 Experiences of patients with MG

Patients with MG have unique disease-specific experiences. They experience anxiety (from the uncertainty of their disease) and social negativity (forced withdrawal from normal social activities). They experience stigma, deconditioning and exhaustion. Many experience stigmatizing side-effects of the medication, such as obesity, skin rashes and poor mood. Many experience disability and are unable to work.

There are 3 possible reasons that patients experience worsening of symptoms: 1) a worsening of the underlying disease process leading to worsening of symptoms, 2) poor compliance to medication and 3) patient is experiencing exacerbating factors, such as stress, lack of sleep, extreme heat or cold, contraindicated medications and viral illness.

Although one benefit of using an app could be that patients receive an escalation in treatment sooner, many patients paradoxically fear dose escalation because of the side effects they experience from using some medications. It is hoped that better tracking of exacerbating factors could help minimize dose escalations by identifying triggers for worsening of symptoms, other than a worsening of disease. All these assertions would, of course, need to be tested.

We combined disease-specific factors and patient motivations to create 4 personas: 1) The In-Charge is a user with intrinsic motivation to use the app because they like to collect data and analyze it for insights that they can act upon themselves. 2) The Worrier is anxious about the disease, the symptoms they experience, how the medication makes them feel, how they will cope if things get worse and the uncertainty of when the next exacerbation will occur. They also worry about how others perceive them and the loss of control they have over their lives because of MG. 3) The Adaptive Manager seeks to control events by gathering as much information as possible and partnering with their doctor to be proactive and manage their disease in the best way possible. And 4) the Passive Monitor who collects information because their doctor has asked them to do so. They trust that if their doctor thinks it is a good thing, then it must be so. There is of course a fifth persona: The Non-User. The Non-User does not believe that an app can be of enough benefit to make it worth their while to use.

2.1.2 App design considerations

The key underlying premise for developing the MG mhealth app was to help patients track their symptoms, treatments and exacerbating factors in between visits to their doctor so that they can self-manage their disease better and so that their HCP can review information in the app to get a more accurate and more comprehensive summary of what happened since their last visit. We selected the validated MG quality of life tool called the Myasthenia Gravis Activities of Daily Living profile (MG-ADL) [86] to capture data about patient symptoms. The app also allows tracking of some common physical activities such as walking the dog or climbing stairs which are important to the patient. This provides them with the ability to track how well they are doing for important activities which may not be considered to be ‘activities of daily living’.

Benefits and goals of tracking symptoms, medication use, health system use and exacerbating factors we identified included, 1) patients may identify reasons for disease worsening earlier with use of the app and, in some cases, be able to act on the information themselves; e.g., get more sleep or avoid situations which make their disease worse (benefit to In-Charge and Adaptive Manager). 2) Patients may make the visit with their HCP more efficient and productive, giving them more time to ask questions that are important to them (benefits Worrier, Adaptive Manager). 3) Patients may receive treatment escalation sooner, if the HCP is better able to tease out worsening of underlying disease from a string of bad days (benefits all patient types). These benefits are communicated to the patient throughout the app, to remind them of the benefits and reinforce use of the app.

Most patients (75% of women and 56% of men) do not like the side-effects of prednisone and resist dose escalations [87]. Making it easy for patients to capture more granular information about their medication use may be helpful for physicians to tailor doses and minimize the dose escalations or minimize the duration of a dose escalation. Rather than asking patients to enter all their medication data into the app and track detailed usage, it may be as valuable to capture the main 2 most problematic medications used in the treatment of MG and ask the patient periodically whether they used it as prescribed and if not, why not. That information would be easier for the patient to enter and may be just as helpful to the HCP as a much more detailed log of medication use.

Fear, uncertainty, change and stigma are a big part of the MG experience [88]. Using more reassuring and calming language, without promising anything that cannot be delivered by the app is a good way of addressing anxiety. A root cause of stigma is ignorance. Providing useful facts about MG to the patient about self-management and how to explain their disease to others could help decrease uncertainty and stigma and help the patient cope better with unavoidable change. These facts and messages can be entered into a fact and message bank that can be displayed to the patient randomly, helping to keep the app fresh and educating patients at the same time. In future iterations, the app may wish to include an optional cognitive behavioral therapy component and/or a mood or anxiety tracker.

Patients who desire more control over the app (In-Charge and Adaptive Manager) are given an opportunity to make changes to the settings for a variety of features. Expert review identified that some of the features that patients could control (for example, what would be released to their HCP in the report) would only increase their anxiety and have a paradoxical effect on patients perceived control over the app. It was recommended that the control over the HCP report be removed as it did not impact the patient. The reports provided to patients were also harmonized to look more like what was provided to the physician so that they would not be disoriented when having a conversation with their HCP.

Patients with MG frequently experience exhaustion, which is independent of muscle weakness, the hallmark of the disease. This means that patients with MG spend a lot of time in bed, unable to move, but still able to think and perform cognitive tasks. We recommended that the app provide a function to lock the aspect ratio so that patients can view the app in the more convenient portrait mode while lying down.

Almost half of patients with MG experience reduced social positivity and physical activity, increasing their chances of becoming depressed and becoming deconditioned. Future iterations of the app will consider adding a gratitude journal and/or a cognitive behavioral therapy component. Future iterations could also provide the patient with a physical activity program to prevent physical deconditioning.

2.2 Identifying and designing for non-disease-specific drivers and barriers

Patients experience many frictions to use of apps [17]. A small segment of approximately 20% of the app-using population has an intrinsic motivation to use an app [89]. They track their disease on a regular basis from an internal motivation with little encouragement – they will use an app if you offer them one. Another 34% of users say they would use an app if their doctor recommended it [6]. Making the app useful to HCP will make it more likely that HCP will endorse and encourage use. We addressed the following issues in our design.

2.2.1 App provides information that conflicts with information received from HCP

We designed the app to be consistent with current guidelines or current standards of practice in MG. Unfortunately, the current MG treatment guidelines are not well-respected and utilized. In this case, we asked our clinical advisors to provide us with the latest information about diagnosis, treatment and management of patients with MG. The clinical advisors provided guidance to include simple medication and health system outcome tracking which is important to doctors. It will be important to ensure that app maintenance includes regular check-ins with neurologists to update the app to current standards of practice.

2.2.2 Language and terminology of the app not compatible with the patient’s health literacy

We simplified the language used in the app. Although it is very difficult to translate all medical issues to a grade 6 level, where possible, we minimized use of difficult words and used the same difficult terminology in different contexts so that users would learn their meanings after repeated use. We repeated important concepts to reinforce learning. We used language that was compatible with the 4 different personas we identified (see below). We also reframed messages on goals and outcomes to appeal to the various types of users.

2.2.3 Patient must enter the data himself or herself

We minimized data entry tasks and burden (aka response burden) by asking patients to identify what was important to them. Although the questionnaire is relatively short at only 8-questions, not all questions are relevant to all patients. In a clinical trial setting, there is no option but to use the entire scale because missing data can easily invalidate a study. However, for an app that tracks the individual effectiveness of clinical treatment, focusing on what’s most important to the patient can go a long way to decreasing response burden and increasing compliance to data capture; some data is always better than no data. The purpose of the app is not to capture data, but to help the patient manage their disease and to track the trajectory of their disease. If the patient rarely or never experiences a particular symptom, there is no need to track that information. If patients experience their worst symptoms in a particular part of their body, then tracking that symptom may be an excellent sentinel event for tracking overall disease state. Using this approach, we were able to decrease the number of questions that the patient had to answer.

Another way to reduce response burden is to ask patients to fill out the questionnaire randomly spread out over a longer period. By ‘sampling’ the patient’s disease experience over a longer period, it is possible to get a good sense of the patient’s disease trajectory and then sample more or less frequently to optimize the amount of information compared to the response burden for the patient.

The magnitude and/or the magnitude of change in patient responses can also be used to make data entry more meaningful to the patient. If the patient’s symptoms are low and/or stable, the app can take longer to notify the patient to enter data. If the patient’s symptoms are worse or changing, then capturing data more frequently makes more sense and is likely to be more acceptable to the patient.

2.2.4 Patient cannot use information in a meaningful way

Patients generally have little control over their clinical condition. They cannot order diagnostic testing, prescribe medications or refer themselves to specialists. They are dependent to a great extent on their HCPs for those clinical actions. However, it does not mean that they have no control over their condition.

In myasthenia gravis, the patient has 1 major concern on a day-to-day basis: when my symptoms worsen on any one day, am I just having a ‘bad day’ or is it a worsening of my underlying condition? The uncertainty of symptom worsening can be a great source of anxiety [88]. The app could help patients see the trends of their disease and help them better and more quickly distinguish between a ‘bad day’ and a worsening of their disease, thereby giving them greater control over their disease experience.

The other way that patients can be empowered to use the app is to provide an easy-to-use report from the app for their HCP. This report, if useful and used by the HCP, would benefit the patient directly. Because of the uncertainty and daily variation in symptoms experienced by patients with MG, recalling their symptoms and experience of their disease during a visit with their HCP can be challenging. This was confirmed by our panel of clinical experts who indicated that history taking in MG is challenging and time-consuming. HCPs are likely to benefit from and value a simple, easy to read, visual report of the patient’s symptoms overlaid with information about compliance to medication and exacerbating factors experienced at the time of symptom worsening. Since, this is the most beneficial information for HCP, we need only capture medication compliance and exacerbating factor information at the time of symptom worsening, thereby minimizing response burden further.

Patients are influenced by non-verbal cues from their HCP. If the HCP does not use the information in the report, they are likely to stop using the app. However, if patients perceive that HCPs value the reports, they will continue using the app. HCPs have a strong influence on patient app usage and can reinforce app usage by requesting the report and by viewing the information and acting on in it, where appropriate.

2.2.5 Lack of incentives like cost saving or social approval

There are few external incentives for using an app in MG. MG is not a lifestyle disease, so getting empathy from other people is rather difficult. MG is also a stigmatizing disease (see below), so social sharing of progress may not be appropriate or desired by the patient. However, there is a useful behavior change theory called the Self-determination Theory (SDT) [90] which was determined to be appropriate for patients with MG and could provide a significant incentive to use the app. How SDT was incorporated into the app is described below in Section 2.3.

2.2.6 Daily use of the app is not required and therefore patient does not get into the habit of using it

Although patients with MG can experience symptoms at any time, the lived reality is that exacerbations and improvements play out over weeks and months. Collecting data everyday can become tedious and lead to response fatigue. How do we design an app that maintains a good balance between infrequent data collection and loss of skill over time?

Through Expert Usability reviews, we simplified the data collection so that patients only reported data about the symptoms that are most troublesome to them. We also simplified the task loops so that they could get feedback from their data entry in smaller cycles of data entry, instead of getting one big report after answering a long series of questions. Encouraging and educational messages are spread throughout the data entry tasks so that patients do not get fatigued with answering many questions. Messages that explain the rationale for capturing specific information can help the patient connect the data they are entering to the outcomes they are hoping to achieve.

Notifications can help remind the patient to track information. To improve response rates, the notification could be developed to enable data entry directly into the notification rather than having to open the app and enter the data there. This is particularly useful where a single response is required, such as ‘Did you take your medications as prescribed yesterday?’ It is better to ask a question like that about a completed time unit rather than asking it for an incomplete time unit, since there is a finite chance that the patient may not have completed a task that the app is asking about.

2.2.7 HCPs may not value or use the data collected by patients in apps whose provenance and pedigree is not known or established

It is important that HCPs understand how the app was designed, who was involved in the design and what evidence was used to guide its development. More importantly, this information will be more credible and trustworthy if they hear it from their peers and key opinion leaders they look to for knowledge about new products in their field. If HCPs are convinced about the benefits of the app for themselves and their patients, based on reports from opinion leaders who have already tested the app in their own practices, the more likely it is that they will be the ones to recommend it to patients in the first place, obviating this barrier.

2.2.8 There is no way for HCPs to consume the large amounts of data that are collected in apps

HCPs do not have time to download data from an app, clean it up, analyze it and visualize it during a patient encounter. The entire task needs to be done for them before the patient even arrives at the clinic. It should already be in the patient’s electronic medical record when the HCP is reviewing the chart. The app should generate a simple report that the patient can email to their HCP so it can be attached to the record by the time the patient arrives.

The report should summarize the data from the previous 3–6 months since the last visit and should provide the HCP with actionable information. Do the exacerbations point to a worsening of disease or just poor control on the part of the patient? Is the poor control because of poor compliance to medication or due to exacerbating factors? If the HCP can answer these two main questions, they can have a more fruitful discussion about the patient’s goals and how they can be achieved, rather than spending most of their time sorting out what happened since the last visit.

2.2.9 HCP is unable to integrate app data into their own EMR for analysis or follow-up or share the data in their EMR with their patient’s apps

The current state of interoperability in most jurisdictions has not matured to the point where this type of digital data exchange can occur easily or quickly. HL7’s Fast Healthcare Interoperability Resources (FHIR) standard is evolving rapidly and is likely to be readily available over the next 5–10 years. As of late 2021, it is relatively immature and not ready for production use with apps.

2.3 Identifying and designing for a behavior-theoretical model

Through a process of discussion, reflection and mapping the experience of patients with MG to various behavior change theories, we determined the Self-determination Theory (SDT) [90] to be appropriate for patients with MG. SDT posits that people have a need for personal growth and that there are 3 intrinsic motivators that drive that growth: 1) A need for mastery over life’s situations (Competence); 2) a need to feel in control over our lives (Autonomy); and 3) a need to feel connected to others (Relatedness).

SDT has a strong connection to the lived experiences of people with MG. Many patients with MG want to have more control over their lives and be able to do that through more knowledge and skills about their disease. They also want to gain greater connectedness to their HCP to get better guidance on how to manage their disease and faster time to treatment. The incentive for using the app should be rooted in a behavior theory that is compatible with improvement of the disease experience.

We incorporated the 3 elements of the SDT by providing more facts and information that the patient can use to manage their disease, by providing visualizations of the data they collect to help them see how well they are doing and what they can do to improve their disease experience and providing them with a concise and easy to understand report suitable for sharing with their HCP, thereby promoting control and relatedness at the same time. These factors can be refined over time, as patients start interacting with the app in the real-world.

2.4 Identifying and designing for app-related behaviors

App-related behaviors were considered at various stages of app use: 1) during on-boarding, 2) when capturing baseline data, 3) during routine use. The Elaboration Likelihood Model and the Information-Motivation Behavioral Skills model are excellent behavior change models for use in mhealth app design and development as the focus on app-related behaviors [54].

The Elaboration Likelihood Model (ELM) states that behavior change will usually arise after a change in one’s beliefs and attitudes and that a change in beliefs and attitudes can be triggered by a cognitive stimulus, i.e., a message or fact. The ELM proposes several mechanisms for delivering the cognitive stimulus, including personalization, verifiability, expertiseand surface credibility.

The Information-Motivation Behavioral Skills (IMB) model states that new behaviors are the result of information, motivation and skill in executing a behavior. The IMB proposes the following mechanisms for delivering relevant information, motivations and skills to patients: reductionof effort needed to do something, tunnelingto breakdown large goals into smaller, more manageable goals, remindersthat help the patient remember to do a task and macro tailoringwhich means adapting messages to the needs of a specific group or segment.

During on-boarding, we want to make it fun and easy for users to start using the app. The first few screens do not require any data entry (reduction). They inform the patient about the app, explain the benefits of using the app from the perspective of all the different personas (macro tailoring) and start educating the patient about how to use the app and what to expect from using the app. The app’s design is very professional and has a clean and visually appealing look and feel, giving the app surface credibility. The patient also learns that the app has been developed by experts in the field (expertise).

When capturing baseline data, the patient is offered some control over what they would like to track and share with their HCP (personalization). Although all patients are asked to enter the minimum data that will generate a report for the HCP, they have the option of only capturing relevant information about their symptoms. Once they have entered a small amount of data, they are offered a visualization of their information (tunneling). Baseline capture occurs on the first day of use. The aim is to keep the session relatively short and pleasant, even though the patient is likely to be excited about using the app for the first time and would be willing to spend a lot more time with the app. Allowing the patient to get too excited could lead to overinflated expectations and disappointment.

Once the patient has entered their baseline information, they enter the routine use phase. During this phase, they can explore the app, learn about their disease and learn about the provenance of the information made available to them (verifiability). They also receive notifications to enter data periodically (reminders) and can change the settings to personalize the schedule of notifications.


3. Conclusion

This chapter contributes new knowledge about how to design the clinical components of a mobile health app. It does not replace existing guidelines and frameworks for mobile app development in general and mhealth apps specifically. Rather, it complements existing approaches and adds new information that may be helpful for app developers when designing the disease-specific features and functions of an mHealth app. Specifically, it adds the following to our current knowledge about designing mhealth apps: 1) It makes a distinction between disease-specific behaviors and needs and non-disease-specific barriers and needs. This enables app designers to dig down deeper into specific health-related experiences and encourages them to identify information in the literature which might illuminate app development. It provides a list of common barriers to mhealth app use and potential solutions to those barriers. 2) It makes a distinction between disease-related behaviors and app related behaviors. These are two very different types of behaviors and should have different design approaches, including use of different behavior change theories to underpin them.

This chapter also brings together several existing concepts and design patterns into a more coherent mhealth app design approach. We identify that human factors methodology is necessary but not sufficient for app development and recommend the expansion of user-centred design to human-centred design that considers a wider group of stakeholders, especially the HCP and the opinion leaders who influence them. We complement the use of personas with the Jobs to be Done framework and explain the key limitation of using personas in the design of apps compared to their use in marketing. We elaborate on the use of patient segmentation using disease-specific criteria, rather than generic or health-system level segmentation as a way of meeting the needs of different patient types and different app user types.

The limitations of this framework include the fact that the outcomes of using the framework have not been tested in the real-world and that there are two issues that the framework does not address. These include no research-based or proven guidance on 1) how to make a mhealth app engaging or 2) how to make an app visually appealing. In addition, we did not include any guidance on behavioral economic theory and choice architecture, also known as ‘nudge theory’ [91].

Overall, we believe this chapter will help app developers and publishers to build better apps that consider the disease-specific needs of patients and use behavior theories more effectively by conceptualizing disease-specific behaviors and app-specific behaviors as qualitatively different and therefore making apps more useful to patients and their caregivers.



We would like to thank Patrick Glinski at Normative for his support in the development of the app.


Conflict of interest

Karim Keshavjee was a consultant on the project to develop the app. Dustin Johnston-Jewell and Brian Lee work at Normative.

© 2021 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of the Creative Commons Attribution 3.0 License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

How to cite and reference

Link to this chapter Copy to clipboard

Cite this chapter Copy to clipboard

Karim Keshavjee, Dustin Johnston-Jewell, Brian Lee and Robert Kyba (November 30th 2021). Designing Disease-Specific mHealth Apps for Clinical Value, Smart and Pervasive Healthcare, Urvashi Sharma, IntechOpen, DOI: 10.5772/intechopen.99945. Available from:

chapter statistics

46total chapter downloads

More statistics for editors and authors

Login to your personal dashboard for more detailed statistics on your publications.

Access personal reporting

Related Content

This Book

Next chapter

Emerging from Smoke and Mirrors

By Lo Fu Tan

Related Book

First chapter

Introductory Chapter: The Contribution of Cohort Studies to Health Sciences

By René Mauricio Barría

We are IntechOpen, the world's leading publisher of Open Access books. Built by scientists, for scientists. Our readership spans scientists, professors, researchers, librarians, and students, as well as business professionals. We share our knowledge and peer-reveiwed research papers with libraries, scientific and engineering societies, and also work with corporate R&D departments and government entities.

More About Us