Design Research Data Capture Tool

Mo Med. 2015 Jan-Feb; 112(1): 46–52.

Online Electronic Data Capture and Research Data Repository System for Clinical and Translational Research

Abu Saleh Mohammad Mosa

Abu Saleh Mohammad Mosa is the Director, Research Informatics, at the University of Missouri Institute for Clinical and Translational Science

Jerry C. Parker

Jerry Parker is the Associate Dean for Research, MU School of Medicine and Co-director, Institute for Clinical and Translational Science

This article has been cited by other articles in PMC.

Abstract

Data is at the core of any clinical and translational research (CTR). In many studies, the electronic data capture (EDC) method has been found to be more efficient than standard paper-based data collection methods in many aspects, including accuracy, integrity, timeliness, and cost-effectiveness. The objective of this article is to present a secure, web-based EDC system for CTR that has been implemented by the Institute for Clinical and Translational Science (iCATS) at the University of Missouri School of Medicine.

Introduction

In clinical and translational research (CTR),¹ questions are answered by analyzing relevant data. Data is at the core of CTR. Almost all CTR projects have a data management component that increases cost and decreases efficiency. The data capture strategy must ensure the quality of data in order to produce effective research outcomes.² In addition, the regulatory authorities for CTR, such as the Institutional Review Broad (IRB), require a secure, HIPAA-compliant data management plan.³ The objective of this article is to describe a secure, web-based application for CTR data management that has been implemented by the Institute for Clinical and Translational Science (iCATS)⁴ at the University of Missouri School of Medicine.

Traditionally, the standard method of data capture in CTR projects includes two steps. In the first step, data is collected using paper-based case report forms (CRFs). In the second step, data is manually entered into electronic databases from paper-based CRFs for the purpose of data analysis. This standard paper-based data capture method is inefficient in terms of data accuracy and timeliness. The alternative to the standard data capture method is the electronic data capture (EDC) method in which data is directly entered into electronic databases using electronic CRFs. In recent years, the adoption of EDC systems for CTR has greatly increased. For example, Emam et. al. (2009)⁵ estimated that about 41% of clinical trials used some form of EDC system during 2006–2007. The use of EDC systems increases data accuracy^{6 – 9}, decreases research-related costs^{6 , 7 , 10}, decreases overall data capture time^{6 , 7 , 9 – 13}, and ensures data integrity, security and compliance with HIPAA.¹⁴ In this article, we describe an online EDC and research data repository (RDR) system for CTR.

System Implementation

Figure 1 presents the system architecture and user interactions used at the iCATS. The system consists of three main components: an electronic data capture (EDC) system, a research data repository (RDR), and a security layer. The system interacts with the clinical data repository system for retrieving clinical data for IRB-approved research projects. The EDC system has three subcomponents: user management and access control, REDCap, and electronic research data delivery (ERDD) service. The main features and subcomponents of the system are discussed in the following sections.

EDC and RDR System Architecture and User Interactions

Electronic Data Capture System

User Management and Access Control

In the Electronic Data Capture (EDC) system, there are three user groups: super users, primary users, and secondary users. The super and primary users are required to create user accounts to access the system, whereas the secondary users are not. The system utilizes the university-wide federated access control service (known as the Shibboleth single sign-on authentication service) for authenticating the super and primary users. Accordingly, those users do not need to maintain separate accounts for the EDC system.

The super users are the employees of iCATS. They have two roles: system administrator and honest broker. The system administrator manages the EDC and RDR system, and the honest broker handles the data requests from various research teams. The honest broker is an individual who collects and provides PHI data to research investigators in an IRB-approved manner¹⁵. The primary users include the members of a research team such as project owners (e.g., principal investigators (PIs), co-principal investigators (co-PIs), co-investigators (co-Is), study coordinators, and scientists), data entry personnel, and data analysts. The project owners have access to the project management tools such as the project setup and CRF design module as well as all the applications within REDCap. The data entry personnel have the user rights to create or modify records, and the data analysts have the user rights to export de-identified data for data analysis purpose.

The secondary users are study participants including study subjects and survey participants. Study subjects can use the system to sign electronic consents. Any data collected from the study subjects are entered into the research database by the data entry personnel. Laboratory results can be either entered into the research database by data entry personnel or imported electronically from the Electronic Medical Record (EMR) system. If a project includes survey instruments, participants can record their responses through personalized URLs or a public URL.

Research Electronic Data Capture

Research Electronic Data Capture (REDCap)¹⁶ is the core component of the EDC system. REDCap, developed at Vanderbilt University (VU), is a secure, web-based informatics application for developing and managing online surveys and research databases for CTR. As of April 2014, the developer team at VU has collaborative support from 1,017 active institutional partners in 79 countries (known as the REDCap Consortium). REDCap has already been implemented in all of the NIH Clinical and Translational Science Award institutions.¹⁷ Figure 2 presents a typical workflow for the EDC process in REDCap.

A typical workflow in REDCap

Project Setup

The first step of the EDC process is project setup (see Figure 2). In CTR, data is captured from study participants. REDCap allows two types of data collection instruments: data entry forms and surveys. Data entry forms are intended for storing data that are collected by clinicians, researchers, or any designated data entry personnel at the study site. Survey instruments are intended for collecting survey responses from study participants. There are two data collection modes: classic and longitudinal. In the classic mode, data collection is carried out only once per study subject. In the longitudinal mode, data collection is performed multiple times per study subject.

Electronic Case Report Form Design

The second step of the EDC process is designing electronic Case Report Forms (CRFs) (see Figure 2). REDCap provides a simplified methodology for building research databases quickly and easily through the online designer module. The online designer provides functionality for CRF design through an intuitive user interface. The CRFs can be designed from "scratch" or downloaded from the shared library¹⁸. REDCap also allows downloading the data dictionary that can be edited by experienced REDCap users and uploaded to REDCap to reflect the changes in the CRF design.

To further facilitate CRF design, there are 12 types of fields in REDCap that allow many types of data capture for CTR. Section separators with header text can be used to organize the fields into sections. Table 1 presents the field types and their properties in REDCap. The design of a field is defined by various field properties: "Field Label" defines the question or label for a field in CRF; "Variable Name" is used for data export and data analysis; "Validation", "Minimum" and "Maximum" field properties are used for performing validation on text inputs and ensuring data integrity; "Required" indicates that the field is a required field; "Identifier" indicates that the field contains personally identified information or Protected Health Information (PHI); "Alignment" defines the position of the field in the CRF; "Field Note" allows the display of short instruction on a field; "Choices" defines the pre-defined input for a field; and "Equation" defines the equation for the calculated field.

Table 1

Field Types and Field Properties

Field Properties	Label	Variable Name	Required	Identifier	Alignment	Field Note	Validation	Minimum	Maximum	Choices	Equation
Field Types
Text Box (Short Text)	✓	✓	✓	✓	✓	✓	✓	✓	✓
Notes Box (Paragraph Text)	✓	✓	✓	✓	✓	✓
Calculated Field	✓	✓	✓	✓	✓	✓					✓
Multiple Choice
Radio Buttons	✓	✓	✓	✓	✓	✓
Drop-down List										✓
Checkboxes
Binary Choice
Yes – No	✓	✓	✓	✓	✓	✓
True - False
Slider / Visual Analog Scale	✓	✓	✓	✓	✓	✓
File Upload (for users to upload file)	✓	✓	✓	✓	✓	✓
Descriptive Text (with optional image/file attachment)	✓	✓
Dynamic Query (SQL)	✓	✓	✓	✓	✓	✓

REDCap allows two types of text input: Text Box and Notes Box. The Text Box field allows single–line, short text input, while the Notes Box field allows for a large amount of text input up to 65,535 characters. The Text Box field can be validated for predefined text patterns such as data, time, email, integer, number, phone, and zip code; it also allows setting the minimum and the maximum values for validated text input. In addition, the Text Box field provides a date and time picker for date and time validation. The validation on text input improves data integrity by preventing invalid input. Thus, use of validation on text input is strongly recommended.

There are three types of multiple choice input: the Radio Buttons and Drop-down List fields allow single answer only; the Checkboxes field allows multiple answers. The choices in the multiple choice fields can be coded with numeric values for the purpose of data analysis. The Yes/No and True/False fields allow binary choice inputs; Yes and True values are coded as 1; No and False values are coded as 0. REDCap also has developed a Slider Bar or Visual Analog Scale in which the selection is between 0 and 100. The File Upload field allows end users to upload any files type. The Descriptive Text field allows displaying text with an inline image. The Dynamic Query field, available to super users or system administrators only, allows creation of SQL Select statements to populate drop-down lists.

Calculated fields allow users to define an equation to calculate a value based on data in other fields. Variable names of other fields are enclosed within square brackets to define the equations. An equation can be defined using 4 mathematical operations (add, subtract, multiple, and divide) and 12 functions (round, round-up, round-down, square root, exponents, absolute value, minimum, maximum, mean, median, sum, and standard deviation).

There are two other widely-used features for CRF design: matrix of fields and branching logic. In CRFs, a group of similar multiple-choice fields (either single-answer through radio buttons or multiple answers through checkboxes) can be displayed in a very compact manner by using the matrix of fields. This is a widely used feature in designing survey instruments. The branching logic is used for hiding/showing certain fields within a form based on the values in other fields. The attribute-value pairs are combined with logical operators (AND and OR) to define a branching logic.

Data Collection

While the project is in development mode, a strong recommendation is that CRFs be thoroughly tested and revised as desired before starting real data collection (Step 3 in Figure 2). Once the CRFs are tested and found satisfactory, the project should be marked as "production mode" before starting real data collection (Step 4 in Figure 2). Although modification of CRFs is allowable in "production mode", the recommendation is not to do so once data collection has started. In production mode, changes in CRF design should be reviewed very carefully to avoid potential data loss.

The project needs to be approved by the IRB before data collection can be started (Step 5 in Figure 2). The final step of the EDC process is data collection (Step 6 in Figure 2). To create new records or to modify existing records, primary users will need to have access to the CRFs with "create/modify records" user rights. The data is entered using the electronic CRFs through a web-based application and stored in the research database which resides in the RDR. Survey participants receive either a generic public URL or personalized unique URLs correlating each participant to record their survey responses. If a project contains both data entry forms and survey instruments, the survey responses are stored with the corresponding records of each participant to ensure data integrity.

REDCap Applications and Tools

REDCap provides several applications and tools for project management. Access to the applications is controlled based on a user role within the project.

The Calendar application allows maintaining a project calendar that helps to organize project schedules, especially for scheduling the study subjects' visit for longitudinal data collection. In longitudinal projects, study subjects are seen multiple times (called events) for data collection. The Scheduling Generator module can be used to generate the schedules based on the predefined events and stored in the project calendar. The study coordinator and the data entry personnel can greatly benefit from this application by ensuring on-time data collection.

The Data Export Tool allows users with appropriate access permission to export data from a project. The data export functionalities include exporting data in Microsoft Excel, SAS, Stata, R, or SPSS format for all or selected fields; data export also allows HIPAA-complaint de-identification; this tool is useful for the data analyst role. The Data Import Tool application is useful for project owners (e.g. PIs, co-Is, co-Is, or scientists) in order to import data from existing sources. The File Repository application enables the users to store, retrieve, or upload files and documents in a project. The previously exported data files also can be retrieved from this application. The Data Comparison tool can be used to compare two records in a project.

REDCap keeps track of all activities including data exports, changes in project design, and the creation, modification or deletion of users and data. The Logging tool is used for auditing all changes within a project. The Field Comment Log application allows the display, search, or download of comments associated with the fields. Records can be locked with or without E-signature, and the locked records can be managed using the E-signature and Locking application. The record locking options can be customized for individual CRFs using the Record Locking Customization application.

The Graphical Data View and Stats application displays descriptive statistics and aggregate results in graph form that can be used for data cleaning and evaluation. The Data Quality application has two functions: defining data-quality rules and executing those rules to check for discrepancies. There are some pre-defined data-quality rules available to every project such as missing values, missing values within required fields only, field validations for incorrect data types and out of range values, outliers for numeric fields, and multiple choice fields with invalid values. The Report Builder application creates and exports customized reports.

REDCap API: REDCap provides an Application Programming Interface (API) for exporting project metadata (e.g., data dictionary), records, files, events, and users; it also allows importing records and files in a secured and automated manner from external applications remotely. For example, connection is possible to REDCap from R software for retrieving the data and performing analysis.

Data Transfer Service

Data from external sources can be directly entered into REDCap projects through the Data Transfer Service (DTS). The process requires a user to map data fields from external sources to REDCap project fields. DTS loads data from external sources into REDCap in a periodic manner and makes the data available to the project owners for adjudication before saving into their projects.

Electronic Research Data Delivery Service

The Electronic Research Data Delivery (ERDD) service is available to researchers through the honest broker. The function of the honest broker is to deliver data from the identified database to researchers who have IRB approved projects¹⁵. The ERDD service enables CTR researchers to get clinical data, including protected health information (PHI) from the clinical data repository (CDR) system. The CDR system was implemented using an open source system called Informatics for Integrating Biology and the Bedside (i2b2)¹⁹ with the goal of secondary reuse of existing clinical data for CTR. The researchers can utilize the system for cohort identification, retrospective data analysis, and hypothesis generation. The CDR system has two databases: de-identified and identified databases. CTR researchers have aggregate access to the de-identified database. The aggregate access allows a researcher to query the de-identified database to generate a patient count based on inclusion and exclusion criteria. Once the data subset is identified for a CTR project, the researcher can submit an IRB application to get approval for data download. The honest broker then retrieves the data from i2b2 in electronic format and deposits the data into the research database through the REDCap data import tool.

The honest broker performs the ERDD service in four steps. First, data is exported from the CDR system for the requested query. Second, a CRF is created in REDCap for all the columns in the dataset. Third, the dataset is converted into a REDCap-importable format. Fourth, the dataset is imported into REDCap.

Research Data Repository

Research databases are stored in the Research Data Repository (RDR), which is built upon the MySQL database management system. The databases are designed through the electronic CRF design module. All the fields in the CRFs have unique variable names within a project and these are used for storing the data into the database as attribute-value pairs.

System Security Layer

The University of Missouri classifies PHI data (subject to HIPAA regulations) as Data Classification Level 4 (DCL4 – Highly Restricted)²⁰. The EDC system is secured with a DCL4 security layer that is maintained by the Division of IT at the University of Missouri.

System Usage and Discussion

Figure 3 presents the system utilization graphs for the past year (May, 2013 to April, 2014). The three charts show: (a) number of users, (b) number of projects, and (c) page hits. All of the graphs present a linear growth of system usage. Currently, the EDC system hosts 64 projects and involves 102 users. A total of 43 projects are currently active with 19 projects in production status and 24 projects in development status. Out of those 43 active projects, 35 projects contain survey instruments.

System Usage Charts from May 2013 to April 2014

(a) Number of Users

(b) Number of Projects

(c) Number of Page Hits

The web-based EDC system that has been implemented provides several benefits over traditional data collection strategies using paper-based CRFs. First, it facilitates the design of project-specific electronic CRFs with data validation and audit trail capabilities that reduces project-specific programming and improves the quality of data. Second, the EDC system allows federated authentication with role-based access control to facilitate collaborative access to data from anywhere at any time. Third, it can store data and project specific documents in a highly-secured central research data repository with scheduled backup service. Fourth, it allows importing bulk data from other systems and exporting data to common statistical packages for data analysis.

Currently, there are two semi-automated processes that could be fully automated. First, the data entry related to lab results requires manual data input into the REDCap project. The manual process is not user friendly for large projects, and it can be fully automated. In CTR, the study subjects are seen by clinicians at the study site who may collect some of their data through laboratory tests. Once the test is complete, the lab results are available in the EMR system. The DTS allows data from external sources (such as EMR) to be entered directly into REDCap projects. Currently, the process is underway to design the data mapping from EMR to REDCap to enable the DTS service. Second, the honest broker has to complete the four semi-automated steps for transferring the data electronically from CDR to a REDCap project. The future goal is to develop a fully automated process in which those steps are combined into a software application using the REDCap API and i2b2 web services.

There are limitations to implementing an EDC system based on REDCap. First, REDCap can host only small to medium sized projects because of its data storage design. Data is stored using the Entity–Attribute–Value (EAV) model, instead of the relational model. The EAV model allows metadata-driven project development, so it is not suitable for storing a large amount of data. Second, REDCap projects are partially portable; projects cannot be exported from one REDCap system to another. The only way to port a project is by exporting the data dictionary from a REDCap system and importing the data dictionary into another REDCap system. However, the project settings are not exported with the data dictionary. Thus, the project settings have to be applied manually. In addition, the exported data cannot be imported directly; it requires some modification to the data file. For example, the calculated fields cannot be imported. Third, REDCap API does not allow importing a data dictionary. Thus, the project fields cannot be created programmatically. As a result, the ERDD application must create a data dictionary first, and the honest broker needs to upload the data dictionary into the REDCap project requiring one manual step. Alternately, the ERDD application can be developed as part of the REDCap system, instead of developing a standalone application.

Conclusion

We have implemented an online EDC system for the CTR researchers at the University of Missouri. Adoption of the system has been increasing gradually. The EDC system allows the CTR researchers to collect, store, and manage research data electronically in a secure and HIPAA-compliant central research data repository; this can significantly reduce research-related time, effort, and costs so that CTR researchers can focus on data analysis and their research activities.

Acknowledgment

The authors are thankful to Win Phillips and Cynthia Haydon, University of Missouri School of Medicine, for their critical review of the manuscript.

Biography

•

Abu Saleh Mohammad Mosa (above) is the Director, Research Informatics, at the University of Missouri Institute for Clinical and Translational Science. Illhoi Yoo is the Associate Professor of Health Informatics, MU School of Medicine. Jerry Parker is the Associate Dean for Research, MU School of Medicine and Co-director, Institute for Clinical and Translational Science.

Contact: ude.iruossim.htlaeh@aasom

Footnotes

References

1. Rubio DM, Schoenbaum EE, Lee LS, et al. Defining translational research: implications for training. Acad Med. 2010;85(3):470–5. doi: 10.1097/ACM.0b013e3181ccd618. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

2. Krishnankutty B, Bellary S, Kumar NBR, Moodahadu LS. Data management in clinical research: An overview. Indian J Pharmacol. 2012;44(2):168–72. doi: 10.4103/0253-7613.93842. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

3. Nosowsky R, Giordano TJ. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) privacy rule: implications for clinical research. Annu Rev Med. 2006;57:575–90. doi: 10.1146/annurev.med.57.121304.131257. [PubMed] [CrossRef] [Google Scholar]

4. Institute for Clinical and Translational Science. [Accessed April 29, 2014]. Available at: http://icats.missouri.edu/

5. El Emam K, Jonker E, Sampson M, Krleza-Jerić K, Neisa A. The use of electronic data capture tools in clinical trials: Web-survey of 259 Canadian trials. J Med Internet Res. 2009;11(1):e8. doi: 10.2196/jmir.1120. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

6. Sahoo U, Bhatt A. Electronic data capture (EDC)--a new mantra for clinical trials. Qual Assur. 10(3–4):117–21. doi: 10.1080/10529410390892052. [PubMed] [CrossRef] [Google Scholar]

7. Lane SJ, Heddle NM, Arnold E, Walker I. A review of randomized controlled trials comparing the effectiveness of hand held computers with paper methods for data collection. BMC Med Inform Decis Mak. 2006;6:23. doi: 10.1186/1472-6947-6-23. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

9. Lal SO, Smith FW, Davis JP, et al. Palm computer demonstrates a fast and accurate means of burn data collection. [Accessed May 12, 2014]; J Burn Care Rehabil. 2000 21(6):559–61. discussion 558. Available at: http://www.ncbi.nlm.nih.gov/pubmed/11194811. [PubMed] [Google Scholar]

10. Walther B, Hossin S, Townend J, Abernethy N, Parker D, Jeffries D. Comparison of electronic data capture (EDC) with the standard data capture method for clinical trial data. PLoS One. 2011;6(9):e25348. doi: 10.1371/journal.pone.0025348. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

11. Walker I, Sigouin C, Sek J, et al. Comparing hand-held computers and paper diaries for haemophilia home therapy: a randomized trial. Haemophilia. 2004;10(6):698–704. doi: 10.1111/j.1365-2516.2004.01046.x. [PubMed] [CrossRef] [Google Scholar]

12. Tiplady B, Crompton GK, Dewar MH, et al. The Use of Electronic Diaries in Respiratory Studies. Ther Innov Regul Sci. 1997;31(3):759–764. doi: 10.1177/009286159703100317. [CrossRef] [Google Scholar]

13. Rivellese AA, Ventura MM, Vespasiani G, et al. Evaluation of new computerized method for recording 7-day food intake in IDDM patients. [Accessed May 12, 2014]; Diabetes Care. 1991 14(7):602–4. Available at: http://www.ncbi.nlm.nih.gov/pubmed/1914803. [PubMed] [Google Scholar]

14. Weber BA, Yarandi H, Rowe MA, Weber JP. A comparison study: paper-based versus web-based data collection and management. Appl Nurs Res. 2005;18(3):182–5. doi: 10.1016/j.apnr.2004.11.003. [PubMed] [CrossRef] [Google Scholar]

15. Dhir R, Patel AA, Winters S, et al. A multidisciplinary approach to honest broker services for tissue banks and clinical data: a pragmatic and practical model. Cancer. 2008;113(7):1705–15. doi: 10.1002/cncr.23768. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

16. Harris PA, Taylor R, Thielke R, Payne J, Gonzalez N, Conde JG. Research electronic data capture (REDCap)--a metadata-driven methodology and workflow process for providing translational research informatics support. J Biomed Inform. 2009;42(2):377–81. doi: 10.1016/j.jbi.2008.08.010. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

17. Shirey-Rice J, Mapes B, Basford M, et al. The CTSA Consortium's Catalog of Assets for Translational and Clinical Health Research (CATCHR) Clin Transl Sci. 2014 doi: 10.1111/cts.12144. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

18. Obeid JS, McGraw CA, Minor BL, et al. Procurement of shared data instruments for Research Electronic Data Capture (REDCap) J Biomed Inform. 2013;46(2):259–65. doi: 10.1016/j.jbi.2012.10.006. [PMC free article] [PubMed] [CrossRef] [Google Scholar]

Design Research Data Capture Tool

Source: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6170092/

Posted by: wallaceconces1968.blogspot.com

Share this post