REDCap = Research Electronic Data Capture

• An easy-to-use data entry system, with data validation
• The ability to import data from external sources
• Automated exports to the most common statistical packages (SPSS, SAS, R, and Stata)
• Audit trails for tracking data changes and exports
• Branching logic, calculations, and piping to increase functionality and personalization
• A sophisticated survey tool for building and managing online surveys

There are 4 types of accounts, Basic and Full:

• A basic account is designed for people doing data-entry level tasks
• A full account is for people who need to do project design/management (would include any investigator or data roll staff who need to build a project)
• An Investigator account is reserved for IHR Principal Investigators that only require data-entry privileges and do not need to create projects (if the PI will be creating projects, a Full Account training must be completed)
• A Data-Role account is for Data Specialists, Analysists, and Biostatisticians who will not be creating projects but managing their data

The functional difference is that the full account gets the “Create Project” feature; however, if someone with a basic account has been given project design or user rights privileges in a project, they will need additional training to get a full account.

All new IHR REDCap account requests will require formal training before being granted by the IHR REDCap Administrative team. Please contact the REDCap Administrative team to request access to the appropriate training for your role by emailing Project_REDCap@kp.org

Account creation at KPCO IHR goes through the REDCap Admin Team by:

1. User submits a request to the REDCap admin team email at (Project_REDCap@kp.org) to request access to the appropriate training.
2. After training is complete, user submits an account request to the REDCap admin team email at (Project_REDCap@kp.org). Following training and administrative approval, user will receive an automated email from REDCap prompting them to set up their account.

Account users will then need to:

• sign in to REDCap
• set up an account password
• set up two factor authentication
• send their username to their project manager to be added to the desired project

Accounts will be automatically suspended after 90 days of inactivity. Passwords must be updated every 120 days and the 5 most recently utilized passwords may not be reused.

Universal REDCap Best Practices provide guidance that users shall only be granted the minimal amount of user rights necessary to complete their job duties within REDCap and that defined user roles should be created for each level of access (e.g., Admin, Data Entry, Data Analysis, PI Review).

PHI Considerations

It is especially important to consider the security of any PHI housed within your project. Only users that must be able to review this PHI should have the ability to view and export this data. If your project users include external collaborators, you must consult with your study PI/PM to align these user rights with your study data agreement(s) before granting project rights to external users. If your project must include these users, but your data agreement(s) are still pending, you must restrict data access/exports from these users until your data agreement(s) are fully executed.

PI/PM: Granting User Rights

It is incumbent upon the project PI/PM to exercise discretion when granting user rights within the project. If the PI/PM are not involved directly in the REDCap project build, they must be consulted about user rights prior to moving the project into production.

Data Access Groups (DAGs)

Data Access Groups (DAGs) should be created to help separate users and the data they enter by placing users into 'data access groups', after which they will only be able to access records created by someone in their group.

This feature is especially helpful in certain situations, such as for multi-institutional projects where the data entered by one institution should not be accessible or viewable by other institutions with access to that same project.

Beginning in 2020, user roles must be created prior to a project being moved into production. Each user within the project must be assigned to the appropriate role for their project duties.

The IHR suggests the following user roles be created within each research project:

Standards/best practices recommended to all users include, but aren’t limited to:

• The record ID must be the first variable of the first form (Can be changed to study ID, MRN etc.)
• Keep variable names short, succinct, and meaningful (must be less than 26 characters to avoid truncation)
• Use multiple choice questions where possible
• Minimize the use of free response fields
• Use field notes to help the data enterers enter information correctly
• When using free text fields, ensure validation of the data type whenever possible (e.g., date, zip)
• Keep forms short, with similar types of data grouped together
• Limit the use of calculations and never use stacked calculations (calculations that include other calculated fields)
• Be consistent in the coding of multiple choice questions (1, 2, 3, 4 etc.)
• Use the 1-Yes 0-No/1-True 0-False convention
• Use large, negative numbers for answer choices like NA or Other (e.g., 00, 999)
• Minimize the use of required fields in surveys
• Test projects thoroughly, including all branching logic, calculations, and piping; send test surveys both to yourself and to different email domains (e.g., gmail); practice data entry on a longitudinal project; have other team members practice data entry and pulling data from the project to make sure it is functional
• Ensure variables are broken into appropriately separated fields for analysis (e.g., address, city, state, zip)
• Set up data quality rules
• Ensure that all appropriate REDCap forms/instruments are sent to project manager for review by IRB
• Take frequent snapshots of the data dictionary
• Be consistent in how questions are framed
• Use validated instruments from the REDCap Library where possible
• Be conscious of copyright issues when using pre-existing forms and translate them as exactly as possible from their paper formats; be aware that if they cannot be properly translated, they are no longer validated instruments
• Flag identifiers and limit who can access and export them (e.g., deidentified vs. full data set)
• Be consistent in coding your variables (code to recognizable terms) (e.g., phq9 q1, phq9 q2, etc.)
• Variable name should not be changed once data collection has begun- this will corrupt your data
• If you have multiple questions that will use the same answer choices, code them all the same
• Ensure data roles are created and users appropriately assigned with the minimal required rights
• Consult with Biostatistician for Randomization Setup
• Utilize File Repository to upload/organize documents
• Utilize E-consent framework & Auto-archiver for all participant consenting
• Utilize Auto-archiver for surveys
• Confirm ALL automated settings PRIOR to moving project into production
• Ensure any safety alerts are built PRIOR to moving into production
• Ensure reports that guide workflow are built PRIOR to moving into production
• Ensure survey settings are finalized PRIOR to moving into production
• Ensure IRB number is included for any IRB approved projects
• Above all, consider carefully how the data you collect will be used in analysis and code variables appropriately. Make sure to consult, if possible, with the data analyst/statistician who will be reviewing data on the back-end
• Under no circumstances may real data be collected and/or stored in a REDCap project prior to production status

All projects must be moved to production before data collection begins. Users wishing to move projects to production must email the administrative team at Project_REDCap@kp.org with the request OR a request will automatically be sent when they attempt to move the project to production.

When a user submits a request to move to production:

1. Project user rights are reviewed and adjusted if necessary
2. A copy of the data dictionary will be downloaded
3. Admin team will run the macro "CheckMate"--Checkmate alerts the admin team to likely identifiers and text fields that require validation. A list of any errors requiring correction will be sent to the requesting user. After errors have been corrected, the user will resubmit a request and the admin team will perform another check
4. Presence of the IRB number will be verified
5. Admin team will delete all existing data in the project as no real data should have been collected prior to production mode. If you would like to keep your test data in the project, please download it prior to production and re-import it once in production
6. The project is moved to production by the admin team

Standards/best practices recommended to all users include, but aren't limited to:

• DO NOT delete/rearrange events once real data exist in your project - this can result in deletion/data scrambling
• DO NOT alter your existing automations once real data exist in your project - any changes will ONLY apply to new records, not existing records
• DO NOT rearrange survey questions/answers once real data exist in your project - this can result in deletion/data scrambling/alteration of existing survey responses
• AVOID making any major structural changes to your project once it is in production (this does not include minor survey question adjustment, aesthetic changes etc.)
• Utilize Data Quality Rule H to update calculations in instruments
• New instruments must be assigned to events in longitudinal projects
• Download your current data set at least monthly AND before any large data imports
• PRIOR to making any major changes to the structure of your project, make a copy of your project, including the dataset
• Consult the REDCap Admin Team PRIOR to making any major changes to your project to formulate a sound plan - Admin team must approve any changes that could alter existing data

In general, REDCap project maintenance (adding/removing users, maintaining forms, managing reports and exports, moving to inactive/archived, making sure data quality rules are used where appropriate, etc.) is the responsibility of the project owner/project manager.

Changes that could potentially affect data require administrator approval, as does deleting a project. In these instances, the admin team will make certain the user is aware of the consequences before approving the action; the same principle applies for actions like moving forms around in longitudinal projects or deleting events.

The admin team also reserves the right to check user rights and adjust when necessary. The admin team is available for any questions at Project_REDCap@kp.org.

Project storage is the responsibility of the study PM/PI.

Projects must be moved to "analysis/cleanup" status if data collection is complete. This will disable most project functionality, although all collected data will remain intact. Once in Analysis/Cleanup status, the project can be moved back to production status at any time.

If you are finished with a project and wish to make it completely inaccessible, you may mark the project as 'Completed'. Doing so will take it offline and remove it from everyone's project list, after which it can only be seen again by clicking the Show Completed Projects link at the bottom of the My Projects page.

Once marked as Completed, no one in the project (except for REDCap administrators) can access the project, and only administrators may undo the Completion and return it back to an accessible state for all project users. Marking a project as Completed is typically only done when you are sure that no one needs to access the project anymore, and you want to ensure that the project and its data remain intact for a certain amount of time.

Project analysis/cleanup and completion are entirely up to the REDCap project managers, although they cannot delete a production project without administrator approval. It is the responsibility of all REDCap project owners/project managers, to ensure projects are appropriately organized and cleaned up when no longer needed. Please note: projects continue to be accessible in both the analysis/cleanup state and can be returned to production status with approval of the administrative team.

The KP Center for Health Research (CHR) currently manages/hosts both our REDCap Internal and DMZ instances on secure servers at CHR. CHR primarily sticks to a maintenance/upgrade schedule of every 3rd Sunday of each month. They use the Standard Support updates for system upgrades. These updates are more frequent and provide quicker resolutions to previous bugs and errors within REDCap. Bugs are reported to Vanderbilt as soon as they are discovered, usually through the REDCap consortium.

If you think you notice a bug in the system, please immediately notify Project_REDCap@kp.org with your findings. Any valid glitches will be directed to the Admin team at CHR for further investigation.

Please cite the publications below in study manuscripts using REDCap for data collection and management. We recommend the following boilerplate language:

If using the DMZ or External IHR REDCap, please cite your project when publishing manuscript using the following language:

Study data were collected and managed using REDCap electronic data capture tools hosted at [YOUR INSTITUTION]. REDCap (Research Electronic Data Capture) is a secure, web-based software platform designed to support data capture for research studies, providing 1) an intuitive interface for validated data capture; 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 data integration and interoperability with external sources.

Example Citations:

PA Harris, R Taylor, R Thielke, J Payne, N Gonzalez, JG. 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. http://www.sciencedirect.com/science/article/pii/S1532046408001226

PA Harris, R Taylor, BL Minor, V Elliott, M Fernandez, L O’Neal, L McLeod, G Delacqua, F Delacqua, J Kirby, SN Duda, REDCap Consortium, The REDCap consortium: Building an international community of software partners, J Biomed Inform. 2019 May 9 [doi: 10.1016/j.jbi.2019.103208] https://www.sciencedirect.com/science/article/pii/S1532046419301261

If your project uses the e-consent framework, please cite the following:

Lawrence CE, Dunkel L, McEver M, Israel T, Taylor R, Chiriboga G, Goins KV, Rahn EJ, Mudano AS, Roberson ED, Chambless C, Wadley VG, Danila MI, Fischer MA, Joosten Y, Saag KG, Allison JJ, Lemon SC, Harris PA, "A REDCap-based model for electronic consent (eConsent): Moving toward a more personalized consent", J Clin Transl Sci. 2020 Apr 3;4(4):345-353. https://doi.org/10.1017/cts.2020.30

If using UCD instance of REDCap, please acknowledge the support by CCTSI in any publications with the following text:

This [publication, patent, project] was supported by NIH/NCRR Colorado CTSI Grant Number UL1 RR025780. Its contents are the authors' sole responsibility and do not necessarily represent official NIH views.

¹REDCAP OVERVIEW: REDCap is a web-based application that consists of two major components: A PHP-based web application that runs on a web server and a MySQL database that runs on a database server. The REDCap web application allows authenticated users to create projects, design data capture forms, configure a multitude of product features, and collect, view, maintain, and export data. REDCap has a number of optional features that may be authorized on a per-project basis that add capabilities such as participant-completed surveys, mobile device access, texting support, API access, etc. REDCap includes a robust and fine-grained authorization model. More information about the REDCap software, which was created at Vanderbilt University and continues to be maintained by the Vanderbilt team, can be found at http://project-redcap.org/. The application development and code repositories are hosted by Vanderbilt University. The IHR instance of REDCap is hosted on the data center servers at the Center for Health Research in Portland, Oregon.

²EXAMPLE CONSENT/PROTOCOL LANGUAGE FOR PROJECTS UTILIZING REDCAP FOR DATA CAPTURE/STORAGE: 1) REDCap is being used to collect data from subjects. While Kaiser Permanente does not own or control REDCap, which is the web-based application supporting administration of the study questionnaire, the REDCap database is securely hosted on a DMZ server behind the KP firewall and requires unique username and password for entry.

2) The external instance of REDCap is now hosted on a DMZ server at the Center for Health Research. A DMZ (demilitarized zone), also sometimes known as a perimeter network or a screened subnetwork, is a physical or logical subnet that separates an internal local area network (LAN) from other untrusted networks, usually the internet. External-facing servers, resources and services are located in the DMZ. So, they are accessible from the internet, but the rest of the internal LAN remains unreachable. This provides an additional layer of security to the LAN as it restricts the ability of hackers to directly access internal servers and data via the internet. Additionally, IHR's REDCap project protocols limit data access to only approved users. Adherence to those protocols within the DMZ environment mean that it's safe to store PHI on the database server. While Kaiser doesn't own REDCap, there are privacy policies in place that forbid any use or trading of information collected/stored.

Data for Aim 2 will be collected and stored in REDCap. While Kaiser Permanente does not own or control REDCap, which is the web-based application supporting qualitative interview and focus group data, the REDCap database is securely hosted on a DMZ server and has privacy policies in place that forbid any use or trading of information collected/stored. Data stored in REDCap is accessible only by the study personnel that must provide a username and password to gain access.