Disabled Individuals’ Negative Perceptions of Mobile Health Applications: Design Guidance for HFE Practitioners

Abstract

Disabled individuals experience significant inequities in healthcare access, healthcare quality, social determinants of health, and health outcomes compared to non-disabled individuals. By including people with disabilities in the co-design of mobile health (MHealth) applications, we gain valuable insights to improve alignment between users’ needs and MHealth technologies. Through a secondary analysis of mixed-methods data, this paper investigates negative perceptions of disabled individuals regarding MHealth applications to inform MHealth application design guidance for human factors practitioners. Fifty participants with physical, cognitive, sensory, and/or mental health-related disabilities interacted with three MHealth applications during task analysis sessions, revealing concerns about data security, data privacy, and unnecessary patient work. Recommendations include clear articulation of security measures, clarifications that patient profiles are not publicly available, and simplified data entry processes. Implementing these recommendations may enhance the accessibility and usefulness of MHealth applications, promoting healthcare access for a broader range of individuals.

Introduction

As human factors/ergonomics (HF/E) practitioners increase their capacities to address complex challenges in healthcare, there is an opportunity to broaden our impact by addressing the unmet needs of disabled individuals as a health disparity population. Historically, the disability community has experienced significant inequities in health access, healthcare quality, social determinants of health, and health outcomes compared to non-disabled individuals (NIH Designates People with Disabilities as a Population with Health Disparities, 2023). The lack of consideration and engagement of disabled users in ergonomics research may exacerbate current health disparities experienced by people with disabilities by perpetuating exclusionary design practices, discrimination, stigmatization, and structural barriers (Valdez & Swenor, 2023). One opportunity to address these inequities exists across the development of mobile health (MHealth) applications. Despite the evolution of MHealth guidelines, a majority of websites and applications remain inaccessible to disabled people (Alshayban et al., 2020; Human Network Contributor, 2020; WebAIM: The WebAIM Million–The 2024 Report on the Accessibility of the Top 1,000,000 Home Pages, n.d.). By including people with disabilities in the co-design of MHealth applications from a cross-disability lens (i.e., universal design), we gain valuable insights that may improve access and usefulness of MHealth technologies across all patient groups (Valdez et al., 2022).

MHealth applications are used by a wide range of people, both disabled and non-disabled, to communicate with their care teams, manage medications, gain health education, and access patient portals (Palos-Sanchez et al., 2021). Across this diverse user population, individuals hold different preferences and needs for MHealth use. For instance, individuals with disabilities may choose to use an MHealth application with support from assistive tools and features such as screen readers, ALT text, stylus pens, and phone grips.

However, prior research in HF/E demonstrates that MHealth application design and implementation do not always fit the preferences and needs of end-users (Lazard et al., 2021). When this misalignment occurs, additional patient (and care partner) work may be required to achieve high-quality care and meaningful engagement with MHealth technology (Holden & Valdez, 2021; Valdez et al., 2015). Researchers have previously underscored the importance of applying an HF/E approach to maximize application accessibility and usefulness while minimizing the patient workload and risk of unintended consequences (e.g., psychological distress, dissatisfaction, and high cognitive load) (Proctor et al., 2022). Though prior work has investigated certain user experiences (e.g., siloed experiences of individuals with a specific medical condition) (García-Gómez et al., 2014; Kirkscey, 2021), it is critical for HF/E practitioners to more broadly examine MHealth application accessibility and usefulness through cross-disability studies designed to uncover a larger range of user preferences, needs, and unintended consequences (Valdez et al., 2022).

MHealth applications may be made more inclusive by designing from a more holistic approach that accounts for an intersection of disabilities and a diversity of user perspectives (Peng et al., 2016). Thus, to improve the accessibility and usefulness of MHealth application designs and mitigate risks of unintended consequences for all users, the objective of this secondary analysis is to highlight rich post-use reflections from individuals with varying combinations of physical, cognitive, sensory, and mental health-related disabilities. This paper contributes actionable design guidance for HF/E experts developing MHealth applications and promotes the co-creation of improved MHealth applications with and for a broad range of individuals with disabilities.

Methods

IRB Approval

This study was approved by the University of Virginia Institutional Review Board for the Social and Behavioral Sciences.

Study Design

Our team conducted a secondary analysis of data collected in the Central Virginia region between 2015 and 2017 as part of a four-phase mixed-methods study. We employed a secondary analysis as it is a respected approach to optimize the usefulness of data and to investigate research questions that were not included in the primary analysis (Ruggiano & Perry, 2019). While the primary study aimed to uncover challenges pertaining to interactions among disabled users, MHealth technology, and frequent tasks completed on the MHealth applications (e.g., scheduling transportation to a medical appointment, sending a secure message to a provider), this secondary analysis aims to uncover disabled individuals’ more broadly articulated challenges pertaining to MHealth applications. To achieve this objective, we conducted a thematic analysis of videos and transcripts from the primary study’s task analysis sessions.

Sampling and Eligibility Criteria

Participants were enrolled via maximum variance sampling across intersecting identities, including race, ethnicity, socioeconomic status, education level, technological literacy, and access to technology. Eligibility criteria for the primary study required individuals to self-identify as disabled by the guidelines of the Americans with Disabilities Act, self-identify as managing their personal health needs, and be 18 years or older. Participants who had one or more disabilities related to cognition or thinking were additionally given a Montreal Cognitive Assessment (MoCA). This assessment evaluated memory, attention, language, image recognition, abstraction, delayed recall, temporal orientation, and visuospatial orientation. Individuals scoring 18 or less on the assessment were deemed eligible for the study. This requirement was enforced due to IRB concerns for including those with cognitive disabilities considered to be more than mild. During eligibility screenings, all participants completed Functional Independence Measure (FIM) assessments and Quick Disabilities of the Arm, Shoulder, and Hand (QuickDASH) assessments. Participants were eligible if they scored a 5 or greater in each FIM category (e.g., communication, social interaction, and cognition).

Recruitment

Participants were recruited from rehabilitation hospitals, two Centers for Independent Living, and local non-profit organizations in the mid-Atlantic region. Additionally, snowball sampling was conducted. Eligible individuals completed verbal consent via telephone. Participant demographic data were captured following verbal consent.

Data Collection

During the task analysis sessions, 50 participants were asked to interact with 3 MHealth applications on an iOS smartphone or tablet to uncover any use difficulties. The selected applications included an untethered personal health record, a tethered personal health record, and a social support application. The order of the applications tested was counterbalanced across participants. Sessions lasted up to 3 hr in length (average 1 hr 50 min) and were held in participants’ homes, two Centers for Independent Living, and private rooms at local libraries. Participants were introduced to different accessibility tools and features (e.g., stylus pens, phone grips, iOS VoiceOver feature) at the start of each session to ensure devices were as accessible as possible prior to application use. Research assistants observed participants as they interacted with each application and recorded task difficulties or failures. After each application use, participants were asked to reflect upon their experiences and offer recommendations to improve future MHealth application designs. All task analysis sessions were video and audio recorded for analysis. Video recordings included both screen captures and videos of participants’ hands and/or stylus pens interacting with the screen.

Data Analysis

The audio files were deidentified and professionally transcribed. Our team analyzed transcripts using QSR NVivo 14 qualitative analysis software and followed Clarke & Braun’s procedure for thematic analysis (Clarke & Braun, 2017). Four research assistants trained in qualitative methods reviewed the data before iteratively developing a qualitative codebook with oversight from the senior author (RSV). The codebook was developed deductively and inductively. Deductively, the codebook drew upon Shneiderman’s golden rules for interface design (e.g., reduce short-term memory load, permit easy reversal of actions, offer informative feedback) (Shneiderman’s Eight Golden Rules of Interface Design – Capian, n.d.). Inductively, the codebook drew upon empirical challenges and participants’ post-use reflections from the task analysis sessions.

Code definitions within the codebook were refined for clarity, completeness, and specificity across 33 transcripts until all coders agreed that the codebook was complete. The codebook was presented to the senior author for discussion and final approval. The finalized codebook was then used to code all 50 transcripts. To ensure data trustworthiness, all coders met weekly to resolve questions regarding data interpretation and code selection. Any outstanding coder disagreements were raised to the senior author.

Following coding, the team iteratively grouped coded passages into overarching themes, and discrepancies were resolved via consensus building and group discussions. Among these were themes describing “Positive Post-Use Reflections” and “Negative Post-Use Reflections.” To achieve the objective of our secondary analysis, we held an additional round of group discussions to identify subthemes within the “Negative Post-Use Reflections.” This paper specifically reports on subthemes relevant to participants’ negative perceptions.

Results

Participant Characteristics

All participants (n = 50) self-identified as having one or more sensory, cognitive, physical, or mental health-related disability. In total, participants self-identified 89 different disabilities and medical conditions. Across our sample, 58% were female, 72% were white, 60% never married, and 38% attended some college but did not receive a higher educational degree. All participants disclosed ownership of a cell phone, 66% owned a smartphone, 48% owned a tablet, and 68% used an application on a smartphone or tablet daily.

Overview of Subthemes

Our analysis uncovered a range of disabled users’ negative post-use perceptions of MHealth applications. Emergent subthemes span topics of (1) security concerns, (2) data privacy concerns, and (3) unnecessary patient work. These subthemes are described in detail below.

Security Concerns

Several participants expressed apprehensions surrounding the applications’ capacities to protect against hackers. For example, one participant with a stroke condition stated:

“These days, with the internet stuff, people are always hacking people stuff. I wouldn’t want anybody to hack my account and maybe be able to get some information that they don’t need to have” (P21).

Another participant with Raynaud’s disease and small fiber neuropathy reflected that adding a proxy account is “like giving somebody your bank account information” (P40). Other participants shared concerns that if their patient account was not hacked, then the proxy account may be targeted. One participant with upper body mobility restrictions expressed:

“You can share it with a brother, or a sister-in-law or a mother, whatever. As long as if their computer files get corrupted, [it’s important] that information can’t be taken from them. A little security [is needed] on that” (P18).

Data Privacy Concerns

Multiple participants expressed fears that by creating an MHealth account, their health information would be involuntarily or unknowingly shared with strangers on the internet. They emphasized the importance of data privacy. One participant with hemiparesis and memory loss stated,

“I don’t like sharing too much information with people who don’t need to know. I don’t want it out there floating around on the web, here and there, where anybody can sit there and search it and say, ‘Oh, so that’s what happened.’ That sorta thing. That’s a tough thing” (P16).

This participant further stated they wouldn’t use the applications because they “don’t really like to blog out your [their] medical conditions” (P16).

Another participant with a seizure condition, cerebral palsy, and dyslexia expressed concerns that they would be judged by others on the application because of their seizure condition:

“I wouldn’t really want the people in my social network to know that I have somewhat of a seizure disorder. . .because people are so judgmental on people with seizure disorders. I wouldn’t want anybody to know that I have a seizure disorder” (P31).

Unnecessary Patient Work

Most participants expressed frustrations with the high levels of patient work required to create and use an MHealth patient account. Participants reflected that the applications were “over-stimulating” (P45), “not sufficiently user friendly” (P40), and “really annoying” (P42). One participant with small fiber neuropathy and Raynaud’s disease stated, “I don’t think it’s [MHealth application] worth the emotional turmoil” (P40).

Many participants expressed frustrations with the patient work required to set up a user account, particularly the work required to manually enter one’s personal information, proxy account contact information, and medical history. One participant with Type 1 diabetes stated, “The fact that you have to meticulously record everything is a little annoying” (P47). A participant with fibromyalgia and Ehlers-Danlos syndrome shared they believe their patient profile on the MHealth application is unnecessarily redundant of paper records they already maintain:

“Because you have to enter all the information yourself, and I already keep all of my health information in a file folder. . . Not having to have a mass import or anything, it just doesn’t make sense for me to enter all of the information” (P37).

Other frustrations were particularly prominent when participants attempted to recover from errors during the log-in process. Several participants, especially those with visual or memory and retention-related disabilities, noted their discontent when the password characters quickly and automatically turned into black dots. This password feature increased the patient work required to access their MHealth application accounts.

In addition to frustrations surrounding manual data entry, participants stated they would not add proxy users because they believed this access could exacerbate concerns about the primary user’s health. Exacerbating such concerns may increase patient work managing interpersonal patient-carer relationships. One participant with multiple sclerosis explained, “I don’t say too much to my mom, ‘cause I don’t want to get her worried, you know?” (P14). Another participant with cerebral palsy, glaucoma, and diabetes stated:

“I would only do it in a situation where their [proxy users’] assistance would be required. Because I don’t want to put any undue stress on them or give them anything other than what they need [to support care needs]” (P13).

Discussion

Our analysis sheds light on disabled individuals’ negative perceptions of MHealth applications. These perceptions may be critical for increasing adoption, use, and retention of MHealth applications among the disability community as well as maximizing positive health outcomes among disabled users. Our secondary analysis identified specific concerns surrounding application security, data privacy, and high levels of patient work.

Our findings indicate that MHealth applications must be further developed to clarify the security of patient information within the application. Future MHealth application designs should explicitly articulate security protections to MHealth users. Prior work in the telematics and informatics literature has primarily focused on the prevalence and health-related impacts surrounding security breaches of MHealth applications. These studies have conducted comparative analyses of MHealth risk features and have evaluated conceptual security frameworks to improve data protection for MHealth applications (Adhikari et al., 2014; Hussain et al., 2018). This paper uniquely presents how security risks are perceived by users with disabilities-despite efforts to improve MHealth application security. Understanding these perceptions offers a roadmap for HF/E experts to increase confidence in MHealth applications among not just individuals with disabilities but all users.

Prior studies in the MHealth literature have examined MHealth users’ concerns surrounding the unsolicited sharing of personal health information (Krebs & Duncan, 2015). Our findings uniquely complement this understanding by highlighting the concerns of disabled users regarding data privacy. While data privacy is generally important to all users, regulations against the unsolicited sharing of personal health information are particularly important to the disability community, as some disabled individuals opt not to disclose their disabilities to individuals in their personal and/or professional networks to avoid cases of discrimination in various social and professional settings. To address these concerns, we recommend that MHealth application designers integrate clarification that information added to one’s patient profile will not be made publicly available. It should be explicitly noted in plain language that doctors and proxy users will have exclusive and protected access to the patient’s profile. Such disclosures should be accessible to those using screen readers. Additionally, visualizations may be used to more clearly communicate the application’s security in comparison to other MHealth applications. ALT text must be used to disclose the content of such visualizations to users with visual disabilities using screen readers.

Further, our paper extends upon prior work in the mobile software engineering literature and population health literature examining user frustrations resulting from high data entry burden on MHealth users. In 2022, Philip and colleagues analyzed data collection practices across 3,251 MHealth applications. This study uncovered a high reliance on manual data entry across MHealth applications. The authors suggested future research investigate the use of sensors that automatically transfer information to fitness-tracking MHealth applications, thus reducing patient work. In a separate 2022 study, Philip and colleagues administered an online survey about MHealth challenges to 70 participants via online recruitment. Of these individuals, 30 responded that they “somewhat disagree” or “strongly disagree” when asked if they are “happy to manually enter data in MHealth apps” (Philip et al., 2022). Our findings expand upon those of Phillip et al. (2022) by evidencing that the data entry burden on MHealth users similarly impacts disabled users’ application retention. Our second subtheme, “Unnecessary Patient Work,” demonstrates how the high levels of patient work involved in current data entry processes make the creation of a new account difficult or potentially impossible for disabled users. Thus, we recommend reducing the patient work required by integrating AI features, including voice-to-text options for all textbox inputs and optical character recognition for automatic patient information transfer (e.g., by uploading photos of typed or written documents). Our research also specifically reports barriers logging into MHealth applications. AI technology could be utilized to aid in the log-in process by enabling users to use facial recognition rather than requiring users to remember and troubleshoot log-in credentials.

Limitations

Our study has several limitations that should be taken into account. First, our data were collected from 2015 to 2017. However, recent literature, discussed in the section above, evidences that our findings are still relevant and prevalent at the present. A second limitation is that, although this study engaged individuals across a wide range of disabilities and chronic conditions, our findings may not be representative of the MHealth barriers and facilitators experienced by individuals with different combinations of intersecting disabilities.

Conclusion

The participant perceptions and design recommendations described in this paper may act as descriptive and prescriptive guidance for HF/E practitioners to improve the accessibility and usefulness of MHealth applications not only for disabled users but for all users. Future research should integrate participatory design approaches to co-create more accessible and useful MHealth applications designed to promote healthcare access for a broader range of individuals. Such work is crucial for addressing the unmet needs of the disability community as a health disparity population.