Open access peer-reviewed chapter

Designing Disease-Specific mHealth Apps for Clinical Value

Written By

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

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

DOI: 10.5772/intechopen.99945

From the Edited Volume

Smart and Pervasive Healthcare

Edited by Urvashi Sharma

Chapter metrics overview

364 Chapter Downloads

View Full Metrics

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, 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’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 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.

Advertisement

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, expertise and 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: reduction of effort needed to do something, tunneling to breakdown large goals into smaller, more manageable goals, reminders that help the patient remember to do a task and macro tailoring which 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.

Advertisement

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.

Advertisement

Acknowledgments

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

Advertisement

Conflict of interest

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

References

  1. 1. Pai, A., 2021. Mobile Health Investors [online] MobiHealthNews. Available at: shorturl.at/sNW28 [Accessed 5 April 2021]
  2. 2. Mercom Capital Group, 2021. mHealth Companies Raised $2.2 Billion in Venture Funding in 2019 – Mercom Capital Group [online] Mercom Capital Group. Available at: shorturl.at/eDMN3 [Accessed 5 April 2021]
  3. 3. Fortune Insights, 2021. mHealth apps market size is projected to reach USD 57.57 billion [online] GlobeNewswire news room. Available at: Shorturl.at/lzAL0 [Accessed 5 April 2021]
  4. 4. Robbins R, Krebs P, Jagannathan R, Jean-Louis G, Duncan DT. Health app use among US Mobile phone users: Analysis of trends by chronic disease status. JMIR mhealth Uhealth 2017;5(12):e197. URL: https://mhealth.jmir.org/2017/12/e197 DOI:10.2196/mhealth.7832
  5. 5. McCarthy, J., 2019. One in five U.S. adults use health apps, wearable trackers [online] Gallup.com. Available at: <shorturl.at/ptxB8> [Accessed 13 April 2021]
  6. 6. Rupp, S., 2021. Mobiquity study: 70 percent of people track their health and fitness daily with Mobile apps – Electronic health reporter [online] Electronichealthreporter.com. Available at: <tinyurl.com/n748db4> [Accessed 10 May 2021]
  7. 7. Adu MD, Malabu UH, Callander EJ, Malau-Aduli AE, Malau-Aduli BS. Considerations for the Development of Mobile Phone Apps to Support Diabetes Self-Management: Systematic Review. JMIR Mhealth Uhealth. 2018 Jun 21;6(6):e10115. DOI:10.2196/10115. PMID: 29929949; PMCID: PMC6035345
  8. 8. Tuan, J., 2021. 6 Best Practices To Improve Your Mobile Health App | Healthcare IT Today [online] Healthcare IT Today | Fresh, Daily, Practical Healthcare IT Insights. Available at: <shorturl.at/inyP7> [Accessed 6 April 2021]
  9. 9. Wicklund, E., 2021. How to Design and Develop a Mobile Health Application [online] mHealthIntelligence. Available at: <shorturl.at/wJW37> [Accessed 13 April 2021]
  10. 10. Kays Harbor Technologies. 2016. Designing healthcare apps: 10 best practices to follow | Kays Harbor [online] Available at: <shorturl.at/kuyWX> [Accessed 13 April 2021]
  11. 11. Farao J, Malila B, Conrad N, Mutsvangwa T, Rangaka MX, Douglas TS. A user-centred design framework for mHealth. PLoS One. 2020 Aug 19;15(8):e0237910. DOI:10.1371/journal.pone.0237910
  12. 12. Carballo-Dieguez A, Carry M, Gelaude D, Mosley JP, Travers J. A user-centered model for designing consumer mobile health (mHealth) applications (apps). J Biomed Inform. 2016 Apr;60:243-251. DOI:10.1016/j.jbi.2016.02.002. Epub 2016 Feb 20
  13. 13. GOV.UK. 2021. A guide to good practice for digital and data-driven health technologies [online] Available at: <https://tinyurl.com/abmsrjjv> [Accessed 8 May 2021]
  14. 14. Swann C, Rosenbaum S, Lawrence A, Vella SA, McEwan D, Ekkekakis P. Updating goal-setting theory in physical activity promotion: A critical conceptual review. Health Psychol Rev. 2021 Mar;15(1):34-50. DOI:10.1080/17437199.2019.1706616. Epub 2020 Jan 27. PMID: 31900043
  15. 15. Davis R, Campbell R, Hildon Z, Hobbs L, Michie S. Theories of behaviour and behaviour change across the social and behavioural sciences: a scoping review. Health Psychol Rev. 2015;9(3):323-44. DOI:10.1080/17437199.2014.941722. Epub 2014 Aug 8. PMID: 25104107; PMCID: PMC4566873
  16. 16. Rees S, Williams A. Promoting and supporting self-management for adults living in the community with physical chronic illness: A systematic review of the effectiveness and meaningfulness of the patient-practitioner encounter. JBI Libr Syst Rev. 2009;7(13):492-582. DOI:10.11124/01938924-200907130-00001. PMID: 27819974
  17. 17. Chindalo P, Karim A, Brahmbhatt R, Saha N, Keshavjee K. Health apps by design: A reference architecture for mobile engagement. InHealth care delivery and clinical science: Concepts, methodologies, tools, and applications 2018 (pp. 553-563). IGI Global
  18. 18. Fiscella K, Williams DR. Health disparities based on socioeconomic inequities: Implications for urban health care. Acad Med. 2004 Dec;79(12):1139-1147. DOI:10.1097/00001888-200412000-00004. PMID: 15563647
  19. 19. Stoyanov SR, Hides L, Kavanagh DJ, Zelenko O, Tjondronegoro D, Mani M Mobile App Rating Scale: A new tool for assessing the quality of health Mobile apps. JMIR Mhealth Uhealth 2015;3(1):e27. DOI:10.2196/mhealth.3422
  20. 20. Hensher M, Cooper P, Dona SWA, Angeles MR, Nguyen D, Heynsbergh N, Chatterton ML, Peeters A. Scoping review: Development and assessment of evaluation frameworks of mobile health apps for recommendations to consumers. J Am Med Inform Assoc. 2021 Mar 31:ocab041. DOI:10.1093/jamia/ocab041. Epub ahead of print. PMID: 33787894
  21. 21. Lagan S, Sandler L, Torous J. Evaluating evaluation frameworks: a scoping review of frameworks for assessing health apps. BMJ Open. 2021 Mar 19;11(3):e047001. DOI:10.1136/bmjopen-2020-047001. PMID: 33741674; PMCID: PMC7986656
  22. 22. Harte R, Glynn L, Rodríguez-Molinero A, Baker PM, Scharf T, Quinlan LR, ÓLaighin G. A human-Centered design methodology to enhance the usability, human factors, and user experience of connected health systems: A three-phase methodology. JMIR Hum Factors 2017;4(1):e8 DOI:10.2196/humanfactors.5443
  23. 23. Doorley, S., Holcomb, S., Klebahn, P., Segovia, K. and Utley, J., 2021. Design thinking bootleg — Stanford d.school [online] Stanford d.school. Available at: <https://dschool.stanford.edu/resources/design-thinking-bootleg> [Accessed 11 May 2021]
  24. 24. Baysari MT, Westbrook JI. Mobile Applications for Patient-centered Care Coordination: A Review of Human Factors Methods Applied to their Design, Development, and Evaluation. Yearb Med Inform. 2015 Aug 13;10(1):47-54. DOI:10.15265/IY-2015-011. PMID: 26293851; PMCID: PMC4587034
  25. 25. International Organization for Standardization. 2017. ISO 9241--210:2010. https://www.iso.org/standard/52075.html (2017)
  26. 26. Olsen, M., 2004. Making Personas More Powerful: Details to Drive Strategic and Tactical Design – Boxes and Arrows [online] Boxes and Arrows. Available at: <https://tinyurl.com/2wwkzkvt> [Accessed 13 May 2021]
  27. 27. Lau, K., 2018. Personas and User Journeys in Health [online] Medium. Available at: <https://uxplanet.org/personas-and-user-journeys-in-health-b4f4596f428d> [Accessed 13 May 2021]
  28. 28. Neate T, Bourazeri A, Roper A, Stumpf S, Wilson S. Co-created personas: Engaging and empowering users with diverse needs within the design process. InProceedings of the 2019 CHI conference on human factors in computing systems 2019 May 2 (pp. 1-12)
  29. 29. France, H., 2020. How To Create Personas For Marketing In 2021 | Digital Agency Network [online] Digital Agency Network. Available at: <https://tinyurl.com/29xf5r9w> [Accessed 13 May 2021]
  30. 30. McKeen, J., 2019. The pitfalls of personas and advantages of jobs to Be done: UXmatters [online] Uxmatters.com. Available at: <https://tinyurl.com/4z6nhaff> [Accessed 10 May 2021]
  31. 31. Christensen, C., Hall, T., Dillon, K. and Duncan, D., 2016. Know Your Customers’ “Jobs to Be Done” [online] Harvard Business Review. Available at: <https://tinyurl.com/32ebycxm> [Accessed 10 May 2021]
  32. 32. Abraham, M., 2016. My product management toolkit (10): jobs-to-be-done [online] Medium. Available at: <https://tinyurl.com/2brbnv7r> [Accessed 10 May 2021]
  33. 33. Ulwick, T., 2021. Jobs-to-be-Done: A Framework for Customer Needs [online] Medium. Available at: <https://tinyurl.com/56bwwwwj> [Accessed 10 May 2021]
  34. 34. Sedlmayr B, Schöffler J, Prokosch HU, Sedlmayr M. User-centered design of a mobile medication management. Inform Health Soc Care. 2019;44(2):152-163. DOI:10.1080/17538157.2018.1437042. Epub 2018 Mar 5. PMID: 29504838
  35. 35. Amann J, Fiordelli M, Brach M, Bertschy S, Scheel-Sailer A, Rubinelli S. Co-designing a Self-Management App Prototype to Support People With Spinal Cord Injury in the Prevention of Pressure Injuries: Mixed Methods Study. JMIR Mhealth Uhealth. 2020 Jul 9;8(7):e18018. DOI:10.2196/18018. PMID: 32673241; PMCID: PMC7380902
  36. 36. Bierbrier, R., Lo, V., & Wu, R. C. (2014). Evaluation of the accuracy of smartphone medical calculation apps. Journal of Medical Internet Research, 16(2), e32. doi:10.2196/jmir.3062 PMID:24491911
  37. 37. Fleming GA, Petrie JR, Bergenstal RM, Holl RW, Peters AL, Heinemann L. Diabetes digital app technology: Benefits, challenges, and recommendations. A consensus report by the European Association for the Study of diabetes (EASD) and the American Diabetes Association (ADA) diabetes technology working group. Diabetologia. 2020 Feb;63(2):229-241. DOI:10.1007/s00125-019-05034-1. PMID: 31802144
  38. 38. Philpott D, Guergachi A, Keshavjee K. Design and validation of a platform to evaluate mHealth apps. Stud Health Technol Inform. 2017;235:3-7. PMID: 28423744
  39. 39. Obucina M, Harris N, Fitzgerald JA, Chai A, Radford K, Ross A, Carr L, Vecchio N. The application of triple aim framework in the context of primary healthcare: A systematic literature review. Health Policy. 2018 Aug;122(8):900-907. DOI:10.1016/j.healthpol.2018.06.006. Epub 2018 Jun 18. PMID: 29935730
  40. 40. Carey RN, Connell Bohlen L, Johnston M, Rothman A, de Bruin M, Kelly MP, et al. Behaviour change techniques and their mechanisms of action: a synthesis of links described in published intervention literature 2018. doi:10.1093/abm/kay078. Available at <https://theoryandtechniquetool.humanbehaviourchange.org/.> [Accessed 10 May 2021]
  41. 41. Kwan YH, Cheng TY, Yoon S, Ho LYC, Huang CW, Chew EH, Thumboo J, Østbye T, Low LL. A systematic review of nudge theories and strategies used to influence adult health behaviour and outcome in diabetes management. Diabetes Metab. 2020 Nov;46(6):450-460. DOI:10.1016/j.diabet.2020.04.002. Epub 2020 May 6. PMID: 32387700
  42. 42. Sittig S, McGowan A, Iyengar S. Extensive review of persuasive system design categories and principles: Behavioral obesity interventions. J Med Syst. 2020 Jun 5;44(7):128. DOI:10.1007/s10916-020-01591-w. PMID: 32500161
  43. 43. Wali S, Keshavjee K, Nguyen L, Mbuagbaw L, Demers C. Using an Electronic App to Promote Home-Based Self-Care in Older Patients With Heart Failure: Qualitative Study on Patient and Informal Caregiver Challenges. JMIR Cardio. 2020 Nov 9;4(1):e15885. DOI:10.2196/15885. Erratum in: JMIR Cardio. 2020 Nov 11;4(1):e25624. PMID: 33164901; PMCID: PMC7657601
  44. 44. Tassone C, Keshavjee K, Paglialonga A, Moreira N, Pinto J, Quintana Y. Evaluation of mobile apps for treatment of patients at risk of developing gestational diabetes. Health Informatics J. 2020 Sep;26(3):1983-1994. DOI:10.1177/1460458219896639. Epub 2020 Jan 8. PMID: 31912754
  45. 45. Lan A, Lee A, Munroe K, McRae C, Kaleis L, Keshavjee K, Guergachi A. Review of cognitive behavioural therapy mobile apps using a reference architecture embedded in the patient-provider relationship. Biomed Eng Online. 2018 Dec 17;17(1):183. DOI:10.1186/s12938-018-0611-4. PMID: 30558610; PMCID: PMC6296144
  46. 46. Hannah Maria Jennings, Joanna Morrison, Kohenour Akter, Abdul Kuddus, Naveed Ahmed, Sanjit Kumer Shaha, Tasmin Nahar, Hassan Haghparast-Bidgoli, AK Azad Khan, Kishwar Azad & Edward Fottrell (2019) Developing a theory-driven contextually relevant mHealth intervention, Global Health Action, 12:1, DOI:10.1080/16549716.2018.1550736
  47. 47. Schroé H, Van Dyck D, De Paepe A, Poppe L, Loh WW, Verloigne M, Loeys T, De Bourdeaudhuij I, Crombez G. Which behaviour change techniques are effective to promote physical activity and reduce sedentary behaviour in adults: A factorial randomized trial of an e-and m-health intervention. International Journal of Behavioral Nutrition and Physical Activity. 2020 Dec;17(1):1-6
  48. 48. Milne-Ives M, Lam C, De Cock C, Van Velthoven MH, Meinert E. Mobile Apps for Health Behavior Change in Physical Activity, Diet, Drug and Alcohol Use, and Mental Health: Systematic Review JMIR Mhealth Uhealth 2020;8(3):e17046 DOI:10.2196/17046
  49. 49. Jiang L, Liu S, Li H, Xie L, Jiang Y. The role of health beliefs in affecting patients' chronic diabetic complication screening: A path analysis based on the health belief model. J Clin Nurs. 2021 May 5. DOI:10.1111/jocn.15802. Epub ahead of print. PMID: 33951248
  50. 50. Abuzinadah AR, Alanazy MH, Butt NS, Barohn RJ, Dimachkie MM. Exacerbation Rate in Generalized Myasthenia Gravis and Its Predictors. Eur Neurol. 2021;84(1):43-48. DOI:10.1159/000512077. Epub 2020 Dec 15. PMID: 33321491; PMCID: PMC7969373
  51. 51. Paglialonga A, Patel AA, Pinto E, Mugambi D, Keshavjee K. The healthcare system perspective in mHealth. In m_Health current and future applications 2019 (pp. 127-142). Springer, Cham. DOI:10.1007/978-3-030-02182-5_9
  52. 52. Chib A, Lin SH. Theoretical advancements in mHealth: A systematic review of mobile apps. Journal of health communication. 2018 Nov 2;23(10-11):909-955
  53. 53. J. Geuens, L. Geurts, K. Gerling, R. D. Croon and V. V. Abeele, "A Dyad of Lenses for the Motivational Design of mHealth: Bridging the Gap between Health Theory and App Design," 2019 IEEE International Conference on Healthcare Informatics (ICHI), 2019, pp. 1-12, DOI:10.1109/ICHI.2019.8904839
  54. 54. https://www.lensesofmotivationaldesign.com/ accessed May 11, 2021
  55. 55. Babich, N., 2021. A Comprehensive Guide To Mobile App Design [online] Smashing Magazine. Available at: <https://tinyurl.com/bc4xv4be> [Accessed 11 May 2021]
  56. 56. Brommels M. Patient Segmentation: Adjust the Production Logic to the Medical Knowledge Applied and the Patient's Ability to Self-Manage-A Discussion Paper. Front Public Health. 2020 May 27;8:195. DOI:10.3389/fpubh.2020.00195. PMID: 32537449; PMCID: PMC7267007
  57. 57. Read, L., & Korenda, L. (2019, October 29). How do consumers navigate the health care frontier? Deloitte Insights. Available at: https://tinyurl.com/3bpcspfz [Accessed May 10, 2021]
  58. 58. Riihimies R, Kosunen E, Koskela T. Web-Based Patient Segmentation in Finnish Primary Care: Protocol for Clinical Validation of the Navigator Service in Patients With Diabetes. JMIR Res Protoc. 2020 Nov 2;9(11):e20570. DOI:10.2196/20570. PMID: 33136062; PMCID: PMC7669435
  59. 59. Sandy R, Connor U. Variation in medication adherence across patient behavioral segments: a multi-country study in hypertension. Patient Prefer Adherence. 2015 Oct 29;9:1539-48. DOI:10.2147/PPA.S91284. PMID: 26604707; PMCID: PMC4631417
  60. 60. Masud, Mohammed T., et al. "Unobtrusive monitoring of behavior and movement patterns to detect clinical depression severity level via smartphone." Journal of biomedical informatics 103 (2020): 103371
  61. 61. Arora, Siddharth, et al. "Detecting and monitoring the symptoms of Parkinson's disease using smartphones: A pilot study." Parkinsonism & related disorders 21.6 (2015): 650-653
  62. 62. Rajalakshmi, Ramachandran, et al. "Automated diabetic retinopathy detection in smartphone-based fundus photography using artificial intelligence." Eye 32.6 (2018): 1138-1144
  63. 63. Taylor, James A., et al. "Use of a smartphone app to assess neonatal jaundice." Pediatrics 140.3 (2017)
  64. 64. Cartledge S, Maddison R, Vogrin S, Falls R, Tumur O, Hopper I, Neil C. The utility of predicting hospitalizations among patients with heart failure using mHealth: Observational study. JMIR Mhealth Uhealth. 2020 Dec 22;8(12):e18496. DOI:10.2196/18496
  65. 65. Yim SJ, Lui LMW, Lee Y, Rosenblat JD, Ragguett RM, Park C, Subramaniapillai M, Cao B, Zhou A, Rong C, Lin K, Ho RC, Coles AS, Majeed A, Wong ER, Phan L, Nasri F, McIntyre RS. The utility of smartphone-based, ecological momentary assessment for depressive symptoms. J Affect Disord. 2020 Sep 1;274:602-609. DOI:10.1016/j.jad.2020.05.116. Epub 2020 May 25. PMID: 32663993
  66. 66. Shin KE, Newman MG, Jacobson NC. Emotion network density is a potential clinical marker for anxiety and depression: Comparison of ecological momentary assessment and daily diary. Br J Clin Psychol. 2021 May 7. DOI:10.1111/bjc.12295. Epub ahead of print. PMID: 33963538
  67. 67. Radhakrishnan K, Kim MT, Burgermaster M, Brown RA, Xie B, Bray MS, Fournier CA. The potential of digital phenotyping to advance the contributions of mobile health to self-management science. Nurs Outlook. 2020 Sep-Oct;68(5):548-559. DOI:10.1016/j.outlook.2020.03.007. Epub 2020 May 8. PMID: 32402392
  68. 68. Gharani P, Karimi HA, Syzdykbayev M, Burke LE, Rathbun SL, Davis EM, Gary-Webb TL, Mendez DD. Geographically-explicit ecological momentary assessment (GEMA) architecture and components: Lessons learned from PMOMS. Inform Health Soc Care. 2021 Feb 20:1-20. DOI:10.1080/17538157.2021.1877140. Epub ahead of print. PMID: 33612061
  69. 69. Yang YS, Ryu GW, Choi M. Methodological Strategies for Ecological Momentary Assessment to Evaluate Mood and Stress in Adult Patients Using Mobile Phones: Systematic Review. JMIR Mhealth Uhealth. 2019 Apr 1;7(4):e11215. DOI:10.2196/11215. PMID: 30932866; PMCID: PMC6462888
  70. 70. Juengst SB, Terhorst L, Nabasny A, Wallace T, Weaver JA, Osborne CL, Burns SP, Wright B, Wen PS, Kew CN, Morris J. Use of mHealth Technology for Patient-Reported Outcomes in Community-Dwelling Adults with Acquired Brain Injuries: A Scoping Review. Int J Environ Res Public Health. 2021 Feb 23;18(4):2173. DOI:10.3390/ijerph18042173. PMID: 33672183; PMCID: PMC7926536
  71. 71. Gallacher KI, Quinn T, Kidd L, Eton D, Dillon M, Elliot J, Johnston N, Erwin PJ, Mair F. Systematic review of patient-reported measures of treatment burden in stroke. BMJ Open. 2019 Sep 18;9(9):e029258. DOI:10.1136/bmjopen-2019-029258. PMID: 31533946; PMCID: PMC6756342
  72. 72. Cerimele JM, Goldberg SB, Miller CJ, Gabrielson SW, Fortney JC. Systematic Review of Symptom Assessment Measures for Use in Measurement-Based Care of Bipolar Disorders. Psychiatr Serv. 2019 May 1;70(5):396-408. DOI:10.1176/appi.ps.201800383. Epub 2019 Feb 5. PMID: 30717645; PMCID: PMC6543835
  73. 73. Alappattu M, Harrington SE, Hill A, Roscow A, Jeffrey A. Oncology Section EDGE Task Force on Cancer: A systematic review of patient-reported measures for sexual dysfunction. Rehabil Oncol. 2017 Jul;35(3):137-143. PMID: 29082117; PMCID: PMC5656275
  74. 74. Stewart VM, Mendis MD, Low Choy N. A systematic review of patient-reported measures associated with vestibular dysfunction. Laryngoscope. 2018 Apr;128(4):971-981. DOI:10.1002/lary.26641. Epub 2017 May 23. PMID: 28543184
  75. 75. White DK, Master H. Patient-Reported Measures of Physical Function in Knee Osteoarthritis. Rheum Dis Clin North Am. 2016 May;42(2):239-52. DOI:10.1016/j.rdc.2016.01.005. Epub 2016 Mar 17. PMID: 27133487; PMCID: PMC4853650
  76. 76. Dias N, Boring E, Johnson LA, Grossoehme DH, Murphy S, Friebert S. Developing a theoretically grounded, digital, ecological momentary intervention for parental bereavement care using the ORBIT model-phase 1. Death Stud. 2021 Apr 29:1-10. DOI:10.1080/07481187.2021.1914239. Epub ahead of print. PMID: 33913789
  77. 77. Hawker CO, Merkouris SS, Youssef GJ, Dowling NA. A Smartphone-Delivered Ecological Momentary Intervention for Problem Gambling (GamblingLess: Curb Your Urge): Single-Arm Acceptability and Feasibility Trial. J Med Internet Res. 2021 Mar 26;23(3):e25786. DOI:10.2196/25786. PMID: 33769294; PMCID: PMC8088874
  78. 78. Lucas-Thompson RG, Rayburn S, Seiter NS, Broderick PC, Smyth JM, Coatsworth JD, Henry KL. Learning to BREATHE "Plus": A Multi-Modal Adaptive Supplement to an Evidence-Based Mindfulness Intervention for Adolescents. Front Public Health. 2020 Nov 17;8:579556. DOI:10.3389/fpubh.2020.579556. PMID: 33282814; PMCID: PMC7705247
  79. 79. Carroll, L., 2021. Experimental phone app works with insulin pumps to control diabetes [online] Reuters. Available at: <https://tinyurl.com/9yk8bce8> [Accessed 11 May 2021]
  80. 80. Hawker CO, Merkouris SS, Youssef GJ, Dowling NA. A Smartphone-Delivered Ecological Momentary Intervention for Problem Gambling (GamblingLess: Curb Your Urge): Single-Arm Acceptability and Feasibility Trial. J Med Internet Res. 2021 Mar 26;23(3):e25786. DOI:10.2196/25786. PMID: 33769294; PMCID: PMC8088874
  81. 81. Blevins CE, Marsh EL, Stein MD, Schatten HT, Abrantes AM. Project CHOICE: Choosing healthy options in coping with emotions, an EMA/EMI plus in-person intervention for alcohol use. Subst Abus. 2020 Sep 1:1-8. DOI:10.1080/08897077.2020.1806182. Epub ahead of print. PMID: 32870129
  82. 82. Nugent NR, Pendse SR, Schatten HT, Armey MF. Innovations in technology and mechanisms of change in Behavioral interventions. Behav Modif. 2019 Apr 29:145445519845603. DOI:10.1177/0145445519845603. Epub ahead of print. PMID: 31030527
  83. 83. Nice.org.uk. 2021. Overview | Evidence standards framework for digital health technologies | Guidance | NICE [online] Available at: <https://www.nice.org.uk/corporate/ecd7> [Accessed 11 May 2021]
  84. 84. Ninds.nih.gov. 2021. Myasthenia Gravis Fact Sheet [online] Available at: <https://tinyurl.com/5ctyf2cc> [Accessed 11 May 2021]
  85. 85. Goldenberg, W. and Sinert, R., 2021. Emergent Management of Myasthenia Gravis: Overview, patient history, physical examination [online] Emedicine.medscape.com. Available at: <https://tinyurl.com/5jzd7kfc> [Accessed 11 May 2021]
  86. 86. Wolfe GI, Herbelin L, Nations SP, Foster B, Bryan WW, Barohn RJ. Myasthenia gravis activities of daily living profile. Neurology. 1999 Apr 22;52(7):1487-1489. DOI:10.1212/wnl.52.7.1487. PMID: 10227640
  87. 87. Lee I, Kaminski HJ, McPherson T, Feese M, Cutter G. Gender differences in prednisone adverse effects: Survey result from the MG registry. Neurology-Neuroimmunology Neuroinflammation. 2018 Nov 1;5(6)
  88. 88. Keer-Keer T. The lived experience of adults with myasthenia gravis: A phenomenological study (Doctoral dissertation, University of Otago)
  89. 89. McCarthy, J., 2019. One in five U.S. adults use health apps, wearable trackers [online] Gallup.com. Available at: <https://tinyurl.com/2spvu4we> [Accessed 11 May 2021]
  90. 90. Ryan, Richard M.,Deci, Edward L. (2000). Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being. American Psychologist, 55(1), 68-78
  91. 91. Beshears J, Kosowsky H. Nudging: Progress to date and future directions. Organ Behav Hum Decis Process. 2020 Nov;161(Suppl):3-19. DOI:10.1016/j.obhdp.2020.09.001. Epub 2020 Dec 10. PMID: 33716395; PMCID: PMC7946162

Written By

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

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