This study was conducted in four phases:
-
1.
Needs assessment and determination of educational content.
-
2.
Determination of functional and non-functional requirements of the App.
-
3.
Design and development of the App.
-
4.
Usability evaluation.
These phases were conducted according to the principles of the IMS patient education model. The goal of this model is to increase patient adherence to treatment, especially in the management of chronic diseases. It has three factors or dimensions:
-
Information: This dimension emphasizes the provision of accurate, appropriate, and sufficient information and effective communication with the patient.
-
Motivation: This dimension refers to the use of methods that increase patient motivation to follow the treatment process.
-
Strategy: This dimension helps patients overcome practical barriers to following treatment and create a feasible strategy for long-term disease management [20].
Phase 1: needs assessment and determination of educational content
In order to comply with the principles of the information dimension of the IMS model, in this phase, the required exercises were identified, and during a meeting with physiotherapy experts, books, guidelines, and authentic instructions of physiotherapy were examined, and facial muscle rehabilitation exercises were extracted from them. Then, with focus group meetings and the approval of the research team (a medical informatics specialist, a medical education specialist, and a physical therapy specialist), these exercises were categorized. The exercise checklist was designed in four sections and based on a 5-point Likert scale. Additionally, at the end of each section, a free text box was considered for recording any new experts’ suggestions. Finally, to evaluate the exercises checklist based on the Delphi technique, 6 physiotherapy specialists were selected based on the following inclusion and exclusion criteria.
-
Educational level less than a PhD.
-
Work experience less than two years.
-
Lack of willingness to cooperate.
Experts were invited to cooperate and participate in the study through email and SMS. Exercise checklists were provided to the experts in person and by email at the same time. The response time to the checklists and sending them was considered to be a maximum of two weeks and a week after sending them, the response time was reminded to the participants. To reach a consensus regarding the items on the checklists, we used a consensus agreement level of 75%.
The average score given to each case was calculated to analyze the data collected by the checklists using Excel software. The maximum score was 5, and the minimum was 1. The basis of acceptance was an agreement above 75% of the experts (average scores ranging from 3.75 to 5). Items with 50–75% agreement (average scores ranging from 2.5 to 3.75) were included in the second round of Delphi and re-evaluated through a checklist by the specialists. If the agreement of less than 50% of the experts was obtained (average scores less than 2.5), they were eliminated. Finally, the results were sent to the experts via email.
Phase 2: determination of functional and non-functional requirements of the mobile app
Requirement Engineering (RE) is the most important phase of the software development life cycle (SDLC). This phase is used to translate the imprecise, incomplete needs and wishes of the potential users of software into complete, precise, and formal specifications. The specifications act as the contract between the software users and the developers. Therefore, the importance of Requirement Engineering is enormous in developing effective software and in reducing software errors at the early stage of the development of software. Since Requirement Engineering (RE) has a great role in different stages of the SDLC, its consideration in software development is crucial. Two types of software requirements are functional requirements and non-functional requirements [21].
Functional requirements: specify the functions a system is supposed to accomplish defined in terms of inputs, behavior, and outputs. Functional requirements specify particular results of a system, such as calculations, technical details, data manipulation, and processing.
Non-functional requirement (NFR): in software system engineering, a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, design constraints, timing constraints, security, cost, and software quality attributes. Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively [22, 23].
To determine the requirements and capabilities of the program in line with the motivation and strategy dimension of the IMS model and to identify the characteristics and strategies that strengthen the patient’s motivation to follow the treatment, using the keywords “facial paralysis”, “therapeutic exercise” and “telerehabilitation” and “mobile application”, based on Mesh, the search strategy was determined. And then in PubMed (MEDLINE), Web of Science, and Scopus databases, a systematic search was conducted based on the Prisma checklist.
After studying related articles, functional and non-functional requirements were extracted from these articles, and during a meeting with the research team, the obtained items were reviewed and categorized. The requirements checklist was designed based on a 5-point Likert scale and validated by experts (n = 12) through the Delphi technique. Then it was completed by specialists based on the following inclusion and exclusion criteria.
-
Inclusion criteria:
-
Specialists in physiotherapy, medical informatics, and health information management.
-
Faculty members of Shiraz University of Medical Sciences.
-
Having enough time to participate in the study.
-
Exclusion criteria:
-
Educational level less than a PhD.
-
Less than two years of work experience.
-
Lack of willingness to cooperate.
Experts were invited to cooperate and participate in the study through email and SMS. checklists were designed using Porsline, which is an online questionnaire creation tool, and its link was sent to experts along with the original file in Word and PDF format.
The average score given to each item was calculated to analyze the data collected by the checklists. The maximum score was 5, and the minimum was 1. The basis of acceptance was the agreement above 75% of the experts (average scores ranging from 3.75 to 5), and the cases with 75%-50% agreement (average scores ranging from 2.5 to 3.75) were entered into the second round of Delphi and re-evaluated through a checklist by the specialists. If the agreement of less than 50% of the experts was obtained (average scores less than 2.5), they were eliminated.
Phase 3: design and development of the mobile app
To convert the exercises into content that can be loaded into the program and present them with a better understanding to the patient in line with the information of the IMS training model, how to perform the approved exercises was filmed in the studio.
After evaluating and reviewing the educational videos recorded in specialized meetings with the research team and receiving the necessary approvals, Adobe After Effects software was used to remove the background add the program logo to the relevant videos, and edit them.
Also, to reduce the storage volume of the videos to facilitate the uploading of the exercises and their faster reception by the patients in line with the motivation dimension and strategy of the IMS model, the image resolution of all the videos was determined in SD format.
Then, based on the approved requirements, the prototype was designed using Adobe XD software. After meeting with the research team and approving the prototype, the program was developed using Java based on Android Studio. The name of the application was determined as TFP, which stands for Tele exercise therapy for facial paralysis.
Phase 4: usability evaluation of the mobile app
After the development phase, usability evaluation of the TFP program was done with the Heuristic method and medical informatics experts were considered as the research community of this phase and evaluators. For this purpose, available sampling was done and samples were selected based on availability, familiarity with systems evaluation methods, and willingness to cooperate.
The TFP application was sent to these evaluators and they were asked to install it and as users, evaluate the application using the Heuristic evaluation checklist. This checklist includes 13 main dimensions and 54 items, and its validity and reliability have already been measured in the Hwang study [24],
After completing the checklist, the problems identified by the independent evaluators were combined and after removing the duplicates, they were collected in a single list and given to the evaluators in the form of a list of identified problems. They independently weighed the degree of severity of the problems based on the five-point scale based on Table 1, and then the average severity of the problems of each principle was calculated and determined.
link