REDCap on FHIR: Clinical Data Interoperability Services

Abstract

Background

Despite widespread use of electronic data capture (EDC) systems for research and electronic health records (EHR), most transfer of data between EHR and EDC systems is manual and error prone. Increased adoption of Health Level Seven Fast Healthcare Interoperability Resource (FHIR) application programming interfaces (APIs) in recent years by EHR systems has increased the availability of patient data for external applications such as REDCap.

Objective

Describe the development of the REDCap Clinical Data Interoperability Services (CDIS) module that provides seamless data exchange between the REDCap research EDC and any EHR system with a FHIR API. CDIS enables end users to independently set up their data collection projects, map EHR data to fields, and adjudicate data transfer without project-by-project involvement from Health Information Technology staff.

Methods

We identified two use cases for EHR data transfer into REDCap. Clinical Data Pull (CDP) automatically pulls EHR data into user-defined REDCap fields and replaces the workflow of having to transcribe or copy and paste data from the EHR. Clinical Data Mart (CDM) collects all specified data for a patient over a given time period and replaces the process of importing EHR data for registries from research databases. With an iterative process, we designed our access control, authentication, variable selection, and mapping interfaces in such a way that end users could easily set up and use CDIS.

Results

Since its release, the REDCap CDIS has been used to pull over 19.5 million data points for 82 projects at Vanderbilt University Medical Center. Software and documentation are available through the REDCap Consortium.

Conclusions

The new REDCap Clinical Data and Interoperability Services (CDIS) module leverages the FHIR standard to enable real-time and direct data extraction from the EHR. Researchers can self-service the mapping and adjudication of EHR data into REDCap. The uptake of CDIS at VUMC and other REDCap consortium sites is improving the accuracy and efficiency of EHR data collection by reducing the need for manual transcription and flat file uploads.

Graphical Abstract

1. Introduction

Although health records and clinical research records have both been collected and stored digitally for many years in highly resourced countries, the process of transferring patient data from the electronic health record into transactional study-based research databases is still predominantly a manual and laborious process.[1] Electronic data capture (EDC) for research has created new opportunities for improving data accuracy, operational efficiency, and participant safety in clinical studies and trials.[2] The shift from paper-based data collection to EDC has also resulted in substantial cost reductions for clinical studies and trials.[3,4] As the adoption of EDC systems for research gained popularity in the US, the passing of the US Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 led to increased adoption of electronic health records (EHRs) at academic medical centers.[5] Another piece of legislation that improved the availability of EHR data for other applications is the 21^st Century Cures Act, which required EHR vendors to make patient data easily available through application programming interfaces (APIs).[6] The US Food and Drug Administration (FDA) recently acknowledged these opportunities by issuing guidance to facilitate the use of EHR data in clinical investigations and to promote the interoperability of EHR and EDC systems.[7] The confluence of technology adoption in support of both the clinical enterprise with EHRs and research enterprise with EDCs is opening new opportunities for the use of real-world data in clinical investigations.[8]

Despite the digitization of both health and research records, there are significant content, technical, and organizational barriers for direct EHR-to-EDC data transfer.[9] Researchers are often skeptical of reusing EHR content for research, citing outdated or incomplete data, inaccurate coding, and a lack of data standardization.[10] EDC developers face technical and privacy challenges gaining real-time connectivity to clinical data systems, leaving researchers to access clinical data indirectly through research data warehouses that are only periodically updated.[11] Other technical barriers include the lack of semantic interoperability of data available from the EHR, the complexity of mapping and transformations required for meaningful data exchange, and the patchwork of standards implementation across EHR systems.[12] Organizational barriers also exist. Health IT teams do not routinely support research and are therefore not prepared to navigate complexities of research database connectivity that are constrained by Institutional Review Board (IRB) approvals, waivers of informed consent, and HIPAA authorization.[13]

Research Electronic Data Capture (REDCap) is a secure, web-based data capture application developed using technical approaches that mitigate many of the challenges above. REDCap allows users to design their own forms and data collection workflows. REDCap is designed to support clinical research but can be used for all types of data collection needs such as patient-facing surveys, mobile fieldwork data gathering, or research operations workflow. REDCap includes a user-friendly forms design interface, field validation, customizable skip logic patterns, calculated fields, data import options, data export routines for common statistical packages (SPSS, SAS, Stata, R), data quality checking, basic report creation, role-based user access, audit trails, and a linked mobile app for phone and tablet-based data collection.[14,15] Notably, REDCap has a comprehensive set of APIs that enable seamless integration with other platforms using standards such as the HL7 Fast Healthcare Interoperability Resources (FHIR).[16] The software is developed at Vanderbilt University Medical Center (VUMC) and distributed at no cost to members of the REDCap Consortium. The REDCap Consortium is a global collaboration of over 4,700 diverse institutions that have installed the software and collaborate to provide support for over 1,400,000 unique end-users across 140 countries.[15] The REDCap platform is constantly evolving based upon user input to improve existing capabilities or create additional features.

One frequently requested feature from the earliest days of REDCap has been direct data transfer between a local EHR system and a locally hosted and supported REDCap installation. To address this need, we developed a new REDCap data exchange module based on FHIR. We describe our approach and experience developing the new REDCap Clinical Data and Interoperability Services (CDIS) module and deploying it at VUMC and at the University of Texas (UT) Southwestern.

2. Methods

2.1. Defining System Requirements

One design principle that led to the success of REDCap is empowering researchers to set up projects with minimal involvement from Information Technology (IT) staff and REDCap administrators. This principle guided development of CDIS as we sought to enable EHR-to-EDC extraction for hundreds of projects with self-service setup and execution, rather than a solution for a single project. We adhered to existing REDCap development guiding principles in the REDCap Consortium (‘build small, evaluate, evolve’ and ‘fail early, fail small’) when developing CDIS.[15] Specifically, we gathered input from researchers at VUMC regarding desirability of a generalizable CDIS service, then did preliminary technical feasibility work to determine whether the EHR provided a FHIR-enabled API that could be leveraged to extract data into REDCap. Next, we socialized the concept with VUMC Institutional Review Board leadership to help inform rules of use and necessary guardrails for the research community. To develop a minimum viable product, we borrowed design ideas from a previously developed and disseminated REDCap Module called Dynamic Data Pull (DDP), which allowed REDCap teams to connect their local REDCap installation to local research data warehouse infrastructure.[18] Once a minimum viable product was developed, we sought early champions to help test CDIS setup and transactional data expectations using real-world use cases as defined by the research teams. In this phase and as we began rolling out the module to additional groups, we paired one of our lead analysts with research teams to demonstrate and train research project owners. The analyst was then able to translate and transfer feedback information from limited research project users to the development team, and subsequently add or refine the most requested features. Given this feedback cycle, CDIS module setup and use became more intuitive for researchers. Thus we relaxed the requirement for project setup teams to meet with the expert analyst for each new project. Table 1 summarizes the milestones in the development process of CDIS as well as the stakeholders engaged at each stage.

Table 1:

Milestones in CDIS development and stakeholders engaged

Milestone	Stakeholders engaged	Time
Initial Epic EHR and VUMC health IT engagement	Leadership	2017 Q1
Commencement of early FHIR and OAuth2 connectivity testing at VUMC	Technical	2017 Q2
CDP module design and testing	Technical	2017 Q2
CDP IRB consultation and planning	Regulatory	2017 Q2
UTSW engagement as early adopter	Leadership, Consortia	2017 Q3
End-user documentation created @ UTSW	Technical, Research support	2018 Q1
Training model established for enterprise dissemination @ VUMC	Research Support	2018 Q2
CDP dissemination to at Epic developers conference	Consortia	2018 Q2
CDP dissemination to REDCap consortium	Consortia	2018 Q2
Approval process for new projects established @ VUMC	Regulatory, Research support	2018 Q2
First CDP project live @ VUMC	Researchers, Research support	2018 Q3
Release of REDCap button within Epic browser	Technical	2018 Q3
Approval process for new projects established @ UTSW	Regulatory, Research support	2018 Q3
First CDP project live @ UTSW	Researchers, Research support	2019 Q1
First end-user training @ VUMC	Researchers, Research support	2019 Q1
REDCap released on Epic App Orchard	Leadership	2019 Q1
First CDM project live @ UTSW	Researchers, Research Support	2019 Q2
CDM IRB consultation and planning (for access controls)	Regulatory	2019 Q3
First CDM project live @ VUMC	Researchers, Research Support	2019 Q3
First Cerner site live	Technical, Consortia	2019 Q3
Mapping helper design and testing	Technical, Researchers	2020 Q1
Break-the-glass live	Technical, Researchers	2020 Q2
Stakeholder groups
Leadership (VUMC C-suite, Epic research leadership, VUMC Office of Research leadership, Health IT leadership, Clinical Research Informatics Officer)
Technical (Health IT analysts, Epic analysts)
Regulatory (IRB representatives, privacy officer)
Research Support (Trainers, and process managers)
Consortia (Epic customer groups, REDCap consortium)
Researchers (Investigators, coordinators, biostatisticians)

We sought to differentiate CDIS from other efforts to use FHIR APIs to collect EHR data in research databases[17] by making the entire process of project creation, data selection, data mapping, and data adjudication is driven by the end user. Just as non-informatics trained researchers can set up data collection forms on their own in REDCap, we sought to design CDIS in an intuitive and user-centered way so that any clinical researcher could use data from the EHR. A group of clinical researchers and REDCap administrators reviewed the challenges and limitations of the prior REDCap-based data extraction solutions. Certain components of previous user interfaces were reusable and had received broad user acceptance such as field-mapping and data adjudication. We then identified other aspects of the workflow that would require redesign.

In parallel, we reviewed use cases for EHR-to-REDCap data extraction through existing REDCap partner collaborations. We collected statistics for previous studies that used EHR data in our local REDCap installation and solicited feedback from researchers and informatics professionals participating in the REDCap Consortium.[15] Discussions with EHR vendors informed project feasibility and technical design. The REDCap development team attended an EHR module development course and an EHR developers conference to supplement their knowledge for developing the EHR interface.

We selected the Epic EHR system for initial development and rollout of CDIS because Epic’s EHR has a FHIR API and because VUMC is an Epic customer. Health IT leaders at VUMC provided us with access to an Epic test server, direct communication with Epic technical representatives, and dedicated effort from the VUMC Health IT analysts. A team of three REDCap programmers met weekly with informatics faculty to discuss FHIR protocols, data mapping, and design decisions. Representatives from Epic met every two weeks with the REDCap development team to answer questions on EHR integration and the EHR FHIR API. Informatics faculty met regularly with VUMC Health IT analysts, the Privacy Office, and IRB representatives to ensure all necessary privacy, security, and regulatory issues were addressed. Both data and user access restrictions were implemented based on input from all groups. Pilot testing of the resulting tool was conducted jointly with REDCap partners at UT Southwestern Medical Center. UT Southwestern is also an Epic customer and was able to implement all the features of CDIS in a similar fashion to VUMC.

2.2. Defining Initial Use Cases and Operational Data Flow Requirements

The first use case, called Clinical Data Pull (CDP), improves the process for data collection in traditional prospective studies where research teams create and complete case report forms (CRFs) for each study participant. Stakeholders identified two workflows for adding patients to studies. Adding patients to a CDP project is possible from an EHR browser window (e.g. researcher views a patient and wants to insert them as a study participant in the EDC system) or within the EDC screens (e.g. researcher is working in EDC system and wants to add a participant by typing an medical record number (MRN) or refresh CRF data on an existing participant). The goal was to allow researchers to use whichever workflow was natural for their particular use case while eliminating the need for clinicians and research personnel to transcribe data with the EHR open in one window and a REDCap CRF open in another window.

The second identified module use case is called Clinical Data Mart (CDM) and models the workflow of extracting EHR data in bulk for a known cohort of patients. Researchers identify a cohort using a list of MRNs, specify applicable begin/end dates by project or by patient, and provide information on relevant data elements for retrieval. REDCap then takes these instructions and creates a project database, extracts all relevant patient data, deposits those data into the newly created database, and assigns user rights for that database to the researcher. The CDM is ideal for developing registries and other research projects where an unknown and unlimited number of visits or measurements values such as laboratory results, vital signs, diagnoses, or other collected data points of the same type are needed per patient. This self-service workflow is an improvement over traditional methods of creating a data mart (see Figure 1). Obtaining data directly from the EHR eliminates the dependency on research data warehousing infrastructure, which is often unavailable at smaller healthcare organizations. Direct EHR to EDC data transmission also carries the benefit of data timeliness, as research data warehouses are not typically updated with operational EHR data in real-time and are instead updated periodically such as every evening. EHR-based FHIR APIs allow researchers to obtain data as soon as they are entered in the EHR.

Figure 1:

Traditional workflow for creating a registry from EHR data in REDCap (greyed out) compared to new CDIS workflow

In the remainder of the methods section, we discuss design considerations for specific features of CDIS, including EHR variable selection, mapping, adjudication, EHR window iframe, CDM data representation, break-the-glass, access control, and authentication.

2.3. Choosing EHR Data Fields

For both CDP and CDM use cases, users must specify EHR data elements needed for their project. We designed this process to be as user-friendly as possible so that researchers without experience with EHR coding standards would be able to identify the data elements they need. Figure 2 shows the REDCap user interface developed for this purpose. Researchers navigate lists of available data fields by domain or use a keyword search bar that helps users find the right data types. The organization and availability of individual EHR-based data fields available for mapping are derived from a file that can be customized by any REDCap partner institution. Initial seeding for this informational file was derived from a list of Logical Observation Identifiers Names and Codes (LOINC) codes for available data in the research data warehouse at VUMC. It was supplemented by LOINC codes contributed by UT Southwestern, who gathered this list from available data in their local Epic system.

Figure 2:

Variable selection screen with keyword search

In practice, we found that even with the search bar some clinicians had a hard time finding the EHR variables needed for their study. For example, a search for “glucose” might yield 20 possible data types, many of which will not have any data from the EHR. To address this challenge, we designed a “mapping helper” shown in Figure 3 that enabled users to search the available FHIR data by entering a known study participant’s MRN. The researcher can then see real-world data and associated codes to inform the process of final EHR-to-REDCap data mapping choices.

Figure 3:

Mapping helper

2.4. Mapping EHR Data to REDCap Fields

Since no two study CRFs are alike, creating an interface to map EHR data to fields in REDCap that can generalize to many use cases has to be flexible and easy to use. Mapping fields between an EHR system and EDC system in a meaningful way requires careful consideration, including static and temporal data relationships. Stakeholders identified the need for mapping one-to-many relationships, where multiple measurements on a given day had to map to a single REDCap field. We also designed a way to define mapping relationships where several similar observation types (for example blood pressure while sitting or supine) could be considered for mapping to one REDCap field. Figure 4 shows a typical mapping screen configuration and illustrates several important concepts supported in the mapping process. Mapping non-temporal data that is static for patients such as demographic data is straightforward. Users simply select the REDCap field in the CRF where the EHR data of that type should be deposited. Temporal measures require an anchoring date such as the date of an encounter. For data elements with multiple values per patient such as lab values or vital signs, the user can define criteria for REDCap to preselect a given value. Users specify preselection of the closest measurement to the anchoring date and time, the greatest or least value over a time interval, or the earliest or latest value in that time interval. Defining pre-selection criteria expedites the EHR-to-EDC data adjudication process that is part of the CDP user workflow.

Figure 4:

REDCap CDP project mapping with examples of non-temporal, one-to-one, many-to-one, and many-to-many scenarios.

2.5. EHR Workflow for CDP Project

Another requested functionality of our CDP module was the ability to complete REDCap case report forms from within a patient’s record inside an EHR browser window. If desired, local Health IT teams may create a menu item in the EHR interface that serves to launch the REDCap Client App from within the EHR. With authorization to access the REDCap CDIS, users could click this menu item to open REDCap in an iframe (allows inclusion of web content from one source within the current web environment), providing secure connectivity and rendering REDCap screens within the EHR window. The REDCap screens displayed within the EHR workflow were modified to remove non-essential REDCap menu items and hide all REDCap projects except those granted permission to use CDIS.

When accessing the module from within the EHR, the REDCap view shows all REDCap projects where the user has access, CDP is active, and data mappings have been established. When a patient record is active in the EHR, REDCap will automatically show the status of the patient on each of the displayed CDP projects. If a patient is already added to a specific study, selecting that study in the REDCap iframe automatically opens that patient’s REDCap case report forms. If a patient is not yet enrolled in a specific study, selecting that study in the REDCap iframe asks for confirmation, then adds the patient to study. A patient can also be added to a study in the REDCap interface by entering a medical record number in the REDCap project.

2.6. Data Adjudication in CDP

Modeling after researcher workflows, we recognized that chart reviews sometimes involve clinical interpretation by research coordinators. Therefore, we built into the CDP workflow an adjudication step where all relevant data automatically retrieved from the EHR could be quickly reviewed in one screen before ingestion into electronic CRFs. When a patient is added to a study, REDCap immediately uses the EHR-FHIR services to extract demographic data elements from mapped fields. The retrieved data is presented to the end user for adjudication before being recorded in the CRFs. Figure 5 shows a screenshot of the data adjudication for demographic data while Figure 6 demonstrates data adjudication for lab data with the most recent lab measurements preselected.

Figure 5:

REDCap CRF Data Adjudication Process

Figure 6:

Adjudication of labs with multiple values and most recent value preselected

After a patient is registered within the REDCap project, REDCap will scan for any anchor dates for temporal data elements such as lab values. When identified, REDCap invokes an EHR FHIR API call requesting relevant patient data within the specified date window and matching CRF-defined data types. The REDCap system can perform automated data retrieval on a user-specified frequency (default is every 24-hours) to collect new data from the EHR for each research participant. If new data are found, the REDCap system automatically alerts the research project team for new data adjudication upon next login to REDCap.

2.7. Registry Data Representation

Generalizability was also paramount when designing a data model for CDM projects. Registry data in REDCap must mimic a relational database where some tables are one row per record while other tables are many rows per record keyed to a record identifier. The solution we came up with was to use REDCap repeating instruments for data that had many values per record such as for vital signs, labs, medications, problem list conditions, and allergies. Data adjudication is not necessary in CDM because data elements such as labs and vital sign measurements with multiple values are all imported into REDCap. Figure 7 shows how data are represented in repeating instruments in CDM.

Figure 7:

Data representation in CDM

Researchers initiate a Data Mart project by selecting the “Clinical Data Mart” template when creating a new REDCap project. Users enter a list of medical record numbers to include in their study and specify a date range for data to obtain from the EHR. They also select the types of data they want to obtain from the list of available endpoints. Once they create their project, REDCap project creation can be halted to allow a REDCap Administrator to grant approval for pulling data. Once approved, REDCap will automatically create one instrument per data type. Data elements where there may be more than one observation per individual will appear as repeating instruments where the data element name will appear in a data label field accompanied by the value of the observation and the date and time of the observation. A data mart project can be revised and re-run with new medical record numbers and a different date range. In this case, REDCap appends new records and repeating values to existing data. There are also options to revise data elements within the Data Mart at any point after initial setup and data retrieval.

2.8. Break-the-glass scenarios

The first VUMC project to use CDM brought to light an issue where researchers were unable to confirm escalated authorization to access patient records (“break-the-glass” procedures to access records of flagged patients such as employees or famous individuals) when retrieving data for a patient that the EHR suspected was inappropriate for the user to access. Through the typical process of opening a restricted patient’s chart in the EHR browser, users must enter a reason for viewing the record but then are immediately granted access. These justifications are audited by security officials at the institution. Although carefully controlled, our developers devised an Epic-only feature that allowed users to provide a reason for accessing the patient record from within REDCap. In the case where CDIS is attempting to access multiple restricted records, users have the option of entering in one reason and explanation for all records, or to enter in separate justifications for each patient. These justifications are available for audit and users may be held responsible for any inappropriate access.

2.9. Controlling Access to CDIS Modules

Electronic health records are sensitive data. Ethically, the clinical research enterprise must protect the privacy of patients and research participants.[19] Privacy or security breaches could also result in hefty fines or loss of reputation for the institution.[20] Our goal in creating CDIS was to create additional tools and operational efficiency for researchers, while ensuring data extracts were immediately stored in a HIPAA-compliant data ecosystem. We also sought to standardize the processes for regulatory review and approval of research projects requiring EHR data. Before creating any new informatics self-service tool, we usually engage local experts and key informants from human subjects, privacy, and cybersecurity. In this case, we also consulted with a group of Epic customers interested in clinical research to ensure direct FHIR endpoint connections and project extraction processes would not adversely affect performance of our production EHR system.

At Vanderbilt and all other adopting REDCap consortium partners, CDIS must be enabled by a REDCap Administrator using the REDCap Administrator Control Center. This allows local REDCap Administrators at each organization to ensure local authentication and launch procedures are in place before CDIS functionality is available to researchers. Administrators can also enter institution specific information that users can view such as links to local policies and CDIS study-specific activation requests (usually a REDCap survey managed by the REDCap support team). Within the CDIS framework, CDP and CDM modules can be enabled or disabled independently by the local REDCap Administrator and the decision to authorize use for a specific project requires Administrator approval. This multi-tiered level of access control gives full autonomy to local research informatics teams.

For VUMC investigators, we also designed a real-time automated algorithm to allow project-level access to CDIS module functionality depicted in Figure 8. First, the REDCap user’s credentials are checked to ensure the user has EHR access privileges. Next, the REDCap project’s registered IRB number is checked against the local IRB record system to ensure the project has an active IRB approval. Finally, the REDCap username is checked against the list of current “key study personnel” registered for the IRB study associated with the REDCap project. If any one of the checks failed, the REDCap EHR connection is immediately blocked. This is all done using a custom web service with which CDIS can optionally interface if a given REDCap institution wishes to employ additional permission checks for users utilizing the CDIS services.

Figure 8:

Real-time algorithm for establishing CDIS connection between REDCap and EHR at VUMC.

End-users inherit access rights only to data that their EHR access allows them to access. Access logs are kept by both the EHR and by REDCap should auditing become necessary. REDCap monitors and logs when users view and access data that has been stored in a REDCap project, including EHR-imported values, and for values that have been imported but not yet saved formally in a REDCap project using the CDP service, REDCap additionally logs the data being viewed by a user prior to adjudicating such data. This provides an extra layer of logging on top of REDCap default audit trail capabilities.

2.10. Technical considerations

Back-end connectivity between EHR FHIR endpoints and REDCap must be established before activating CDIS. At Vanderbilt, our Health IT team enabled FHIR web services and registered a new FHIR App Client for CDIS with Epic. This App Client is available for Health IT access and registration at any Epic institution. The registration of this App Client is required for Epic to accept web service connections from any third-party client. Once the FHIR App Client was established, the Health IT team provided Client App token identifiers and “secret” workflow and data exchange connectivity tokens to be stored in the accessing application (REDCap). We were able to configure the client to use OAuth2 authorization with refresh tokens enabled to ensure persistent connectivity between REDCap and Epic. To avoid burdening providers with multiple logins, we configured REDCap to accept the EHR login using the OAuth2 protocol. The first time a specific EHR user invokes REDCap within the EHR workflow, the CDIS module requests that the user login to REDCap to link a user’s REDCap and EHR accounts.

When testing CDIS with our early adopters, we had to determine a proper strategy for maintaining the integrity of data in REDCap. Because CDIS allows for only unidirectional data transfer from the EHR to REDCap, all data validation steps are performed in REDCap. If the connection between REDCap and the EHR fails during a transfer, no data is added to the project and REDCap will reattempt the API call once the connection is reestablished. With all transfers, REDCap will check to see if the incoming EHR data already exist in REDCap. If the data already exist, REDCap will skip over that record to ensure that the data is consistent. If data is changed in the EHR for a repeating data element such as a lab value or vital signs measurement in a CDM project, a duplicate repeating instance will be created with the changed data. Therefore, it is incumbent on the user to resolve conflicting data in a CDM project, such as two blood glucose measurements with different values but the same timestamp.

2.11. Evaluation

We performed an initial evaluation of CDIS by measuring the extent of its use among research teams at VUMC and UT Southwestern. To calculate statistics, we used reporting capabilities built into REDCap to count the number of projects, records, and data points collected for CDIS projects from the beginning of CDIS implementation on May 1, 2018 to November 30, 2020. To measure the growth of CDIS use at other institutions, we used data from the Epic App Orchard[18] to track how many institutions requested the REDCap application, when those institutions first pulled data from their Epic production environment into REDCap, and how many total Epic FHIR API invocations those institutions made.

3. Results

As of November 30, 2020, the CDIS services have been implemented for 82 projects at VUMC. Among these, 55 are clinical data pull projects and 27 are clinical data mart projects. These projects have transferred over 19.5 million data values from the EHR system to REDCap. Figure 9 shows the growth of projects, patients with data imported by CDIS, and data points imported by CDIS over time. VUMC users first started creating CDP projects in July 2018 and started creating CDM projects in March 2020.

Figure 9:

Numbers of projects, patients, and data points collected from the EHR at VUMC by CDIS by month

At UT Southwestern, 17 projects used CDP to pull 45,724 data points for 5181 records from October 2018 to November 2020. As with VUMC, and UT Southwestern saw growth in CDIS usage over time as indicated in Figure 10.

Figure 10:

Numbers of projects, patients, and data points collected from the EHR at UT Southwestern by CDIS by month

Twenty-six other institutions using Epic have implemented the module and 38 additional organizations are in the process of implementing. Among the Epic institutions that have implemented CDIS in their production environment, REDCap has invoked the FHIR API 512,829 times from October 2019 to September 2020. Figure 11 shows the growth of requests for CDIS among institutions with Epic EHRs over time. As of December 2020, REDCap is the most downloaded research app, second most downloaded free app, and ninth most downloaded of all apps on Epic’s App Orchard. Nine institutions with Cerner EHRs are also in the process of installing REDCap CDIS.

Figure 11:

Institutions with the Epic EHR that requested and implemented CDIS cumulatively by month since requests on the App Orchard began in February 2019.

The most common FHIR resource used by CDIS users depended on whether they were collecting data using CDP or CDM. Figure 12 shows the proportion of data by FHIR resource. CDP projects were typically built around case report forms and pulled more patient demographic data. Meanwhile, CDM projects pulled more observation data such as vital signs and laboratory values, medications, and conditions.

Figure 12:

Proportion of data values collected in CDIS at VUMC and UTSW by FHIR resource.

Qualitatively, we see a variety of medical specialties using CDIS. While most projects thus far have come from critical care use cases, we have also seen projects initiated by clinicians in Allergy, Pulmonary, Cardiology, Gastroenterology, Hearing and Speech Sciences, Infectious Disease, Medical Oncology, Medicine, Microbiology, Neurology, Nursing, Orthopedics, Pediatrics, Pharmacy, Psychiatry, Rehabilitation Services, and Surgery. Additionally, we have used CDIS to build a COVID-19 Recruitment Data Mart to proactively identify trial participant candidates from our outpatient population for three concurrent COVID-19 trials.[21]

4. Discussion

4.1. Lessons Learned

We successfully created and deployed FHIR-based EHR data extraction services, enabling researchers to map and automatically extract EHR data for use in the REDCap EDC system. We also proved that CDIS can be deployed and operationalized at other institutions using Epic. At VUMC and other institutions that have implemented CDIS, millions of data points on hundreds of thousands of patients have been pulled in real-time from the EHR. Every record pulled through CDIS is one fewer that had to be entered through a more error-prone, less efficient, or less secure manner. CDIS has decreased the need for data to be manually transcribed, copied and pasted, or uploaded as a flat file into REDCap. The growth of projects using CDIS at VUMC and UT Southwestern shows that researchers are initiating and running their own projects. Aside from the initial effort to set up CDIS, there has been no need for project-by-project involvement of Health IT in these research projects that collect data from the EHR.

CDIS is enabling EHR to EDC data transfer at institutions that never had that capability in the past. By enabling direct transfer of data from the EHR to REDCap, CDIS makes it possible for smaller healthcare organizations without a research database to create registries and participate in pragmatic inter-institutional studies where EHR data is needed. Furthermore, data latency is no longer an issue since FHIR service calls allow realization of real-time data extraction immediately after entry in the EHR.

Additional guidance on the REDCap CDIS setup and functionality is available at https://rocket.app.vumc.org/index.php?doc_id=21968. All REDCap distribution source code is available at no cost to REDCap Consortium partners including code for CDIS described in this manuscript. The only minimum system requirements for CDIS are that the EHR system has enabled the FHIR API services, and that the REDCap server is on the same network or is able to reach the EHR FHIR server. An Epic Client App is available through the Epic App Orchard (search for “REDCap”). REDCap consortium members with Cerner can find installation guides within REDCap Control Center and support for setting up the Cerner to REDCap connection is available on the REDCap Community website.[22]

Developing CDIS not only yielded a product that can improve the efficiency and accuracy of research data collection; it also taught us about the technical, policy, and governance challenges of implementing technology that interfaces with EHRs. Engaging the right institutional leadership and informatics staff was paramount in developing CDIS. We were able to rally organizational support because of the collegial relationship between informatics and IT, and willingness by developers at Epic to think about integration with REDCap from a vendor perspective.[23] Pairing research infrastructure with clinical operations infrastructure required technical parity in terms of development, testing, and production systems integration. Engaging IT staff from the beginning of implementation was also essential for success. Anecdotally and at UT Southwestern, implementation can take as little as 4 hours if Health IT staff and REDCap administrators sit down for a focused session to set up CDIS. A focused implementation session is highly preferred to sending emails back and forth, which can take months from project initiation to project completion.

From a technical standpoint, we learned that there is value in selecting the FHIR resources with the greatest impact. We started CDIS development with DSTU2 and a select set of data types prioritized by experience with research data management: Demographics, conditions, medications, vital signs, and laboratory measurements. These data types represented a high percentage of those requested by researchers in completing case report forms (CRFs). Even with the right resources selected, figuring out the best representation for the data would ensure that users are not overwhelmed with data. The FHIR API payload contains much more information than what we save in REDCap. We were careful to include all information needed to enable our use cases, while excluding any extraneous data that was not useful for researchers.

We also learned important lessons in regulatory and governance considerations when it comes to developing applications that extract data from the EHR with FHIR APIs. Direct extraction of data from EHR systems has great advantages to research teams, but also carries privacy risks. To limit risks, external applications should establish linkage, if possible, to institutional source systems (e.g. clinical trial management system, IRB system). At Vanderbilt, we built a restful API service that confirms person-level EHR login rights, REDCap login rights, REDCap project permissions, IRB project approval status, and key study personnel status each time an end user logs into a FHIR-enabled REDCap project. In addition to having guardrails, data permissions need to be properly managed. Data permission rights are set at the project level (through mapping processes previously described in this manuscript), but also inherit rights and limit controls from the EHR system. Individuals cannot generally pull data via HL7-FHIR services that they would not otherwise be able to view in the medical record. EHR controls such as “break the glass” operations for employees and VIP-flagged patients are preserved in our extraction methods. Finally, involvement of the IRB is a critical part of the process. We discussed the new REDCap module and associated data extraction services multiple times with VUMC IRB leadership and were assigned an analyst who participated in research project consultations and helped design standard procedures for review and approvals. This helped ensure we were maximizing protection of research participants while minimizing burden to researchers. The IRB also assisted in writing protocol and amendment language that researchers could reuse.

Just because we built something functional does not mean users were ready to take advantage of the new functionality right away. We learned that socializing a complex new EDC feature requires hands-on support at the individual project level. We promoted the new FHIR-based services using education seminars and the VUMC StarBRITE researcher portal,[23] and supplemented our weekly REDCap walk-in clinics with consultations by request for EHR data extraction support. These one-on-one meetings helped to ensure research teams were aware of features and provided valuable feedback to our development team about real-world study needs. To avoid distractions, we declined requests to incorporate data types outside our initial offerings (demography, medications, problem list, allergies, vital signs, and laboratory measures) until we were able to test and operationalize the general framework on multiple production research projects. Individual research team training sessions allowed our team to understand complexity and coverage for data mappings and research team data management workflows. This led directly to a REDCap ‘Mapping Helper’ functional product used in setting up projects that takes as input a single medical record number and returns all LOINC codes associated with that MRN over a relevant period. This functionality can be easily used by our REDCap trainer and a research coordinator to minimize time needed for mapping individual data fields between the EHR and REDCap. While CDP was developed first, early work with research teams frequently requested the functionality now available in CDM. Finally, by listening to research team questions about data, we have developed a prioritization queue of new data elements (e.g. clinical notes) to add to the mapping and implementation roadmap.

Building on our experience disseminating REDCap, we have also learned lessons about disseminating CDIS that are unique to a product that integrates with EHRs. As we began sharing CDIS services outside of VUMC, we found partners often asked similar questions about technical and regulatory hurdles. In addition to improving the guidance for implementation embedded into REDCap, we started bi-monthly “office hours” conference calls open to any REDCap consortium members that had questions about CDIS. These calls were staffed by a CDIS developer and an analyst. After initiating these calls, we saw a decrease in the amount of time sites took to go from requests to deployments in the production environments of their respective EHRs. Research collaborations with other institutions were also critical to testing and launching the CDIS module. Our earliest research collaboration included sharing mappings with a team at UT-Southwestern for a multi-center project where both Vanderbilt and UT Southwestern were participating. We found that 80% of the EHR-REDCap mappings set at Vanderbilt transferred to the UT Southwestern EHR. Later, we were able to secure funding for a multi-center grant leveraging use of the FHIR Module at four Epic partner sites and one Cerner partner site. This helped incentivize sites to join and helped our consortium support team learn how to engage and promote conversations between local Health IT teams, local REDCap teams, and local research leadership. The one driving factor in promoting adoption and uptake was realization by research leadership that setting up the module once would enable use for many studies, ultimately reducing the requirements for Health IT teams to engage in individual research project planning and implementation. After initial deployment at UT Southwestern and Vanderbilt, using direct connection with Epic engineers at Vanderbilt to support security token creation and sharing, we realized that large-scale deployment across many institutions would benefit from inclusion in Epic’s App Orchard. The App Orchard option helped streamline communication and raised the reputation and visibility of the REDCap platform and research domain work. Another part of our strategy for disseminating CDIS was to take advantage of every opportunity to present the technology to potential users and collaborators. Requests for CDIS and attendance at office hours increased following each event. As of December 2020, we have made presentations about CDIS to the NIH Collaboratory, the Center for International Blood and Marrow Transplant Research, and the American Medical Informatics Association.

4.2. Upcoming CDIS features

We are continuing to improve and adapt CDIS based on feedback from the research community at VUMC as well as our consortium members. CDIS currently supports the DSTU2 version of the FHIR standard. With the newer R4 becoming widely implemented across most EHR systems, we will be adding R4 resources such as encounters and appointments in an upcoming version of REDCap.

Another highly requested feature by CDP users is to have the ability to automatically adjudicate preselected values using mapping modifiers to guide computational choice. After a requisite round of testing on multiple study participants, we will allow research teams to select auto adjudication mode to reduce burden on research staff by eliminating the step of having to log into REDCap to adjudicate values whenever new data are available.

With the increasing popularity of CDIS at VUMC, large clinical data mart projects with many patients and a large number of records are starting to affect the performance of the EHR’s API. Future versions of CDIS will take advantage of Bulk FHIR Data Access, where a large amount of data can be transferred in on a single request instead of the current model where each patient and each resource requires a separate request.[24] CDIS with Bulk FHIR will improve CDM performance for data transfers that involve many patients and many endpoints. We are also looking at patient OAuth2 functions allowing patients to authenticate into a patient portal to give explicit approval for use and transfer of medical data to the EDC.

From an evaluation standpoint, we are designing studies to collect quantitative data for the time saved and errors reduced by CDIS. For a clinical trial where the workflow is for study coordinators to enter data into a case report form from the EHR, we will observe how much time was spent entering data using EHR and REDCap access logs. We will then collect the same data using CDIS and determine, through manual review, the level of agreement between the human curated data and the CDIS collected data. Studies such as these will provide us with more evidence that CDIS is improving the efficiency and accuracy of clinical research data collection.

4.3. Limitations

While FHIR is an interoperability standard adopted by many EHR systems, the extent to which data elements are available via FHIR varies greatly from institution to institution. Availability of FHIR services from the EHR varies by EHR vendor, EHR version, and local Health IT teams ability and willingness to enable those FHIR services. CDIS configuration requirements, such as those that affect how EHR systems establish and maintain FHIR-client sessions or how specific components of FHIR domain services are enabled, also vary by EHR vendor, version, and local software customizations.

Due to the rapid and iterative nature of software development within the REDCap consortium, we were not able to follow a rigorous qualitative process for guiding the development of CDIS or evaluating its usability. With software developed for clinical research and available at no cost, users “vote with their feet”, and will only use software that improves their processes and is well-designed for their needs. Therefore, we believe that usage statistics are an appropriate metric for usability in this case.

We rejected one stakeholder use case as being out of scope for CDIS development. A common request among research teams was to write data to the EHR in addition to reading data from the EHR. Given strict regulatory and institutional policies regarding what data can become part of the medical record, we decided this was beyond reach for most organizations. However, we will continue to assess the research landscape and consider this feature for future implementation.

Non-Epic institutions constitute a minority of CDIS module users to date. We have partnered with REDCap institutions using Cerner to test the CDIS workflow and hope to find partners using other EHR systems. Differences in FHIR implementation, especially persistent connectivity, across EHR vendors offers an additional challenge. Although we have described our methods here in the context of Epic software, we believe the processes required for setup will generalize to other EHR systems.

5. Conclusion

We established a generalizable real-time data exchange between a vendor EHR system and an electronic data capture system (REDCap) in a scalable manner that supports many concurrent research projects with little project-specific investment by an institution’s Health IT enterprise or REDCap Administrators. By leveraging HL7 FHIR standards, we were able to develop a new REDCap module that enables data extraction for traditional CRF-based studies, registries, and data marts. The module has been used in many high-profile studies at Vanderbilt University Medical Center and has been disseminated to many REDCap institutions. Implementation and testing of the module with other EHR vendor systems is ongoing and we are exploring data mapping options for additional FHIR Resource domains, including clinical notes and medical device data. REDCap is developed around the concept that “used systems get better”. We are excited about the prospect of building innovative use cases and iteratively improving CDIS functionality based on feedback from REDCap Consortium members, ultimately with the goal of improving the efficiency, accuracy, and safety of clinical and translational research across the globe.

Highlights.

• REDCap has a new Clinical Data Interoperability Services (CDIS) module that collects data from electronic health records (EHRs).

• CDIS uses application programming interfaces (API) that adhere to the HL7 Fast Healthcare Interoperability Resources (FHIR) standard.

• Clinical researchers are able to set up projects, map EHR data to REDCap fields, and adjudicate data transfer on their own without involvement from informatics staff.

• The module supports single or batch data pulls from the EHR.

• The module is in use with both Epic and Cerner EHR systems.