Electronic data capture for large scale typhoid surveillance, household contact tracing, and health utilisation survey: Strategic Typhoid Alliance across Africa and Asia [version 2; peer review: 2 approved, 2 approved with reservations]

Electronic data capture systems (EDCs) have the potential to achieve efficiency and quality in collection of multisite data. We quantify the volume, time, accuracy and costs of an EDC using large-scale census data from the STRATAA consortium, a comprehensive programme assessing population dynamics and epidemiology of typhoid fever in Malawi, Nepal and Bangladesh to inform vaccine and public health interventions. A census form was developed through a structured iterative process and implemented using Open Data Kit Collect running on Androidbased tablets. Data were uploaded to Open Data Kit Aggregate, then auto-synced to MySQL-defined database nightly. Data were backed-up daily from three sites centrally, and auto-reported weekly. Pre-census materials’ costs were estimated. Demographics of 308,348 individuals from 80,851 households were recorded within an average of 14.7 Open Peer Review


Introduction
Use of electronic data capture systems (EDCs) for health research has increased since Apple's launch of the first handheld device in 1993 1 , and for observational studies and clinical trials is beginning to replace paper-based data collection methods. Paper-based systems have the advantage that they provide a hard copy source document but are characterised by high inaccuracies, substantial omissions, longer data turnaround time, longer data entry time, and high incremental costs both during the data collection and subsequent entry into an electronic database 2-6 . The advantages of EDC include built-in global positioning system (GPS) locator that automatically capture geographical coordinates thus minimizing transcription errors from external GPS locators; password-locked tablets and data encryption that maintain participant data confidentiality; required checks that prevent data omissions; range checks and data type checks that prevent typographical errors; skip patterns that provide logical responses; barcode technology that automates entry of unique identification; timestamps that provide a means to monitor work rate; and internet connectivity that ensures availability of real-time data 3,4,7,8 . Despite these benefits 9 , there is limited description of the performance of EDCs for large-scale or multisite surveys in low and middle-income countries.
Each year, an estimated 9.9-24.2 million typhoid fever cases occur from low-and middle-income countries resulting in approximately 75,000-208,000 deaths 10,11 . However, although essential to build a public health case for disease control efforts such as vaccination and provision of clean water, sanitation and hygiene, obtaining reliable estimates for the burden of disease at national and sub-national level is difficult 12 . This requires collection of high quality field demographic, mapping, epidemiological, and clinical and laboratory data at scale from both hospital and community-based survey studies 13 . Interestingly, the collection of such quality data is hindered by complexities of dilapidated health facilities, overcrowding, unstructured housing or slums, and illiteracy, poor internet connectivity during data submission to servers, poor road networks, poor supervision of data quality control and assurance 14 .
To address some of these data quality complexities in poorresource settings, we have adopted to using an open sourcebased EDC, and evaluate the efficiency, quality, and costs of the EDC by measuring volume, time, accuracy, and material costs using multisite census data collected from sub-Saharan Africa and Asia 15 . The EDC was developed and implemented within the Strategic Typhoid alliance across Africa and Asia (STRATAA), a comprehensive programme which is assessing population dynamics and epidemiology of typhoid fever in Malawi, Bangladesh and Nepal to inform design of vaccine and public health interventions.

Implementation
The census component of the STRATAA study aimed to collect demographics from approximately 100,000 individuals, of all ages, in each of the three sites, to form the sampling frame for subsequent sub-studies. More details of the STRATAA study design and participants have previously been described 13 . In brief, the three sites, one in each country, were selected based on high known burden of enteric fever, differing epidemiological patterns and previous ability to deliver paper-based studies of high participant volume and logistical complexity.
An electronic census report form (eCRF), uniform to all sites, was developed through a structured iterative process. An eCRF comprised household-and individual-level questions. The eCRF data fields reflected a range of data types including integers to capture census team identifier, interviewer identifier, phone numbers of key respondent and older household members, household member number, and age; decimal to capture GPS points; alphanumeric to capture household unique identifier (barcode); texts to capture ward/traditional authority name, community/district name, physical address, respondent name, respondent relationship to head of household, respondent position in the household, head of household name, household member name, household member tribe/ethnicity, household member relationship to head, marital status, spouse name, education levels, employment status, mother's name, and father's name; characters to capture study site, household occupancy status, consent status, study information access status, sex, and school attendance status; and dates to capture household visit date and date of birth of each household member (Figure 1) 15 .
To ensure ultimate generation of error-free data, the eCRF data fields were designed with quality control tools, such as dropdown menus, range checks, choice fields, skip patterns, required checks, double-data entry checks, systematic auto-numbering (automatic assignment of sequential numbers), preloading (loading existing information from the tablet), and looping (repetition of a sequence of operations until condition is met). However, due to other internal and external limitations of the EDC, we further built external database queries based on the Structured Query Language (SQL) to track potential data entry errors that might have arisen beyond EDC's control. External SQL queries were aimed to expose persistent

Amendments from Version 1
A few sentences have been added to improve the manuscript reading which include other problems related to data collection in low income countries, clear objective of why we conducted this study, definition of technical terms, potential reasons for differences in census uptake numbers between sites, potential reasons for the difference between our EDC performance and those reported by others, and other unmeasured costs related to implementing our EDC.
Any further responses from the reviewers can be found at the end of the article error sources which included duplication of study household identifiers (barcode); duplication of entire individual demographics; barcode decoding errors during scan; illogical ages or date of births of children relative to parents; incorrect household visit dates relative to tablet system date; misspellings of traditional authority names/ward numbers, physical addresses, respondent names, and household members names; missing GPS points; inaccurate GPS points relative to the household; and mismatches between community names and GPS points. After running the external SQL queries on the census database table and identifying the errors, each correction of an error by the data officer triggered an automatic log to an audit-trail table with entries (table's column names) that included table name with error, action on an error (update, insertion, or deletion), individual/household barcode identifier with an error, field name with an error, old value, new value, timestamp, and a user's name modifying an error. This generated a single row in an audit-trail table for each single error that was modified in the original census table. Errors corresponding to GPS points were specifically identified through sub-setting and importing GPS points (longitude, latitude, and altitude) from the census table into Google Earth Pro software v7.3.2 (Google LLC, Mountain View, California, USA) as a keyhole markup language file, and then mapping the GPS points on the overlay of community boundaries' and households' satellite images. Once a GPS point was not mapped within 5 meters at 10% accuracy of the household or within the community boundary, it was considered a mapping error, and corrected through remapping in the field and updating it in the census table thereby triggering an audit-trail table error record. All the other errors exposed by the external SQL queries were investigated thoroughly in the field before corrections could be applied to the census table and subsequently auto-logged into the audit-trail table. The maximum number of visits to the household prior declaring the household vacant or errors permanently unresolved was twice. We show the flow diagram of the eCRF in (Figure 1), whereas the technical details of the extensible markup language code used to create an eCRF, and the SQL code used to create the audit-trail table and triggers to the audit-trail table have been publicly shared through GitHub (GitHub Inc, San Francisco, California, USA) 15 .

Operation
We designed a uniform EDC using combined open-source tools; Open Data Kit (ODK) software v1.4.16 (Nafundi, Seattle, Washington, USA) 16-18 , and MySQL relational database management system v8.0.1 (Oracle Corporation, Redwood city, California, USA) 19 . The eCRF was customized in ODK Collect and uploaded onto Android-based Asus ZenPad (AsusTek Computer Inc., Taipei, Taiwan), and Samsung (Samsung group, Seoul, South Korea) tablets. Then data were collected in the field during the day and temporarily saved in the tablet's memory. At the end of each day, tablets were returned to the base STRATAA data office and data were uploaded from the tablet's memory to ODK Aggregate server via a secure wireless network technology. Tablets were then charged overnight at the base data office in preparation for use on the next day. For every scheduled time of the night, data automatically synchronized from ODK Aggregate server to MySQL-defined database, set up for four main reasons; first, to facilitate corrections of inconsistencies beyond ODK validations (e.g. all persistent error sources mentioned above) and auto-audit the corrections; second, to ensure homogeneous database structure across sites in order to facilitate multisite dataset merging, and to preserve meaningful variables (excluding metadata generated by ODK software) in order to provide intuitive datasets to epidemiologists and statisticians; third, to generate automated reports using SQL; and last, to allow automated back-up of cleansed data from MySQL-defined database to external storage devices. The EDC also allows daily comma-separated value and anonymized data format to securely and automatically synchronize from each site's ODK Aggregate server to a central repository. Conversely, the comma-separated value data format, from MySQL-defined database, were sporadically exported back to tablet's ODK media folder to enable data preloading for sub-sequent sub-studies ( Figure 2). Technical details of the scripts for synchronizations, and creation of table structures and triggers have been publicly shared through GitHub 15 .

Pre-census time, costs, and training
We estimated time and costs required to attain the following census-related materials or complete census activities; tablets (including screen protectors, and protective covers), desktop server computers, network devices, barcodes, development of eCRF, training of field workers, replacement of broken tablets, and backpacks. We did not assess other operational costs because of uncertainty e.g. electric power to servers, charging tablets, and electronic data synchronization. We trained fieldworkers and assessed their suitability to conduct census by administering a practical mock test and then selecting best performers. Moreover, five weeks post-census implementation, we retrained fieldworkers based on calculated individual performances on data quality and data collection speed.
Ethics approval and consent to participate. Ethical approval was obtained from the Malawi National Health Sciences Research Committee, 15/5/1599; Bangladesh ICDDR,B Institutional Review Board, PR-15119; Nepal Health Research Council, 306/2015; and Oxford Tropical Research Ethics Committee, 39-15. Following extensive sensitisation and engagement with community and traditional leaders, and community health-workers, the key informant from each household provided a verbal informed consent, to enumerate the household, which was documented in the eCRF.

Statistical analysis and visualization
We estimated the error rates, after running external SQL queries but prior to data cleaning, by dividing the total number of errors observed by the total number of data points (≈ all expected errors). A data point was defined as a discrete unit of information that could possibly be obtained from each member of the population after administering an eCRF e.g. If an eCRF had (n) number of unique questions, with each question corresponding to a variable (X i ), for (N) number of respondents, then the total data points for eCRF would be ( ) In our calculations, data points for household-and individual-level variables were calculated separately and summed up. The reason was that household-level questions were answered by a key informant (head of household Figure 2. Electronic data capture system for a multisite study. MySQL-defined databases b_strataa, k_strataa, and d_strataa have homogeneous structures (*) e.g. table columns, data types, triggers or views. Data from MySQL-defined database table are exported back to Android-based tablet enabling data preloading for subsequent sub-studies (P). Homogeneous databases across sites merge enabling multisite data analyses (H).
or respondent ≥ 18 years old), while individual-level questions were hypothetically answered by all household members (represented by a key informant). Exact binomial confidence intervals were used to estimate error rates. Data entry speed and accuracy by fieldworkers were combined into a single merit in order to measure their performance 20 . For each fieldworker, we standardized the data entry speeds (z s ) and errors (z e ), and assigned more weight to data entry speed (60%) than errors (40%) given the background that the EDC was robustly developed to prevent most data entry errors, thus, speed was more important. The final data entry speed-accuracy trade-off was calculated using the formula (SAT = −z s * 0.6 − z e * 0.4) where z s = (s − μ s )/δ s and z e = (e − μ e )/δ e , (s) is the total speed for all data entries per field worker, (μ s ) is the mean speed for all fieldworkers, (δ s ) is the speed standard deviation, (e) is the total number of errors per field worker, (μ e ) is the mean error for all fieldworkers, and (δ e ) is the error standard deviation. In addition, we used Wilcoxon Signed-Rank Test for paired samples pre-versus post-retraining in order to measure any statistical difference in the number of errors committed, and determine whether retraining the fieldworkers helped improve accuracy. All statistics and plots were conducted in R v3.4.0 21 , eCRF flowchart and EDC diagram were created using www.draw.io (JGraph, London, England) v6.4.2.
An earlier version of this article can be found on the pre-print server for health sciences, MedRxiv 22 .

Data collection volume, time and accuracy
We recorded demographics of 308,348 individuals from 80,851 households in three countries between June 2016 and October 2016; 97,410 individuals and 22,364 households from  (Figure 3). The maximum number of visits to the household prior declaring the household vacant or errors permanently unresolved was twice.

Time and cost of census materials
The time required to attain each material or complete each activity in preparation for census implementation varied by study site, ranging from 2 to 60 days. The most time-consuming activity was the development and customization of eCRF, which was completed in 60 days collectively. This was followed by the procurement of tablets and backpacks, which were acquired in between 7 and 60 days. In addition, we also procured and designed household identifier (barcode) stickers in between 7 and 21 days. Replacement of malfunctioned tablets reported by each study was accomplished within 30 days. We extensively trained our study fieldworkers for up to 5 days focussing on the study protocol, practical aspect of completing an eCRF, and community engagement skills. Selection of potential fieldworkers to join the study team was sorely based on successful completion of the training. Computer servers and network devices to enable data storage and transfers from tablets were pre-existing in Malawi and Bangladesh, and newly acquired in Nepal within 30 days (  (Table 2).

Discussion
In this study, we have developed and implemented an EDC which allows high volume of data collection over short time periods, high data accuracy, 12-hourly updated data access, and quality checking for decision making 15 . Additionally, the EDC is robust, allowing for automated reports generation, scalability and could be adaptable to other epidemiological settings. Finally, the total variable cost of the EDC's pre-census materials and activities, was minimal relative to paper-based data collection methods from similar settings.
Data were collected by largely secondary school level only fieldworkers receiving 1 week of training and a day of retraining, and although the learning curve of using an eCRF in ODK Collect on Android-based tablets was steep in the first 5 weeks of field work, high volume and fairly accurate data were recorded (Figure 3 and Figure 4)   Ŧ Only 1 uniform eCRF was developed for 3 sites, for purposes of calculations, we divide the total cost by 3. § Some tablets already existed in other sites. Similarly, network devices and computer servers pre-existed in Malawi, Bangladesh, and a central coordinating site (Oxford Vaccine Group) but not in Nepal.
** Excludes costs of electric power to servers, charging tablets and data synchronization because of uncertainty.

US$ United States dollar currency.
eCRF generated more errors than numeric fields, and suggest that such errors could be prevented in eCRF designs by minimizing the use of text fields through coding of text responses or leaving out insignificant text responses completely. The accuracy variations between EDCs are probably due to robustness of the EDC design in terms of error proofing. Robustness in the design is likely to depend on the limitations of software and hardware, and technical know-how of developers. Our accuracy comparisons to other studies may be limited by the technologies used, non-systematic review of included EDC studies in low-income settings and time period when these studies were conducted.
Household data collection completeness against the baseline count was 20% higher in Malawi than in Bangladesh and Nepal despite two household visits across sites before declaring the household vacant. This observation may have been driven by more refusals, unavailability of respondents, or vacant households.
Unlike the EDC and paper-based methods used in a similarly setting 29 , our EDC synchronized study data updates at least every 12 hours post-data collection in order to provide recent data accessibility for decision making; Rapid accessibility to recent data has enabled immediate quality checks and data cleaning on critical variables which, at the time of the study, are beyond ODK's built-in validations. It also enabled us to quickly understand and decide on ways to improve participant uptake rates, adding to a growing body of literature reporting how rapid data updates by an EDC enable swift decisions 9,30,31 .
The EDC was also designed to counteract some complexities associated with data collection in low-and middle-income countries; Internet connectivity was through a client-server system where data capture client (ODK Collect) was an offline stand-alone instance separated from the database server (ODK Aggregate). Data were synchronized from client to server at a later point in time at the base STRATAA data office where connectivity was possible. This approach has also been recommended by others 32,33 , and we did not experience any damage or theft of the tablets which led to data loss before data was synchronized to the database server. Our approach ensured that the field workers could reach data offices daily, where internet connectivity was stable, to enable data uploads to server and this may not be a practicable scenario in some low-income countries. We adhered to a practice of disabling eCRF 'edit' options, post-interview, in order to maintain data integrity in the field. Validations within the ODK Collect prevented most errors. However, 0.4% duplicate household identities and 0.3% missing GPS points were uncovered in addition to other text and numeric errors. Following good data management practices 34 , our EDC also provided three backup strategies; scheduled data synchronization to (i) centralized repository, (ii) MySQL-defined databases, and (iii) scheduled incremental backup of MySQL-defined databases to external storage devices.
The EDC delivered considerable capacity for automated report generation, scalability and adaptability. We were able to use SQL to pull seasonal data from MySQL-defined database, and automate summaries of demographics in order to monitor progress of field work, and collective and individual performance of field workers. SQL was preferred because of its simple but powerful syntax, and its wider use in handling complex queries to epidemiological datasets 23,25,30,33 . Since the STRATAA consortium continuously generates laboratory data, post-census, the EDC also allows scalability, pushing laboratory data from laboratory database systems to MySQL-defined databases while keeping the database structure homogeneous across sites. This will be useful for future analysis of EDC's accuracy using data generated from other STRATAA study components. The EDC could therefore not only be adopted by others collecting large data volumes requiring centralized data storage and automation of process, but also be tested by settings with little experience in conducting field-based research. The EDC is installed in three typhoid endemic settings and will be maintained by STRATAA consortium for adaptability of potential future studies.

Conclusion
In conclusion, we have designed an EDC which has been implemented in three typhoid endemic sites to collect large volume of accurate data in short time periods with rapid access through automated reports. The EDC's development required careful attention to detail but the materials' variable costs prior to census implementation, were minimal relative to some EDCs and paper-based data collection methods. This EDC could be adopted in similar epidemiological settings, enabling the collection and management of large data volumes, centralize data storage, and automated data processes where adequate funding, staffing and transportation are readily available.
File '8.strataa_s1_s2_figures.csv' contains raw data on error rates, errors before and after retraining field workers, and data entry performance.
Data are available under the terms of the Creative Commons Zero "No rights reserved" data waiver (CC0 1.0 Public domain dedication).
License: GNU General Public License version 2.

Consent for publication
Not applicable.

Open Peer Review
Division of Gastrointestinal Sciences, Christian Medical College, Vellore, India Electronic data capture is essential for clinical research. Data quality has been an issue, particularly where field staff with limited education are responsible for data capture. The authors have described how they built an eCRF using Open Data Kit and MySQL and deployed it for capturing data from over 300,000 individuals from 80,000 households.

○
The group collected baseline data from households for a census with an error rate of less than 50 per 10,000 in all three sites. Expectedly, text fields had more errors. While low, the error rate in Nepal was almost double other sites. It would be useful to know whether there were specific fields that were problematic in one location and not others? Or whether the errors were distributed evenly across field staff?

○
A key issue with electronic data capture is the availability of internet access and the group has addressed the combination with offline collection and twice daily uploading. It would help to have clarity on whether there are country-level regulatory/legal issues with the data being hosted with the Oxford Vaccine Group? ○ While this was not included in the scope of the paper, the authors' comments on whether baseline census information data collection accuracy was comparable to data collected during follow-up or plans for future analysis would be helpful.

Is the rationale for developing the new software tool clearly explained? Yes
Is the description of the software tool technically sound? Yes

Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed.

Reviewer Expertise: Public health
I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.
time/cost for transportation, stable WiFi, electricity, and GPS signals. In summary: where adequate core funding, staffing, and transportation are readily available, the EDC system presented by the authors is likely to be readily adaptable as an upgrade to paperbased or out-moded electronic systems at a reasonable cost.

Is the rationale for developing the new software tool clearly explained? Yes
Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes

Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Partly Reviewer Report 02 September 2020 https://doi.org/10.21956/wellcomeopenres.17339.r39897 © 2020 Gauld J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Jillian S Gauld
Institute for Disease Modeling, Seattle, WA, USA This paper provides an excellent overview of a substantial electronic data capture system, implemented in three different locations.
I appreciate the detailed tables and schematic figures, as well as the cost and timeline data being published. This study would be very helpful for other settings deciding on whether to implement such a system, and identify potential issues to be aware of.
However, there is a narrative challenge throughout the paper. It is unclear after reading through the introduction, what the purpose of this particular paper was. Is it a summary of a novel tool? If so, what is novel about it as compared to other EDC's? Or, if this is a descriptive study of a large scale implementation of an electronic system, what other large scale surveillance studies have failed to report this type of accuracy data, and how does this impact the quality of research? I think it would be helpful to the reader to more thoroughly ground the paper in a very clear introduction and purpose.
Similarly in the discussion, I appreciated the comparison of the EDC's costs and accuracy to other systems. However, there is only a limited discussion of what might be driving these differences. For example, are the different error rates driven by the rate of text-based data entry, or the type of disease being surveiled? For costs, are all of these studies geo-locating individuals? Investigating these differences further would very much strengthen the discussion and conclusions made.
For Figure 3, I am not sure this is displayed correctly, or I may be misunderstanding what is being displayed. It appears that the post-retraining error is 1 minus the pre-retraining error for each field worker. Presumably some field workers may benefit less than others from the re-training? Some more minor comments:

Methods
Paragraph 2 of the methods seems to be summarized at least partly in Figure 1, so would remove.
○ Some of the terms (preloading, looping) not obvious to a general audience, can you define?
○ "All the other errors exposed by the external SQL queries were investigated thoroughly in the field before corrections could..." This section was a bit unclear -what are the other ○ errors? Any non-GPS errors, or those that couldn't be auto-corrected through the SQL script?
"The maximum number of visits to the household prior declaring the household vacant or errors permanently unresolved was twice." Would move this to results.

○
The operation and implementation sections could be switched in order in the paper.

Discussion
The first time I see the 12 hour upload frequency is in the discussion unless I missed it, this should be in the methods somewhere. For Figure 3, I am not sure this is displayed correctly, or I may be misunderstanding what is being displayed. It appears that the post-retraining error is 1 minus the pre-retraining error for each field worker. Presumably some field workers may benefit less than others from the re-training? Response: It interprets as the proportion of all errors committed per fieldworker e.g. if fieldworker 1 committed 10 errors pre-retraining and 5 errors post-retraining then 10/15 (67%) for pre-retraining and 5/15 (33%) for post-retraining are the % errors.
Paragraph 2 of the methods seems to be summarized at least partly in Figure 1, so would remove. Response: In the spirit of keeping manuscript text independent from figures, we were previously advised by a reviewer to include the text in case some readers don't have to check Figure 1. It also needs to speak more on the challenges and limitations especially in real time data updates to servers in low income settings where network remains an issue, collecting data and the assumption that dilapidated facilities etc. are justification for poor data is not proven and does not hold true.
A 12 hour regular synchronization is really not feasible in our setting esp. Africa.
Once these issues are addressed the paper should be considered for indexing.
I have some specific comments that can be found in the PDF file here which need to be addressed.

Is the rationale for developing the new software tool clearly explained? Partly
Is the description of the software tool technically sound? Yes

Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Partly from previous ECDs, and leaves room for bias with facilities chosen for previous good performances. It also needs to speak more on the challenges and limitations especially in real time data updates to servers in low income settings where network remains an issue, collecting data and the assumption that dilapidated facilities etc. are justification for poor data is not proven and does not hold true. Response: (a) We report a new application of an existing open source software platform. We show how this electronic system can be built and how it can be deployed to improve quality of huge volumes of data collection from across poor-resource settings, globally. We have amended the text accordingly. This manuscript is targeted at researchers who are considering adopting EDC. We have not formally compared our EDC with other systems, because this would require another large-scale census which was not feasible.
(b) The selected study sites have considerable experience of paper-based data collection systems but no prior experience of using ODK at scale, particularly in high-density urban slums. The field workers using the EDC frequently had little prior experience of data collection. We have amended the text accordingly. (c) We agree with the reviewer that network interruptions could render EDC impractical, although network coverage and stability is improving in many resource-limited settings. To avoid this potential barrier to implementation, synchronisation between tablet and server was done at the data office, not in the field, and typically at night when connectivity was stable. d) Contrary to the Reviewer's comments, we have presented the limitations of our system in the manuscript. These include errors from (i) using text fields, (ii) not retraining field workers for better performance or due to field worker steep learning curve, (iii) lack of knowledge and skills required to develop and manage the ODK-SQL apps, (iv) limited built-in functionality of ODK e.g. lack of detection of duplicate barcodes for individual IDs when scanned, (v) lack of ODK built-in GPS validations relative to map boundaries.
A 12 hour regular synchronization is really not feasible in our setting esp. Africa. Response: On the contrary, one of the benefits of this system is that 12 hourly synchronisation was feasible. We describe a protocol whereby Android tablets were given out in the morning and returned in the late afternoon by field workers on a daily basis for collection and submission of data. We also provide datasets that have timestamps of data collection and submission for your review. (Lines 159-164) Is the rationale for developing the new software tool clearly explained?, Partly Response: The last paragraph of the introduction has been revised to make clear the purpose/rationale of developing the EDC (Lines 80-89).
Is the description of the software tool technically sound?, Yes Response: Thank you.
Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others?, Yes Response: Thank you.
Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool?, Yes Response: Thank you.