Next Article in Journal
Reliable IoT-Based Monitoring and Control of Hydroponic Systems
Previous Article in Journal
Improving Effectiveness of a Coaching System through Preference Learning
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

User-Centric Design Methodology for mHealth Apps: The PainApp Paradigm for Chronic Pain

by
Yiannis Koumpouros
Department of Public and Community Health, University of West Attica, 11521 Athens, Greece
Technologies 2022, 10(1), 25; https://doi.org/10.3390/technologies10010025
Submission received: 19 December 2021 / Revised: 23 January 2022 / Accepted: 28 January 2022 / Published: 31 January 2022
(This article belongs to the Section Information and Communication Technologies)

Abstract

:
The paper presents a user-centric methodology in order to design successful mobile health (mHealth) applications. In addition to the theoretical background, such an example is presented with an application targeting chronic pain. The pain domain was decided due to its significance in many aspects: its complexity, dispersion in the population, the financial burden it causes, etc. The paper presents a step-by-step plan in order to build mobile health applications. Participatory design and interdisciplinarity are only some of the critical issues towards the desired result. In the given example (development of the PainApp), a participatory design was followed with a team of seventeen stakeholders that drove the design and development phases. Three physicians, one behavioral scientist, three IT and UX experts, and ten patients collaborated together to develop the final solution. The several features implemented in the PainApp solution are presented in details. The application is threefold: it supports the management, reporting, and treatment effectiveness monitoring. The paper is giving details on the methodological approach while presenting insights on the actual plan and the steps followed for having a patient-centric solution. Key success factors and barriers to mobile health applications that support the need for such an approach are also presented.

1. Introduction

Chronic pain is defined as pain that lasts or recurs for more than 3 to 6 months [1]. The pain extends beyond the expected period of healing and can involve complex psychological and social factors. The International Association for the Study of Pain (IASP) define it as an unpleasant sensory and emotional experience associated with, or resembling that is associated with, actual or potential tissue damage [2]. According to several studies, around 30% of the global population suffer from chronic pain. Chronic pain affects many aspects of a person’s life and is highly correlated to increased medical costs and reduced quality of life. The main causes of pain are spinal pain, arthritis, cancer pain, headaches, fibromyalgia, injuries, and neurogenic pain, making the etiology of pain a very complex issue. Depression, absence from work, lack of social life or even suicidal thoughts are only some of the consequences of pain. Other symptoms include anxiety, fatigue, insomnia, and mood swings. Its significance is revealed by the fact that back and neck pain are among the top five causes of years lived with disability [3].
More than 500 million days have been missed in Europe, according to the European Pain Federation, due to chronic pain issues. This equals to more than EUR 300 billion or 1.5% to 3% of the GDP [4]. The World Health Organization, in 2019, incorporated chronic pain in the eleventh version of the International Classification of Diseases (ICD-11) [5]. In the United States of America, the prevalence of chronic pain exceeded the one of diabetes, cancer, and heart disease combined. Recent statistics show that chronic pain is more prevalent among women (e.g., 85% of chronic migraine sufferers are women).
Based on the above analysis, the multifaceted effect of chronic pain becomes apparent (e.g., on the economy, health system, quality of life, etc.). Additionally, pain accounts for 15% to 20% of physician visits [6,7]. It is therefore imperative to find a solution for the proper management of chronic pain. However, the inherent subjectivity of pain makes it very difficult. Objective data is valuable in supporting a clinical decision in order to arrive at a proposed treatment. In this direction, Health Data Research UK, the Medical Research Council, and charity Versus Arthritis have collaborated to form the Alleviate: APDP pain research data hub [8]. This hub aims to maximize the value of chronic pain data from a range of sources for researchers and innovators to develop new treatments for the condition.
Based on the exact condition and the patient profile, several medications may be recommended to relieve chronic pain, including: corticosteroid, anticonvulsants for nerve pain, nonsteroidal anti-inflammatory drugs, medical marijuana, opioids, products applied to the skin that contain pain relievers or ingredients that create soothing heat or cold, and many others. Other medical treatments include transcutaneous electrical nerve stimulation (TENS), nerve blocks (by injecting an anesthetic near the site of pain), or epidural steroid injections. On the other hand, it is well known that any medication may have potential side effects. Possible complications from medical treatments for chronic pain include opioid addiction, acute liver failure from acetaminophen treatment, respiratory issues, or even infection from spinal cord stimulators. As chronic pain makes patients’ lives unbearable, they look for solutions in every area in order to deal with everyday life. Many patients who do not find a solution to the problem of chronic pain follow alternative therapies such as: acupuncture, biofeedback, mindfulness training, massage, and other relaxation techniques. Both doctors and patients work together to find the best solution to the individual’s problem.
Information and communication technologies (ICTs) have been proved a valuable tool for dealing with many health issues. The Global Observatory for eHealth (GOe) defined mobile health or mHealth as “medical and public health practice supported by mobile devices, such as mobile phones, patient monitoring devices, personal digital assistants (PDAs), and other wireless devices” [9]. mHealth exploits the different functionalities of mobile phones (e.g., short messaging service (SMS), general packet radio service (GPRS), third and fourth generation mobile telecommunications (3G and 4G systems), global positioning system (GPS), and Bluetooth technology) to serve the needs of the different health clients (health professional, patients, citizens, health organizations). mHealth applications offer virtually every stakeholder a better outcome [10]. The use of mobile apps for pain management and tracking has been evident for many years, even though the early attempts were relatively primitive [11]. An increasing number of applications appear every day targeting the management, tracking and assessment of pain, providing a variety of features [12]. The absence of consumer and clinician involvement in the design and development phases is critical and affects negatively the produced mHealth applications (apps) and their quality [13]. To produce high-quality and useable applications, it would be advantageous to incorporate users earlier in the development process, as well as find mechanisms to blend end-user requirements with evidence-based material. The limited involvement of stakeholders during the design and development phases can greatly affect the quality of mHealth applications produced in terms of clinical content, interface design and usability [13]. Current guidelines for digital technology development and implementation force urge for participatory codesign approaches to build meaningful mHealth apps [14,15]. User-centric design can improve an application’s usability issues so that it is easy to use, understandable, efficient to complete, and acceptable [16]. Moreover, a growing number of studies have emphasized the importance of a participatory development process to increase the uptake of digital health technologies in the wake of health 2.0 and medicine 2.0 initiatives [17,18]. According to other studies [19,20,21], a holistic approach using human-centered design modeling is required to overcome the aforementioned obstacles. More studies support also that a user-centered, collaborative, interdisciplinary approach is required to improve the feasibility, acceptability, and usefulness of mHealth apps [15]. Researchers were able to get input from patients, caregivers, and clinicians who will be utilizing the solution to address their individual requirements and ideas, while also taking into consideration technological literacy and personal preferences, thanks to the user-centered approach [22,23,24]. The latest technological innovations (sensors, increase of processing power, wearables, cloud computing, and big data analytics) promise significant support in various health issues and the aforementioned topics as well [25,26,27]. Moreover, there is limited knowledge on how to develop effective mHealth applications that meet the actual needs of intended end users and can improve health outcomes [28,29,30]. This appears with a great variance in the quality of each app.
According to the Interaction Design Foundation, the user-centric design (UCD) process outlines the phases during a design and development lifecycle, while focusing on gaining a deep understanding of the users and their needs in each phase [31]. The international standard 13407, which was replaced by ISO 9241-210 in 2019 [32], was the basis for many UCD methodologies. According to the UCD approach, the design is based on a clear knowledge of the users, the tasks, the workflow, and the environment in which the application will be used, while considering the whole user experience. This is an iterative approach, involving users throughout the design and development process, where design and evaluation steps are built in from the first stage of a project, through implementation [33]. User-centered design entails extensive study into users’ behaviors, from their interactions with the product to their vision for how it should appear and operate [34]. The UCD process can be incorporated into waterfall, agile, and other approaches. Waterfall and agile are some of the most commonly used methodologies in mobile app development.
Agile Alliance defines agile software development as a set of approaches focused on the notion of iterative development, in which requirements and solutions emerge from cooperation among self-organizing cross-functional teams [35]. Agile development allows teams to provide value more quickly, with higher quality and predictability, as well as a greater ability to adjust to change. Every project should be handled differently, according to the Agile model. Two of the most extensively utilized agile techniques are Scrum and Kanban [36,37]. Scrum is a lightweight process framework for agile development which is used to help teams make a hypothesis about how they think something works: try it, reflect on the experience, and make the appropriate adjustments. Kanban, on the other hand, is a basic lean strategy that focuses on maintaining a continuous workflow and providing continuous added value to customers. Kanban concludes in a development pipeline that delivers high-value work in a predictable and efficient manner.
The waterfall methodology was the first software development life cycle (SDLC) model to be used. It uses a sequential or linear approach to software development. The waterfall approach splits the project into phases that are completed in sequence and have formal exit criteria. Typically, the outcome of one phase acts as the input for the next phase sequentially [38].
Some of the main advantages of an agile methodology are the fast development life cycle, the end-user focused approach, the flexibility in accepting changes, etc., which result in increased customer satisfaction. On the other hand, agile requires a high degree of customer involvement and assumes every project team member is completely dedicated.
The User Experience (UX) Design is another commonly used methodology. Don Norman coined the term “user experience” in the 1990s. According to Norman, “User experience encompasses all aspects of the end-user’s interaction with the company, its services, and its products” [39]. UX is used to create evidence-based, interaction designs between users and digital applications. Usability, usefulness, attractiveness, brand perception, and overall performance are all characteristics of a user’s perceived experience with a product or website that are covered by UX Design. In UX Design, research, data analysis, and test results drive design decisions rather than aesthetic preferences and views.
The current study presents a user-centered approach, while giving an example of a pain management solution that can support the different actors (doctors and patients). The paper is organized as follows: We first give an overview of the UCD approach followed, along with market data on which our decisions were based. Then we describe the domains supported by the PainApp application and the different features and functionalities implemented. Finally, we discuss a prototype developed as a proof of concept along with some important issues for optimizing the overall quality and retention rate of mHealth apps. Future steps and limitations are also presented at the end of the paper.

2. Materials and Methods

The research team followed a highly user-centered design, involving all different target groups. Patients and physicians from different specialties were involved in all steps of the design and development process to guarantee the desired outcome. Since the examined domain concerns applications that should probably be used for a very long time by the patient, user acceptance is a major key performance indicator [40,41,42,43,44].
To ensure a good acceptance rate, we formed a highly multidisciplinary design team [15,45,46,47,48,49]. One patient organization, three physicians (one neurologist, one pathologist, and one surgeon), one behavioral scientist, one expert in mHealth solutions, and two senior IT developers were the main working group. At the beginning, a kick-off meeting was held between all stakeholders in order to present the idea and the key features envisaged. In the next two days after a brainstorming process, ideas were shared about the content, workflow, features to be implemented, etc. A meeting was held each week to ensure proper progress and to avoid any delays or failures. The collaboration was achieved using appropriate teleworking/teleconferencing solutions for the convenience of all parties. Nine more patients were collaborating in all steps of the process. All patients were initially informed on the project and participated on a voluntary basis. The design of the first platform took 12 weeks. During the development period, an iterative process was followed (see Figure 1).
Before even starting to design something, one should consider the technological approach. Based on the market data available (February 2020–February 2021), Android is dominating the mobile market. Android, being an open-source platform owns almost 72% of the total market size. The specific operating system has consistently prevailed over rival awe (iOS) in recent years (see Figure 2).
According to the above data, our final solution should support, at least, Android devices. Other criteria to base our decision on were: (i) the profile of the end users (education level, financial status, etc.), (ii) the cost for developing the final product, (iii) the time needed for developing the solution, (iv) the resources needed, and (v) technical complexity during development. Taking into account the above criteria, we decided to develop the first prototype only in the Android platform.
A user-centered methodology (UCD) was followed as described by Johnston et al. [50]. The four phases that guided the design and development phases are presented below.

2.1. Phase 1: Background and Conceptualization

During this phase, we defined the evidence base and developed a theoretical understanding of the intervention’s underlying environment. For this to be done, we searched the literature for mHealth solutions targeting pain. The underlying diseases which were causing pain were also a subject of our study in order to conclude in a generic, disease-agnostic solution. Using focus group discussions, we were able to obtain valuable information from both patients and healthcare professionals. This led us to appropriate intervention targets (self-management and objective reporting). An in-depth understanding of end-users’ perspectives was considered crucial before moving on to the next step. This was followed by the development of the flow and content of the intervention. A human-centered approach, based on design thinking methodology, led the innovation process. During this phase, weekly meetings took place with IT and UX (user experience) experts, behavioral scientists, health professionals, and patients. Various mock-ups were designed and presented before deciding on the most suitable one.

2.2. Phase 2: Alpha Testing

This phase helped us to evaluate the quality of the proposed solution. By getting feedback from users, we tried to discover major usability problems and critical feature gaps. To this end, we evaluated the intervention flow, the content, and the design. At each phase, a significant number of end users (patients and physicians) participated. All of them should not have prior experience with the prototype. The objective of this phase was to check whether the solution works following the three requirements of customer validation (real people, real environment, real product). Semi-structured interviews were used to collect the desired information. Data were then analyzed by two experts independently. Based on these results, we finalized the design.

2.3. Phase 3: Software Development

In this phase, we followed a heuristic approach, by acknowledging that the development team do not know everything at the start of the project and will evolve through experience. So, scrum-based design helped us to naturally adapt to changing conditions and user requirements. Following this approach, it was possible to re-prioritize and shorten release cycles. Meetings between the different stakeholders were taking place every week on a constant basis in order to check the progress and decide on the next steps. The three-tier application approach was applied, giving the advantage of divisibility and information structure at independent levels, creating flexible and reusable parts of the application. The data storage tier uses relational databases through RDBMS MySql. The technology of php services that are hosted on the open-source Apache HTTP Server is applied in the logic tier. Specifically, php services are created to manage the flow of information on the part of the user and the retrieval of data from remote data sources. The data model is also created through php classes which represents the data structure as they are grouped in logical records, creating an object-oriented approach to the data stored in a relational database. Php services are accessible through classified access and appropriate practices are followed to prevent data interception. Communication with data sources follows the tcp protocol and is implemented through existing php technologies (PDO, mysqli). Secure Socket Layer [51] was implemented at the transport layer.

2.4. Phase 4: Field Testing

The final phase was dedicated to field testing. Ten patients and two physicians used the solution for fifteen days. Participants were selected to meet the following criteria: (i) physicians who frequently treat patients in pain (e.g., neurologists, orthopedics, etc.), (ii) patients suffering from chronic pain, (iii) participants should be acquainted with smartphones, (iv) participants must have a smartphone with Android operating system, and (v) should not be the same as the ones involved in the design phase. Basic issues explored were the task success, the problems faced by the users, and their satisfaction. At the beginning, all participants received appropriate training and observed a tutorial on how to use the application and the different functionalities provided. For this purpose, an instructional video was developed and watched by all users. A meeting was held in the presence of a member of the IT team who participated in the design of the application in order to explain and clarify any questions. Then, they were observed by two researchers while performing the different tasks offered. A think-aloud process was followed to record their opinion.

3. Results

This section presents the different features and functionalities provided by the final PainApp solution following the highly user-centered methodology followed during the design and development phases. During the brainstorming phase, patients expressed their views on the desired features and characteristics of the application: (i) to be able to record the point of pain very easily without having to type any text; (ii) the application should not require special knowledge for its use and should not be complicated; (iii) developers should take into account the limited knowledge of using mobile phones; (iv) to have functions that help them in their daily life; (v) there should be no labyrinthine menus; (vi) do not know the official names of the drugs or diseases; (vii) the language used should be simple and understandable, even by users with a low level of education; (viii) some treatments and medications may be repetitive; (ix) to be able to add simplistic descriptions that suit them (e.g., the purpose of the treatment received). Doctors, on the other hand, requested functionalities that served the following issues: (i) pain points recording; (ii) recording of how long the pain lasts; (iii) how long after the treatment did the pain decrease and to what extent; (iv) what medications the patient is taking and how often; (v) how and how intensely he/she feels the pain; (vi) if the pain has affected other activities in the patient’s daily life; (vii) if the pain has created other problems in the patient such as depression, stress, etc.; (viii) does the patient believe that some other conditions caused the pain he/she is feeling?; (ix) is the pain permanent or transient; (x) the patient feels that the particular treatment has helped him/her in relieving the pain and to what extent and after how long; (xi) access to complete history data. The following table (Table 1) shows the matching exercise to decide the final functions. Based on this table, the consensus of all parties was reached. The wording of the menus and the embedded text were also approved by all parties.
Based on the collected information, ten main domains were supported:
  • Pain recording (body location, pain intensity, pain features);
  • Consequences (domains affected);
  • Pain treatment (medications and related scheduling);
  • Pain assessment (medication vs. pain relief);
  • Physiological parameters (age, sex, height, weight, body mass index);
  • Underlying diseases;
  • Lifestyle (habits, physical exercise);
  • Alarms;
  • History;
  • Other functionalities (Login, Registration, Settings).
The following paragraphs present some indicative key features of the above domains. After the user registers, the PainApp application presents a basic summary of the user profile where one can proceed by selecting one of the following functions:
  • Pain recording
The patient is able to record the exact location on the body where he/she feels pain. This is being achieved by rotating the body and simple clicking on the right point on the human figure presented. In case of an error, a long click deletes the specific entry (Figure 3). Each recording is accompanied by individual characteristics per point (i.e., pain intensity, pain nature, type of pain, frequency of pain). Zooming in is also possible in order to enter a more precise point of pain.
After entering the point(s) of pain, one is given the opportunity to enter data about the specific pain, by clicking on the “Questionnaire/Ερωτηματολόγιο” green button. The data collected relate to the following sections:
(i)
What are the symptoms due to pain (e.g., nausea, dizziness, memory loss, etc.)?
(ii)
If the pain is accompanied by an event in the last 15 days (e.g., tension in the family or friendly environment, financial problems, weather changes, depression, starting an activity or sport, etc.).
(iii)
If the pain affected any daily activities (e.g., self-care, socializing, sleeping, housework, work, etc.).
The application allows one to enter the above data for each pain point separately or in bulk or even to skip such an entry. Once an entry is made, one can go to the “Pain Records” and see briefly the entire history, by date of entry.
2.
Pain treatment
Through an appropriate interface, the user is asked to register the medications he/she is receiving and/or evaluate the treatments. The PainApp application provides the following options (Figure 4):
(i)
When registering a treatment, he/she may choose to give an easy name to the treatment (e.g., shoulder, for a treatment involving a shoulder problem). One can start typing the name of the medicine or alternatively press the “Scan Barcode” button and scan the barcode on the medicine box with the camera of his/her mobile phone. The name of the drug is automatically registered and proceeds to declare the dosage, the route of administration (e.g., capsule, ampoule, injection, etc.), and the start date of the treatment. The user is also allowed to enter notes or make this treatment repeated (e.g., repeated monthly chemotherapy, daily treatments for orthopedic problems or cardiovascular disease, etc.).
(ii)
When evaluating the treatment/medication, the user can state whether the pain has changed (if it got worse or better and by how much), and for how long since he/she received the specific treatment. Again, the current date is automatically assigned as the evaluation date, but one can change it.
Figure 4. Treatment evaluation.
Figure 4. Treatment evaluation.
Technologies 10 00025 g004
The “Treatment Evaluations” section stores the entire history of evaluations, presented by date of registration and with all available details.
3.
Underlying diseases
Using the appropriate menu, one can state the diseases from which they are suffering and would like to be recorded in the application. Through a very user-friendly interface, the user can enter his/her illness and the application automatically brings to the fore the official ICD-10 names to select one. Again, the current date is automatically assigned as the start date of the disease, but can be changed as wished.
4.
Profile and Lifestyle activities
Another feature provided by the PainApp is the recording of data relevant to the profile of the user. Basic information such as height, weight, age, sex, along with the patient’s lifestyle activities (e.g., walking, dancing, sports), and their intensity are recorded to the platform (Figure 5).
Figure 6 presents the architectural diagram of the application.
The collected data is stored in a remote secure database in the University of West Attica. The doctor can see patient information only if the patient decides to share it. Only the user id is stored locally on the smartphone, so that the user can log in automatically and receive the appropriate notifications. The user id is stored in the internal storage directories of the application. The system prevents other apps from accessing these locations, and on Android 10 (API level 29) and higher, these locations are encrypted [52].

4. Discussion

The paper presents a walk-through methodology for user-centric design of mHealth applications. PainApp intends to serve patients facing chronic or acute pain and their doctors. An initial literature review revealed that there are already several available solutions in the above domain. However, the majority of the provided solutions do not report any user-centered or participatory design processes. This is highly correlated to the fact that the majority (62%) of the mHealth apps have a very limited number of MAUs (mobile active users), while only a very small percentage (7%) have more than 50,000 MAUs [53]. As far as the mHealth apps are concerned, the average time from last usage session to uninstall is approximately 9 days. Another important fact is that mobile health applications have the highest uninstall rates reaching 28% [54,55].
According to Baumel et al. [56], the number of app installations and daily active minutes of use are not an indication of success. The study reveals that only a small portion of users actually use the mHealth apps for a long period of time. The user engagement is extremely poor in most cases, ranging from 3.3% (30-day retention) to 3.9% (15-day retention) [56]. It is crucial, therefore, to develop methodologies in order to enhance long-term engagement of real-world usage of mHealth apps.
The main reasons that lead users to uninstall the applications can be summarized as follows: (i) the first impression is significant for the users since the uninstall rate is higher in the first day; (ii) a not clear interface and low aesthetics; (iii) implementation of too many features; (iv) unmet expectations; (v) many bugs; (vi) lack of value in the daily life of the user; (vii) many notifications that end up annoying the user; (viii) inadequate communication so they forget to use the app; (ix) content issues (e.g., not interesting, not updated regularly, etc.); (x) too many permissions asked without any explanation, and (xi) a hard to follow interface (not intuitive; that requires a lot of time to learn to use it).
Based on the above, the imperative need for a highly participatory design becomes clear in order to arrive at a successful implementation. The current paper proposes such a methodology giving details in the several steps of the design process along with an example of a mobile health application targeting a major health issue: chronic pain.
The next table (Table 2) shows how PainApp addressed some major barriers to the successful adoption of the app, as highlighted in the previous paragraphs.
The above data reveal the PainApp co-design approach which is a key factor towards mHealth success. A critical issue that arises from the literature is the lack of a gold standard for the subjective evaluation of mHealth applications. The existence of a valid and reliable scale could lead to more successful solutions. Most existing and commonly used usability scales were developed for websites or computer software and are not focused on apps. For example, the Perceived Usefulness and Ease of Use questionnaire [57], the Software Usability Measurement Inventory [58], and the System Usability Scale (SUS) [59]. It is clear that the “quality” evaluation of mHealth apps is difficult to obtain. From 2015 onwards, there are some efforts towards developing such scales. However, most recent scales for rating mHealth apps tend to focus on a specific health domain. For example, the APPLICATIONS scoring system focuses on pregnancy apps [60]; the NICE, on change of behavior apps [61]; the MedAd-AppQ on medical adherence apps [62]; the Nutrition App Quality Evaluation on nutrition apps [63], and the Quality Assessment tool for Evaluating Medical Apps on medication complication apps [64]. Despite the emergence of such efforts, most of the scales have not yet provided evidences of their reliability and validity. Other general scales for quality assessment purposes of mHealth apps are: the Health Care Apps Evaluation Tool [65], the Organisation for the Review of Care and Health Applications-24 Question Assessment [66], and the Mobile Application Rating Scale-MARS [67]. Only MARS has been developed, yet to be used by the general public. The limited scope of the aforementioned scales makes it hard to find the right tool to assess the quality of an mHealth app targeting the pain domain. In addition, many aspects are ignored on most scales (e.g., price, value, etc.). It is obvious that there is still a great need to establish a credible and effective method for subjective evaluation of mobile health applications [68].
One of the main concerns of PainApp was to satisfy the General Data Protection Regulation [69]. For this purpose, before the field tests, the required approval was obtained by the Bioethics and Deontology Committee of the University of West Attica. In addition, the appropriate consent form was incorporated into the application. Users are informed, before logging in, about the purpose and the research use of their anonymous data being collected, asking for their positive consent. The security of the data and the access to the data server is ensured by the services of the University of West Attica. All necessary precautionary measures have been taken in accordance with the regulation. More specifically, the users enter only very limited personal data in order to be able to use the application (i.e., user name and password). Indicatively, these data are encrypted and cannot be read by anyone, access to device location in the background requires permission, the system transmits randomized MAC addresses by default, and the communication between the smartphone and the server is encrypted and secure using appropriate Secure Socket Layer (SSL) mechanism [51]. All other information is anonymized and stored in the server side so that users are no longer identifiable. In the current version, the data is not transmitted to the doctor. The patient can choose whether or not to share the data with the doctor only when he/she visits the doctor for consultation. Doctors can have an overview of the patient’s condition from the PainApp history data screen. This screen shows all the data collected with the appropriate timestamps. Thus, the doctor can decide on the effectiveness of the treatments and give the appropriate instructions.
The paper presents a step-by-step methodology that can be followed to achieve the best possible implementation of a mobile health application. The process followed is a combination of agile methodologies and reveals important aspects that need to be considered when deciding on a development approach. Team characteristics (size of team, interdisciplinarity of members, etc.), project characteristics (size, complexity, budget, time frame, requirements, etc.), and external project factors (market size, market stability, etc.) are some of the basic considerations. The proposed approach is flexible enough and can be easily adapted to the requirements of users at any time throughout the development phase. Indicatively, characteristics like the iterative process and unpredicted environment comes from the scrum approach [36], while the limited budget and team empowerment comes from lean agile software development model [37]. On the other hand, team collaboration and immediate review from the users is based on the extreme programming model [70]. In the example given, several characteristics were critical during the design phase. For example, too much information was initially requested. The prioritization of information was crucial so as not to lose important data, and at the same time, to preserve all the valuable information for the doctors. A common mistake is either to keep all the originally recorded information or for the technicians to decide what should be kept or not. This greatly affects the graphical user interface, making it usually very complex, resulting in the final application losing its value. The domain of pain was decided because of its importance. In addition, its subjectivity, in relation to how a patient feels it, creates a big problem for a successful treatment plan. Finally, the application should be disease-agnostic in order to be able to serve the majority of patients feeling chronic pain.
As far as the pain domain is concerned, medications are very often insufficient to reduce pain. Accurate knowledge of which drugs are successful in which types of pain, in which diseases, and in which patient profile is extremely important. The PainApp application collects such data so that the doctor can easily choose the treatment that is appropriate for the patient in order to alleviate the pain. This is a really innovative feature that has not yet been implemented in other mHealth apps that target pain. It is important to emphasize the fact that, many times, doctors give medications to the patient not to fight the cause of the pain but to fight the pain itself. This is in line with the latest directions of WHO, where pain is considered a disease and not a symptom [5]. PainApp can be proved a valuable tool in the hands of a physician, since, according to a recent study, the time of pain recording is critical for making decisions [71]. The subjective experience of pain supports similar solutions [72]. Patient engagement is a critical issue in healthcare nowadays. Most of the patients are willing to disclose extra health information to their clinicians for better treatment. Unsolicited health data can originate from a variety of places (e.g., personal health records and patient-generated from mobile devices). Patients may opt to do so in an effort to assist the physician to better understand their specific medical situation [73]. However, many “side effects” may arise, like too much information received by the clinicians, duplicate information, pertinent information may be mixed in with volumes of non-essential information, or review of the unsolicited information can be very time consuming, etc. Clinicians’ views on the incorporation of patient-reported data vary [74,75]. Pain assessment, on the other hand, relies heavily on subjective data [72].
Regarding the limitations of the study, we can mention the small size of the population that tested the final application, the short testing time, as well as the absence of a valid and reliable scale for the evaluation of the PainApp. However, the main purpose of the study was to present the design methodology. PainApp has tried to combine all the different aspects of pain serving both doctors and patients in a way that is useful, but at the same time, simple and intuitive. As far as the future steps are concerned, artificial intelligence (AI) algorithms are being implemented in order to get insights from the collected data that could lead to decisions related to the effectiveness of drugs in pain and health economics. Moreover, PainApp is currently being developed in the iOS environment. We are also finalizing the implementation of a valid and reliable scale that will be able to assess mobile health applications targeting different objects and domains. Additionally, we are currently preparing an appropriate rigorous protocol for the subjective assessment of PainApp with more than 60 users. A new paper will be prepared based on the extensive evaluation of the application, which will present both the perceived subjective satisfaction from PainApp and the new scale. Future work will involve also deployment and clinical validation of the revised version of PainApp, incorporating the AI module under development.

5. Conclusions

The paper presents a highly user-centered approach for designing mHealth applications. A detailed methodology was followed in order to be able to capture the actual needs of the target stakeholders. The study also highlights the steps and methodology for how to effectively address, during development, the various barriers often encountered in most mHealth applications. The ultimate purpose was to develop a generic solution being disease-agnostic, able to fit the real needs of a variety of patients suffering from chronic or acute pain and their doctors. The developed mHealth application (PainApp) provides a practical example of how to adopt the theoretical guidelines presented. The small size of the participants who evaluated the application and the lack of a reliable tool for subjective assessment can be considered as limitations of the study. As for the next steps, artificial intelligence algorithms are currently being implemented and PainApp is being developed in iOS. The work is based on a combination of agile methodologies for developing mobile health applications. The purpose of this article was to describe the mHealth application development process in a way that is easily followed by other researchers and developers. Concluding, to optimize the overall quality and retention rate of an mHealth app, it is important to ensure: (i) active participatory design involving the different stakeholders, (ii) optimal user experience, (iii) communication of what the end user is missing out on by not using it, and (iv) appropriate subjective assessment.

Funding

This research received no external funding.

Data Availability Statement

Not applicable.

Acknowledgments

The author especially thanks the patients’ association Hellenic League Against Rheumatism (EL.E.AN.A.) for supporting the design phase of PainApp.

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Merskey, H.; Bogduk, N. Classification of Chronic Pain, 2nd ed.; IASP Press: Seattle, WA, USA, 1994; p. 1. [Google Scholar]
  2. Raja, S.N.; Carr, D.B.; Cohen, M.; Finnerup, N.B.; Flor, H.; Gibson, S.; Keefe, F.J.; Mogil, J.S.; Ringkamp, M.; Sluka, K.A.; et al. The revised International Association for the Study of Pain definition of pain: Concepts, challenges, and compromises. Pain 2020, 161, 1976–1982. [Google Scholar] [CrossRef] [PubMed]
  3. PAHO. Leading Causes of Mortality and Health Loss at the Regional, Subregional, and Country Levels in the Region of the Americas, 2000–2019; Pan American Health Organization: Washington, DC, USA, 2021. [Google Scholar]
  4. SIP Platform. Impact of Pain on Society Costs the EU Up to 441 Billion Euros Annually. Societal Impact of Pain (SIP). 2017. Available online: https://www.sip-platform.eu/press-area/article/impact-of-pain-on-society-costs-the-eu-up-to-441-billion-euros-annually (accessed on 18 December 2021).
  5. International Association for the Study of Pain (IASP) Working Group. ICD-11 for Mortality and Morbidity Statistics 2019. Available online: https://icd.who.int/browse11/l-m/en (accessed on 18 December 2021).
  6. Koleva, D. Pain in primary care: An Italian survey. Eur. J. Public Health 2005, 15, 475–479. [Google Scholar] [CrossRef] [PubMed]
  7. Mäntyselkä, P.; Kumpusalo, E.; Ahonen, R.; Kumpusalo, A.; Kauhanen, J.; Viinamäki, H.; Halonen, P.; Takala, J. Pain as a reason to visit the doctor: A study in Finnish primary health care. Pain 2001, 89, 175–180. [Google Scholar] [CrossRef]
  8. Health Data Research UK. Available online: https://www.hdruk.ac.uk/helping-with-health-data/health-data-research-hubs/alleviate/ (accessed on 18 December 2021).
  9. WHO. mHealth: New Horizons for Health through Mobile Technologies, Global Observatory for eHealth Series—Volume 3; World Health Organization: Cham, Switzerland, 2011; ISBN 9789241564250. [Google Scholar]
  10. Koumpouros, Y.; Georgoulas, A. A systematic review of mhealth funded R&D activities in EU. Trends, technologies and obstacles. Inform. Health Soc. Care 2020, 45, 168–187. [Google Scholar] [CrossRef] [PubMed]
  11. Rosser, B.; Eccleston, C. Smartphone applications for pain management. J. Telemed. Telecare 2011, 17, 308–312. [Google Scholar] [CrossRef]
  12. Lalloo, C.; Jibb, L.A.; Rivera, J.; Agarwal, A.; Stinson, J.N. There’s a Pain App for That: Review of patient-targeted smartphone applications for pain management. Clin. J. Pain 2015, 31, 557–563. [Google Scholar] [CrossRef]
  13. Reynoldson, C.; Stones, C.; Allsop, M.; Gardner, P.; Bennett, M.I.; Closs, S.J.; Jones, R.; Knapp, P. Assessing the quality and usability of smartphone apps for pain self-management. Pain Med. 2014, 15, 898–909. [Google Scholar] [CrossRef] [Green Version]
  14. Ossebaard, H.C.; Van Gemert-Pijnen, L. eHealth and quality in health care: Implementation time. Int. J. Qual. Health Care 2016, 28, 415–419. [Google Scholar] [CrossRef] [Green Version]
  15. Matthew-Maich, N.; Harris, L.; Ploeg, J.; Markle-Reid, M.; Valaitis, R.; Ibrahim, S.; Gafni, A.; Isaacs, S. Designing, Implementing, and Evaluating Mobile Health Technologies for Managing Chronic Conditions in Older Adults: A Scoping Review. JMIR mHealth uHealth 2016, 4, e29. [Google Scholar] [CrossRef]
  16. Jibb, L.A.; Cafazzo, J.A.; Nathan, P.C.; Seto, E.; Stevens, B.J.; Nguyen, C.; Stinson, J.N. Development of a mHealth real-time pain self-management app for adolescents with cancer: An iterative usability testing study. J. Pediatr. Oncol. Nurs. 2017, 34, 283–294. [Google Scholar] [CrossRef]
  17. Van De Belt, T.H.; Engelen, L.J.; Berben, S.A.; Schoonhoven, L. Definition of Health 2.0 and Medicine 2.0: A systematic review. J. Med. Internet Res. 2010, 12, e18. [Google Scholar] [CrossRef]
  18. Eysenbach, G. Medicine 2.0: Social networking, collaboration, participation, apomediation, and openness. J. Med. Internet Res. 2008, 10, e22. [Google Scholar] [CrossRef]
  19. Dansky, K.H.; Thompson, D.; Sanner, T. A framework for evaluating eHealth research. Eval. Program Plan. 2006, 29, 397–404. [Google Scholar] [CrossRef]
  20. Yusof, M.M.; Kuljis, J.; Papazafeiropoulou, A.; Stergioulas, L.K. An evaluation framework for Health Information Systems: Human, organization and technology-fit factors (HOT-fit). Int. J. Med. Inform. 2008, 77, 386–398. [Google Scholar] [CrossRef]
  21. Van Gemert-Pijnen, J.; Nijland, N.; van Limburg, M.; Ossebaard, H.; Kelders, S.; Eysenbach, G.; Seydel, E. A Holistic Framework to Improve the Uptake and Impact of eHealth Technologies. J. Med. Internet Res. 2011, 13, e111. [Google Scholar] [CrossRef]
  22. Cicolini, G.; Simonetti, V.; Comparcini, D.; Celiberti, I.; Di Nicola, M.; Capasso, L.; Flacco, M.; Bucci, M.; Mezzetti, A.; Manzoli, L. Efficacy of a nurse-led email reminder program for cardiovascular prevention risk reduction in hypertensive patients: A randomized controlled trial. Int. J. Nurs. Stud. 2014, 51, 833–843. [Google Scholar] [CrossRef]
  23. Slater, H.; Campbell, J.M.; Stinson, J.N.; Burley, M.M.; Briggs, A.M. End User and Implementer Experiences of mHealth Technologies for Noncommunicable Chronic Disease Management in Young Adults: Systematic Review. J. Med. Internet Res. 2017, 19, e406. [Google Scholar] [CrossRef] [Green Version]
  24. Trettin, B.; Danbjørg, D.; Andersen, F.; Feldman, S.; Agerskov, H. Development of an mHealth App for Patients with Psoriasis Undergoing Biological Treatment: Participatory Design Study. JMIR Dermatol. 2021, 4, e26673. [Google Scholar] [CrossRef]
  25. Koumpouros, Y.; Georgoulas, A. The Rise of mHealth Research in Europe: A Macroscopic Analysis of EC-Funded Projects of the Last Decade. In Mobile Health Applications for Quality Healthcare Delivery; IGI Global Publishing: Hershey, PA, USA, 2018. [Google Scholar]
  26. Koumpouros, Y. The role of informatics and digital applications in chronic pain treatment. Tomorrow’s health, today: Patient Centered Care and Digital Technology. In Proceedings of the Agora Platform Annual Conference, Podgorica, Montenegro, 25–26 September 2020. [Google Scholar]
  27. Koumpouros, Y.; Pappa, A. An mHealth tool for shared decision making for patients with rheumatism and arthritis. In Proceedings of the European Congress of Rheumatology (EULAR 2020), Frankfurt, Germany, 3–6 June 2020. [Google Scholar]
  28. Schnal, R.; Roja, M.; Bakke, S.; Brow, W.; Carballo-Diegue, A.; Carry, M.; Gelaude, D.; Mosley, J.P.; Travers, J. A user-centered model for designing consumer mobile health (mHealth) applications (apps). J. Biomed. Inform. 2016, 60, 243–251. [Google Scholar] [CrossRef]
  29. Curti, K.E.; Lahir, S.; Brown, K.E. Targeting parents for childhood weight management: Development of a theory-driven and user-centered healthy eating app. JMIR mHealth uHealth 2015, 3, e69. [Google Scholar] [CrossRef] [Green Version]
  30. Iribarren, S.; Akande, T.; Kamp, K.; Barry, D.; Kader, Y.; Suelzer, E. Effectiveness of Mobile Apps to Promote Health and Manage Disease: Systematic Review and Meta-analysis of Randomized Controlled Trials. JMIR mHealth uHealth 2021, 9, e21563. [Google Scholar] [CrossRef] [PubMed]
  31. Interaction Design Foundation. Available online: https://www.interaction-design.org/ (accessed on 18 December 2021).
  32. ISO. Available online: https://www.iso.org/standard/77520.html (accessed on 18 December 2021).
  33. Lowdermilk, T. User-Centered Design; O’Reilly Media: Sebastopol, CA, USA, 2013. [Google Scholar]
  34. Barnum, C. Usability Testing Essentials, 2nd ed.; Elsevier Inc.: Amsterdam, The Netherlands, 2020. [Google Scholar]
  35. Agile Alliance. Available online: https://www.agilealliance.org/agile101/ (accessed on 18 December 2021).
  36. Scrum.org. Available online: https://www.scrum.org/resources/what-is-scrum (accessed on 18 December 2021).
  37. Kanban Tool. Available online: https://kanbantool.com/kanban-software-development (accessed on 18 December 2021).
  38. Sherman, R.; Imhoff, C. Business Intelligence Guidebook; Morgan Kaufmann: Burlington, MA, USA, 2015. [Google Scholar]
  39. Nielsen Norman Group. Available online: https://www.nngroup.com/ (accessed on 18 December 2021).
  40. Berridge, E. Customer Obsessed: A Whole Company Approach to Delivering Exceptional Customer Experiences; Wiley: Hoboken, NJ, USA, 2016. [Google Scholar]
  41. Suman, R.; Sahibuddin, S. User Acceptance Testing in Mobile Health Applications: An overview and the Challenges. In Proceedings of the 2019 2nd International Conference on Information Science and Systems (ICISS 2019), Tokyo, Japan, 16–19 March 2019; Association for Computing Machinery: New York, NY, USA, 2019; pp. 145–149. [Google Scholar]
  42. Pindeh, N.; Mohd Suki, N.; Mohd Suki, N. User Acceptance on Mobile Apps as an Effective Medium to Learn Kadazandusun Language. Procedia Econ. Financ. 2016, 37, 372–378. [Google Scholar] [CrossRef]
  43. Nunes, A.; Limpo, T.; Castro, S.L. Acceptance of Mobile Health Applications: Examining Key Determinants and Moderators. Front. Psychol. 2019, 10, 2791. [Google Scholar] [CrossRef] [PubMed]
  44. Petersen, F.; Jacobs, M.; Pather, S. Barriers for User Acceptance of Mobile Health Applications for Diabetic Patients: Applying the UTAUT Model. In Responsible Design, Implementation and Use of Information and Communication Technology, Proceedings of the 19th IFIP WG 6.11 Conference on e-Business, e-Services, and e-Society—I3E 2020, Skukuza, South Africa, 6–8 April 2020; Lecture Notes in Computer Science; Hattingh, M., Matthee, M., Smuts, H., Pappas, I., Dwivedi, Y.K., Mäntymäki, M., Eds.; Springer: Cham, Switzerland, 2020; Volume 12067. [Google Scholar] [CrossRef] [Green Version]
  45. Pagliari, C. Design and evaluation in eHealth: Challenges and implications for an interdisciplinary field. J. Med. Internet Res. 2007, 9, e15. [Google Scholar] [CrossRef]
  46. Kazanjian, A.; Green, C.J. Beyond effectiveness: The evaluation of information systems using A Comprehensive Health Technology Assessment Framework. Comput. Biol. Med. 2002, 32, 165–177. [Google Scholar] [CrossRef]
  47. McCullagh, P.; Mountain, G.; Black, N.; Nugent, C.; Zheng, H.; Davies, R. Knowledge transfer for technology based interventions: Collaboration, development and evaluation. Technol. Disabil. 2012, 24, 233–243. [Google Scholar] [CrossRef]
  48. Boulos, M.N.K.; Wheeler, S.; Tavares, C.; Jones, R. How smartphones are changing the face of mobile and participatory healthcare: An overview, with example from eCAALYX. Biomed. Eng. Online 2011, 10, 24. [Google Scholar] [CrossRef] [Green Version]
  49. Stephan, L.S.; Dytz Almeida, E.; Guimaraes, R.B.; Ley, A.G.; Mathias, R.G.; Assis, M.V.; Leiria, T.L. Processes and Recommendations for Creating mHealth Apps for Low-Income Populations. JMIR mHealth uHealth 2017, 5, e41. [Google Scholar] [CrossRef]
  50. Johnston, S.K.; Nguye, H.Q.; Wolpin, S. Designing and testing a web-based interface for self-monitoring of exercise and symptoms for older adults with chronic obstructive pulmonary disease. Comput. Inform. Nurs. 2009, 27, 166–174. [Google Scholar] [CrossRef] [Green Version]
  51. SSL.com. Available online: https://www.ssl.com/ (accessed on 18 December 2021).
  52. Android Developers. Available online: https://developer.android.com/about/versions/10/privacy/changes (accessed on 18 December 2021).
  53. Research2Guidance. mHealth Economics—How mHealth App Publishers Are Monetizing Their Apps. Available online: https://research2guidance.com/product/mhealth-economics-how-mhealth-app-publishers-are-monetizing-their-apps (accessed on 18 December 2021).
  54. Benes, R. Most Apps Get Deleted within a Week of Last Use. Insider Intelligence. Available online: https://www.emarketer.com/content/most-apps-get-deleted-within-a-week (accessed on 18 December 2021).
  55. Statista, Mobile App Categories with Highest Uninstall Rate 2018. Available online: https://www.statista.com/statistics/892975/highest-uninstall-rate-app-categories (accessed on 18 December 2021).
  56. Baumel, A.; Muench, F.; Edan, S.; Kane, J.M. Objective User Engagement with Mental Health Apps: Systematic Search and Panel-Based Usage Analysis. J. Med. Internet Res. 2019, 21, e14567. [Google Scholar] [CrossRef] [Green Version]
  57. Price, M.; Sawyer, T.; Harris, M.; Skalka, C. Usability Evaluation of a Mobile Monitoring System to Assess Symptoms After a Traumatic Injury: A Mixed-Methods Study. JMIR Mental Health 2016, 3, e3. [Google Scholar] [CrossRef]
  58. O’Malley, G.; Dowdall, G.; Burls, A.; Perry, I.J.; Curran, N. Exploring the usability of a mobile app for adolescent obesity management. JMIR mHealth uHealth 2014, 2, e29. [Google Scholar] [CrossRef]
  59. Brooke, J. SUS: A “quick and dirty” usability scale. In Usability Evaluation in Industry; Jordan, P.W., Weerdmeester, B.A., McClelland, A.L., Eds.; Taylor and Francis: London, UK, 1996; pp. 189–194. [Google Scholar]
  60. Chyjek, K.; Farag, S.; Chen, K.T. Rating pregnancy wheel applications using the APPLICATIONS Scoring System. Obstet. Gynecol. 2015, 125, 1478–1483. [Google Scholar] [CrossRef]
  61. McMillan, B.; Hickey, E.; Patel, M.G.; Mitchell, C. Quality assessment of a sample of mobile app-based health behavior change interventions using a tool based on the National Institute of Health and Care Excellence behavior change guidance. Patient Educ. Couns. 2016, 99, 429–435. [Google Scholar] [CrossRef] [Green Version]
  62. Ali, E.E.; Teo, A.K.S.; Goh, S.X.L.; Chew, L.; Yap, K.Y. MedAd-AppQ: A quality assessment tool for medication adherence apps on iOS and android platforms. Res. Soc. Adm. Pharm. RSAP 2018, 14, 1125–1133. [Google Scholar] [CrossRef]
  63. DiFilippo, K.N.; Huang, W.; Chapman-Novakofski, K.M.; Eckhoff, R.; Nezami, B. A new tool for nutrition App Quality Evaluation (AQEL): Development, Validation, and Reliability Testing. JMIR mHealth uHealth 2017, 5, e163. [Google Scholar] [CrossRef] [Green Version]
  64. Loy, J.S.; Ali, E.E.; Yap, K.Y. Quality assessment of medical apps that target medication-related problems. J. Manag. Care Spec. Pharm. 2016, 22, 1124–1140. [Google Scholar] [CrossRef]
  65. Jin, M.; Kim, J. Development and evaluation of an evaluation tool for healthcare smartphone applications. Telemed. J. e-Health 2015, 21, 831–837. [Google Scholar] [CrossRef]
  66. Leigh, S.; Ouyang, J.; Mimnagh, C. Effective? Engaging? Secure? Applying the ORCHA-24 framework to evaluate apps for chronic insomnia disorder. Evid.-Based Mental Health 2017, 20, e20. [Google Scholar] [CrossRef]
  67. Stoyanov, S.R.; Hides, L.; Kavanagh, D.J.; 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, e27. [Google Scholar] [CrossRef] [Green Version]
  68. Koumpouros, Y. A Systematic Review on Existing Measures for the Subjective Assessment of Rehabilitation and Assistive Robot Devices. J. Healthc. Eng. 2016, 2016, 1048964. [Google Scholar] [CrossRef] [Green Version]
  69. General Data Protection Regulation (GDPR). Available online: https://gdpr-info.eu/ (accessed on 18 December 2021).
  70. Auer, K.; Miller, R. Extreme Programming Applied; Addison-Wesley: Boston, MA, USA, 2002. [Google Scholar]
  71. Dildine, T.C.; Necka, E.A.; Atlas, L.Y. Confidence in subjective pain is predicted by reaction time during decision making. Sci. Rep. 2020, 10, 21373. [Google Scholar] [CrossRef]
  72. Coghill, R.C. Individual differences in the subjective experience of pain: New insights into mechanisms and models. Headache 2010, 50, 1531–1535. [Google Scholar] [CrossRef] [Green Version]
  73. Nicholas, J.; Shilton, K.; Schueller, S.M.; Gray, E.L.; Kwasny, M.J.; Mohr, D.C. The Role of Data Type and Recipient in Individuals’ Perspectives on Sharing Passively Collected Smartphone Data for Mental Health: Cross-Sectional Questionnaire Study. JMIR mHealth uHealth 2019, 7, e12578. [Google Scholar] [CrossRef]
  74. Zhang, R.; Burgess, E.R.; Reddy, M.C.; Rothrock, N.E.; Bhatt, S.; Rasmussen, L.V.; Butt, Z.; Starren, J.B. Provider perspectives on the integration of patient-reported outcomes in an electronic health record. JAMIA Open 2019, 2, 73–80. [Google Scholar] [CrossRef]
  75. Archer, A.; Bolser, B.; Crocker, J.; Miller, J.; Parman, C.C.; Warner, D. Managing Unsolicited Health Information in the Electronic Health Record. J. AHIMA 2013, 84, 70–73. [Google Scholar]
Figure 1. User-centered iterative design.
Figure 1. User-centered iterative design.
Technologies 10 00025 g001
Figure 2. Mobile operating market share worldwide (Q1 2018–Q3 2021). (Source: StatCounter. Available at: https://infogram.com/ios-vs-android-marketshare-1hxr4zx013edo6y (accessed on 18 December 2021)).
Figure 2. Mobile operating market share worldwide (Q1 2018–Q3 2021). (Source: StatCounter. Available at: https://infogram.com/ios-vs-android-marketshare-1hxr4zx013edo6y (accessed on 18 December 2021)).
Technologies 10 00025 g002
Figure 3. Pain recording.
Figure 3. Pain recording.
Technologies 10 00025 g003
Figure 5. User profile.
Figure 5. User profile.
Technologies 10 00025 g005
Figure 6. PainApp architecture.
Figure 6. PainApp architecture.
Technologies 10 00025 g006
Table 1. Matching exercise.
Table 1. Matching exercise.
Doctor RequirementsPatient RequirementsItems IncludedDomains-FeaturesComments
D1. Pain recordingP1. To record the point of pain very easily without having to type textsD1, D2, D5, D9, D11, P1Pain recording: several locations may be pointed, duration of pain, intense of pain, type of pain.A patient may feel pain in various parts of the body. All different points must be recorded.
D2. How long the pain lastsP2. Should not require special knowledge for its use and should not be complicatedD4, P8, P9Treatment recording: name of medicine, time administered, frequency.
D3. How long after the treatment did the pain decrease and to what extentP3. Limited knowledge of using mobile phonesD3, D10, P9Treatment efficiency: if the treatment helped to reduce the pain, how long after the treatment did the pain decrease, how much did the pain decrease, for how long did the treatment work effectively.
D4. What medication the patient is taking and how oftenP4. Functions that help them in daily lifeD6, D7Domains affected: work, daily life, socializing, psychological issues, etc.Each pain point can have a different effect on the patient and his/her daily life.
D5. How and how intensely he/she feels the painP5. No labyrinthine menusD6, D8Other possible causes of pain: new routine, sports, weather, etc.Many of these can happen in parallel.
D6. Pain has affected other activities in the patient’s daily lifeP6. Do not know English or the official names of the drugsP2, P3, P5, P7, P10User Interface: easy to use, not many texts, use of images, not many sub-menus, etc.Better to use images and sliders were possible. Not long texts. Simple wording.
D7. Pain has created other problems in the patient such as depression, stress, etc.P7. Simple and understandable text even by users with a low level of educationD10, P4, P6, P8, P10Usability: alarms and notifications, drop down lists, scanning functionality.Notifications for repeated treatments and reminders to evaluate their effectiveness. Scan drugs and choose disease from a list. Very limited typing.
D8. Are there some other conditions that the patient suspects are the cause of the pain he/she is feeling?P8. Treatments and medications may be repetitive
D9. The pain is permanent or transientP9. Treatment has helped in pain relief (to what extent and after how long)
D10. The patient feels that the particular treatment has helped him/herP10. Add simplistic descriptions
D11. How the pain is felt
D12. Access history data
Table 2. PainApp design vs. mHealth adoption barriers.
Table 2. PainApp design vs. mHealth adoption barriers.
BarrierMethodologyPainApp Approach 1
Not clear interfaceUX experts and behavioral scientists collaborated with many and different patients with diverse diseases.Phase 1 → The interface provides only the necessary information considering issues such as low IT literacy. There are a limited number and basic menus without submenus.
Unmet expectationsFrequent meetings with health professionals and patients in order to detect and assess the needs.Phase 1 → Initial recording of all functionalities asked. Prioritization from the end users in order to agree and keep only the “essential” ones.
Many bugsDebugging in all phases.Phase 2–4 → Continuous debugging was performed in each phase of the project with the active participation of all the different end users. The collected info was then grouped and the necessary actions were taken.
Lack of valueSpecific problems should be addressed taking into account all requirements from different users. Generic assumptions and requirements should be avoided.Phase 1–2 → Pain was the core target of the app. Doctors and patients were the only target groups. The solutions should not focus on specific diseases. Intervention flow was assessed at an early stage.
Notifications and communication strategyOnly important notifications should be given.Phase 1–2 → Only notifications regarding assessment of scheduled treatments was provided.
ContentContent should be valid and updated as needed.Phase 1–2 → Only patients can add content. So, its validity is guaranteed. No need for updates from other sources.
Learning curveIntuitive interface.Phase 1–4 → Graphics are clean and used appropriately only when providing value. Following the principle of simplicity, no confusing content or graphics have been added without providing real value to the user.
1 The phases mentioned in the last column of the table correspond to the ones in the Methodology section.
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Koumpouros, Y. User-Centric Design Methodology for mHealth Apps: The PainApp Paradigm for Chronic Pain. Technologies 2022, 10, 25. https://doi.org/10.3390/technologies10010025

AMA Style

Koumpouros Y. User-Centric Design Methodology for mHealth Apps: The PainApp Paradigm for Chronic Pain. Technologies. 2022; 10(1):25. https://doi.org/10.3390/technologies10010025

Chicago/Turabian Style

Koumpouros, Yiannis. 2022. "User-Centric Design Methodology for mHealth Apps: The PainApp Paradigm for Chronic Pain" Technologies 10, no. 1: 25. https://doi.org/10.3390/technologies10010025

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop