HSPH Upgrade: March. 31, 10:00 PM EDT

Version 5.5.21

Version 5.5.21 (Vanderbilt released 03/07/2014)

NEW FEATURES:

User Roles - User roles can now be created in projects in order to group users according to their specific role in the project. Roles are especially useful when you have several users who will have the exact same privileges in a project, in which roles allow you to easily add many users to a role in a much faster manner than setting their user privileges individually. Roles are also a nice way to categorize users within a project. You may still add new users with custom rights (just as before), but now you have the extra option to create roles (e.g. data entry person, project manager, etc.) and then assign users to those roles. Any user assigned to a role will assume the user privileges of that role. Users can be assigned, reassigned, or unassigned to roles at any time. There is no limit to how many roles that can be created per project nor a limit on how many users can be assigned to a given role.
The Data Resolution Workflow module (also known as the Data Query module) provides a workflow for certifying the validity of data values and also enabling users to open "data queries" (i.e. report an error), which is a common term used in clinical trials/studies. Opening a data query initiates a well-documented process of investigating a possible error in a data value and then ultimately resolving the error.
The Data Resolution Module is *not* enabled by default but can be enabled in the Additional Customizations pop-up on the Project Setup page. Users must be given new user privileges specific to this module on the User Rights page, in which you can set any given user with the following: No access (default), View only access, Respond only to opened queries, and Open/Close/Respond to queries.
When the module is enabled, on any given data entry form one will see a gray balloon icon next to the field, and when clicked, it will open the Data Resolution Workflow pop-up where users can either validate the data value for that field OR open a data query if there is an issue with the data value (if one has user privileges to do so). Once a data query is opened, a user with "respond to query" privileges can come and investigate the issue, correct the issue (if applicable), and leave a documented response. After this, a user with "close query" privileges will come and close the data query, thus leaving the query's status as "resolved". This entire process gets recorded and documented from beginning to end.
Data queries can also be opened from the discrepancy results pop-up in the Data Quality module when discrepancies are returned for a given Data Quality rule. This also includes the discrepancy pop-up when a DQ rule is violated on a data entry form via the DQ "real-time execution" feature. Note: If a custom DQ rule contains more than one field in its logic, the data query gets associated with the rule, whereas data queries initiated for single-field DQ rules get associated with the field (not the rule) just as if the query was initiated for that field on the data entry form.
The Data Resolution Workflow provides a new "Resolve Issues" page that can be seen on the project's left-hand menu. The Resolve Issues page provides a nice dashboard to help manage all the data queries as they are opened and resolved. There also exists a Resolution Metrics section on that page for viewing useful statistics and visual charts for viewing the progress and activity of opening, responding, and closing queries in the project.
Real-time execution of Data Quality rules on data entry forms. Users may now enable any of their custom Data Quality rules to be executed in real-time whenever the Save button on a data entry form is clicked. This will allow users to catch data errors in real-time as data is being entered for an individual record. The DQ real-time execution functionality can be thought of as an advanced type of field validation in which it will be vigilantly watching all data entered to ensure that the DQ custom rules are not violated. Real-time execution is completely optional and may be enabled for any given DQ custom rule you have created. By default, it will be disabled.
Piping - The Piping feature allows users to inject previously collected data into text on a data collection form or survey, thus providing greater precision and control over question wording. It can also be used in other ways, such as for customizing survey invitations (e.g. by including the respondent's name in the email) or survey acknowledgments (e.g. thanking your respondent by name after completing a survey). See the full documentation on Piping at To see Piping in action, you may view a live demo of Piping on a survey at
Field Comment Log: All projects will have the Field Comment Log enabled by default (but it can be disabled for a project on the Additional Customizations pop-up on the Project Setup page). A balloon icon will appear next to all fields on all data entry forms, and after being clicked, it will open a pop-up to allow a user to enter comments about the field.
Field comments can serve as a way to have field-level annotations about your data, similar to posting sticky notes on the margins of a piece of paper. Having this feature can prove very useful if you need to add any notes or comments about a data value entered. There is no limit to how many comments can be left per field.
All the field comments in a project can also be accessed on the new "Field Comment Log" page seen on the project's left-hand menu, which allows users to easily find existing field comments by filtering through them by record, event, field, user, data access group (if applicable), and also by a keyword search.

IMPROVEMENTS / CHANGES

When an existing user's or role's privileges are being modified in the popup on a project's User Rights page, the save button now says "Save Changes" rather than "Edit User"/"Edit Role" to prevent confusion about what clicking the button does.
If a project is utilizing surveys and data access groups together and a user belongs to a DAG, now in the Participant List it only displays the participants that belong to that user's DAG. In previous versions, it would display all participants regardless of whether the user was in a DAG. Note: In the initial survey, it still displays participants that have not yet begun their survey (i.e. their record has not been created yet), which is the same behavior as in previous versions.
A link to the Data Access Groups page is now displayed on the project's left-hand menu (if the user has privileges to access that page).
If using a Project Bookmark inside a longitudinal project, in which the option "append record info to URL" is enabled, it now appends the record info to the bookmark URL when the user is on the event grid page for a record. In previous versions, it only did this on the data entry forms. (Ticket #461)
The Data History pop-up now displays data changes listed in chronological ascending order. In previous versions, it sorted them in descending order.
For projects with multiple surveys, it was previously impossible to keep a response completely anonymous when using the Participant List because the respondent's email address could be viewed in the "Compose survey invitation" pop-up on an incomplete data entry form when viewing an individual record. This has been changed so that when participant identifiers have been disabled and when the designated survey email field has not been enabled, the respondent's email address from the Participant List will not be displayed in the "Compose survey invitation" pop-up on data entry forms but instead it will say "[undisclosed email address]" in order to maintain anonymity while still allowing the user to email the respondent, if needed. In addition, this has also been done on the Survey Invitation Log so that it displays "[undisclosed email address]" instead of the respondent's email address under these same conditions in order to maintain anonymity since there is the possibility of identifying a respondent's record by looking at the survey invitation send time and response status in the Invitation Log and cross-checking those values with the status of completed surveys on the data entry forms (this is more difficult to do but definitely possible).
When viewing the Participant List for a follow-up survey (i.e. any survey that is not an "initial survey" - not the first instrument), it now displays a pop-up tooltip if the user clicks a cell in the Participant Identifier column in an attempt to add or edit an identifier. The tooltip explains that participant identifiers can only be added or edited *prior* to the record/response being created. Thus, a participant's identifier can never be added or edited for a follow-up survey but only for the initial survey and only before the participant begins the initial survey. This does not change any functionality at all but merely displays this tooltip to explain this, which is often misunderstood or confusing to users.
For survey participants that are invited via the Participant List who click the "Save & Return Later" button on the survey page, which then automatically emails them a notification about partially completing the survey, it now also includes an extra sentence in that email letting them know that they can contact their survey administrator who originally sent them the invitation if they need to retrieve their return validation code.
Change: For archived or inactive projects, users could navigate to data entry forms via reports that had a link to records listed in the report. Since users should not be able to navigate to the data entry forms for projects that are inactive or archived, it now still allows users to access reports but no longer provides a link to individual records in the reports in order to prevent access to data entry forms.
When a longitudinal project is moved to production, the "Define Your Events" step on the Project Setup page now gets repositioned to the second-to-last step on the page (right above the "Draft Mode" step) to imply that events may still be modified once in production. It will do this if the system setting is enabled which allows users to add, edit, or designate events while in production, but if not enabled, the "Define Your Events" step will remain near the top of the page where it was located while in development status.
Change: The Project Setup page in each project now contains a step titled "Test your project thoroughly" right above the step to move the project to production. This new step serves as a simple reminder to the user to test all essential aspects of their project before moving it to production.
A more clear error message is displayed to a Double Data Entry user if they are restricted from accessing a page that should not be accessed by DDE user #1 or #2.
If using Double Data Entry, DDE user #1 or #2 would mistakenly be able to access certain pages within the project that display data from multiple records at once (e.g. reports, Field Comment Log, Data Quality). DDE users should not have access to these types of pages. They will now not be able to access those pages, and if they do, it will display an error message telling them why their access is restricted.
On PDFs of data entry pages, Descriptive fields now have their line breaks preserved in the text in the same way that line breaks in Section Header text is preserved in PDFs.
The link to navigate to the "Check For Identifiers" page has been returned to the Design step on the Project Setup page for development projects. It was removed in version 5.2.0.
A clarifying note has been added to the "Add Matrix of Fields" pop-up in the Online Designer, in which it states that adding text for the matrix section header will force a new page on a survey if the data collection instrument is enabled as a multi-page survey. Some users where unaware that the matrix header text is just a normal section header.
Whenever a user creates a new instrument in the Online Designer, it no longer displays a confirmation pop-up after each time this is done because it was considered to be too many unnecessary clicks if creating many instruments at once. (Ticket #427)
On the Online Designer, although the "Add Question" buttons would correctly appear for the first data collection instrument (if enabled as a survey), it would mistakenly display the "Add Field" buttons (i.e. with different text on those buttons) for any other instruments in the project that are enabled as surveys. So instead of merely fixing this issue, it has been changed to always display "Add Field" for those buttons (rather than "Add Question") in order to provide more consistency through REDCap for surveys and non-survey instruments alike.
"super" has now been added to the list of reserved variable names that cannot be used as the variable name of a field because it is a reserved keyword used in older versions of Internet Explorer.
A new section of text was added on the page where users can share/upload a data collection instrument to the REDCap Shared Library. This section provides several bullet points to help clarify to the user what it is they are doing by sharing their instrument to the Shared Library. This is done in order to cut down on accidental or unintentional submissions to the library.
New section named "API Security: Best Practices" was added to the API Help page and to the API page in each project. This section discusses the most secure ways of communicating with the REDCap API, such as always validating the REDCap server's SSL certificate.
When using the Data Export Tool to export data into Stata, it now adds an extra command in the Stata syntax file that automatically causes Stata to scroll to the bottom of the output rather than making the user page through it manually, which is an added convenience.
Videos were updated for the Online Designer and Data Dictionary.
More information about the REDCap Shared Library has been added to the "Design your data collection instruments" step on the Project Setup page when projects are in development status. This provides a more upfront introduction to the Shared Library, and it allows the user to go to the library directly from the Project Setup page.
It has always been the case that the "simultaneous user prevention" feature is activated whenever a user tries to access the same record on the same instrument (on the same event, for longitudinal projects) as another user. This has been changed/improved slightly so that if the second user has "read-only" rights on that particular instrument, then they *will* be able to view the same record-form[-event] while the first user is accessing it. Since they have "read-only" privileges, there is no chance of them causing data from the other user to be overwritten, which is the purpose of the simultaneous user prevention feature. So this change does not take anything away from the existing functionality of the feature, and it adds more flexibility for users.
New "execute" buttons for rules in Data Quality module. Now has 3 buttons to execute "All", "All except A & B", and "All custom".
When copying a project, there is now an option (if desired) to copy all Data Quality rules.
On the page for viewing a summary of all Draft Mode changes, it now only considers an issue to be "critical" if the field has data. In previous versions, if a field was deleted, or had its field type changed to an incompatible field type, or had its multiple choice options deleted or re-coded, it would be considered a critical issue, whereas now it only gets flagged as critical under those circumstances if it has data saved for it. More specifically, for multiple choice questions it is more granular, in which it does not consider it a critical issue unless the specific option that is being deleted or re-coded has data. This means that more requests will be automatically approved since the issue is only considered to be "critical" if the field has data.
Enhancements for Data Entry: When a user puts focus on a field on a data entry form or survey, it will add a subtle green highlight to the row to make it easier to note the field on which they are currently focused.
Enhancements for Data Entry: When a data entry form loads, it now automatically moves the user's cursor to the first field to help speed up data entry.
Enhancements for Data Entry: At the top right of all data entry forms, users will now see a floating box of "Save" buttons, which will always stay visible even as one scrolls up and down the page.