No programming, networking, or project development experience is needed to use REDCap. Users can create and manage projects via a point-and-click web interface or by creating a template file in Microsoft Excel or LibreOffice, called a "Data Dictionary,” which can easily be uploaded into the application.
Any publication that results from a project utilizing REDCap should use the following citation:
Study data were collected and managed using REDCap1 electronic data capture tools hosted at the University of Illinois, Urbana-Champaign, with the support of the Interdisciplinary Health Sciences Institute and Research IT – Technology Services. REDCap (Research Electronic Data Capture) is a secure, web-based application designed to support data capture for research studies, providing: 1) an intuitive interface for validated data entry; 2) audit trails for tracking data manipulation and export procedures; 3) automated export procedures for seamless data downloads to common statistical packages; and 4) procedures for importing data from external sources.
1Paul A. Harris, Robert Taylor, Robert Thielke, Jonathan Payne, Nathaniel Gonzalez, Jose G. Conde. Research electronic data capture (REDCap) - A metadata-driven methodology and workflow process for providing translational research informatics support, J Biomed Inform. 2009 Apr:42(2):377-81.
Illinois REDCap is not intended to be a long-term repository or warehouse for project data. Principal Investigators and/or designated Project Administrators will be contacted by the IHSI REDCap team on a regular basis to confirm that the project is still active. If a project is no longer active, the IHSI REDCap team can meet with relevant members of your research team to discuss options for data storage, migration, etc. We consider a project to no longer be active if new data has not been entered into a project in one year.
Once a user is added to Illinois REDCap, the user will be visible and can be assigned through the “User Rights” portal in each project. The name and email of anyone that is a user in Illinois REDCap will appear in a dropdown list as their name is being typed in the “Add new user” or “Assign new user” boxes.
You cannot prevent a user from viewing selected fields (such as those containing high risk data), but you can prevent a user from viewing selected forms. Therefore, to restrict a user from viewing specific data fields, you must first group all the sensitive fields into a form, then set the user’s data entry rights for that form to “No Access.” This will prevent the user from viewing the entire form. See “Required Strategies to Maintain Security of Research Data in Illinois REDCap” in Protecting High Risk Data.
For more information, see User Rights and Roles.
Data Access Groups are used to restrict viewing of data within a project. Data Access Groups are commonly used in multi-site studies so that users can view data from their own sites but not from other sites. When users are assigned to a data access group, they can only view data entered by users of the same group.
See Protecting High Risk Data and follow the steps for exporting research data under “Required Strategies to Maintain Security of Research Data in Illinois REDCap.”
Date shifting is a method of de-identification in REDCap. During data export, dates in the project may be shifted up to 364 days back in time so as not to reflect actual dates. When data shifting is enabled, dates are shifted by a consistent length of time for each record, thus preserving the interval between dates. For example, if a participant, Mary, had three sequential appointments with actual dates of April 2, April 15 and April 26, when the dates are shifted, Mary’s appointment dates may appear as November 16, November 29, and December 10.
Date shifting, if enabled, leaves the record intact and will not affect the actual saved dates in the project. It merely alters the dates in their resulting format when performing a data export in REDCap.
Date shifting is important for de-identification because dates, like name and social security number, are identifiers that can be used for identifying an individual and thus possibly exposing confidential personal information. Date shifting prevents any dates from being used as identifiers for each project record while preserving the interval between dates. For more about de-identification, see Protecting High Risk Data.
REDCap does not auto save during data entry mode. It is highly recommended that users save their data early and often.
- “Save Record” will save the data entered and return the user to the main data entry screen, where the Participant ID was entered.
- “Save and Continue” will save the data entered and refresh the page so data can continue being entered on this page.
- “Save and go to the Next Form” will save the data and take the user to the next form but will only appear if there is more than one data entry form in the project.
REDCap will auto save between forms and pages when participants are taking surveys. Because of this, it is recommended that you set the Question Display Format to “One section per page” under “Survey Settings.”
Development vs. Production
No real data should be entered while a project is in development since it is easier to accidentally delete or corrupt data while in development. Additionally, the IHSI REDCap team will delete all test data when a project is moved from development to production.
You will be prompted to delete all test data when you request to move your project to production. If you do not delete the test data, the IHSI REDCap team will do so prior to moving the project to production.
It is highly discouraged to modify a project once in production. It is critical that research teams test projects thoroughly while in development. However, in-production changes can be made automatically if your project does not contain any records OR if the changes you make in draft mode (of production mode) do not contain any potential critical issues (e.g., deleting fields, re-coding multiple choice field options). Any other changes will require IHSI REDCap team approval.
Altering a project that is in production can cause data loss. It is critical that research teams test projects thoroughly while in development and it is highly discouraged to modify a project once in Production.
However, if a production project must be modified, follow these rules to protect your data:
- Do not change existing variable names, or data stored for those variables will be lost.
- Do not change existing form names via a data dictionary upload. Form names may be changed within the Online Designer without data loss.
- Do not modify the codes and answers for existing dropdown, radio, or checkbox variables, or existing data will be lost or confused. It is only acceptable to add further choices to a dropdown, radio, or checkbox field.
For more information, see Making Changes in Production.
In development is the status for projects as they are being built and while test data is being entered. This stage allows the research team to confirm that all instruments, surveys, forms, branching logic, and so forth, present as they should. Projects should be moved into production when active data collection is going to start, either by participants accessing surveys or through researchers entering data into the database. Projects should be moved into production (rather than collecting data while still in development) because it protects the integrity of the data. It is harder to delete fields or change answer choices while a project is in production, which prevents data loss and protects data validity.
Yes. In fact, it is highly recommended that you export your practice data in order to test the use of this function prior to moving your project into production. In development, all the applications function like they would in production; however, changes in production cannot be made in real time. As such, it is best to make sure you test your project thoroughly in development, including data export.
Research teams are expected to test projects thoroughly before requesting to move them to production mode. The Move to Production Checklist has been designed to help with this process. When you are ready to move your project from development to production, you will request this via Illinois REDCap.
The IHSI REDCap team will reach out regarding any pending requirements, including compliance documentation, before moving your project to production. At that point, you may begin collecting research data.
Note: The IHSI REDCap team does not review how projects are built or make any changes to project builds prior to moving projects to production. Research teams are expected to have tested the design and functionality of all forms and surveys prior to requesting that projects be moved to production.
- Branching logic cannot be applied at the section level (i.e., to skip an entire section). It must be applied to each field.
- In order to test the functionality of branching logic, you must enter new records and test data directly in your forms. Simply previewing a form will display all questions.
- REDCap can call variables from different forms as part of calculated fields or branching logic.
You can use html tags to modify survey text. Some common html tags include:
- Italics: <i>italicized text here</i>
- Underline: <u>underlined text here</u>
- Bold: <strong>bolded text here</strong>
You may also combine these tags, such as <u><i>underlined and italicized text here</i></u>. Because the question text, or field label, is already in a bold font, the strong tag is best used for answer choices.
Yes. Open the “Record Status Dashboard” under “Data Collection.” Select the record in question from the table. There will be a dropdown menu that says, “Choose action for record.” Open this menu and select “Delete record (all forms).” A pop up will appear asking if you are you sure you want to delete the data, since it cannot be recovered once deleted. It is important that not all users have the rights to delete records.