Though REDCap has safeguards in place to protect against data loss from disasters and mistakes, backups provide an additional layer of security and are a best practice. If the data is downloaded, be sure it is saved to a secure BIDMC ITS approved location.
Suggestions for when to backup data:
Before moving to Production: If data has accidentally been collected in Development mode, backup the data and download it before moving to Production.
Before editing Production projects: Backup data before making changes to a Production project. Download of data optional; a copy of the file generated is saved to the File Repository.
Periodically as data is collected. Download of data optional.
How to backup data using the File Repository:
In the project, go to "Data Exports, Reports and Stats" in the left hand navigation bar.
In row A: 'All data (all records and fields)', click "Export Data"
Select the "CSV / Microsoft Excel (raw data)" option. (The "raw" format is the format that REDCap can use to import the data.)
Be sure that none of the de-identification options is selected in the middle column. If they are, and cannot be removed, then your permissions specify only de-identified data exports, and
Deleting a record should not be undertaken lightly. It may require notification of the IRB or PI, depending on the situation. Best practice guidelines are to document the record id, what is being deleted and the reason for the delete in a Word document, which can be uploaded to the project's File Repository. This documentation is particularly important in case of an audit of a multi-year study, where it may be difficult to recall individual events.
Technically, deleting a record tends to be a 2 step process:
A user with admin rights in the project assigning themselves the delete permission
That user doing the delete.
By default at BILH, no user has delete permission in the project. Users with admin rights, however, can grant themselves this permission.
Add Delete to User Rights:
Go to User Rights.
Click on the name of the role to grant delete rights ("Admin" shown below).
Find the "Delete Records" privilege and check the box.
Save Changes.
Delete a Record:
Go to Add/Edit Records and open the record.
Click on the Record ID in the left navigation bar to bring up that record's Record Home Page.
Click "Choose action for record", and select "Delete record (all forms)"
If a question, or set of questions, will not be used in the future, it is generally better to hide the question(s), rather than delete them. If the question is deleted, that also deletes that data from all existing records. A better method is to hide legacy question(s).
There are several methods that can be used to hide question(s), but the simplest is to add branching logic so that the question is not shown unless it already has an answer. This hides it from all future surveys or data entry forms, but makes it easy to see the legacy data on existing records.
The variable name of the question is placed in square brackets. Be sure not use any spaces between the square brackets and the variable name, nor between and >, nor between the quotes.
Sometimes it is necessary to hide one or more of the possible answers (also known as "retire a choice" or "retire an option"). This prevents an answer from being used in the future, but does not delete it from existing records.
To do this, add @HIDECHOICE= 'n' in the Action Tags box, where n is the raw value, also called the choice number, of the answer to hide. To hide several choices, use a comma separated list, such as: @HIDECHOICE='1,2' to hide options 1 and 2.
The screenshot below demonstrates using the @HIDECHOICE Action Tag to hide the "Not sure" option from new users or survey participants, limiting their choices to "Yes" or "No". Records marked "Not sure" in the past will keep that answer.
A critical issue is a change to your project that will cause data to be deleted or radically altered. This includes deleting a field or incorrectly editing a field. In this example, a user made the following edit when trying to add the "Mocha" option to a question that asked about a favorite ice cream flavor.
Above is the wrong way to add a new choice such as "Mocha". All of the records that had "Strawberry" as the favorite ice cream would have answer converted to "Mocha". Likewise, all of the "Vanilla" answers would be converted to "Strawberry". This would have a huge negative impact on the project's data integrity.
1. Check the summary of all drafted changes: Before submitting changes for review, always click on the "View detailed summary of all drafted changes" link.
2. Check for critical issues: The summary will show you if you have a critical issue. These changes are never automatically approved.
3. Click Compare: The Compare button will show how existing records will be altered by the changes.
7 records would change from "Strawberry" to "Mocha"
6 records would change from "Vanilla" to "Strawberry"
REDCap saves the raw value (also called the choice number: 1,2,3,4), not the label, when saving the data for a field. That means if you change the label, or renumber labels, you can profoundly change the meaning of an answer for all existing records. Do not change a raw value/label pair in production projects. Minor changes to a label alone, such as fixing typos, is ok.
Here is a radio button question, asking survey respondents to select their favorite flavor of ice cream:
But what if you want to add an option, and still keep a list in alphabetical order? The option numbers do not need to be in numeric order; they just need to be unique.
Increment the highest existing choice number in the question.
Add the new option with that choice number in its preferred place in the list.
DO NOT DO THIS:
This is the wrong way to add a new choice such as "Mocha". All of the records that had "Strawberry" as the favorite ice cream would have their answer converted to "Mocha". Likewise, all of the "Vanilla" answers would be converted to "Strawberry". This would have a huge negative impact on the project's data integrity.
REDCap projects in production can be edited but the process is slightly different from editing in development mode. When in production, the user must first enter Draft Mode by clicking the "Enter Draft Mode" button at the top of the Designer page to start making changes.
Changes made in Draft Mode are visible in the Designer but can't be seen on forms and surveys. This hides pending changes/edits from survey participants and data entry personnel, but it also means that editors can't test their changes before the changes are visible to everyone (after submission).
Once the changes are complete, click "View detailed summary of changes" (A) to review the changes. Then, click on the "Submit Change for Review" button (B).
A. Review your changes, and check for potentially critical issues. A critical issue is one that will delete or alter existing data; REDCap will list these. Also, the summary will tell you if your changes will be accepted automatically or if they need to be reviewed by the REDCap Team.
Look for the Will these changes be automatically approved? line
Click the "RETURN TO PREVIOUS PAGE" to be returned to the submission options.
