REDCap downtime: Tuesday, Dec. 8 » Clinical and Translational Science Institute

On the evening of Tuesday, Dec. 8, the CTS-IT will upgrade REDCap from version 9.3.5 to 10.5.1. You can expect a downtime for REDCap from 8 p.m. to 10 p.m. while we complete the upgrade.

The new version of REDCap scheduled for release on Dec. 8 has some new features and several improvements to existing features, including…..

New features

Missing Data Codes (i.e., “Data Missingness” functionality)

Fields that have a blank/missing value may be marked with a custom ‘Missing Data Code’ to note why the value is blank. These missing codes may be used to aid in data analysis by specifying why a field lacks a value. Users may enable custom missing data codes at the project-level in the Additional Customizations popup on the Project Setup page. The missing codes should be coded just like the choices of a multiple-choice field with code + comma + label, in which the codes can only have letters, numbers, dots, dashes, and underscores (e.g., ‘-999, Not asked’ or ‘UNK, Unknown’). If no codes are entered, this feature will remain disabled. After missing data codes have been set up in a project, you will see an ‘M’ icon next to each field when viewing a data entry form. Click the icon to open your list of missing data codes, and select one. Once selected, it will save the missing code as the literal data value for the field. Missing data codes can be used for any field type (e.g., date, slider, file upload fields).
If utilizing missing data codes, the functionality will be enabled on all fields by default, and the code will be saved as the literal data value for the field.
New action tag @NOMISSING can disable the missing data option for a given field.
Behavior with branching logic – If a field should be hidden by branching logic, REDCap will ask the user (except on surveys) if they wish to delete the value of the field being hidden. But if the field has a missing data code saved for it, it will still hide the field but will not remove the missing data code as the field’s value. This allows a field to still be “blank” and have a missing code while being hidden by branching logic.
New isblankormissingcode() function for branching logic, logic, and calculations – Returns a Boolean (true or false) if the field value is blank/null/”” or if the value is a Missing Data Code, in which Missing Data Codes have been explicitly defined in the project on the Project Setup page under Additional Customizations. E.g. isblankormissingcode([age]), in which if “age” has a value of “UNK” (which might be a Missing Data Code in a project), then it will return TRUE. And if the field has any non-blank/non-null value that is also not a Missing Data Code, it will return FALSE.
All the missing data codes are displayed for reference at the top of the Codebook page.
When creating/editing a report, a new option exists under the “Addition report options” section: “Display any Missing Data Codes in place of blank values (where applicable)”. This option will allow users (based on their preference) to show or not show the Missing Data Codes (if they have been saved for any field in any record) in the report or export. Note: In PDF exports of data collection instruments, any Missing Data Codes will be represented as blank values in the PDF.
Changes for Data Quality Rules:
- DQ rule A and B (for finding blank values) will continue to return only truly blank values and thus will not return fields with missing data codes saved as the value.
- New rule – DQ “Rule I (Fields containing missing data codes)” has been added as a new rule for specifically finding fields with missing data codes saved as the value.
- DQ rule F (Hidden fields that contain values) will ignore fields that have a missing data code saved as the value because it is allowable for such fields to be hidden by branching logic while still maintaining a missing data code as a value.

REDCap-branded URL Shortener

The “Get short survey link” and “Create custom survey link” buttons on a project’s Public Survey Link page now utilize the REDCap-branded URL Shortener (https://redcap.link) instead of BIT.LY and IS.GD, which are third-party websites utilized by previous versions.

New Action Tag: @HIDDEN-PDF

Hides the field only in the downloaded PDF of one or more instruments (including blank PDFs, PDFs with data, and compact PDFs with data). Note: Other @HIDDEN action tags will not hide fields inside PDF exports, so @HIDDEN-PDF must be used specifically to hide fields in PDFs.

Integration of the DAG Switcher external module

Users assigned to Data Access Groups (DAGs) can optionally be assigned to multiple *potential* DAGs, in which they may be given the privilege of switching in and out of specific DAGs on their own whenever they wish.
When assigned to multiple DAGs, the user will see a blue banner at the top of every project page, which will present them with the option to switch to another DAG. Note: Users may not move into another DAG unless someone with rights to this page has explicitly granted them privileges to be in multiple DAGs.
To assign a user to multiple DAGs, navigate to the Data Access Groups page in a project where you will see the DAG Switcher near the bottom of the page. Then follow the directions provided there. The DAG Switcher feature is completely optional and can be used in any project that has Data Access Groups.

Project life cycle changes

Change: The “Archived” project status has been removed and converted into a built-in Project Folder named “My Hidden Projects”, as now seen at the bottom of each user’s My Projects page. If users wish to hide any projects from their My Projects list, they may click the Organize button on that page and place the projects into that new Project Folder. Note: Any already-archived projects will be automatically placed there and will have their project status set as “Analysis/Cleanup” to match the projects’ general behavior prior to the upgrade.
Change: The “Inactive” project status has been renamed to “Analysis/Cleanup” status to help reinforce that cleaning and analyzing the data is the next logical step after data collection in Production status.
New feature: Projects that are in “Analysis/Cleanup” status can now optionally have their project data set as “Locked/Read-only” or “Editable” (see the top of the Project Setup or Project Home page). This will give users more control to prevent data collection from happening while in this project status.
Change: New records can no longer be created while in “Analysis/Cleanup” status. If users wish to create records, the project must be moved back to Production status.
New feature: Mark a project as “Completed”: If users are finished with a project and wish to make it completely inaccessible, they 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 users are sure that no one needs to access the project anymore, and they want to ensure that the project and its data remain intact for a certain amount of time.

Record-level locking feature

This feature allows users to lock an entire record (as opposed to locking individual instruments) so that none of the record’s data can ever be modified unless someone with record-level locking/unlocking privileges goes and unlocks the record again.
The old “lock all forms for all events” feature has been changed into this new record-level locking feature, which is distinguishable from the existing instrument-level locking feature. Now the instrument-level locking can only be used while on a data entry form (using the Locking checkbox at the bottom of the form). Whereas the record-level locking feature is available as an option on the Record Home Page and on the project’s left-hand menu after a record has been selected.
While records have always been able to be locked (i.e., made read-only) for individual data collection instruments in a project, you may now easily lock an ENTIRE record so that no data in the record can ever be modified while it is locked.
What has changed? It is important to note that the old user privilege “Lock all forms” has now been converted into the new record-level locking feature, which works completely independently from instrument-level locking (i.e., the checkbox at the bottom of data entry forms). Instead of that particular user privilege allowing you to lock all forms individually (which was the previous behavior), it will now serve in a slightly different capacity as the record-level locking user privilege to lock an entire record fully.
How to use it: You may lock an entire record via the “choose action for record” drop-down on the Record Home Page or by clicking the “Lock Entire Record” link on the project’s left-hand menu when viewing a record. Note: Since the record locking and instrument locking are completely separate features, they both may be used together in a project, if you wish. However, please note that since record locking is a higher-level locking than instrument locking, an entire record may be locked or unlocked while one or more instruments are currently locked, but an instrument cannot be locked or unlocked while the entire record is locked.

Field Embedding

Field Embedding is the ultimate way to customize surveys and data collection instruments to make them look exactly how you want. Field Embedding is a Shazam-like feature that allows you to reposition field elements on a survey page or data entry form so that they get embedded in a new location on that same page. Embedding fields gives users greater control over the look and feel of your instrument. Users may place fields in a grid/table for a more compact user-friendly page, or they can position fields close together in a group if they are related.
To use Field Embedding, users simply need to place the REDCap variable name of a field inside braces/curly brackets – e.g., {date_of_birth} – and place it in the Field Label, Field Note, Section Header, or Choice Label of any other field on that same instrument. Field embedding will not work across instruments but only on the current instrument/survey being viewed. If on a multi-page survey, then the embedded field must be on the same survey page as its host field.
No action tags or custom HTML is required to use Field Embedding. Users can simply use the rich text editor in the Online Designer to design their layout and then place the field variables inside that layout. The layout does not have to be a table/grid (although tables are common for this), and fields can be embedded inside *any* field type (not just Descriptive fields).

Integration of “My Projects Tweaks” External Module

Link to Online Designer: Adds links to the Online Designer page of projects in the Fields column.
Link to Record Status Dashboard: Adds links to the Record Status Dashboard in the Records column.
Collapse All: Adds a Collapse All button next to the Organize button that collapses all project folders.
Organize Projects filtering: Adds a filter in the Organize Projects pop-up.

Select and modify multiple fields together on the Online Designer

Users may select multiple fields on the Online Designer by holding the Ctrl, Shift, or Cmd key on their keyboard while clicking on the field in the table, which will reveal the options to Move, Copy, or Delete all the selected fields. To make users aware of this feature, a floating note now appears near the right side of the page in the Online Designer with instructions on how to use this.

Integration of “Stealth Queue” external module

New “Keep the Survey Queue hidden from participants?” setting in the “Set up Survey Queue” dialog on the Online Designer
This setting will keep the Survey Queue table hidden from participants and will force Auto Start to be enabled for all queue-activated surveys. This is useful if users wish to use the Survey Queue to automatically guide survey participants to the next survey without displaying the queue of surveys.

Added “Language of text to be spoken” for the “Text-To-Speech” survey functionality

Available on the Survey Settings page.
For several years, REDCap has had a Text-to-Speech feature for surveys that, when enabled, allows questions and other text on survey pages to be converted into natural-sounding audio for the participant to hear. Up until now, it supported English only, but now REDCap users may utilize the Text-to-Speech feature in a variety of non-English languages and voices if the survey text is in a non-English language.
This includes Arabic, Brazilian Portuguese, English (UK and US), French, German, Italian, Japanese, and Spanish (Castilian, Latin American, and North American).

Users may re-evaluate some or all Automated Survey Invitations for all records in a project

If an ASI has been modified after data has already been entered in the project, users may click the “Re-evaluate Auto Invitations” button in the Online Designer, which will re-evaluate selected ASIs for all records to ensure that invitations get properly sent or scheduled based on the new conditions of the ASI (otherwise they could only be triggered if each individual record had data modified). If a user modifies the conditional logic of an ASI, it will recommend that they utilize the “Re-evaluate Auto Invitations” functionality. If an ASI has the “Ensure logic is still true…” option checked, then it is possible during this process that some already-scheduled invitations might get removed (and thus would no longer be scheduled) based on the new conditions.

Users may re-evaluate some or all Alerts & Notifications for all records in a project

If an alert has been modified after data has already been entered in the project, users may click the “Re-evaluate Alerts” button on the Alerts & Notifications page, which will re-evaluate selected alerts for all records to ensure that notifications get properly sent or scheduled based on the new conditions of the alert (otherwise they could only be triggered if each individual record had data modified). If a user modifies the conditional logic of an alert, it will recommend that they utilize the “Re-evaluate Alerts” functionality. If an alert has the “Ensure logic is still true…” option checked, then it is possible during this process that some already-scheduled notifications might get removed (and thus would no longer be scheduled) based on the new conditions.

New action tag: @CALCDATE

Performs a date calculation by adding or subtracting a specified amount of time from a specified date or datetime field and then provides the result as a date or datetime value – e.g., @CALCDATE([visit_date], 7, ‘d’). The first parameter inside the @CALCDATE() function should be a text field with date, datetime, or datetime_seconds validation, in which you may specify (if needed) the event and repeating instance – e.g., @CALCDATE([baseline_event][visit_date], 7, ‘d’). The second parameter represents the offset number amount that should be added or subtracted. It can be a decimal number or integer. Tip: To subtract (i.e., go backward in time), use a negative number. The third parameter represents the units of the offset amount, which will be represented by the following options: ‘y’ (years, 1 year = 365.2425 days), ‘M’ (months, 1 month = 30.44 days), ‘d’ (days), ‘h’ (hours), ‘m’ (minutes), ‘s’ (seconds). The unit option must be wrapped in quotes or apostrophes. Note: Both the source field and the result field must be a text field with date, datetime, or datetime_seconds validation. It is important to realize that a field with @CALCDATE will not be editable on the survey page or data entry form, and the field will function almost exactly like a normal calculated field, in which its value may get updated via a data import when running Data Quality rule H, or in real-time during normal data entry on a form or survey.

New action tag: @CALCTEXT

Evaluates logic that is provided inside a @CALCTEXT() function and outputs the result as text, typically performed with an if(x,y,z) function – e.g., @CALCTEXT(if([gender]=’1′, ‘male’, ‘female’)). Note: It is important to realize that a field with @CALCTEXT will not be editable on the survey page or data entry form, and the field will function almost exactly like a normal calculated field, in which its value may get updated via a data import when running Data Quality rule H, or in real-time during normal data entry on a form or survey. If desired, it is possible to return the value as a number – e.g., @CALCTEXT(if([age] >= 18, ‘adult’, 5*[other_field])).

Data Access Group import/export and DAG-User assignment import/export

The Data Access Groups page in a project now displays a drop-down list of options for users to import/export Data Access Groups, which allows users to bulk create or rename DAGs via a CSV file. It also allows for the import/export of DAG-user assignments via CSV file to bulk assign/reassign/unassign users from DAGs in a project. Note: The DAG-user assignment import affects only a user’s *current* DAG assignment; thus, it has no effect on the DAG Switcher assignments for the user.

New action tag: @PREFILL

Sets a field’s value to static text or dynamic/piped text whenever a data entry form or survey page is loaded, in which it will always overwrite an existing value of the field. The format must follow the pattern @PREFILL=”????”, in which the desired value should be inside single or double-quotes. A field with @PREFILL will always be read-only, thus its value cannot be modified manually on the data entry form or survey page. For text fields, you may pipe and concatenate values from other fields in the project – e.g., @PREFILL=’Name: [first_name] [last_name], DOB: [dob]’. For checkbox fields, simply separate multiple checkbox values with commas – e.g., @PREFILL=’1,3,[other_field:value]’.
Note: The piped value does *not* get applied during any data imports (via API or Data Import Tool) but only operates when viewing survey pages and data entry forms. Note: A field with @PREFILL will have its value updated ONLY when the page loads, which means that its value will not be updated in real-time if you modify other fields on the same page that are piped into the @PREFILL tag. Note: If being used on a date or datetime field, the date value inside the quotes must be in Y-M-D format – e.g., @PREFILL=’2007-12-25′ – regardless of the field’s set date format.
Note: The only difference between @PREFILL and @DEFAULT is that @DEFAULT is only applied when an instrument has no data yet, whereas @PREFILL will always be applied on an instrument, meaning that @PREFILL will ALWAYS overwrite the value if a field value already exists. TIP: To pipe the value of one multiple-choice field into another multiple-choice field, make sure you append ‘:value’ to the variable being piped – e.g., @PREFILL='[my_dropdown:value]’.

New special functions:left(), right(), mid(), length(), find(), trim(), upper(), lower(), and concat()

These nine new functions can be specifically used when dealing with text values and may be especially useful when using them in conjunction with the @CALCTEXT action tag. To learn more and to see some practical examples of their usage, click the blue ‘Special Functions’ button in the Online Designer in any project.

left (text, number of characters) – Returns the leftmost characters from a text value. For example, left([last_name], 3) would return ‘Tay’ if the value of [last_name] is ‘Taylor’.
right (text, number of characters) – Returns the rightmost characters from a text value. For example, right([last_name], 4) would return ‘ylor’ if the value of [last_name] is ‘Taylor’.
length (text) – Returns the number of characters in a text string. For example, length([last_name]) would return ‘6’ if the value of [last_name] is ‘Taylor’.
find (needle, haystack) – Finds one text value within another. Is case insensitive. The “needle” may be one or more characters long. For example, find(‘y’, [last_name’]) would return ‘3’ if the value of [last_name] is ‘Taylor’. The value ‘0’ will be returned if “needle” is not found within “haystack”.
mid (text, start position, number of characters) – Returns a specific number of characters from a text string starting at the position you specify. The second parameter denotes the starting position, in which the beginning of the text value would be ‘1’. The third parameter represents how many characters to return. For example, mid([last_name], 2, 3) would return ‘AYL’ if the value of [last_name] is ‘TAYLOR’.
concat (text,text,…) – Combines/concatenates the text from multiple text strings into a single text value. For example, concat([first_name], ‘ ‘, [last_name]) would return something like ‘Rob Taylor’. Each item inside the function must be separated by commas. Each item might be static text (wrapped in single quotes or double quotes), a field variable, or a Smart Variable.
upper (text) – Converts text to uppercase. For example, upper(‘John Doe’) will return ‘JOHN DOE’.
lower (text) – Converts text to lowercase. For example, lower(‘John Doe’) will return ‘john doe’.
trim (text) – Removes any spaces from both the beginning and end of a text value. For example, trim(‘ Sentence with spaces on end. ‘) will return ‘Sentence with spaces on end.’.

Improvements

New options for Alerts & Notifications

A “Trigger Limit” setting was added to Step 1 in the Add/Edit Alert popup that allows users to define where and to what extent within a record that the alert will be triggered. Its options include “only once per record”, “only once per event”, “only once per instrument regardless of the event”, and others that are displayed if the project contains repeating instruments/events. The trigger limit will help users to limit alerts to only be triggered on certain parts of a record and/or so many times within a record to achieve the behavior they desire for their notifications. Note: For non-longitudinal projects that do not have repeating instruments, this option (Step 1C) will not be displayed at all since it would contain only one choice: “only once per record”. (Ticket #70860)
The “every time” option of the “Send it how many times?” setting in Step 2 has been expanded to have sub-options to provide more possible scenarios in which an alert will be triggered. In previous versions, the only option was to set an alert to be triggered “every time the form/survey in Step 1B is saved”, but now it contains two new variations: “every time the form/survey in Step 1B is saved with new or modified data” and “every time the form/survey in Step 1B is saved with new or modified data (ignoring calc fields)”.
Recurrence maximum – When setting an alert to send multiple times in a recurring fashion in Step 2, a new option has been added to limit the maximum number of recurrences (i.e., the total times the alert will be sent on its repeated schedule). In previous versions, the alert would continue sending indefinitely at its defined interval (typically until conditional logic became no longer true), but now the alert can be set to repeat up to 9999 times at the interval that has been defined.

Survey pages are now considered ADA Section 508 compliant

The REDCap Development Team at Vanderbilt has been collaborating with the CDC to improve the accessibility of REDCap overall. While the user-facing side of REDCap (i.e., non-survey pages where users must authenticate) is not 508 compliant, it continues to be improved with regard to accessibility over time. But according to the CDC’s recommendations and testing of REDCap, survey pages in REDCap do meet the minimum requirement for ADA Section 508 compliance.

More rich text editors

The rich text editor is now available when composing survey invitations. This includes composing Automated Survey Invitations or invitations to be sent via the Participant List or via the Survey Options on data entry forms.

Exporting data from REDCap into SAS

Full integration of the Missing Data Code functionality in the SAS data export syntax file to prevent issues when loading data containing Missing Data Codes into SAS.
- Note: The SAS Pathway Mapper file has been removed and is no longer utilized. Users exporting data to SAS will now need to manually modify the path of the CSV data file in their .SAS syntax file to reflect its locally saved path on the device.

Improvements to the Data Resolution Workflow feature

When a user is opening a new data query and assigning the query to a user, there are new options to send a notification to the assigned user via email and/or REDCap Messenger to inform them about their query assignment.
Attachment files that have been uploaded to an opened data query may now be deleted after the fact, if needed. Note: As a precaution, only REDCap administrators may delete such attachments.
For existing data queries, users may now be assigned to an opened query after the fact, and if the data query already has a user assigned to it, it may be reassigned to another user.
Adaptive and Auto-scoring instruments (i.e., PROMIS assessments) that have been downloaded from the REDCap Shared Library may now have their survey responses deleted via the Delete button at the bottom of the data entry form when viewing the survey response. In previous versions, if an Adaptive and Auto-scoring instrument had been partially completed or the wrong one had been taking accidentally, there was no way to remove the existing response since the whole response was locked afterward. Now the “Delete data for THIS FORM only” button appears at the bottom to allow users to remove the response if they wish to add another to replace it.
Performance improvement for large data exports that might have previously taxed the REDCap servers or might have failed to complete altogether for some large projects. An internal auto-batching mechanism is now utilized to limit the performance hit to the servers (both database and web server) when exporting large quantities of data (via API or user interface) in order to improve the user experience and to prevent REDCap processes from using up too many server resources. Note: This does not necessarily mean that data exports will be faster; in fact, some exports might be slightly slower as a means of preserving server resources used by REDCap processes.
Performance improvement for when REDCap is generating the record list cache for a project, especially for projects with Data Access Groups. For each project, REDCap maintains a record list in a database table that is used throughout a project. This record list improves overall performance, especially for large projects. Every few days the record list cache is automatically rebuilt internally. The process of rebuilding the record list is now more efficient, faster, and less error-prone than in previous versions.
The Codebook now denotes if an instrument is enabled as a survey, in which it is noted immediately to the right of the instrument name.
If a user is viewing a data entry form that has been enabled as a survey and then clicks “Compose survey invitation” in the survey options at the top right of the page, if they compose and send an invitation that is marked to be sent “Immediately”, it will display a popup to inform the user that it is recommended that they leave the page very soon before the respondent has a chance to enter any data on the survey page. This is done because if the respondent begins entering data on the survey immediately after receiving the invitation, and then the user (while still viewing the data entry form) saves the form, the user could unwittingly erase the respondent’s data values that were just entered.
If the Custom Record Label and/or Secondary Unique Field are being used in a project, their values will now be displayed on the Calendar page when viewing the Day or Agenda tab for any calendar event connected to a record in the project.
On the Alerts & Notifications page, users may now edit a deactivated alert. This is especially useful if a user is setting up part of an alert and wishes to make incremental edits to the alert prior to re-enabling it.
A new setting “Utilize the Display Name in all outgoing emails?” was added to the “Configuration for Outgoing Emails” section on the Control Center’s “General Configuration” page. This setting allows administrators to disable the email Display Name feature in all outgoing emails from REDCap. This feature might need to be disabled if your institution is having a disproportionate amount of emails not being received due to email servers blocking them, sometimes due to the usage of the display name.
Major performance improvement when loading the Participant List page for projects with surveys. For projects with thousands of records or more, this page should be significantly faster.
Performance improvement for record searching on the “Add/Edit Records” page when entering part of a record name in the “Enter a new or existing [Record ID]” text box. For projects with thousands of records or more, this functionality should be much faster.
Performance improvement for projects using record auto-numbering, in which the process of generating the record name of the next potential record is much faster, especially for projects with many records.
The email “display name” for most outgoing emails is now automatically populated and thus is able to be displayed in the recipient’s email client. Previous versions did not use the display name but left it blank for outgoing emails. For user requests that are triggered by users, such as production change requests, API token requests, etc., the user’s first and last name from their My Profile page will be used automatically as the display name in those emails. For emails originating from REDCap administrators that are automated by the system, the email display name will the “Name of REDCap Administrator” setting (from the General Configuration page) or else the “Contact name to display on Home page” (from the Home Page Configuration page), which is dependent upon the type of email being sent.
Line breaks may be preserved in data values in CSV data exports – When creating/editing a report, the section “Additional report options” contains a new setting: “Remove line breaks/carriage returns in all text data values (only applicable for CSV Raw and CSV Label data exports)”. This setting will be enabled by default for all existing reports and for any new reports being created. The option will effectively be enabled (i.e., will remove line breaks) when exporting Reports A and B in order to be consistent with their current behavior in previous versions. This option is only used for CSV data exports and not for reports or exports to statistical analysis packages.
Added “Copy” and “Paste” options to the [right-click] context menu for all rich text editors.
The rich text editor is now available on the Email Users page in the Control Center and also for the Survey Confirmation Email option on the Survey Settings page.
When using the Data Resolution Workflow and exporting all data queries in a CSV file, the following attributes are now all exported as their own separate columns in the CSV file: record name, event name, data access group, data quality rule, and field name. In previous versions, some of these attributes existed together in a single column and thus were harder to parse out individually. Additionally, the following columns have been added to the CSV export file: Current Query Status, Time Raised, and Time Resolved
In Alerts & Notifications when clicking the “Preview Message by Record” option, it now displays the Custom Record Label and/or Secondary Unique Field value in the record drop-down list in the dialog.
A custom email “display name” can be set for the email sender when sending an email for Alerts & Notifications, the Survey Email Confirmation option on the Survey Settings page, and when sending survey invitations via Automated Survey Invitations, via the Participant List, or via the Compose Invitation option on a data entry form.
By popular demand, the “Send test email” link/feature has been re-added to all the following places where emails are composed: Email Users page in the Control Center, Automated Survey Invitations setup dialog, Compose Survey Invitations dialog for Participant List, Compose Survey Invitation dialog at the top right of data entry form, and the Confirmation Email setting on the Survey Settings page.
A custom email “display name” can be set for the email sender when sending an email for Alerts & Notifications, the Survey Email Confirmation option on the Survey Settings page, and when sending survey invitations via Automated Survey Invitations, via the Participant List, or via the Compose Invitation option on a data entry form.
Users are now able to utilize dots/periods/full stops in the codings of choices for checkbox fields. In previous versions of REDCap, this was not allowed for checkbox fields.
A new send-time option has been added when setting up Automated Survey Invitations and Alerts & Notifications. When defining when the ASI/Alert should be sent, the option “Send after a lapse of time” has a new setting added so that, if desired, the user may set the time lapse relative to the value of a date or datetime field in the project. In previous versions, the time lapse setting could only be set relative to the time in which the ASI/Alert was triggered. That is still an option, but now users may also opt to send the ASI/Alert a certain amount of time either before or after the date/time of a specific field. This new setting will allow users to have greater control with regard to setting when ASIs/Alerts will be sent without getting too complicated in their setup, such as having to use complex logic (with datediff, etc.).
New PDF customization to hide the Record ID from the PDF header. In the “PDF Customizations” section of the “Additional Customizations” dialog on the Project Setup page, users may set this option to display or hide the record name in the top header of every PDF page when downloading a PDF with data for a record. This is a project-level setting, so setting it applies to all PDFs generated for records in the project.
The sending of a survey confirmation email now gets logged on the project Logging page when a confirmation email has been set to send to a survey participant after having completed a survey, in which the logged event will note the record name, the To address, the From address, the email subject, and whether or not the email contained attachments (including the PDF of the participant’s survey responses).
The datediff() function used in branching logic and calc fields no longer requires the date format parameter (“ymd”, “mdy”, “dmy”). This was required for datediff() in calc fields and branching logic but was not required elsewhere, such as in report filters, DQ rule logic, ASI/Alert conditions, etc. The $returnSignedValue parameter (if provided) can now be provided as the fourth parameter – e.g., datediff([dob], “today”, “y”, true). Note: Both of the date/datetime fields used in the datediff function must still be in the same date format (“mdy”, “dmy”, or “ymd”), so that is still a requirement.
When editing a field’s branching logic in the Online Designer’s “Add/Edit Branching Logic” dialog, when saving the branching logic for a given field, it will now check if any other fields in the project have identical branching logic and will prompt the user to ask them if they want to change the branching logic accordingly for all fields having the same branching logic.
The “Response Limit” option on the Survey Settings page now allows for the use of the rich text editor when defining custom text to display to respondents on the survey when limit is reached.
When importing a CSV file of data on the Data Import Tool or when importing a CSV Data Dictionary, users may now specify the delimiter of the CSV file as a Comma (default), Tab, or Semicolon.
When deleting an invitation from the Survey Invitation Log (either as a single invitation or using the multi-select option to delete many invitations at once), it now provides a new option in the dialog prompt to “Permanently cancel this invitation?”, in which the phrase “permanently cancel” implies that the invitation cannot be re-triggered/scheduled again in the future even if the ASI conditions are met again. If the user chooses to uncheck the option, then the scheduled invitation will be removed, but could possibly get re-triggered in the future if the ASI conditions are met again (assuming it was originally scheduled via an ASI).
The Survey Invitation Log has a new filter drop-down option to view “only deleted invitations” (i.e., permanently cancelled invitations).

Changes

Changes for long-standing quirks with calculated fields and branching logic

Change: In previous versions, calculated fields could only utilize either numeric fields or date/datetime fields in the calculation. Now non-numeric fields may be used, most notably inside IF statements. For example, if ([field1] = “A”, 0, 99).
Change: In previous versions, using > or < in branching logic would not always work as expected. For example, [a] > [b] would have to be formatted as [a]1 > [b]1 to work correctly 100% of the time, which is not intuitive. This is no longer required, in which [a] > [b] will work as one would expect in branching logic. Note: This does not apply to calc fields, which have never had this problem.
Users will no longer be allowed to display all pages of a report (by selecting “ALL” from the report’s page selection drop-down list) if it has been determined that such a report would display more than 500,000 data points (i.e., table cells) on the report page. This is to help prevent users from causing performance degradation to the REDCap server and also to improve user experience (assuming the page would take a very long time to load and might even cause the user’s web browser to crash).
The “Data Search” feature on the “Add/Edit Records” page will no longer allow users to search over “All fields” if a project contains more than 20,000 records. This is done for performance reasons so that it does not bog down the database server.
By popular demand, the “Send test email” link/feature has been re-added to all the following places where emails are composed: Email Users page in the Control Center, Automated Survey Invitations setup dialog, Compose Survey Invitations dialog for Participant List, Compose Survey Invitation dialog at the top right of data entry form, and the Confirmation Email setting on the Survey Settings page.
To wean users off of using Internet Explorer 9 and 10, any users using IE 9 or 10 will see a thin, yellow banner at the top of all project pages, which will inform them that their browser is not fully compatible with REDCap and thus will encourage them to upgrade to IE11 or use another browser. Technically, IE 9 and 10 will be supported till July 2020 in Standard Release, but this warning is mostly preemptive in preparation for that.
For survey participants using Internet Explorer 6, 7, or 8, rather than failing silently, survey pages now display an error message letting them know that the page is not compatible with IE 6-8 and recommends they upgrade or use another browser.
Support for Internet Explorer 9 has been removed.
When clicking the “View past invitations” or “View past notifications” button on the Survey Invitation Log and Alert Notification Log, respectively, it now defaults to displaying the page with the most recently sent invitations/notifications, whereas previous versions would default to the first page (i.e., the oldest sent). This change should provide a more intuitive experience for users.
On the Survey Settings page, The Save & Return Later option “Allow respondents to return without needing a return code” now has a note immediately below it to encourage users not to use this survey option if they are collecting identifying information (PHI, PII) on their survey.
The @READONLY action tags now display the field labels as slightly less faded out (using 60% opacity instead of 50% as in previous versions), and the text of drop-downs, text boxes, and text area boxes that have a @READONLY action tag now have a darker text to make them more readable despite being disabled on the page.
When exporting data to a stats package (R, Stata, SPSS, SAS), if a field contains a long field label, it now truncates the field label in the center of the text (i.e., putting an ellipsis in the middle) to make it more compatible with and easier to read in certain stats packages.
When copying a project via the Copy Project page, Alerts & Notifications will now be automatically set to “Deactivated” status in the newly created project, similar to Automated Survey Invitations when copying a project. This is to ensure that they do not start getting triggered and start sending if all the project records were copied from the original project.
In previous versions, date fields that have Y-M-D date format would allow M/D/Y format values (i.e., American format dates with slashes instead of dashes) to be entered, in which it would automatically reformat the value to a Y-M-D format date with dashes. This is a very old behavior from the earliest days of REDCap that was meant to be a convenience for users, who were mostly from the U.S. at that time. However, since that time REDCap has grown internationally, and it is no longer U.S.-centric as it was in the early days. It makes more sense at this time to remove this old behavior so that Y-M-D date formats only accept Y-M-D formatted values.
When a user accesses a project for which their user privileges have expired, it now tells them to contact the project owner rather than telling them to contact the REDCap administrator.
When running Data Quality rule H on a project with many hundreds or thousands of records, the rule might mistakenly time out or might crash due to a PHP memory limit error, in which none of the calculations could ever be corrected by rule H if it timed out or crashed. To prevent this, rule H will perform an internal batching of 100 records at a time to ensure that the rule will execute more efficiently and thus will finish successfully. Note: The internal batching process will occur invisibly, so nothing will appear different at all with regard to user experience.
When viewing the Participant List page, if the survey has the “survey-specific email invitation field” enabled, it will now display a small notice about this fact near the top of the Participant List table to inform the user and provide more clarity regarding the source of the email addresses being used for that particular survey.
A warning message is now displayed for users that attempt to use both the Survey Queue and Survey Auto-Continue features together in the same project. If one is already enabled while attempting to enable the other, the warning will inform the user that these two features can sometimes conflict with each other.