Agile Development of a Smartphone App for Perinatal Monitoring in a Resource-Constrained Setting

Abstract

Technology provides the potential to empower frontline healthcare workers with low levels of training and literacy, particularly in low- and middle-income countries. An obvious platform for achieving this aim is the smartphone, a low cost, almost ubiquitous device with good supply chain infrastructure and a general cultural acceptance for its use. In particular, the smartphone offers the opportunity to provide augmented or procedural information through active audiovisual aids to illiterate or untrained users, as described in this article. In this article, the process of refinement and iterative design of a smartphone application prototype to support perinatal surveillance in rural Guatemala for indigenous Maya lay midwives with low levels of literacy and technology exposure is described. Following on from a pilot to investigate the feasibility of this system, a two-year project to develop a robust in-field system was initiated, culminating in a randomized controlled trial of the system, which is ongoing.

The development required an agile approach, with the development team working both remotely and in country to identify and solve key technical and cultural issues in close collaboration with the midwife end-users. This article describes this process and intermediate results. The application prototype was refined in two phases, with expanding numbers of end-users. Some of the key weaknesses identified in the system during the development cycles were user error when inserting and assembling cables and interacting with the 1-D ultrasound-recording interface, as well as unexpectedly poor bandwidth for data uploads in the central healthcare facility. Safety nets for these issues were developed and the resultant system was well accepted and highly utilized by the end-users. To evaluate the effectiveness of the system after full field deployment, data quality, and corruption over time, as well as general usage of the system and the volume of application support for end-users required by the in-country team was analyzed. Through iterative review of data quality and consistent use of user feedback, the volume and percentage of high quality recordings was increased monthly. Final analysis of the impact of the system on obstetrical referral volume and maternal and neonatal clinical outcomes is pending conclusion of the ongoing clinical trial.

1. INTRODUCTION

Maternal mortality and perinatal mortality, defined as both stillbirths and early neonatal deaths within the first week of life—are two of the most pressing public health problems globally. Around 300,000 women die annually from complications of pregnancy or labor, and some 2.6 million stillbirths and 2.8 million early neonatal deaths occur each year [1, 2]. There is considerable disparity in the burden of these deaths, with most occurring in Low and Middle Income Countries (LMICs). According to the World Health Organization (WHO), 99% of maternal deaths occur in LMICs [1]. Perinatal deaths are similarly concentrated; for example, one recent analysis has shown that more than 50% of neonatal deaths globally occur in just 5 LMICs [3]. Factors contributing to these disparities between LMICs and High-Income Countries are primarily related to systemic deficiencies in the timely provision of care to women and neonates, rather than to any specific absence of one or several medical interventions [4].

Guatemala is a small Central American lower-middle income country that is often used as a case study to examine the dynamics and causes underlying maternal and perinatal mortality since rates of both are among the highest in all of the Latin America [5, 6]. Guatemala is a country with great income disparities; it has the highest headcount poverty ratio in Latin America, and poverty is especially concentrated among the nearly 50% of the population who identify as indigenous Maya. In fact, 79% of the Maya population lives in poverty, as compared to 45% of the non-indigenous population [7]. Not surprisingly, these economic disparities are paralleled by disparities in health outcomes as well. For example, overall, neonatal mortality is 20% higher in the indigenous population and, in the most rural indigenous communities; the maternal mortality rate is twice as that of the national average [8, 9].

Pregnant indigenous Maya women face multiple cultural, structural, and institutional barriers in order to access high-quality obstetric care. This includes overt racism and discrimination, long transit times and expenses associated with travel from rural communities to urban referral hospitals, lack of a functioning referral system between communities and hospitals, and language barriers as most health services are available exclusively in Spanish rather than indigenous Mayan languages [10, 11]. Due to these barriers, the majority of indigenous Guatemalan women opt for home births attended by lay indigenous (Maya) midwives over institutional deliveries [9].

The Guatemalan Ministry of Health (MOH) has recognized the role lay midwives play providing health services to rural indigenous populations since the 1930s, when the first training programs for detecting and managing obstetric complications were introduced. However, very little effort has been conducted to build a functional referral mechanism for linking lay midwives to the formal healthcare system. One obvious solution to this problem is the use of mHealth technology to strengthen the referral chain and to provide lay midwives with decision support. Recent work has shown that providing rural MOH health workers in Guatemala with basic phones for case data entry and voice consultation with higher-level healthcare providers can reduce maternal-child mortality and improve referral rate [12]. Although lay midwives have much less formal health training and exposure to mobile technology than health workers, nevertheless, it can be reasoned that an appropriately designed mHealth decision support applications may improve maternal and perinatal outcomes for midwife-attended pregnancies. Specifically, a pictogram and audio driven Smartphone application with all of the decision support necessary to guide the midwife through and a standard evaluation of the mother and fetus allows for the early identification of perinatal complications. The phone automatically establish communication between the midwife and the medical team at any sign of trouble and connects the patient to the appropriate care needed.

Recently, the basic prototype for such an application was described, which included functionalities for collecting patient demographic information; decision-support checklists for prenatal, intrapartum, and postnatal complications; and integration with peripheral devices (1-D ultrasound, pulse-oximeter, oscillometric automated blood pressure cuff) [13]. In this article, the process of adaptive field testing and iterative prototyping was described, which was guided by an agile design framework [14]. Details of this agile design process will be of value to other front-line implementers working to develop meaningful mHealth solutions, especially for end-users with limited technology literacy or who speak minority or indigenous languages. They also are responsive to a recent call by the WHO for more detailed reporting on the adaptation and design processes involved in mHealth application development [15].

2. METHODS

2.1 Institutional Context

This research was performed as a collaboration between Emory University’s Department of Biomedical Informatics (app development, technology system design and informatics), Agnes Scott College (anthropological and public health considerations) and a nonprofit primary health care organization, Wuqu’ Kawoq | Maya Health Alliance, which provides comprehensive primary health care services in rural Maya communities in central Guatemala. Indigenous lay midwives—primarily Kaqchikel Maya-speaking—from Wuqu’ Kawoq’s catchment area were recruited to participate in the research. The research was approved by the Institutional Review Boards of Wuqu’ Kawoq (Protocol # WK-2015-001) and Emory University (Protocol # IRB00076231). Informed written consent was obtained from all the participants.

2.2 Agile design process

The agile software movement seeks alternative approaches to traditional project management to help teams respond to unpredictability through incremental, iterative work cadences, and empirical feedback. The movement centers around several core principles, including active up-front involvement of end-users in the design process, frequent delivery of iterative product improvements, and integration of ongoing testing throughout the entire project lifecycle [14, 16].

An initial needs and feasibility assessment with a mixed group of healthcare workers from Wuqu’ Kawoq-including physicians, nurses, and lay midwives-led to the development of a basic prototype, which the authors have already described in detail [13]. The primary target end user of the application were the Wuqu’ Kawoq-affiliated lay midwives-who are typically middle-aged, largely monolingual in Kaqchikel Maya, with low literacy and limited exposure to technology. Several important design decisions were therefore taken at the first prototype stage, including the use of a graphically driven interface with Maya language audio cues and the replacement of text-based data entry with voice recordings, photographs, and wireless data transfer (Table 1).

Table 1.

Description of application features and major decisions taken in each product release cycle

Application Features	Prototype Features	Product Release Cycle 1 Modifications	Product Release Cycle 2 Modifications
Patient Information Registration	- Voice recording of patient information (name, community of origin) - Photograph of patient - Voice recording timer and automatic audio playback - Pictographic and audio cues/instructions - All patient data synced to Amazon S3 database when phone in range of WiFi.	- Customized in-app camera	- Phone SD cards transferred to desktop computer for data backup
Detection of Complications	- Pictographic checklists for prenatal, delivery, and postpartum complications - Pictographic and audio cues/instructions	- Gestational age recording screens
Physiological Signals	- Blood pressure and heart rate recording - Pulse oximetry: maternal heart rate and oxygen saturation measurement - 1-D Ultrasound: fetal heart rate recording - Pictographic on-app instruction manuals	- Photograph recording of blood pressure readings - Lock-out of ultrasound for gestational age<20 weeks	- Locking of phone buttons during recording - Silicon gluing of cable assembly - Recording of ultrasound data in 5 minute segments - Bluetooth and Wi-Fi automatic turn on/off during recording
Decision Support/Alerts	- Voice call automatically generated to on-call physician for high-risk complications - Coded-SMS summary of each patient encounter sent to on-call clinician phone		-”Send” button added at end of encounter to generate SMS alert

Based on the first prototype, an iterative design process was conceptualized, spanning two major product release cycles, as outlined in Figure 1. The first cycle was largely focused on testing and improving the basic usability of the application interface, and involved intensive interactions between a small group of core midwife end-users acting as beta-testers and developers. These interactions occurred in two phases. The first phase was an ‘in-office’ phase, where beta-testers and programmers experimented with the interface, using each other as test subjects when necessary. This phase involved five weeks in which Wuqu’ Kawoq program staff (one physician and one nurse) facilitated daily face-to-face interactions between the four volunteer lay midwives and software engineers from Emory University, constituting the entire research team. In this phase, updated application software was released at the end of each working day. All four lay midwives were monolingual Kaqchikel Maya speakers, illiterate, and had no prior smart-phone use experience. They were consulted extensively on the final layout and design of the app to adapt the interface and workflow to their cultural and logic preferences. After the conclusion of the first phase, software engineers returned to Emory University, and a second period of more prolonged ‘field’ beta testing with the same four lay midwives was conducted for sixteen weeks. During this phase, the entire team met virtually once a week to relay field observations, which informed the software, updates, once per week.

Figure 1. Timeline for iterative adaptive design and product release.

Red indicates the release cycles; blue indicates the originally planned sequence of testing, and orange represents the new agile developments created as a quality/response improvement data.

There were three key reasons for having the U.S. engineers spend time with the users. First, it was vital that the software engineers understood the context in which the app was being developed, and observe the equipment being used in the field to gain a good understanding of potential user challenges. The second reason was to enable training of the Guatemalan team to perform routine hardware and software operations on the phones and physiological data acquisition devices. This included training on how to test for microSD card failures, cable problems, pulse oximeter failure errors, phone software updates and data synchronization issues. These measures were in recognition of the fact that a project can fail for simple reasons such as connector wire polarity or poor assumptions of ‘natural’ usability of common devices (such as mobile phones). The third reason was to develop a sense of empathy and comradery, so that requests on both sides were treated with respect and responded to rapidly. This final point cannot be over-emphasized for mHealth collaboration, which by virtue of its very nature, tends to be mostly virtual.

At the end of this first product cycle, the team felt that an essentially functional and stable application had been produced. However, the team also noted that several components of the application and hardware—especially data capture and transmission quality, device maintenance and troubleshooting—had not been adequately tested in the first round. These were therefore included in the second cycle. A second product release cycle was then undertaken (Table 1), involving a larger sample of 21 practicing lay midwives and integrating the application into their daily practice. This phase was launched with one week of formal training for each participating midwife on how to use the application (including a pass/fail competence test and retraining/retesting if necessary). The cohort comprised 21 experienced, low literacy midwives, primary monolingual in Kaqchikel Maya, and living several kilometers from the nearest medical facility (Table 2).

Table 2.

Characteristics of end-users (lay midwives) involved in agile design process.

Characteristics 1	Value
Age (yrs)	47.35 ± 8.70
Years in Practice (yrs)	15.90 ± 7.71
Distance from Town (km)	15.40 ± 11.28
Literacy (%)	25.0
Monolingual Maya (%)	55.0

¹Mean ± SD for continuous variables. Units are given in the first column.

Subsequently, for seven months, the project team met virtually once a week to review process data (qualitative feedback from program staff and lay midwives, and quantitative data on device usage). Software updates occurred roughly every two months. Initially, planned implementation supervision comprised weekly review of device usage/data quality by the program physician, weekly troubleshooting phone calls, and monthly field visits to each midwife by the program nurse. Issues with the quality of data capture and cabling/device assembly in the field were identified (described below in more detail). In response, in the second month, a round of in-office device retraining sessions were performed for those lay midwives with the highest proportion of low-quality data. During the third and fourth months, the project nurse accompanied each midwife on her clinical visits to directly observe device usage in the field, provide additional coaching and support, and diagnose any additional sources of errors.

3. RESULTS

In this section, the design challenges encountered by the team during both product release cycles and the approaches used to solve them are described, as well as related data on device usage, data quality, and application support provided.

3.1 Release Cycle 1

3.1.1 Camera interface

An important part of the prototype design was allowing capture of a patient photograph for identification purposes, especially since many of the end-users are illiterate. This initially used the Android OS native camera application. However, almost immediately during in-office testing, the team discovered that numerous buttons in the native camera application were confusing to the users. The native resolution of photos was also noted to rapidly consume the phone’s limited storage space, and wasted upload bandwidth, even when set at minimal resolution. Therefore, a customized camera application was created that eliminated all buttons except for the single shutter-release button and significantly reduced the resolution of the photos to be the same as the phone’s screen resolution (any higher resolution would not aid in identification of the patient).

3.1.2 Recording of Gestational Age

Discussions between users and the development team raised significant concerns about the difficulties of obtaining high-quality 1-D ultrasound recordings of fetal heart rate in the early months of pregnancy. The team reasoned that these difficulties could be a source of distress for both lay midwives and patients by generating unnecessary cause for the concern when the midwife failed to locate the fetal heart rate. Therefore, the decision was made to introduce a “lock screen” in the application that would prevent the phone from acquiring the ultrasound signal if the patient was under a certain gestational age.

With feedback from the lay midwives, the decision was made to use a simple pictographic image of uterine height as a proxy for gestational age, since all the lay midwives were skilled in the technique of estimating gestational age using the symphysis-pubis fundal height (SFH) method. A uterine fundal height at the level of the umbilicus corresponds to roughly 20 weeks of gestation [17]. Since none of the lay midwives had trouble detecting fetal heart rate after this gestational age, the application was configured to permit use of the 1-D ultrasound device only if the user clicked on a SFH above the umbilicus (Figure 2 - left).

Figure 2. Screenshots of interface for capturing gestational age data.

Users are able to indicate fundal height of their patient on the application by tapping on the image of the abdomen above or below the umbilicus (left). If the fundal height is below the umbilicus (roughly under 20 weeks gestation), the logic branching does not allow the collection of ultrasound data. Users are also able to indicate gestational age in whole months on a separate screen (right).

The in-office beta-tester group also indicated that, in addition to the SFH, lay midwives often calculate their patient’s gestational age counting the number of whole months since the last menstrual period. This was because patients often forgot the specific date of their last menstrual period and very few received an early obstetrical ultrasound for more accurate dating. Therefore, in order to permit the lay midwives to record gestational age also using this method, a simple interface with a list of numbers from which the midwife could select the patient’s months of pregnancy was added (Figure 2 - right).

3.1.3 Recording of arterial blood pressure

In the prototype, it was planned to utilize a Bluetooth-enabled blood pressure monitor to transmit blood pressure recordings directly through the application in order to deal with the issues of illiteracy or numeracy. However, a systematic review of the literature raised significant concerns about the ability of all the existing Bluetooth-enabled devices on the market to detect preeclampsia, given that the oscillometric method performs unreliably in preeclampsia [18, 19]. The team therefore opted for the Omron M7, a device with robust clinical validation data in preeclampsia [20], which does not offer Bluetooth capability. Based on feedback from the midwife end-users, the decision was made to record blood pressure readings using the same photographic method already designed for capturing patient photographs at registration (Figure 3). A ‘mask’ simulating the layout of the blood pressure interface was overlaid on the camera screen to ensure the blood pressure (systolic and diastolic) and heart rate (or pulse rate) were readable and captured at a high enough resolution. Although an optical character recognition (OCR), system was planned to digitize the blood pressure readings on the fly and alert in real time, a suitable OCR library for Android capable of accurately digitizing the numeric was not available. This may have been due to the fact that OCR libraries were designed to digitize type face and hand writing, with the natural assumption that digital typeface would already be digitized. A back-end transcription of the blood pressure after upload to the cloud was therefore used instead. The trial will therefore generate a large labeled database of representative images with transcribed data, on which an OCR algorithm can be retrained.

Figure 3. Capturing arterial blood pressure data.

Lay midwives use an automated oscillometric blood pressure cuff (Omron M7), validated for capturing preeclampsic pressures in pregnant women, to obtain blood pressure readings in their patients. These data are then captured within the application using the application’s bespoke camera function and a customized photographic template that maps to the layout of the monitor.

3.2 Product Release Cycle 2

3.2.1 Quality of ultrasound recordings

After expanding the use of the application to a larger pool of users in the second release cycle, initial weekly audits of incoming data from the phones showed that most of the ultrasound recording data was of low quality. The most common quality issues identified were related both to low-quality signals (electrical interference noise, background ambient noises during the recording, and silent recordings) and less frequently, to poor recording techniques (fetal heart rate signal fading in and out, recording of maternal heart rate instead of fetal heart rate) (Figure 4).

Figure 4. Quality of ultrasound data captured by lay midwives using the application over the first seven months.

The proportion of high-quality recordings, low quality signals, as well as recordings affected by data corruption are shown for each month during the second product release cycle.

To address these issues, the project nurse performed accompaniment visits with the lay midwives to identify factors contributing to low data quality. This led to the insight that cabling was the primary cause of problems with low-quality signals. For example, the study nurse observed that cables were not always well inserted into the ultrasound device or the phone, leading to a blank recording or a recording with background ambient noise. A frequent in-field review of the cabling system assembly was performed. Lay midwives whose recordings were often of low quality also participated in additional retraining sessions. Finally, the study nurse used silicon glue to make several of the cabling connections semi-permanent and prevent inadvertent disassembly. Another common mistake identified during accompaniment visits was that lay midwives often erroneously pressed random buttons on the phone interface (home, back, or exit buttons) while in the process of attempting to record ultrasound signal. This would often lead to accidental termination of the recording. To solve this problem, the development team developed code to deactivate all native interface buttons during the recording process. After implementation of these solutions, the proportion of high-quality recordings improved significantly. As shown in Figure 4, the proportion of high-quality recordings increased from 15% in the first month to 61% over the next three months; low-quality recordings were reduced after the third and fourth months when accompaniment visits with the lay midwives took place.

3.2.2 Data corruption

In the first month of the second product release cycle, the majority of ultrasound recordings were corrupted/unreadable when analyzed on the Amazon S3 server. After investigating this issue, it was realized that the data corruption corresponded with a massive loss of internet bandwidth in Wuqu’ Kawoq’s central offices, due to an unanticipated and unannounced infrastructure upgrade by the local telecommunications company. As a result, file uploads over Wi-Fi were frequently interrupted when lay midwives visited the offices for synchronization. To address this issue, the team began copying files from each phone’s SD card to a project desktop computer running a desktop client to the server. In addition, ultrasound-recording acquisition was restructured to allow each 5-minute segment to be saved as a series of separate, smaller files. As consequence, the proportion of corrupted file transfers dropped off rapidly after the first month (Figure 4).

3.2.3 Data loss

In the second product release, patient information collected in the application was transmitted in a graded fashion. Immediately urgent clinical information from complication checklists was pushed to an on-call clinician by triggering a voice call and sending a coded SMS message (a series of alphanumerics that represent the responses to each choice during the use of the app). Subsequently, the complete set of collected patient data, including all raw signal files such as ultrasound recordings and blood pressure readings, were uploaded every 1–2 weeks via WiFi when the participant midwife visited the central Wuqu’ Kawoq offices. Wuqu’ Kawoq medical staff then reviewed data on Amazon S3, transcribed information from Amazon S3 to the central electronic medical record as necessary, and checked for missing data.

By using this review procedure, it became clear that the coded SMS visit summary data was frequently not generated at the close of the visit. Accompaniment of lay midwives revealed that this occurred because, when reaching the end of the patient encounter, many lay midwives were simply turning off or dissembling the phone. Therefore, the application was not recognizing the encounter as complete and was not generating the coded SMS. To solve this issue, a large “send” button was added to the last encounter screen of the application to remind lay midwives to formally end the session. An additional time-out was added at the end of each day as a backstop. Figure 5 shows the monthly coded SMS volume received from the participant lay midwives over the second product release cycle.

Figure 5.

Volume coded SMS sent to on-call clinicians from midwife-generated encounters during the second product release cycle.

3.2.4 Supporting and motivating end users

An important component of the development process was to continue to provide high-quality support and motivation to all of the participating lay midwives, who were required to stay, engaged with a complex and frequently changing clinical application during the agile development period. This motivation was primarily provided by the lead study nurse who provided regular phone support, as well as in-person accompaniment as described above. Figure 6 shows the monthly contact volume between the lead nurse and the participant lay midwives over the second product release cycle, broken into the key categories of patient care coordination, device support and synchronization coordination, and other reasons (such as midwife calling to say no new patients encountered in four weeks, and other non-study related questions). Note the large sustained drop in technical support calls after month 2.

Figure 6.

Application support provided to lay midwives by lead project nurse during the second product release cycle divided by incoming (left) and outgoing calls (right).

4. DISCUSSION

This study describes the iterative design and implementation of a perinatal mHealth technology for a group of largely illiterate indigenous lay midwives with no previous exposure to such a system in a resource-poor setting, using an agile approach. The system comprises an extremely complex set of interacting hardware. During the design and implementation processes, special interest was placed on how the midwife end-user interacted with the system and the clinical support team. Lay midwives’ continuous participation throughout the complete product development and release process was pivotal for success of the project, as measured above by the progressive increase in the number of high quality recordings, progressive increase in number of calls for patient care coordination, and continued use of the system.

Edgcombe H, et al. [21] noted that there is little evidence surrounding the use of mobile-based training apps as potential tools with which to improve access to training for health workers worldwide. Yet little evidence exists on how to do this most effectively, and what success might look like, and they therefore urge developers and clinicians to produce training tools and evaluate them rigorously, in partnership with learners, in order to maximize their effectiveness and improve global health. However, there are very few examples of mHealth systems reported in the literature with the complexity presented in this article for the LMIC context. Further, majority of projects using mHealth systems in LMIC contexts have focused on community health workers as end-users, who often have a higher level of literacy and/or training than the population of lay midwives targeted by this study.

Raghu et al., [22] described an agile system design for an RCT evaluation of an intervention for lowering blood pressure and cardiovascular disease risk in a large (72,000) patient population in southern India, which leveraged traditional healthcare workers. Although the process of design has many similarities, the only novel technology in use was an Android tablet with a bespoke app for decision support. The app was not designed for illiterate users and the referrals were for non-emergency medication. In the study reported here, several unfamiliar pieces of technology were introduced, and no literacy was required to use the technology and system. In the context of perinatal health, there are several studies referencing smartphone apps for use by community healthcare workers. Rotherman-Borus et al [23] reviewed 33 smartphone applications for maternal and child health. Although most are not pertinent to the context described here, several can be considered forerunners. For example, the RESCUER project in Uganda was created to generate a referral system from the traditional rural community health providers to the government health system by enabling calls from traditional birth attendants to the nearest health facility during an obstetric emergency [24]. Rotheram-Borus et al. [25], undertook prenatal and postnatal visits by community health workers [Mentor Mothers] focusing on general maternal and child health, HIV/tuberculosis, alcohol use, and nutrition and conducted an RCT in South Africa. However, none of these works used anything more than standard form input. In contrast to these prior works, the approach presented here combined a novel engineering approach to collecting complex biomedical data, with several other cutting-edge approaches to intervention and system design. The use of an agile approach allowed the research team to promptly identify and iteratively solve multiple technical and implementation issues that arose throughout the course of the project. As anticipated, in the first product release cycle, several issues related to the data entry and device interface were identified and solved (Table 1). Importantly, however, ongoing critical issues related to the device interface were continuously identified (such as inadvertent termination of ultrasound recordings by accidently tapping the “back” or “home” buttons). This experience underscores the need for ongoing, prolonged contact between real end-users in the actual target environment and the development team, especially at points of transition such as expansion to a larger pool of users.

In the extended second release cycle, the most challenging problem was data quality. It was anticipated that lay midwives would have significant difficulty with use of the peripheral monitoring devices associated with the application (pulse oximeter, 1-D ultrasound, blood pressure cuff). Although there were some technical issues here, which were largely solved through ongoing accompaniment and retraining, the largest source of low data quality were hardware issues related to cable assembly. Retraining and support, as well as gluing of some cable connections improved the overall quality of data (Figure 4). However, technical problems remain. Consideration of a redesign of several components of the entire system to reduce the number of cable connections and the complexity of assembly is currently underway. Of course, these issues can be obviated by building a bespoke integrated hardware system, as would be expected prior to regulatory approval for a commercial system. This would also lead to a significant reduction in hardware costs when used at scale.

5. CONCLUSION

Overall, the experience obtained from this project has been that meaningful perinatal monitoring, with decision support and augmentation of clinical backup provided through mHealth technology is feasible in rural Guatemala, despite the overall high rates of illiteracy and lack of technology exposure of the target end-users. Evaluation of the impact of the revised mHealth app and accompanying intervention on important clinical outcomes, such as increased rates of emergency referral to a higher level of care, is ongoing using a two-arm stepped-wedge randomized controlled trial design (Clinical Trials Identifier NCT02348840). Post-intervention exit interviews will be used to determine the effect on patients and community healthcare workers, including potentially higher (or lower) levels of stress and anxiety in the use of new technology, community resistance, family tensions, and other barriers to use and acceptance.

6. ABBREVIATIONS USED

LMIC

Low- and Middle-Income Country

MOH

Ministry of Health

SFH

Symphysis-pubis Fundal Height

WHO

World Health Organization