Procedures and Policies

Policy and Procedure Considerations

REDCap should not be used to store patient clinical data or to inform patient care decisions. Clinical care and patient electronic medical records should be stored in EPIC.
A project is created for a specific IRB protocol, QI or Admin purpose; it may not be used/reused for a different study or purpose without authorization from the REDCap Support team.
Data from multiple human subject protocols should not be combined in a single project. Each research project must have a single protocol which establishes how and what data can be collected, stored, and shared.
All REDCap projects must be approved by an oversight authority, who also have the right to audit projects at any time. Research projects are approved by their site’s IRB. QI/QA projects are approved by the site’s QI/QA designee. Admin projects are typically approved at the director level or via VP sponsor. In most cases, the project must be approved and proof of approval provided to REDCap team before the project can be created.
All REDCap projects must go into Production mode before collecting live data. This gives data protection to the project that is not available in Development mode. Projects must not begin live data collection or request Production status unless the IRB study protocol is currently active/approved.
Project inactivity will result in the project being archived. This includes projects that are in Development for more than a year. Users are welcome to archive their own projects if no longer needed by clicking the ‘Mark project as Completed’ button on the ‘Other Functionality’ tab. Archived projects can be viewed on the My Projects page by clicking on the ‘Show Completed Projects’ option located below the projects list, on the left side.
Research teams should contact REDCap Support (edata@bidmc.harvard.edu) upon study closure so that the project can be archived, as BILH policies prohibit accessing data after a protocol has been closed. Research REDCap projects will be archived (no longer accessible) when the IRB protocol status becomes inactive, such as “Study Closed” or “Withdrawn”.
The default data retention for REDCap is seven years. If data needs to be retained for a longer period of time due to contractual or regulatory requirements, the Project Owner must download and store the data with the study documents before the protocol is closed.
Any paper or electronic output generated from REDCap (i.e. data exports, printing a pdf version of a completed form) must be properly maintained, secured and stored according to BILH IS data security policy.
The Project Owner should periodically review the data logs within REDCap to ensure that data is being accessed/exported/imported properly and in a manner that protects PHI. Contact REDCap Support immediately if you think there has been any inappropriate use of data contained within the project.

PHI and Identifiers

All PHI/PII (private health information/personal identifying information) data fields should be stored in a single form and each such field marked as an identifier. This prevents PHI from being scattered throughout the project, and makes it easier to create de-identified exports.
- Be aware that the use of “piping” bypasses instrument-level data viewing rights. This includes Custom Record Labels, which may contain identifiers. People who are restricted to "de-identified” data should not have access to the REDCap project if it contains PHI/PII. Instead, they should be given carefully curated data exports without PHI/PII.
Run the ‘Check for Identifiers’ utility while in Development to determine if any potential PHI/PII fields have accidentally been left unflagged as identifiers. This utility does not guarantee that all PHI fields are marked properly. It is the responsibility of the PI to establish that the PHI/PII fields have been marked properly (see below).
The collection of PHI or personal identifiers in REDCap is only allowed in research studies that have proper IRB approval to do so and quality improvement projects that have received approval from the appropriate QI/QA Designee For all other project types, PHI and personal data collection is prohibited (see below).
Do not place PHI or personal information in survey invitations without using proper security measures. Contact the REDCap Support Team (edata@bidmc.harvard.edu) for more information.
PHI fields include, but are not limited to:

Patient/Subject Name or the names of relatives, employers, or household members	Telephone number	Account numbers
Address street location	Fax number	Certificate/license numbers
Address town or city	Electronic mail (email) address	Vehicle identification numbers and serial numbers including license plates
Address state	Social security number	Medical device identifiers and serial numbers
Address zip code	Medical record numbers	Web URLs
Elements of Dates (except year) related to an individual. For example, date of birth, admission or discharge dates, date of death, dates of procedures	Health plan beneficiary numbers	Internet protocol (IP) address
Biometric identifiers (finger and voice prints)	Full face photographic images	Any unique identifying number, characteristic or code
Links to identifiers (codes)

Anonymous Survey Data Collection

Please direct questions about anonymous data collection to the REDCap Support Team (edata@bidmc.harvard.edu).

Projects that contain both data entry forms and surveys cannot be considered anonymous. Staff entered data needs to be identified by the study team to be properly associated with and linked to survey responses.
All newly created survey-only projects (i.e. projects that contain only survey instruments and NO data entry forms) will collect survey data anonymously by default. Users can utilize the tracking features of the Participant List while maintaining anonymous data collection. However, if a user wishes to identify survey responses, he/she MUST ACTIVELY ENABLE the optional Participant Identifier field. Once this option is ENABLED, it is assumed that data WILL NOT be collected anonymously, even if user refrains from placing identifiers into the enabled Participant Identifier column.

To Collect Survey Responses Anonymously
- Do not include identifying questions in any survey within the Redcap project.
- If you are using the Participant List feature, do not ENABLE the ‘Participant Identifiers’ column.
- If using the Participant List, after sending out the survey invitations, wait until at least 8-10 responses have been collected before reviewing the Participant List. If there are only 1-2 responses/records, then the responses can be sometimes be tracked back to the participant.

Be mindful that projects with multiple surveys present potential challenges to anonymous data collection. First, when using the Participant List, subjects must respond to the first survey before they can be sent any other surveys. In addition, if you are using the Participant List to send 3 surveys out anonymously, a scenario may arise in which a high number of subjects respond to the first 2 surveys and only 1 or 2 subjects respond to the last survey. Each exported record will contain a subject’s response to all of the survey questions. In this scenario, you will need to be aware that the lack of data for the third survey can inadvertently identify a subject’s identity and his/her responses to all prior surveys

For this reason, do not EXPORT any of the project data until the survey in question is completed and closed.

Before exporting survey data, please:
- Review the number of responses (for each survey in the project) and make a judgment as to whether or not enough responses have been received to ensure that subject identities can remain anonymous. This is particularly critical when using the Participant List, as this list will identify the individuals who have responded. A low count of responses could be problematic. Take care to ONLY export and view data from surveys that have a suitable number of responses. For example, if only one response has been received (and the Participant List identifies that jsmith@yahoo.com has responded), you will know that this single response belongs to that subject.
- Only export the data associated with a closed survey (both single and multi-survey projects). Once data has been exported, no further responses should be received or allowed.

Project Setup

Make sure that all text box fields are properly validated (i.e. designate all text box fields as numeric or text-based).
Pilot-test the project with a small number of records to ensure proper form operation.
As part of testing, verify that all export files generated by REDCap are properly structured for analysis.
The Project Owner agrees to thoroughly test the project (i.e. data entry, formation of record_id, data export formats, etc.) before submitting a request to move the project into production. Changes that occur post-go live can take longer to execute. For instance, changes that can be made in seconds in development may take several days to execute in production. It is the responsibility of the Project Owner to ensure that the project design is suitable and appropriate for the study. We encourage all users to contact REDCap Support with any questions they may have throughout the design process.

Managing User Access for Project Team Members

At the time of a project’s creation, the REDCap Administrator will grant the Project Owner (and a designated team member, if formally requested) FULL and COMPLETE ADMIN control over the entire project.
Please ensure that only the Project Owner (and at most 1-2 designated team members) has ‘User Rights’ privileges in the project. Any user with ‘User Rights’ privileges can modify their own access to the project, and effectively access ALL project data and perform ALL operations. External users (non-BILH staff) should never be granted the 'User Rights' privilege.
When providing other users with access to the project, the Project Owner and other project administrators should ensure that each user is granted the minimum necessary access needed to perform his/her duties. User access can be restricted at the form level but be aware that “piping” can bypass instrument level data viewing rights.
The Project Owner should only add users to the project that are permitted per IRB approved protocol, QI/QA designee or VP sponsor/Director. The Project Owner must ensure that all additional users comply with REDCap use guidelines, especially with regards to PHI and data privacy. The Project Owner should only allow individuals that have received the proper training to be added as users.
The use of user roles in REDCap is encouraged to group together users with similar access needs and make management of rights easier and more consistent.
For multi-site studies, Data Access Groups should be used to limit viewing of records to only that site’s data.
- At least one BILH staff member should not be placed in a Data Access Group (or have full DAG Switcher rights) in order to monitor the data being entered into a BILH REDCap project. Other sites should be made aware of this requirement.
Users who have left the project/study/organization should be removed from the project promptly by the study team. Removing a user does not impact any data they may have created in the project nor their audit trail. It just removes access. Bear in mind the individual may return at a future date in a new capacity and should not retain access to former projects.
The study team, especially the account requestor (aka “sponsor”), must promptly notify REDCap support if an External User has left the project so that the external account may be inactivated.

Email Addresses

Primary Email Address: There must be a unique and verifiable user associated with each user account. Each user’s account should be associated with an email address that is affiliated with their local site (@bilh.org or @bidmc.harvard.edu, etc.). Generic accounts (i.e. smith_lab) cannot be used as the primary email address of an account.
Personal email addresses and/or the use of email addresses with 3rd party extensions (i.e. @yahoo.com, @gmail.com) are prohibited as primary, secondary or tertiary email addresses in REDCap unless special permission is granted by the ARC Director.
Additional Email Addresses: REDCap will allow you (and members of your team) to associate additional email addresses with your REDCap account. The ONLY allowable secondary email addresses are generic study-based email addresses that have been setup by and affiliated with your team or study (i.e. studyname@bidmc.harvard.edu or studyname@bilh.org). It is prohibited to use another person’s specific email address as a secondary email address (aka “masking”).

21 Part 11 Compliance

The PI and/or study team must specify in the new project request if 21 Part 11 Compliance is required.
The PI is responsible for ensuring that all project-level documentation is created and maintained to retain 21 Part 11 validation.
The PI is responsible for ensuring that all study team members have received appropriate training for their role on a 21 Part 11 project.

The complex functionality contained in REDCap can lead to inadvertent misuse of the application. Please contact REDCap Support (edata@bidmc.harvard.edu) with any questions, issues or concerns.