We developed an mHealth prototype, named aFib, targeted for patients with AF and their doctors. The main purpose was to facilitate shared decision on anticoagulation therapy during clinical appointment.

Our study population comprised patients with AF followed at the outpatient anticoagulation clinic of our institution. Instituto de Cardiologia do Rio Grande do Sul is a hospital specialized in treating heart diseases, supported by the Brazilian public health system. Every month, around 700 patients with AF are followed by the anticoagulation clinic and the majority of them have low-income and low-educational level. Previous studies showed that only half of these patients are adherent to therapy or within the therapeutic range of international normalized ratio (INR) [14,15], showing that existing strategies are not effective.

The aFib team comprised a cardiac electrophysiologist with expertise in AF, a clinical cardiologist, a software developer, and a designer. After a comprehensive literature review to support all information provided by the app, we used the behavioral intervention technology (BITs) model to ensure that the development process was systematic and replicable [16]. Our process comprised the following steps:

All information collected could be saved and reviewed later. This was motivated by 3 reasons: (1) risk factors often change over time, which means that risk stratification must be updated and recalculated; (2) to allow a staff nurse to collect primary data that could be expanded and modified during the physician’s appointment, providing greater ease of adoption of the app in the primary care setting; and (3) to enable data transfer to other devices, since we expect that our target population will likely migrate to mobile phones in the following years.

aFib app prototype was delivered in Portuguese. Terminology was adapted to both patients and health professionals according to whom the information was directed to. Language in the educational video, in the pictograms, and in the summarized information about medications was directed to low-literacy patients, whereas language of the risk scores and leaflets was directed to their caregivers. Graphic design was developed to be clear and intuitive, with few but meaningful graphics and a color code to highlight risks and benefits of the treatment. The first version was designed to Android tablets with 10.1-inch screen to improve reading since the majority of patients with AF are elderly and may have vision impairment. Security and privacy were assured through unique ID authentication, and data transfer to central database was done using a Transport Layer Security (TLS) with 128-bit encryption method. A privacy policy was presented at the beginning of data collection with appropriate information, purpose, and user rights. See Multimedia Appendix 1 for main screens of aFib.

Three clinical cardiologists, 2 cardiac electrophysiologists, 1 medicine student, and 20 patients evaluated aFib in the pilot phase and gave feedback about perceived ease of use, perceived usefulness (two statements with a 5-point Likert scale), relevancy of content, navigation, terminology, interactivity, attractiveness, learnability (through a pre- and posttest questionnaire about the disease and treatment), and conflict about decision process (measured by a decisional conflict scale) [20]. Written informed consent was obtained from all participants, and the Institutional Ethics Committee approved the study.

After adjustments that were made based on these feedbacks, aFib is being currently evaluated in a randomized clinical trial with the target population described, with short- and long-term outcomes previously established (improve knowledge, treatment adherence, and maintenance of adequate levels of anticoagulation and cost-effectiveness of this strategy).

The main challenges in the development process were (1) in the app contents, to summarize information in a way that would maximize knowledge acquisition and maintain patient’s attention; (2) in the design, to minimize screens and to translate the percentages of risk in graphic information understandable by low-literacy users; (3) in the technical area, to level the knowledge of the development team in order to permit brainstorming, that is, to provide the developer and the designer with the medical information needed to understand the app context and, at the same time, to provide physicians with the technical information essential for structuring the app.

On the basis of this experience, we created a short guide to the development of mHealth apps (Figure 1), suitable for use in other oncoming mHealth apps for use in LMIC.

A solid project starts with understanding who the users are and what problem do the app want to solve. If the subject in question is too broad, try to approach a key problematic aspect, like knowledge gaps, difficult choices, or complex treatments.

An mHealth app may be directed to patients or their relatives, health care professionals, or even to healthy people looking for disease prevention. It is important to understand not only the socioeconomic background and educational level of the target population, but also their desires and doubts. What is their most pressing issue? Where do they get their information? What benefit of the app will help solve their problem? All these questions must be answered in order to develop a user-centered mHealth app. It is important to think also about the Internet connectivity and multimedia capability of the device in which the app will be accessed. In the United States, low-income groups are now using mobile phones as their primary method for Internet access [21]. In other countries, it might be desirable that the content can be downloaded to be accessed offline. Usability has to be planned foreseeing the worst scenario.

Citizens from LMIC can have inconsistent access to their health systems, and an mHealth app can be a great opportunity to reach these populations. Thus, it should provide the best available evidence about the problem: guidelines, meta-analysis, systematic reviews, and randomized clinical trials will be the most helpful, with preference to local guidelines. Identify risk scores, outcomes, and the core information to be delivered. The references should be provided in order to aid users to make their own judgment on its reliability.

Ascertain the prevalence, incidence, and other important measures of impact, effect, and association of the problem in the target population. This would help to justify the app contents and/or interventions and establish outcomes.

If the subject had been addressed before by other apps, then identify which knowledge gaps are still blank and how to fill local population needs.

Once the problem has been defined globally and the content is evidence-based, the main challenge is to transform a huge amount of data in best quality and well-presented information, tailored to the user. Low literacy can be a barrier to the adoption of usual solutions. The 4 topics that should be kept in mind to better achieve the goal of transmitting knowledge are discussed below.

Security and privacy in mHealth apps is a vast subject, and laws regulating these aspects vary widely between countries. A recent review addressed this issue and suggested minimum requirements for developers [29], summarized here:

We strongly recommend a comprehensive review of the laws from the country for which the app is being developed since these minimum requirements can be insufficient in some cases.

A built-in medical-legal disclaimer with the terms of use agreement is of special interest if the app is widely available for download by doctors and patients, to help clarify the publisher’s responsibilities and thereby reduce the legal risks associated with the use.

Recent studies about mHealth usability suggest the use of a multimethod approach and standardized methods and tools in mHealth evaluations, which can result in a more comprehensive identification of usability issues, more specific redesign recommendations, and better reproducibility of results across studies. For users, improved mHealth design and usability could result in improved interactions, greater use of mHealth apps, and perhaps even increased adherence to suggested interventions and therapeutic [30].

To date, there is a paucity of published studies on the efficacy of mobile phone apps for health promotion in low-income populations. More research and evaluation is necessary about both internal and external validity and sustained health outcomes [31].

Internal validity of mHealth apps for low-income populations can be threatened by selection bias (eg, participants with sociocultural characteristics that do not represent the target population), instrument changes (eg, version updates of the app), regression toward the mean (eg, in knowledge evaluation of low-literacy participants), between other factors. To improve and standardize evaluation reports of mHealth interventions, a validated framework like CONSORT-EHEALTH [32] or RE-AIM [33] is recommended. The following are the steps that can be followed to validate an app.

Achieving success in health prevention and treatment in LMIC is challenging and require approaches and tools that (1) have proven clinical benefit, (2) can be scaled to reach a global population and (3) are affordable. Mobile technologies provide a potential platform to facilitate these needs [35].

mHealth is empowering individuals to assume a more active role in monitoring and managing their chronic conditions and therapeutic regimens, as well as their health and wellness [2]. But, this new health tool needs to be adapted to local language and reality [6].

This tutorial was based on the experience acquired while developing the app “aFib,” and describes processes and recommendations to aid developers who are interested in creating or adapting mHealth apps to low-income populations. A problem-targeted and user-centered strategy appears to be a logical trend to the development of these apps. A comprehensive review of literature must be the base of the project. The best efforts should be made to translate information to knowledge and it should be kept in mind that good navigability, terminology, and interface design can help on this task. Protection of user information is essential, and local laws on the matter should be studied beforehand. Usability and efficacy must always be evaluated in a variety of scenarios.

This tutorial has several limitations. First, the literature about mHealth is increasing quickly and new models are being tested every day to improve the development process, which can soon overwhelm the models we used here. Second, it is likely that a single experience cannot provide insight about every step of this process. Third, other diseases or conditions can present with different challenges related to low-income populations. Finally, the characteristics of low-income populations vary widely between countries, with cultural and social differences that may need distinct adaptations.

Despite these limitations, we believe that it can encourage the development and evaluation of mHealth apps in LMIC. mHealth is a low-cost strategy and appear to be an appreciated, easy-to-use, and promising aid to improve knowledge and engage individuals from LMIC in the management of their illness, supporting healthy behavior change and potentially improving population health.

As mobile technologies become increasingly ubiquitous, apps adapted to local use in low-income populations are needed. This tutorial expects to stimulate the development of mHealth apps for low-income populations, on a scientific base. Future work should address other possible ways to reach this special group and the extent to which this new health resource will affect their health care.