����ԭ��

On this page:

• REDCap Use at WSU-affiliated Organizations
• Protecting PHI
• Managing User Rights
• Changes after production
• Citing REDCap
• Analysis/Clean up
• Frequently Asked Questions

REDCap Use at WSU-affiliated Organizations

Organizations outside WSU may use WSU’s REDCap system only if they have an affiliation agreement with WSU. Users from affiliated organizations must also have a WSU username and password (W#). These organizations may include hospitals and clinical practice sites subject to HIPAA requirements, particularly regarding the recording, storage, and sharing of Protected Health Information (PHI).

Project Setup and Review

• Use a REDCap template whenever possible when creating a new project. Templates include predefined WSU User Roles designed to limit access to research data and support HIPAA compliance. If an empty project is created instead, the recommended User Roles should be applied according to the WSU User Rights Table.
• Before a project is moved to Production, WSU REDCap Administrators will review it to confirm that:
  • Fields that may contain PHI are identified as Identifiers.
  • User rights appropriately limit access to and disclosure of PHI.
  • Project users are included in the applicable IRB materials.

Additional Protections for Clinical/PHI Projects

When a project is approved for Production, WSU REDCap Administrators will:

• Convert the project's WSU User Roles to the PHI-specific recommended roles.
• Remove users' ability to change User Rights or Data Access Groups, ensuring access to PHI is controlled by the Project Owner.
• Remove access to the File Repository to reduce the risk of unintended disclosure of documents containing PHI.
• Add a Clinical Site Auditor role to support clinical-site oversight and HIPAA compliance.
• Add a support user for the Project Owner when needed for project-design changes.
• Add the designated Clinical Site Auditor to the project.
• Add the clinical site's initials in brackets to the end of the Project Title (e.g., [ABC]). This allows WSU REDCap Administrators to identify, track, and report on projects by clinical site.

In short: Affiliated organizations can use WSU REDCap, but projects involving PHI are subject to additional user-access restrictions, administrator review, clinical-site auditing, and project-identification requirements.

Protecting PHI

What is PHI?

Protected Health Information (PHI) includes information that can identify a person and must be protected under HIPAA. In REDCap, identifiers include:

• Names, addresses, phone/fax numbers and email addresses
• Social Security, medical record, health plan, account, license or certificate numbers
• URLs, IP addresses, vehicle or device identifiers
• Biometric identifiers and identifying photographs
• Other unique identifying numbers, codes, or characteristics
• Dates more specific than the year

Important: Information that does not identify someone by itself can become identifying when combined with other details. Examples include a person's doctor or treatment location, gender, rare condition, workplace, occupation, income, education, family composition, ethnicity, age/birth year, or detailed free-text responses. This is sometimes called the “19th identifier.”

How REDCap Protects PHI

System-wide protections

REDCap at ����ԭ�� provides:

• Secure access: Users authenticate with their unique University W# and password.
• Controlled account creation: New REDCap accounts must be activated by REDCap Administration.
• Secure servers: REDCap operates behind a firewall on ����ԭ�� CaTS servers.
• Regular backups: Data are backed up on-site, with an additional off-site backup.

Project-level protections

Project Owners are responsible for controlling access to PHI within their projects.

• Grant access only when needed. Add only project team members who require access and set an expiration date when access is no longer needed.
• Use appropriate User Rights. Restrict who can:
  • Change User Rights
  • View forms containing PHI
  • Export data
  • Export specific types of data or identifiers
• Use Data Access Groups when appropriate, especially for multi-site studies.
• Collect the minimum necessary PHI. Only include identifiers required for the study.
• Limit free-text fields. Notes and other open-ended fields can unintentionally contain PHI.
• Mark PHI variables as “Identifiers.”
• Use password masking when entering sensitive information where appropriate.

Protecting PHI During Data Export and Sharing

• Use de-identification options when exporting data whenever possible.
• Limit data-export privileges to users who need them.
• Restrict PHI-containing files in the File Repository.
• Never share exported files or documents containing PHI with people outside the project team unless they are authorized to receive them.
• Use REDCap Logging to monitor activity, including data exports.

Remember- collect the minimum. Give access only to those who need it. Limit exports. Protect files containing PHI. Monitor project activity.

For additional guidance, see PMID 30017974, DOI

Managing User Rights

User access in REDCap is managed at two levels: REDCap account access and project access.

Who manages access?

• WSU REDCap Administrators create REDCap user accounts and manage system-wide access.
• Project Owners control who can access their projects and what each user can do within the project.
• Project Owners are responsible for appropriate access to project data and are encouraged to designate a backup Project Owner with similar rights.

Having a REDCap account does not automatically give a user access to any project.

Give users only the access they need

Set project-specific rights based on each team member's role. Limiting access helps ensure users can access only the settings, features, and data they need—including PHI, data exports, and other sensitive functions.

WSU provides recommended roles that can be imported when creating a project from a template. If you created an empty project, you can create these roles manually.

Common recommended roles:

• Project Owner: Full project management and User Rights responsibilities.
• Data Entry: Access needed to enter and manage study data.
• Quality Reviewer: Read-only access for reviewing data and quality.
• Statistician: Access to appropriate reports, statistics and analysis functions.
• Site Auditor: Limited, read-only access for auditing; this role is added when needed.

The exact rights for each role should follow the WSU recommended User Rights tables.

Add users to a project

Users can be added during Development or Production.

You can either:

1. Assign Custom Rights — search for the user, select their User Rights, and select the forms and functions they need.
2. Assign a Role — create a project role with the appropriate rights, then assign users to that role.

If a user's name does not appear in the search, they do not have a REDCap account. Only WSU REDCap Administrators can create new accounts.

Change or end access

Users with permission to manage User Rights can change a team member's rights or role at any time.

When someone leaves the project team or institution:

• Set an expiration date for their project access.
• Do not delete or remove the user from the project. Doing so can negatively affect audit trails, user logs, and other project functions.
• The project expiration date affects access to that project only.

REDCap accounts are also subject to system-wide W# account status. When a REDCap account expires, access to all projects is suspended. Contact the WSU REDCap Administrators if someone needs continued project access after leaving WSU.

Projects involving PHI

Projects involving WSU-affiliated clinical organizations may require additional restrictions to protect PHI and support clinical-site oversight.

After a project is submitted for Move to Production, WSU REDCap Administrators will change the Project Owner's rights to the appropriate PHI Project Owner role. Additional PHI-specific roles are available for quality reviewers, statisticians, and site auditors.

Use Data Access Groups for multi-site projects

Data Access Groups (DAGs) can restrict users to viewing data from their assigned site. This provides an additional layer of protection for PHI in multi-site research.

• Create a DAG for each site.
• Assign users to the appropriate site.
• Use the DAG Switcher when assigning multiple users.
• A user can belong to multiple DAGs.
• Only place users in a DAG when they need to be restricted to specific sites.
• Do not place users who need access to all sites—such as Project Owners or Project Coordinators—in a DAG.

Key principle- give each REDCap user the minimum level of access needed to perform their role, and update or end that access when their role changes.

Changes after production

Changes can be made to a REDCap project after it has been moved to Production, but they should be made carefully. To make changes, click Enter Draft Mode. The REDCap Administration team will review proposed changes before approval to ensure they do not negatively affect data that have already been collected.

Changes that generally do not affect existing data:

The following changes can be made without consequences:

• Add new fields.
• Reorder existing fields on the same form.
• Add Action Tags or field notes.
• Mark a field as an Identifier.
• Rename forms.
• Add or change Section Headers.
• Change a radio button field to a dropdown, or vice versa.
• Add a new multiple-choice option at the end of an existing list.
• Add or remove minimum or maximum value validation.
• Add, change, or remove branching logic.
• Add or remove whether a field is required.
• Add, modify, or delete a matrix group name.

Note: Adding branching logic may hide fields that already contain data.

Changes that may cause data loss

Use caution with changes such as:

• Deleting fields.
• Changing forms using the Data Dictionary.
• Changing a field between Radio Buttons and Check All That Apply.
• Changing or reordering choices in multiple-choice fields.
• Deleting a multiple-choice response option.
• Updating a calculated-field formula.
  • Existing data remain, but are not recalculated using the new formula.
• Changing slider numbers or anchors.

Changes that may cause data loss or corruption

These changes may affect the meaning or integrity of existing data:

• Changing a field label when the change alters the meaning of the data entered.
• Changing a text box to a calculated field.
• Changing the field validation format.
• Changing slider labels when the change alters the meaning of the data entered.

Changes that cannot be made

The following changes are not permitted after moving to Production:

• Changing a variable name.
• Converting a matrix field into separate fields.

Key principle- Before changing a Production project, consider how the change could affect data that have already been collected. When in doubt, use caution and allow the REDCap Administration team to review the change.

Citing REDCap

If you use REDCap for research, please cite the REDCap publication in the Methods section and References of any resulting publications.

REDCap use is also tracked through information entered in your project settings, including:

• Project title
• Project purpose (e.g., Research)
• Principal Investigator (PI) name
• PI name as it should appear in publications (last name and initials)

REDCap Publication

Use the following citation:

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 Apr;42(2):377–81.

Article:

Analysis/Clean up

When data collection is complete, Project Owners are encouraged to move the project to Analysis/Clean Up status. This limits project changes while allowing necessary data review and analysis.

Move a Project to Analysis/Clean Up

1. Go to Project Setup.
2. Select the Other Functionality tab.
3. Click Move to Analysis/Clean Up status.

This status:

• Restricts changes to the project.
• Restricts data entry.
• Allows data editing and quality checks to continue.
• Keeps data exports enabled.

Project Owners should also review user access at this stage. Add expiration dates for users who are no longer involved in data cleaning or data exports. See Managing User Rights for more information.

Mark a Project as Completed

Once all analysis, data cleaning, and exports are finished:

1. Go to Project Setup.
2. Select the Other Functionality tab.
3. Click Mark project as Completed.

A completed project is locked:

• Users cannot make changes to the project.
• Users cannot export data.
• The project is hidden from users' My Projects list by default.

Users can still choose to display completed projects by selecting the appropriate option in their My Projects list.

Frequently Asked Questions