Abstract
A public health registry and intervention was created in response to the Flint water crisis to identify and refer exposed individuals to public health services to ameliorate the deleterious impact of lead exposure. Traditional technology architecture domains, funded scope of work, as well as community input were considered when defining the requirements of the selected solutions. A hybrid software solution was created using Research Electronic Data Capture (REDCap) to deploy an open participant survey and bypass requirements to create user accounts, and Epic to manage deduplication and participant communication and tracking. To bridge the two software systems, REDCap to Epic unidirectional ADT and Documentation Flowsheet interfaces were built to automate creation of subject records in Epic identical to those created in REDCap and to copy key protocol-driving variables from REDCap to Epic. The interfaces were critical to deliver a successful hybrid solution in which the desired features of each software could be leveraged to satisfy specific protocol requirements and community input. Data from the start of survey administration (December 2018) through 31 December 2020 are reported to demonstrate the usefulness of the interfaces.
Introduction
In April 2014, the water source for the City of Flint was switched from pretreated Great Lakes water to locally treated Flint River water. The local water treatment did not include adequate corrosion control, which resulted in lead leaching from water service lines and home plumbing into the drinking water. 1 The acute consequences of the Flint water crisis included an increase in water lead levels, 2 elevated blood lead levels in children, 3 adults 4 and animals, 5 skin disturbances, 6 and an outbreak of Legionnaires’ disease. 7 In response to this public health crisis, a federal emergency was declared in January 2016, and in December of 2016, Congress funded a Flint Lead Exposure Registry. 8 In August 2017, a grant from the Centers for Disease Control and Prevention was awarded to Michigan State University to create the Flint Registry.
Due to the potential long-term manifestations of the crisis, the Flint Registry is designed to deliver a city-wide intervention to connect individuals to services and to conduct longitudinal surveillance of the impacted population. The Flint Registry is open to individuals who were exposed to lead-contaminated water because they lived, worked, or attended school or daycare between 25 April 2014 and 15 October 2015 at an address serviced by the Flint water system. This includes children who were prenatally exposed. At enrollment, participants complete a health survey used to make adult and child referrals to community services related to lead abatement, child development, health, and nutrition. Follow-up surveys are designed to assess ongoing health concerns and make additional referrals for ongoing needs. With over 100,000 potentially eligible participants, the Flint Registry required an informatics solution that was scalable, customizable, and enabled high-quality data collection. A list of requirements was compiled based on funding specifications, protocols for outreach, recruitment and surveys, and community input. Many of the requirements targeted the reduction of participant burden such as participating without creating a user account, returning to complete the survey over multiple sessions, and choosing from multiple modes of data entry to complete the survey. Other requirements were based on project goals to conduct longitudinal waves of surveys, import lists of potential participants from external partners, track communications with participants, and create a mechanism for service referral identification.
Research Electronic Data Capture (REDCap)9,10 software, installed and maintained at Michigan State University (MSU; East Lansing, Michigan), was selected to collect participant survey data; and Epic Systems, installed and maintained at Hurley Medical Center (HMC; Flint, Michigan), was selected to manage participant identity, communications, and tracking. This software hybrid approach required REDCap to Epic directional HL7 interfaces to synchronize subject creation and a subset of key protocol-driving variables. While there are examples of moving data from Epic into REDCap, 11 to our knowledge this is a unique case of moving data from REDCap into Epic. In the sections that follow, we first describe the hybrid software solution. Next, we report data from the start of survey administration to demonstrate the usefulness of the interfaces. Finally, areas of technical challenge and overall benefits of the solution are presented.
Methods
User and protocol requirements mapped to REDCap and Epic software default functionality.
Isolated software environments
At MSU, a dedicated instance of REDCap was created and configured for exclusive use by the Flint Registry so that other MSU REDCap projects did not experience potential negative performance issues related to the extensive program customizations implemented in REDCap for the Flint Registry. At HMC, a separate Epic production environment was installed for exclusive use by the Flint Registry so that Flint Registry data were isolated from the HMC production environment.
REDCap - survey data collection
Flint Registry recruitment launched in December 2018. The outreach sample was comprised of individuals who responded to city-wide marketing campaigns or to community outreach efforts conducted by four community partner organizations. The population-based sample was comprised of individuals identified from three state public health databases and a local community hospital, with addresses mapped to residences serviced by the Flint water system, who were mailed invitation letters. Interested persons from both samples were directed to the Flint Registry website to complete an online pre-enrollment survey, or to Flint Registry telephone interviewers who entered information directly into the pre-enrollment form on their behalf. Lists of interested persons provided from outreach partner organizations were imported directly into the REDCap pre-enrollment survey. The pre-enrollment survey was completed by adults and included data entry fields for household children, so that an entire family structure was captured within a single pre-enrollment survey. A custom module regularly processed and restructured the data of each pre-enrollment survey into individual records, generating for each a potential participant record with a unique survey code used to access a queue of enrollment surveys: eligibility, consent, and baseline. Although the MSU Institutional Review Board determined this project (STUDY00001359) did not require IRB approval, all participants provided written/digital informed consent.
REDCap was configured to create and send unique survey links to potential participants by text message and email. Persons unable to receive text and email were mailed printed invitation letters with the individual’s unique survey code and directions to access the survey via the Flint Registry webpage. The potential participant was able to use the same code to complete the survey over multiple sessions and to select the mode of survey data entry from online, telephone, and printed options.
ADT interface
To join REDCap and Epic as a hybrid solution to support the Flint Registry, it was necessary to create records in Epic that were identical to those created in the REDCap Flint Registry project. This was accomplished by using a custom developed cron job. First, Flint Registry REDCap records not yet sent to Epic were identified, then an HL7 message for each was created and queued to send, and finally the queued messages were sent to Epic via the ADT interface in the message integration software application, Cloverleaf (Figure 1). The HL7 message received by Epic created a potential participant record identical to that in REDCap, including name, gender, date of birth, primary language spoken, email, address, phone number, unique identifier (Flint Registry ID), unique group identifier, unique survey code, and source variable designating the origination of the record’s demographic information. This interface enabled creation of subject records in Epic matching those in the REDCap Flint Registry project via an automated process. Schematic representation of hybrid system interfaces and data flow. Subject data enter the Flint Registry REDCap project by the processing of pre-enrollment surveys (not pictured) or by the importing of CSV name list files. A custom change detection module queries a subset of key survey variables. In step 1, a cron job queries data to identify records not yet sent (e.g., Name, DOB, Registry ID#, Family Group #, survey code). In step 2, data are queried to identify variables with changed values (i.e., variables with new data entered by potential participants, enrollees, or Flint Registry staff). Data identified in steps 1 and 2 are translated to HL7 messages and sent to the HL7 Message Log REDCap project. Messages in the log are sent to Cloverleaf, which sorts, queues, and transmits the HL7 messages to Epic via the appropriate interface: the ADT interface for data not yet sent (one ADT message per record), and the Documentation Flowsheet interface for data that has changed value (unlimited number of Documentation Flowsheet messages per record). Data in CSV files from third-party mailing vendor are imported to Cloverleaf, which translates, queues, and sends corresponding HL7 data to Epic via the Documentation Flowsheet interface.
Epic - deduplication
The Flint Registry’s open web survey recruitment plan did not exclude potential participants from pre-enrolling more than one time. Epic supplied the critical processes to deduplicate subject records sent from REDCap via the ADT interface. Epic supports deduplication at each attempt to create a new subject record via the ADT interface. Epic was configured to allow only a single ADT message per potential participant. When a new ADT interface message was received, deduplication algorithms evaluated the degree of similarity between demographic variables of the new record against all those of existing Epic records. New records analyzed as unique were marked in the Epic background as known non-duplicate; and those analyzed as true duplicates were merged to leave a single record in Epic. Indeterminant records, often originating from twins, namesakes, and siblings, as well as typographical errors, were programmatically reported in a potential duplicate work queue where they were reviewed manually to either merge or mark as known non-duplicate. In a final step, all duplicates were manually marked in the REDCap Registry project to exclude them from further steps of the survey completion protocol. Updates to information in the ADT message, for example correction to typographical errors, were made manually, directly in each system.
Epic - communications data collection
Standard features in Epic were used to document and coordinate communication and track the progress of potential participants and enrollees through the Flint Registry survey completion protocol. Epic outreach encounters were used to collect both manually entered and automatically captured details, and both structured and unstructured data for each communication event: telephone calling, printing and mailing of individual and bulk letters, and sending of texts and email, timestamp, name of user, digital image of letter printed, interviewers’ case notes, changes in demographic information, and a small set of structured ‘contact’ data to document the type of contact. These data were all stored in the Epic flowsheets of potential participants and enrollees.
Documentation Flowsheet interface
To use standard Epic communication and worklist functionality to drive the Flint Registry survey protocol, it was necessary to copy to Epic a subset of REDCap survey answer and survey completion data. The Documentation Flowsheet interface was developed to send these data to Epic in real-time, every time new data for these variables were detected.
REDCap default functionality provided an “on change” trigger, which fires when a change is saved. Such changes were made when potential participants, enrollees, or Flint Registry staff entered data in REDCap surveys. Its usefulness was limited, however, because it does not indicate for which variable(s) a change has occurred. For this reason, it was necessary to develop a method to identify the exact variable(s) whose change had caused the trigger to fire. For changes to variables that were part of the Documentation Flowsheet, a message was queued. Most of the interfaced variables were calculated by custom code so changes could be detected. For other variables that were populated by an import, an explicit flag variable was used to indicate that an update was needed. Identified changes were configured as corresponding HL7 messages and sent to Epic via the Documentation Flowsheet interface. [Code developed to identify the exact variable(s) causing the ‘on change’ trigger to fire and to support the HL7 interfaces has been made available at https://gitlab.msu.edu/bric/epic-hl7-integration.] REDCap-sending and Epic-receiving messages were linked by the record subject Flint Registry ID (FRID). Successful message sending to Epic required that the REDCap message FRID matched an existing Epic FRID, and that the message data was one of the possible, recognized variable responses. Messages meeting both requirements were accepted by Epic to create a REDCap Interface Message encounter, in which the message data were written to the subject’s corresponding flowsheet. Messages that did not meet both requirements generated and sent an error message to an error work queue to be manually reviewed by analysts.
To support implementation and use of the Documentation Flowsheet interface, a message queue was created. All updates were sent to this queue and all HL7 messages were generated from unsent updates in the queue. The content of the HL7 message and the response received from Cloverleaf were logged as part of the audit history for each send event. Such functionality is typically handled by using third-party middleware, but for the Flint Registry implementation a separate REDCap project was used to deploy this feature. This provided an easy linkage of sent message and corresponding subject and allowed users to work within the same REDCap platform rather than requiring work in a new software. Data captured by the audit log for each message included time queued, time of last send attempt, number of send attempts, a string version of the updated records, and a copy of the HL7 message sent. This approach allowed for ease in management of the interface process, fast queueing of messages, resending on message failure, and proper sending order of messages.
The Flowsheet Documentation interface was also used to import data in bulk for communications events conducted external to Epic; for example, date invitation letter mailed for letters produced and sent by the third-party mailing vendor. The interface engine, Cloverleaf, was used to enable bulk data import of these uniformly structured data. Cloverleaf converted the import file to an HL7 message, which was then processed in the same way as a Documentation Flowsheet interface message generated by REDCap.
Results
Requirements to implement the Flint Registry were met by using the preferred functionality of two software systems and joining them by use of HL7 message interfaces to form a hybrid software solution. With isolated environments established for each software system, other MSU REDCap projects experienced no performance issues related to the Flint Registry’s extensive REDCap customizations. Likewise, Flint Registry data were completely separated from HMC patient data.
Data collection in the Flint Registry survey protocol was driven by sequential completion of the eligibility, consent, and baseline questionnaire surveys. Survey completion paths were highly variable. Many enrollees completed the eligibility and consent surveys during a single session, and then returned later to complete the baseline survey, sometimes over multiple sessions. Others began the baseline survey but did not return to complete it until they received reminder messages. Others received multiple forms of outreach over many months before completing the eligibility survey. Information about each survey completion in REDCap was needed to inform communication events initiated within Epic.
To integrate the separate software platforms, an ADT interface and a Documentation Flowsheet interface were developed to send data through HL7 messages to Epic from REDCap. These unidirectional interfaces, respectively, were used to create in Epic identical subject records as those created in REDCap, and to copy a subset of key survey and administrative variables to Epic from REDCap. Interface data corresponding to the start of baseline survey administration in December 2018 through 31 December 2020 were examined.
The ADT interface was used to create potential participant records in Epic identical to those first created in REDCap by sending a total of 45,281 ADT messages to Epic, comprising 33,593 and 11,688 online and imported submissions of the pre-enrollment survey, respectively, as of 31 December 2021 (Figure 2). Epic deduplication functionality was used to process the ADT messages. A total of 33,742 messages were determined to be unique, non-duplicates, each for which a potential participant record was created in Epic. A total of 4926 messages were identified immediately as duplicates and were rejected. Finally, 6588 messages were determined by manual inspection to represent a duplicate and were merged with the corresponding pre-existing Epic subject record. Of the 33,767 potential participants, 17,741 were determined to be eligible enrollees; 280 were determined to be not eligible; and 15,746 were not determined, because the eligibility survey was not yet completed. The Documentation Flowsheet interface was used to send to Epic from REDCap more than 82,725 messages, containing key variable data to track potential participants and enrollees through the Flint Registry survey completion protocol. Of the 17,741 eligible enrollees, 11,416 completed the baseline survey online; 2288 by telephone; 1117 by other methods; and 2920 were incomplete (Figure 2). Sankey diagram depicting flow of potential participant and enrollee data through the Flint Registry protocol, as of 31 December 2020. A total of 45,281 pre-enrollments were completed by persons interested in participating in the Flint Registry: 33,593 by online REDCap survey, and 11,688 by file import to REDCap. The ADT interface was used to create potential participant records in Epic identical to those created in REDCap. Epic deduplication identified 4926 and 6588 records as exact match and manually confirmed match, respectively. The documentation interface was used to copy a subset of key REDCap survey administrative data to Epic. These data were used in Epic to track potential participants and enrollees through the survey completion protocol and manage the type and timing of communication events. Of the 33,767 total participants, 17,741 were eligible, 280 were not eligible, and 15,746 were of unknown eligibility because they lacked a completed eligibility survey. Of the eligible enrollees, 14,821 completed the baseline survey: 11,416 online; 2288 with an interviewer over the phone; and 1117 by other means. A total of 2920 enrollees had not yet completed the baseline survey.
Certain data were documented directly in Epic when Flint Registry staff conducted phone calls, printed and mailed materials, and performed other communication events. The Epic communication logs showed more than 85,210 documented phone calls between the Flint Registry and potential participants and enrollees, and more than 56,949 documented pieces of mail sent.
Discussion and conclusion
Preferred features
When the composite requirements list was used to evaluate suitable software to deploy the Flint Registry, REDCap and Epic were heavily favored, as these resources were available at collaborating partner organizations. Neither software satisfied all the requirements (Table 1), therefore both were used to build a hybrid software solution, leveraging respective strengths of each to address all project needs.
Epic was used primarily for subject record deduplication, tracking, and driving protocol completion through reporting and worklists. Epic’s standard deduplication processes were used to ensure each potential participant or enrollee was represented only once in the Flint Registry. Duplicates of potential participants were anticipated because the Flint Registry’s recruitment strategy uses an open REDCap pre-enrollment survey (outreach sample) and imports of address-based lists (population-based sample). Epic provided the critical deduplication feature, which was not available in REDCap. The robust reporting features in Epic used communication event encounter data to create worklists identifying groups of potential participants and enrollees to receive protocol-specific communications.
REDCap was used primarily for survey data collection. The open survey format enabled data collection without requiring user account creation. Standard functionality allowed completion of surveys over multiple sessions and sending of survey links by text or email message. All these features were aimed at reducing the burden of participation.
Administering surveys via REDCap also addressed challenges encountered when considering Epic for survey administration. Early plans for survey administration were made to use MyChart in the HMC Epic patient portal. However, juxtaposition of Flint Registry and medical record data created the appearance of common access by Flint Registry staff and HMC medical staff. Strategies to mask the display of HMC and Epic branding in a Flint Registry MyChart were considered but were eventually discarded based on the Flint Registry’s commitment to full transparency. This requirement, to completely separate Flint Registry participant data from HMC patient data, was not anticipated at the outset of our design, however it was implemented to honor the Flint Registry’s commitment to be informed by needs of the community and to build trust.
Another challenge was related to administration of standardized instruments. Publisher and copyright policies for the standardized assessments used to measure child development prohibited the integration of these instruments into an electronic medical record system. It was, however, permissible to deploy them electronically in a REDCap survey.
Interfaces
Implementation of the ADT and Documentation Flowsheet interfaces was integral to the success of the Flint Registry’s hybrid software solution. The ADT interface was used to create Epic subject records identical to those created in REDCap, without requiring any additional data entry or collection, and subsequent Epic deduplication ensured that each subject record represented a unique individual (Figure 2).
The Documentation Flowsheet interface was used to copy information to Epic about each REDCap survey completion event, so that communication events driven within Epic were of the appropriate type and timing. When the Registry initially launched, the Documentation Flowsheet interface was not operational. Without the interface, manual data entry in Epic was needed to document subject-level changes made to key REDCap variables, which required massive time and effort and was naturally prone to data entry error. On a monthly basis quality control protocols were used to compare key variables in REDCap and Epic. Manual review and research of data were conducted to clean discrepancies. Time spent on monthly quality assurance processes was reduced from a 5–8 days process to a 5–8 h process by implementing the interface.
The interface also made sending communications feasible via a third-party mailing vendor, because it enabled the import to Epic of data generated outside of REDCap or Epic. About 9 months after printing and documenting invitation letters exclusively within Epic, an outside company was contracted to produce and send recruitment materials. Though the communication event was conducted external to Epic, it was essential to document it within Epic. The Documentation Flowsheet interface was used to import these external data so that protocol-driving reports and worklists were consistent and accurate, despite having sent communications outside of the Epic system.
Lessons learned
During the build of the hybrid system, both software systems were proved to require establishing an isolated working environment. For REDCap, it was determined that a new instance of REDCap was needed to isolate other MSU REDCap projects from possible poor system performance related to the substantial amount of custom development and scale of the Flint Registry project. For Epic, it was discovered that the planned use of a confidential department configuration to isolate the Flint Registry data did not provide adequate measures for security and access. Therefore, a new, separate Epic production environment was created at HMC to deploy the Flint Registry.
Using Epic for non-medical purposes presented several challenges stemming from its primary function to serve patient care. Satisfying HMC’s required administrative processes to maintain a HIPAA-compliant system posed a challenge. For example, at HMC account creation required in-person identity verification, and the management of minors’ accounts restricted parent permissions and access for persons 14 years of age and older, of which both were not suitable for the Flint Registry survey protocol. Though Epic offers sophisticated reporting features not available in REDCap, the report writing features are not accessible to the research staff, even for simple reports. This limitation required engaging a full-time, Epic-trained report writer to serve the Flint Registry. The complexities of the Epic reporting environment, including the Clarity analytical reporting tool, meant that not all data were immediately available for reporting, with some data elements lagging by as much as 24 h before being extracted to the Clarity reporting server. Although this type of extract-translate-load structure is common when running analytical reports on large datasets, it was not ideal to meet the needs of the Flint Registry.
Cost of implementation, in both time and budget, is a practical issue when considering the usefulness of the hybrid system. REDCap costs are less than Epic costs by an order of magnitude, which may limit the generalizable usefulness of the hybrid system presented here for registries working without a clinical partner. However, using Epic provided important benefits for the Flint Registry that outweighed its costs. Epic default functionality used to support specific requirements of the Flint Registry (Table 1) reduced the time needed for development and shortened the time to launch, which was critical during the public health crisis. Using Epic also leveraged the resources and expertise of HMC, an important Flint Registry partner representing the largest local medical care provider. Using REDCap offered other advantages. Implementation of extensive customization in REDCap necessary to drive the survey protocol was comparatively cost and time effective to that of potential builds in Epic to create similar functionality. Access to REDCap customization was also important, as Epic customizations were not permitted in the absence of significant generalizable utility to warrant modification of the core software product by the Epic Systems development team.
A hybrid system like the Flint Registry hybrid solution presented here would be of general usefulness to organizations with clinical/academic partnerships that have access to Epic and REDCap. An interface between REDCap and Epic, operating a typical clinical production environment with access to the medical record, may be useful to add key research data to an individual’s medical record, as reported for other research data platforms. 12 For example, interfacing to medical records a variable to note a patient’s participation in a clinical trial, with appropriate care to preserve blinding to allocation group, could offer significant value to inform a doctor of potential interventions and treatments that would not otherwise be documented. 13
The work reported here demonstrates the feasibly and utility of using HL7 interfaces to copy data from REDCap into Epic. While there are numerous reports in the literature describing interfaces to copy data from Epic to REDCap, the authors are unaware of reports in which data are copied from REDCap into Epic. Using both platforms enabled timely delivery of all the Flint Registry requirements which demanded an unusually high degree of flexibility and meaningful reduction of participant burden.
Footnotes
Acknowledgements
Registry data were collected and managed using REDCap electronic data capture tools hosted at Michigan State University.6,7 Epic systems was hosted by Hurley Medical Center, Flint, MI. We thank Joseph Grathoff, Hurley Medical Center Epic Interface Analyst, for assistance in the design and implementation of the REDCap-Epic interfaces and Michael Roebuck, Hurley Medical Center Chief Medical Information Officer, for his support. We thank Jacqueline Dannis, Flint Registry Data Analyst, for insightful review of the manuscript and Katherine Negele, Flint Registry Dissemination Specialist, for assistance with manuscript preparation.
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by grant funding from the Centers for Disease Control and Prevention (CDC) of the U.S. Department of Health and Human Services (HHS) (NUE2EH001370) as part of an award totaling $20,360,339 with 0% financed with non-governmental sources; and by funds from the U.S. Department of Health and Human Services (HHS) (U05M15ADM, FAIN 1705MI5ADM) passed through the Michigan Department of Health and Human Services (E20172805-00 and E20180329-00) as part of awards totaling $193,521.72 with 0% financed with non-governmental sources, and $186.336.16 with 0% financed with non-governmental sources. The contents are those of the authors and do not necessarily represent the official views of, nor an endorsement by, CDC, HHS, the U.S. Government, or the Michigan Department of Health and Human Services.
