PHIA questionnaires were programmed in Open Data Kit (ODK; Seattle, WA) open-source software on encrypted Google Nexus 9 Android tablets (HTC Corporation; New Taipei City, Taiwan). The PHIA programmers coded various features to facilitate high-quality data capture. This included a routing structure capturing eligibility of rostered individuals and their data nested within a household on a master tablet used by team leads; the roster was transferred from the master tablet to interviewer tablets assigned to each eligible individual, allowing for multiple interviewers to work in parallel while preserving the roster. In addition, multiple data links were programmed, including linking the individual interview data to the roster data by household identifier so that all eligible individuals were associated with a selected household; linking by roster line number for quality control purposes to compare responses provided in the household questionnaire with the individual questionnaire; and linking by roster line number between sexual partners, parent/guardian and child, and mother and child to facilitate paired analyses.

During the interview process, several tablet features were leveraged to ensure integrity of the selected household sample and household-level and individual-level data. First, Global Positioning System data were recorded to confirm selected households; the consent forms signed on the tablet’s screen were stored as images to keep an audit trail of appropriate consenting practices; and randomly generated participant identifiers (PTIDs) were assigned using scannable preprinted quick response barcodes, which were then scanned using the camera on the tablet and affixed on specimen tubes to minimize data entry mistakes and ensure linkage between questionnaire and specimen data. High accuracy in the linkage between questionnaire and specimen data was essential for timely return of laboratory-based biomarker results, such as VL, to participants. Completed questionnaires were uploaded daily to the ODK server in the DWH (Fig. 1, arrow 1).

Blood specimens were collected from consented participants for HIV and other rapid tests (detailed elsewhere¹⁰), with results recorded in the tablets. CD4 counts for all specimens showing positive results for HIV and a random sample showing negative results for HIV were measured using the Alere Pima Analyzer (Abbott, Abbott Park, IL) and uploaded to the secure Alere server using a vendor-provided modem (Fig. 1, arrow 2).

Blood specimens from the field were sent daily to PHIA SLs set up within on average 2 hours of driving distance from households, along with specimen tracking forms containing PTID labels and specimen information. PTIDs affixed to the specimen tubes were scanned into the LDMS laboratory information management software (Frontier Science, Boston, MA; Fig. 1, arrow 3), and the participant’s household HIV test result and blood draw time also were entered.

LDMS assigned a specimen ID to each expected aliquot (subspecimen), producing scannable labels. At all data entry points, PTID and specimen barcodes were scanned for accuracy. If any aliquots were not produced, because of a short draw or unusable specimens, reasons were recorded into LDMS to help track specimen quality. Freezer locations and freezer entry times for each aliquot also were saved in LDMS.

The Test Results Entry Module was developed specifically for the PHIA surveys to track which specimens required repeat rapid tests for quality assurance (QA) or confirmatory Geenius testing (Geenius HIV 1/2 Supplemental Assay; Bio-Rad, Hercules, CA). The module selected specimens for QA and Geenius testing based on survey-specific algorithms and generated worksheets to record the results. The results were entered into the test results entry module using validation and drop-downs to simplify data entry.

Daily, SLs securely uploaded data to the DWH in access zone 2. The data included the LDMS data through its export function (Fig. 1, arrow 4), transferring inventory and testing records to Frontier, and Geenius results extracted as comma-separated values (CSV) files (Fig. 1, arrow 5).

Weekly, specimens were shipped from the SL to the CL, with a flash drive containing encrypted LDMS inventory and freezer box location data (Fig. 1, arrow 6). When specimens were shipped, shipping dates and destination were recorded, allowing for full accountability of specimen quantities, quality, and location. Importing data into the CL’s instance of LDMS provided a local inventory of received specimens, without handling and recording each specimen. CL LDMS exports (Fig. 1, arrow 7) informed the survey team that the specimens had arrived. The CL uploaded HIV VL results (Fig. 1, arrow 8) weekly to the secure File Transfer Protocol (sFTP) server. Additional laboratory-based biomarker test results (Table 2) also were uploaded from reference laboratories (Fig. 1, arrow 9).

The PHIA DWH was a secure repository for all survey data, including data pulled from the Alere server (Fig. 1, arrow 10), the ODK server (Fig. 1, arrow 11), and LDMS/Frontier (Fig. 1, arrow 12), along with tools for merging, analyzing, and sharing data (described further).

Automated processes extracted data collected in the field (excluding laboratory-based data) from the ODK PostgreSQL¹¹ (Postgres) database daily to approximately 50 raw SAS (SAS Institute, Cary, NC) data files, stripping personally identifiable information (PII), to make the data shareable with the survey management team. The 50 raw files were merged based on links described earlier, producing easy-to-use analytic data sets. These data sets were uploaded and were updated daily, reflecting corrections made to the master change log containing all QA data corrections submitted from the field on an ongoing basis, including but not limited to missing household and individual survey outcomes, broken links between households and individuals, and missing biomarker data (see the “Dashboard and Monitoring” section further). These data sets were used by the survey management team to conduct ad hoc analyses to investigate survey implementation issues, such as low response rates, performance of certain questions, and any errors in consenting processes. The latter was performed at least twice during each survey by an external monitoring group to ensure compliance with all screening and consenting procedures as specified by the protocol. PII was managed by extracting data separately from the Postgres database and storing it in a restricted area with limited access by data management staff, who signed confidentiality agreements, to resolve data discrepancies.

The DWH transferred raw and cleaned extracts of the ODK data to an in-country Ministry of Health server daily (Fig. 1, arrow 13), providing the most recent version of the PHIA data. Final survey data, including all laboratory-based data, were also transferred to the Ministry of Health (Fig. 1, arrow 14). The sFTP server in the DWH shared these raw and corrected data sets, VL and Geenius results, and process files, such as orders for laboratory testing.

As mentioned earlier, this core architecture was customized to address country-level variations in data governance rules and practices, existing information infrastructure, human resource capacity, and national testing guidelines (Table 2). For example, existing information infrastructure in Kenya, Namibia, and Rwanda allowed for primary servers to be hosted in-country. Elsewhere, infrastructure was not easily available and ready for use within the survey budget.

VL testing and transfer of results also differed (Table 2). In most of the countries, VL results were shared in CSV format exported directly from the testing instrument. In Cameroon and Haiti, the instrument produced a CSV format with different column headers, 2 lines for each result, and certain columns presented in an initial stanza of common information. Furthermore, in Zimbabwe and Lesotho, the testing instrument was integrated with each CL’s laboratory information system, and the results were shared as Extensible Markup Language (XML) and CSV extracts, respectively. Third, although VL results were always returned, some countries had an additional laboratory-based testing that needed to be returned. For example, in Côte d’Ivoire where HIV-2 is prevalent, the differentiation of HIV-1 and HIV-2 infection was only made at the laboratory; the results were required to be returned to participants. In Kenya and Namibia,¹² GeneXpert (Cepheid, Sunnyvale, CA) was used for preliminary early infant diagnosis with CL confirmation because regional laboratories where SLs were hosted had existing capacity to run the tests. Each of these tests types was an additional data source for data collection and processing.

Twice a day, DWH files were automatically curated, a process that standardized file names, variable names, and formats and organized files in specific folders. Files of the same type were merged in a multicountry laboratory database using Postgres and programs written in C# (Microsoft; Redmond, WA) and then output as CSV analytic data sets for use in SAS, Stata (StataCorp, College Station, TX), or Excel (Microsoft). For example, for different VL result formats described earlier, the laboratory database merge code mapped key fields into a single format that was standardized across all surveys.

A staging database excluding all PII was set up in Google Drive within a G Suite for Education¹² instance to facilitate cleaning, merging, and preparing analytic data sets containing field-based and laboratory-based data, including data from household, SL, and CL, which were linked through unique PTIDs. The staging database was used to merge household and LDMS data twice a week in the DWH to order laboratory-based tests in the CL. The results were linked back to participant data, creating portable document format reports, downloaded in-country, and sent through courier to health facilities for return of results to participants.¹³ Return and turnaround time were tracked in spreadsheets shared between headquarters and in-country coordinators.

The staging database was also used to identify missing data and mismatched data, including laboratory data without household data or vice versa, missing VL or CD4 data for an HIV-positive participant, or discrepant HIV status data between the household, SL, and CL data sets. This merged data set was also used to select specimens for recency, drug resistance, and antiretroviral testing after fieldwork completion.

The PHIA dashboard was a secure website providing 20 daily reports to facilitate monitoring of the quality, efficiency, and progress of each survey. The dashboard was accessible to all partners to facilitate evidence-based decisions to improve survey performance and data quality in real time. Area closeout and response rate reports tracked teams in the field, and SL reports tracked the collection of blood specimens, specimen processing and storage in SL freezers, and SL testing. These dashboard reports were improved in granularity over time, particularly after the first 3 surveys in Zimbabwe, Malawi, and Zambia, to incorporate lessons learned. Incompleteness and inconsistencies in the data highlighted in these reports were tracked and reconciled centrally. As described earlier, all data corrections resulting from this process were tracked in a master data change log that was then applied to the analytic data sets on an ongoing basis by the project team. As batches of data corrections were made, dashboard reports were updated to show the corrected information.

When SL or CL testing contradicted the original household HIV result, the data team highlighted relevant data so that the laboratory team could follow a retesting and investigation process to resolve these discrepancies. The staging database flagged mismatched results, which were presented for review in a system implemented using the Tracker Capture module of the open source District Health Information System (DHIS2).¹⁴ DHIS2 simplified data entry, minimized transcription errors, and allowed a structured review of the relevant facts for each case, allowing for effective and timely resolution.

Workflow involved a list of cases filtered by reviewer: the in-country laboratory advisor, the central data team, or an overall senior laboratory advisor (Fig. 2). Flagged cases were examined, and additional tests or documentation review was performed and routed to the senior laboratory advisor for final review and determination for case resolution (see Fig. 1, Supplemental Digital Content, http://links.lww.com/QAI/B662). An extract from this system was integrated back into the staging database, replacing discrepant results with a final HIV status and triggering any additional needed laboratory-based testing.

PHIA data management prioritized information security by preventing sensitive data from being exposed and by ensuring that all study data were available for analysis. Tablet data were uploaded as soon as feasible after completion of questionnaires to prevent loss. To prevent exposure, tablets were encrypted; data could not be viewed without entering a randomly assigned PIN. If a tablet was stolen despite extensive security efforts (such as extensive training for staff, provision of lock boxes to survey teams, and documentation of the chain of custody of tablets at all times), the random PIN would prevent unauthorized access.^15–17 In 2018, Find My Device¹⁸ was added to wipe data still stored in stolen tablets remotely. PII was shared only on an as-needed basis.

The staff limited data exposure by entering only the PTID, no PII, and minimal additional information into LDMS and Geenius laptops. Laptops were password protected and encrypted. Data were protected from loss by being backed up and uploaded each day.

The DWH spanned several platforms; all were professionally managed, redundant, housed in secure data centers, and backed up for recovery purposes. Servers for sFTP, ODK, and data cleaning complied with the National Institute of Standards and Technology 800-53¹⁹ security standard. Servers for Google Drive “regularly undergo independent verification of security, privacy, and compliance controls, achieving certifications against global standards,”²⁰ such as the International Organization for Standardization’s ISO 27001.²¹ Data transfers used the Secure Sockets Layer, which confirmed the identity of the server and encrypted data over common carriers so that the data cannot be intercepted.

Hundreds of PHIA staff and partners had access to files on the sFTP server, controlled by assigning unique usernames and passwords to each staff member, grouping staff by roles, and assigning read or write access to each folder, further limiting staff by country. All requests for access were centrally channeled through the PHIA account administrator for approval. Similar access restrictions were in place for all servers.