Foundational knowledge - The process of mHealth software development

1. Introduction

Now that the roles of the software/mHealth project development team are clarified, we will focus on the process of app development.

2. Initial Planning and Concept Development

During the planning phase, thoroughly assess and describe the problem or health system constraint, the end-users, and the programmatic and policy context of the problem to have a firm foundation for selecting or formulating a potential mHealth solution (Matthew-Maich et al., 2016). When starting a new project, the scope of the project, the time frame, the budget, and the resources need to be considered (Davies & Mueller, 2020).

At the beginning of the design process, the capabilities, and functions that the platform must have to support the intervention need to be defined and established. Mobile devices can collect large amounts of data electronically, especially monitoring data, so ethical considerations such as data protection and usability must be discussed (Davies & Mueller, 2020; Yanxia et al., 2020).

• Based on these requirements, determine whether open-source tools and platforms can be used. Building on existing open-source platforms can save time and expense.
• If needed, determine how the solution will link to or be compatible with the existing health information system.
• Build into the platform the capacity to collect monitoring and evaluation data, if possible.
• Assess and include any relevant regulatory frameworks and legislation to assure data protection for users.

2.1. Define the Problem and Ensure that mHealth is an Appropriate Solution

The first step is to make sure that the problem and context drive the solution's identification rather than the desire to use a new mobile technology tool.

• Thoroughly assess and define the problem or health system constraint and end-users or target audiences.
• Define desired outcomes and determine whether and where mobile technology could help (Matthew-Maich et al., 2016).

2.2. Coordinate with Programs and Health System

mHealth is a tool for strengthening health systems and achieving health objectives. Still, it might also be ineffective if it is not designed and implemented correctly or incompatible with health information systems (Matthew-Maich et al., 2016). For effective coordination and integration of interventions, thoroughly assess the end-users, the context, and the existent design methodologies capabilities (Davies & Mueller, 2020).

2.3. Assess the Context

Before selecting the software engineering methodology, a series of aspects need to be assessed:

• How end-users make use of mobile phones (or tablets) and the context in which they will utilize the mHealth solution (through formative research)
• The mHealth evidence base to identify potential mHealth solutions
• Current programs and policies related to the problem, including eHealth and mHealth programs or policies
• Mobile phone infrastructure (operators, coverage, services and fees), and potential technology partners
• Behavioral theories and frameworks related to the problem (Matthew-Maich et al., 2016)

3. Select the Software Engineering Methodology

The next step consists in deciding on a software engineering methodology to be employed in the development of the mHealth software. One of the most popular umbrella concept software engineering methodologies used today is the “Agile” approach (Davies & Mueller, 2020). Agile is an iterative approach that consists of gathering requirements, planning the prioritization of requirements, planning the delivery of requirements, development, testing, and deployment of small working versions of the product (minimal viable product  - MVP) (Davies & Mueller, 2020).

Agile software engineering methodology (Davies & Mueller, 2020)

The Agile software engineering methodology functions on 12 principles presented below:

Agile principles (Beck et al., 2001)

From the Agile approach, the two most common frameworks are Scrum and Kanban. These are detailed below.

Scrum framework is a lightweight Agile framework that “helps people, teams and organizations generate value through adaptive solutions for complex problems” (Schwaber & Sutherland, 2020).

The Scrum master framework contains a Scrum master to develop an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat” (Schwaber & Sutherland, 2020)

Scrum Framework (Schwaber & Sutherland, 2020)

Kanban is another methodology from the Agile framework that “is typically a large physical board that displays the current state of work visually to offer a transparent snapshot for the entire state of the project” (Davies & Mueller, 2020). The physical board is usually split into columns with different cards that contain the working units. These units are moved between the columns to indicate the current state (e.g., from pending to progress). Kanban boards can also be developed digitally, and different softwares use this concept (e.g., Asana, Monday, ClickUp).

Basic Kanban board (Shore Labs, 2021)

4. Requirements gathering and presentation

After the initial planning, data for the system/mHealth app requirements needs to be gathered. Depending on the type of the project, this data can come from either the , the project team or the end-users themselves. The idea behind this step is to have a user-centred design that will allow designers to understand user requirements for all product cycle and, in the end, develop a product that offers value to the customers (Davies & Mueller, 2020). 

Data for system requirement can be gathered using quantitative (surveys) and qualitative tools (focus groups, interviews). This data can already be available from the sponsor or it can be collected specifically for the development of the mHealth software. The aim is to assess users’ values, needs and wants regarding the mHealth solution to be developed. For example, to build the Smoke Free Together app, the project team made use of qualitative data from 30+ semi-structured interviews and survey data collected in three different research projects spanned over 6 years and targeting smoker pregnant women (the same target population as for the Smoke Free Together app).

The initial purpose of the data was not to serve as a basis for the development of the Smoke Free Together app, but the data collection instruments (questionnaires and interview guides) contained questions that were helpful in highlighting the major barriers in smoking cessation, the type of support the women needed to quit, or what expectations would they have from a potential smoking cessation app.

4.1. User stories

A method for gathering data for specification requirements is to offer examples, which can take the form of user stories. User stories are beneficial in deciding and prioritizing the value of the feature included in the app. An template from Davies & Mueller of how user stories work is presented below:

(Davies & Mueller, 2020)

Usually, the stories that can be split into smaller stories are called epics, and data for the epics can be generated through different story points that take into account every user's need (Davies & Mueller, 2020). The user stories are useful because they describe the type of user for each action, the tasks and aims for each user, and what value each feature brings (Davies & Mueller, 2020).

Another example of a user story form the Smoke Free Together app is included below.

4.2. Personas

Another method for presenting data is using personas or stories about the user for different typologies of users of the system. These personas or stories might contain background information about the user, as shown in the example below.

(Davies & Mueller, 2020)

The figure below depicts one of the four personas developed for the Smoke Free Together smoking cessation mobile app designed to be used by pregnant women and one nominated peer supporter of their choice.

4.3. Data modeling diagrams

Data modelling diagrams are used to have a better overview of the structure and flow of the application. These diagrams help in communicating the proposed system designed to the developers and stakeholders (Davies & Mueller, 2020). Data flow diagrams are one type of data modelling diagrams. These can be general, developed to provide a high-level view of the system or can be very detailed, showing how different levels of the system are structured.  For example, the imagine below depicts a high-level view of the architecture of the Smoke-Free Together app.

5. The phases of mHealth software development

It is important to mention that the development of an mHealth software it is not a linear process and the phases described below overlap across the app development timeline.

5.1. Designing the user interface

Use a systematic approach to design and test content and the user interface by employing User Experience (UX) testing in all stages of the product life-cycle (Davies & Mueller, 2020). If the product is designed in a way that is easy to use, enjoyable, and contains useful information, the app's uptake will be a success (Davies & Mueller, 2020). Consider rapid prototyping to design an appropriate user interface to test the product's coverage, software, and usability. (Punchoojit & Hongwarittorrn, 2017; Yanxia et al., 2020). Some examples of UI prototypes are included below:

5.2. Coding

Within the framework of the software development methodology selected by the project manager (i.e., Agile), the developers use a framework (either Scrum or Kanban) to transfer the requirements of the app into code.

5.3. Testing the mHealth software

Test message concepts, content, and user interface by using a User-Centered Design (UCD). UCD refers to “a design process whereby the users of an intended system or product are involved throughout the development processes, and the design process is centered around the needs and requirements of the end-user” (Davies & Mueller, 2020). UCD can be performed using interviews, focus groups, user stories, personas, scenarios, stories, surveys, stakeholder analysis, and any other tools that might fit usability testing needs (Davies & Mueller, 2020).

In general, three testing types are conducted. There is internal testing, conducted by the person(s) who has the tester role in the team, with the purpose to find errors in the way the software is functioning.

The second type of testing is usability testing. Usability testing can be either moderated or unmoderated and it can involve either experts in the behavior targeted by the app or end-users of the app. In moderated usability testing, users are invited to interact with the mobile app on their own mobile device, as they would in usual circumstances, by following a list of pre-defined tasks (for example, the user can be asked to find a piece of information available in the app or to change a setting in the app) and while thinking aloud. Throughout this process, the screen and the face of the users are recorded simultaneously. In unmoderated usability testing, users utilize the app independently for several days or weeks and their activity in the app is recorded with various screen recording software already embedded in the mHealth app. One such software is Smartlook, which is developed to analyze users’ behaviors and generate qualitative and quantitative insights that help teams improve their products.

5.4. Project management tools

A good management tool is required for good management of the project and team working on developing the system. Different tools are used to manage and organize tasks and store the code (these project software management tools are called version control).  A selection adapted from Davies & Muellers is being offered below.

Table adapted from (Davies & Mueller, 2020)

6. Additional important aspects to consider

Here some considerations dealing with other aspects.

6.1. App maintenance

A common misconception is that an app is finished after it was developed and released. However, the life of an app is an ongoing process, and maintenance needs to be considered. Each time the software receives a new update, it affects the application and intervention; therefore, constant maintenance is required. This aspect needs to be covered in the budget of the project for both money and human effort (Davies & Mueller, 2020).

6.2. The performance of the app in real-life

Once the mHealth app is finalized, in collaboration with stakeholders and partners, training and promotion plans need to be developed, and the preparations for monitoring and evaluation need to be finalized. Baseline data should be collected if required for an outcome evaluation (Yanxia et al., 2020). Essential monitoring and evaluation (M&E) tasks consist of collecting end-user feedback, summarizing system data for stakeholders, and evaluating intervention impact (Yanxia et al., 2020).

6.3. Gather Evidence that Stakeholders Need

Stakeholders often require different types of information (e.g., demonstration of acceptability, cost and cost-effectiveness, impact on health outcomes etc.). Transparent collaboration with the stakeholders from the beginning will ensure that appropriate types of evidence are obtained for M&E purposes (Yanxia et al., 2020).

6.4. Analyze and Report on System Data

Leverage the data generated by the mHealth solution (such as from system usage logs) to regularly analyze and summarize data for stakeholders (Yanxia et al., 2020).

6.5. Evaluate Project Impact

Evaluate project impact on end-users and/or the health system. Include health outcomes, gains in quality and efficiency, and cost-effectiveness as appropriate (Yanxia et al., 2020).

6.6. Consider the Potential for Scale Up

The potential for scale up of the mHealth application needs to be considered from the perspective of the end users, the perspective of the health system, and the perspective of available resourses.

6.7. perspective of the end users

To create a scalable system, the mHealth software needs to be easy to use, acceptable and compatible with users’ values and social norms. In addition, it needs to be useful to the end-users, or an improvement compared to what the end-users did or used before, such as by making their jobs easier, improving the quality of their work, saving time, or meeting clients’ needs. A mHealth solution is more likely to be adopted if it is beneficial to end-users, easy to use and minimizes costs. Additionally, if these aspects are met, some of the benefits can be provided in many ways, such as saving costs, saving time, improving quality, by meeting clients’ needs, or by making it easier for health workers to do their jobs (Yanxia et al., 2020).

6.8. The perspective of the health system

The first condition that needs to be met when considering to scale up an mHealth application is the local support and buy-in for its implementation (Nouri et al., 2018; Yanxia et al., 2020). An application is more likely to be scaled up and sustained if it is linked electronically into the health ecosystem. If feasible, ensure that data collected by the solution is linked to facility-level data systems (Yanxia et al., 2020).

6.9. The perspective of the available resources

The mHealth application needs to be cost-effective to deploy and run. To the extent possible, help ensure sufficient human and technical resources for scale-up are in place. This may include advocating for supportive policies or more mobile network coverage. Essential scale-up resources include:

• Adequate mobile network coverage. You may need to adapt the solution for the existing mobile network infrastructure.
• Ongoing technical support to maintain the system and respond to problems as they arise. If the local technology partner does not have sufficient skills for implementing and maintaining the mHealth solution, it will eventually stop working. Consider mentoring them if needed to improve their skills.
• Reliable electricity for databases and monitoring dashboards in the system. How will phones or tablets be recharged?
• Secure database storage capacity, regular data back-up, and network monitoring.
• A privacy and confidentiality policy. Such a policy is needed when collecting and storing patient data (Yanxia et al., 2020).

6.10. Explore Sustainability Models or Make a Business Case for the application

Explore sustainability models or make a business case for the application.

• Identify ways that the application can help mobile operators improve their services and expand market share; use these benefits to negotiate lower rates.
• Seek financial support from public and private sources and/or end-users.
• Explore integrating mobile finance functions for sustainability.
• Explore diverse business models with partners and stakeholders (Yanxia et al., 2020).