Menu
Menu
Menu
Menu
Background: Increasing mobile phone ownership, functionality and access to mobile-broad band internet services has triggered growing interest to harness the potential of mobile phone technology to improve health services in low-income settings. The present project aimed at designing an mHealth system that assists midlevel health workers to provide better maternal health care services by automating the data collection and decision-making process. This paper describes the development process and technical aspects of the system considered critical for possible replication. It also highlights key lessons learned and challenges during implementation. Methods: The mHealth system had front-end and back-end components. The front-end component was implemented as a mobile based application while the back-end component was implemented as a web-based application that ran on a central server for data aggregation and report generation. The current mHealth system had four applications; namely, data collection/reporting, electronic health records, decision support, and provider education along the continuum of care including antenatal, delivery and postnatal care. The system was pilot-tested and deployed in selected health centers of North Shewa Zone, Amhara region, Ethiopia. Results: The system was used in 5 health centers since Jan 2014 and later expanded to additional 10 health centers in June 2016 with a total of 5927 electronic forms submitted to the back-end system. The submissions through the mHealth system were slightly lower compared to the actual number of clients who visited those facilities as verified by record reviews. Regarding timeliness, only 11% of the electronic forms were submitted on the day of the client visit, while an additional 17% of the forms were submitted within 10 days of clients’ visit. On average forms were submitted 39 days after the day of clients visit with a range of 0 to 150 days. Conclusions: In conclusion, the study illustrated that an effective mHealth intervention can be developed using an open source platform and local resources. The system impacted key health outcomes and contributed to timely and complete data submission. Lessons learned through the process including success factors and challenges are discussed.
The study was conducted in North Shewa Zone, Amhara region, which is located 130 Kilometers North East of the capital Addis Ababa. Five intervention health centers, each serving an average of 25,000 people, were involved in the study. Health centers are primary health care facilities staffed with midlevel health workers. All intervention health centers were within 10 Kilometers from the main road from Addis Ababa going to North eastern direction, to ensure they have comparable access to mobile phone network. The health service system in Ethiopia is federally decentralized along the nine regions and two administrative city councils. Each of the nine regions is divided into Zones and each Zone into lower administrative units called Woredas, or Districts. Each Woreda is subdivided into the lowest administrative unit, called a Kebele. The health system is organized in three tiers as primary, secondary (General hospital) and tertiary (Specialized hospital). The primary health care level includes a District hospital (which cater for up to 100,000 people) along with a health center and 5 satellite health posts which together serve on average 25,000 people [19]. The health centers are also staffed with Health Information Technicians who are charged with the responsibility of improving the computer skills of the staff in the unit, report health data upwards in the system and extract health data for local use to improve the quality of care [20]. A two-days training was given to 15 health care professionals (3 from each health center) which was repeated every 3 months (2 days each) to refresh their memory and get feedback on ongoing challenges. To ensure that the system would continue to run after the initial pilot period, the project team additionally trained three members of the Zonal Health bureau IT professionals, and two health officials on the basics of the application including designing new forms and setting-up local servers, if needed. Additionally, the team provided two servers and 15 phones as back-up for future use. The original research was approved by the Institutional Review Board (IRB) of College of Health Sciences at Addis Ababa University (Protocol number 040/12/SPH) and findings of the controlled intervention study was published on PLOSONE – available at DOI:10.1371/journal.pone.0158600. Verbal consent was obtained from participants (clients of Antenatal, Delivery or Postnatal Care) after information about the study was given as required by the local IRB. Participants were informed that their participation is voluntary, their information will remain anonymous and that they are free to withdraw from the study at any point in time. The IRB approved verbal consent procedures (without a need for written consent) as it is customary for simple questionnaire surveys without any invasive procedures in an environment where literacy is relatively low. Like other surveys, women 15–17 were considered as emancipatory minors capable of giving consent to the study as per the national Research Ethics Review Guideline – available at http://www.ccghr.ca/wp-content/uploads/2013/11/national-research-ethics-review-guidline.pdf. The datasets used and/or analysed during the current study are available from the corresponding author on reasonable request. The system had front-end and back-end components. The front-end component was implemented as mobile phone-based application that was used by health workers. The back-end component was implemented as a web-based application that ran on a central server for data aggregation and report generation. The user groups interacted with the system through the front-end (mobile phone-based) or back-end (computer-based) applications (Table 2). User groups who interacted with the mHealth system aHealth Officers – are mid-level professionals who receive 4 years of clinical and public health training Health workers interacted with different features of the mHealth system through the Antenatal Care-Postnatal Care (ANC-PNC) mobile based application (Fig. (Fig.2).2). However, two of the system’s features, “Next Visit Scheduling” and “Data Aggregation” did not require user intervention. Rather they were executed based on the system’s internal triggers and conditions. Use case diagram The technical requirements of the system were determined by an IT expert hired for this purpose. The principal investigator provided relevant documents including current data collection forms in health centers, schedule for ANC visits and Expected Data of Delivery (EDD) calculation logics. The IT expert used these documents and additional resources (journal and online articles) to develop the first version of the system as a prototype. Internal system-level testing and integration-testing was conducted by the IT expert to identify and fix issues. The process of development and feedback gathering was repeated iteratively until the system became good enough to move to end users. A similar feedback scheme was used with end users to iteratively update the system based on their day to day work experience. During the first field visit and user training sessions, the system’s functionalities and features were presented to health workers with the intention of introducing the system and gathering more feedback. Content of the electronic forms were reviewed with users to identify missing questions and issues in question sequencing and wording. Iterations of development and feedback gathering were conducted with health workers during subsequent training sessions where users participated in testing the system before it was deployed in a production environment for piloting. Bearing in mind the existing limited infrastructure at health centers, the system was designed and developed by considering the constraints listed out in Table 3 below. Solution constraints and their rationale To fulfill part of the system’s requirement, an open source data collection tool called Open Data Kit (ODK) was customized [21]. The term “open source software” refers to a software that people can use, modify and share because its design is publicly accessible [22]. ODK has three major tools called ODK Build, ODK Collect, and ODK Aggregate. ODK Build is a web-based cloud application that is used to develop electronic forms for mobile data collection. ODK Collect helps users to collect and upload data using electronic forms. ODK Aggregate is a ready-to-deploy web-based server application used as a data repository. It has data visualization and report generation features and provides a means to receive filled forms from ODK Collect and manage collected data. For the current mHealth system, all the three software tools were used to implement part of the system’s requirement. ODK Build was used to develop five electronic forms that were used to collect mother’s health status during antenatal, delivery, and postnatal care visits. In addition, two additional electronic forms were also developed with ODK Build for the baseline and end-line exit surveys among antenatal care clients. ODK Collect was customized to include the following features in order to fulfill the system’s requirement; ODK Aggregate was used for data aggregation at the central server. Additional features that were required from the system were developed as a separate web-based application and interfaced with ODK Aggregate at database level. The newly developed features that were implemented in the web platform developed for the purpose included: The system had a client-server architecture that used mobile phones at the client side and a web-based application on the server side. At the client side, health workers could use the mobile application to interact with the server system at Addis Ababa University server center. The interaction between the client and the server systems was through Ethio-Telecom’s GPRS connectivity. The system’s high-level architecture is shown in Fig. 3. High level System Architecture The system was designed to work in an offline mode, so that collected data could be saved in the mobile phone’s internal memory until network connectivity was available. A mobile phone model with longer battery life was selected to run the front-end application for longer periods of time without requiring frequent recharging. At the back-end platform, health professionals and/or supervisors working at the Zonal Health Office could interact with the mHealth system using their personal computers. It is worth noting that health officials were able to monitor the activities of health workers from the back-end application, which helped them to make timely decisions based on reports submitted by health workers. The front-end application was developed as an android-based mobile application. An android operating system was chosen because of its capability to be localized and customized easily. The front application’s main menu is shown in Fig. 4a. Whenever there was network connectivity, the form could be sent to the main server by using “Send Finalized Form” option (Fig. 4a). Whenever the application was launched, it automatically displayed a reminder about list of pregnant women who had a scheduled visit for the following 7 days. Pregnant women’s next visit schedule was computed by the back-end application, so that health workers could get the schedule from their front-end mobile application. The visit schedule reminder dialog box that was presented to health workers is shown in Fig. Fig.4b.4b. Once the form was filled and finalized, the collected data was saved in the mobile phone’s memory. a Appointment reminder; b Mobile application’s main menu When a new visitor came for antenatal care, the health worker was expected to use the first form labeled as, “Classify-Follow up”. As shown in Fig. 5a, the system asked whether the visit was made for the first time or whether it was a follow-up visit. Based on the user’s response, an appropriate form was opened. As shown in the sample case, a classification form, “ANC-Classify” was opened by the application (Fig. (Fig.5b)5b) to collect the pregnant woman’s health status and to decide whether or not she required basic or specialized care (Fig. (Fig.5c).5c). This classification was made by the system itself based on the pregnant woman’s previous and current medical and obstetric history. a New or follow-up visitor; b Example of questions used to classify women; c Suggested classification by the system If the woman came for a follow-up visit, her previous visit status could be downloaded from the back-end system. This downloaded list of visit status contains a list of pregnant women who are expected for a follow-up visit (Fig. 6a). Then based on the woman’s last visit status, an appropriate form was proposed by the system for the current visit (Fig. (Fig.6b),6b), so that the health worker could fill-in relevant data about her current health status and report the data to the back-end system (Fig. (Fig.6c).6c). Note that names shown below are random names used for demonstration/training purposes and do not refer to actual women who participated in the study. a List of pregnant women expected for follow-up visit, b Proposed current visit form for selected woman, c Pregnancy Follow-up form for selected woman Health workers could also generate reports from their front-end application. In order to do so, the front-end application interacted with the back-end system to get the pregnant woman’s visit report for a given date range. This feature helped the health worker to easily compile what s/he had accomplished during a given period. Figure 7a and andbb shows report generating feature of the mobile application. a User Interface to select date range for report. b List of pregnant women who visited during a given date range (visit date, type of visit and round of visit) A health worker could also get educational messages from the main server through the front-end mobile application. Educational messages were posted in the back-end system, so that health workers who had access to the front-end mobile application could read the content on their mobile phone (See Fig. 8 for sample educational message on common complaints during pregnancy; namely, vaginal discharge). This feature helped health workers to refresh their knowledge about common complaints during pregnancy and danger signs during pregnancy and delivery. User interface to view educational message Back-end users could interact with the system with their personal computer (with internet connectivity) from anywhere. The ODK Aggregate application had a capability to present aggregated content in a tabular and chart format. In addition, for records with GPS coordinates, reported data could be shown in a map. Figure 9 below shows aggregated data of mother’s status during their delivery which can be exported as excel file, while Fig. 10a and andbb show reported data in a map and chart view respectively. Aggregated mother’s delivery detail when viewed with ODK Aggregate a Aggregated data viewed in a map (Map data ©2018 Google), b Bar chart to show proportion of mothers that require basic care and specialized care To support more back-end functionalities, a separate web-based application was developed and interfaced with ODK Aggregate at the database level. This web-application helped back-end users to view and analyze visit history, visit schedule, and to generate more reports. In addition, users could upload educational messages for health workers from this web-application. Figure 11 shows additional functionalities of the back-end application. Additional functionalities of the back-end application
N/A
