REDCap 16.0.x: What are the new features and changes?

Answer

The list below is an abridged version of the REDCap Change Log Summary for the update to the LTS 16.0..x branch, focusing on the end user impact at BILH.

  • New feature: Form-level "Delete" Rights - Users can now be given privileges to delete the data for specified instruments, enabling them to click the Delete Data button at the bottom of a data entry form. This can be granted without having to give the user the ability to delete whole records and events. Thus, this feature provides more granularity with regard to data deletion privileges. 

    This new form-level privilege can be found in the Data Viewing Rights section of the User Rights dialog when editing a user's rights. The "Delete" privilege can be granted for any or all instruments in the project. This assumes the user does not have the "Delete Records" privilege because, if so, the "Delete Records" privilege already includes the ability to delete data on all forms (in addition to being able to delete a whole record, etc.).
  • Change: When a user is editing user privileges on the User Rights page, in which the user initially does not have "Delete Records" rights, but then the "Delete Records" checkbox is checked and then unchecked while the dialog is still open/unsaved, it previously would leave all the form-level Delete rights as checked. It now leaves them all unchecked in this case and also notifies the user of this. (Ticket #264262)
  • Change/improvement: Improved error message dialogs for branching logic and calculation errors on forms and survey pages. All errors are now combined into a single dialog listing all fields with calc errors and/or branching logic errors. In addition, the "Erase value?" confirmation prompt has also been modernized to display all affected fields in the same dialog if those fields have values but were triggered to be hidden by branching logic (either when the page loads or triggered by the changing of a field value).
  • Improvement: New "combineCheckboxOptions" option for the "Export Records" API method. Similar to the same option seen when creating a report, this option allows users to specify whether or not to combine checkbox field options into a single column containing only the checked-off options. By default, all checkbox field options will be exported as separate columns. The setting's value can be set to "false" (default) or "true"..
  • Change/improvement: When a user clicks the "Save & Go To Next Record" button on a data entry form when record auto-numbering is enabled, in which there is no record after the current record, the user will now be taken to the Record Home page of a potential/non-yet-created record (within the same arm, if multiple arms exist). This makes the process faster by saving the user a click when rapidly creating new records in a project. In this situation in previous versions, the user would instead be taken to the "Add/Edit Records" page. (Ticket #262101)
  • New Feature: New functions for Missing Data Codes
    • isblanknotmissingcode(value) - Is a field's value blank/null and not a Missing Data Code? - Returns a boolean (true or false) if the field value is blank/null/'' and not a Missing Data Code. E.g. isblanknotmissingcode([age]), in which if 'age' has a value of 'UNK' (which might be a Missing Data Code in a project), then it will return FALSE. And if the field has a blank/null value and not a Missing Data Code, it will return TRUE.
    • ismissingcode(value) - Is a field's value a Missing Data Code? - Returns a boolean (true or false) if the field 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. ismissingcode([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 does not have a Missing Data Code, it will return FALSE.
    • hasmissingcode(value, missingDataDodes) - Does a field's value match a Missing Data Code that is provided? - Returns a boolean (true or false) if the field value is a Missing Data Code and also specifically matches one of the Missing Data Codes that are provided as a comma-delimited string as the second parameter. E.g. hasmissingcode([age], 'UNK') or hasmissingcode([age], 'NASK,NI,UNK'), 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 value is not a Missing Data Code or does not match at least one of the Missing Data Codes provided in the second parameter, it will return FALSE.
  • New feature: dayoftheweek() function - Determine the day of the week for a given date or datetime. An integer will be returned corresponding to a specific day of the week as follows: 1=Monday, 2=Tuesday, 3=Wednesday, 4=Thursday, 5=Friday, 6=Saturday, 7=Sunday. Example: dayoftheweek( [visit_date] ). NOTE: You may use "today" or "now" as the date parameter in the function, which can prove helpful for triggering an Alert or ASI to be triggered on weekdays but not weekends, for example - e.g., dayoftheweek("today") < 6 (this means that the Alert/ASI will not trigger on Saturday or Sunday).
  • Improvement: If a user is logging in to REDCap but has their Caps Lock on while entering their password, a warning will be displayed to the user to make them aware of their Caps Lock being on. (Ticket #262840)
  • Improvement: On the Record Home Page, the sort order of rows within the repeat instrument tables at the bottom of the page now persists within the project (per user).
  • Improvement: Aggregate smart variables and miscellaneous project-level smart variables can now be utilized in the description/instructions of Custom Record Status Dashboards. (Ticket #262607)
  • Improvement: Condition-level Form Display Logic Settings - FDL now has more granular controls to implement FDL conditions on data entry forms, and Survey Auto-Continue. In previous versions, FDL could be enabled for Survey Auto-Continue, but those would have been applied to all conditions. Now, users may set each individual condition to be utilized by data entry forms, by Survey Auto-Continue, thus providing greater flexibility for when/where each FDL condition is applied. Note: If the Survey Auto-Continue settings were enabled for FDL in a project prior to the upgrade, to maintain the prior behavior, that setting will be applied to every FDL condition in the project during the upgrade process.
  • Improvement/Change: If a field has been embedded into the choice label of a multiple choice field, the pre-embedded text (e.g., the variable name in the label "Other {other1}") will no longer be displayed as-is in piping, in reports, and in data exports that contain labels. In these cases, the pre-embedded text inside the braces/curly brackets will simply be removed for improved aesthetics and readability. (Ticket #261787)
  • Change: The documentation for special functions has been modified for clarity with regard to functions that return a boolean. (Ticket #263505)
  • Change: In the Additional Customizations popup on the Project Setup page, a warning has been added to the text for the "Designate a Secondary Unique Field" feature. To encourage best practices, it says the following: "It is recommended that you NOT use the Secondary Unique Field on a survey for an identifier field, such as Medical Record Number, Social Security Number, or email address, because doing so may give a survey participant the ability to test if certain values have already been used for that field in order to determine the identity of a specific person who has taken the survey."
  • Improvement: Improved enforcement of the Restricted Upload File Types setting - In previous versions, the Restricted Upload File Types setting would prevent files from being uploaded by users based solely on the file's extension. In the case the a file's extension has been renamed to obscure its true form (e.g., maliciousfile.exe to resume.txt), REDCap will now validate the true mime type (file extension) of the file when cross-referencing it with an extension listed in the Restricted Upload File Types setting.
  • New feature: Import and export survey settings as a CSV file - All settings found on the Survey Settings page can now be exported and imported using a CSV file. A new "Survey Settings" drop-down button will appear in the Online Designer. The dialog for importing the file will list all valid values for some settings that are not obvious, such as multiple choice mappings. Note: The CSV file does not include binary files, such as the Survey Logo and Confirmation Email Attachment.
  • Improvement: The "Help & FAQ" page has been updated with new content (thanks to the FAQ Committee).
  • Improvement: New smart variable [project-title] - Displays the title of the current project.
  • Improvement: New smart variable [project-status] - Returns integer as status of the current project (0=Development, 1=Production, 2=Analysis/Cleanup).
  • Improvement: New smart variable [project-purpose] - Returns integer as purpose of the current project (0=Practice/Just for fun, 1=Other, 2=Research, 3=Quality Improvement, 4=Operational Support).
  • Improvement: New smart variable [project-irb-number] - IRB number of the current project (if specified in the project).
  • Improvement: New setting for the Data Resolution Workflow - Users may enable a new project-level setting "Prevent calc/CALCTEXT fields with closed/verified data queries from being fixed by DQ rule H" in the DRW section of the "Additional Customizations" dialog on the Project Setup page. If using DRW when some calc/CALCTEXT fields have a Verified or Closed data query status, users running DQ rule H may now control whether or not the "Fix calcs now" button in the dialog will fix the value of those fields. In previous versions, DR rule H would automatically exclude calc/CALCTEXT fields with closed/verified status so that they could not be fixed. By default, this new setting is enabled/checked for all existing projects that have DRW enabled in order to maintain backward compatibility. (Ticket #259773b)
  • Improvement: Data Quality rules A through I can now be run for selected fields. A multi-select drop-down is displayed on the page to allow users to select one or more fields, in which DQ rules A through I will be executed against only the selected fields. This will be helpful in some cases when the rules do not need to be applied to all fields in the project or if any of the rules time out after running them against all fields (e.g., Rule H for projects with lots of records).
  • Improvement: The record and DAG drop-down filters for Data Quality rules have been enhanced so that multiple records or multiple DAGs can be selected at the same time, in which any DQ rules that are executed will only be executed on the selected records/DAGs.
  • Improvement: Ability to delete many (or all) Data Quality Rules in a project. (Ticket #245562)
  • Change: The "My Projects" page was widened slightly.
  • Change: For consistency with the Online Designer, uploading a data dictionary that contains multiple choice fields without any choices will now only return a warning, whereas previous versions would return an error. (Ticket #267306)
  • Change/improvement: The project logging page now always displays "SYSTEM" in the "Filter by username" drop-down. (Ticket #267521)
  • Improvement: When exporting a list of users in a project (via CSV file on the User Rights page or via the Export Users API method), it now returns the field "data_access_group_label" to display the name/label of the Data Access Group of a given user. Note: The fields "data_access_group" and "data_access_group_id" were already included in the user export.
  • Improvement: New smart variables for reports and project dashboards
    • [report-access-code] - Returns the access code for the specified public report, assuming the report has been made public and also that an access code has been defined for the report. A colon + the unique report name of the report must be appended - e.g., [report-access-code:R-2554F4TCNT]. Note: The unique report name can be found in the far right column of the report table. Note: If public reports are not enabled at the system level, this smart variable will not be displayed in the smart variable list.
    • [dashboard-access-code] - Returns the access code for the specified public project dashboard, assuming an access code has been defined for the dashboard. A colon + the unique dashboard name of the project dashboard must be appended - e.g., [dashboard-access-code:D-557DRCW87L]. Note: The unique dashboard name can be found in the far right column of the project dashboard table.
    • [dashboard-url] - Returns the web address (URL) of the specified public project dashboard. A colon + the unique dashboard name of the project dashboard must be appended - e.g., [dashboard-url:D-557DRCW87L].
    • [dashboard-link] - Returns a HTML web link that, when clicked, will navigate to the specified public project dashboard. The format must be [dashboard-link:unique_dash_name] or [dashboard-link:unique_dash_name:Custom Text]. "Custom Text" is an optional parameter whereby you can specify the visible link text, and if it is not provided, it defaults to the dashboard title.. A colon + the unique dashboard name of the project dashboard must be appended - e.g., [dashboard-url:D-557DRCW87L] or [dashboard-url:D-557DRCW87L:Click to view our dashboard].
  • Improvement: Improvement: Access code protection for public reports and public project dashboards. Users may optionally set a single access code for a given public report or public project dashboard. Once set, no one will be able to view those pages unless the correct access code has been entered. Users may define their own custom access code or optionally let REDCap auto-generate one for them.

    Once an access code has been successfully entered on a report or dashboard, if the page is refreshed or visited again in the near future, the viewer will not have to re-enter the access code if returning to the page within REDCap's normal auto-logout time for authenticated users (default: 30 minutes). For example, if the auto-logout time is 30 minutes, and the viewer returns 45 minutes after initially entering the access code, they will have to enter the access code to view the page again.
  • Improvement: The locking/e-signature settings found on the Record Locking Customization page in a project can now be exported and imported via a Project XML file.
  • Improvement: The calendar table on the Calendar page is now much wider to fill out the page better and allow more text to be viewed for individual calendar events.
  • Improvement: The "Project Statistics" table on the Project Home page now displays the number of instruments in the project, and if longitudinal, it also displays the number of events/arms.
  • Improvement: Several new categories/classifications were added to the "Standardized Field (CDE)" search feature (formerly known as the "Field Bank").
  • Improvement: Accessibility - Descriptive Popups are now more accessible when using screen readers on surveys and data entry forms.
  • Improvement: When calling the API method "Export a List of Files/Folders from the File Repository", it now also returns the unique User Role (as "role") and unique Data Access Group name (as "dag") for any folder that is role-restricted and/or DAG-restricted, respectively.
  • Improvement: Additional project-level stats are shown on the Project Home stats table, such as when the project was created, when moved to production, and when moved to analysis/cleanup status.
  • Improvement: Accessibility - Some issues with regard to the usage of HTML "BR" tags in field labels on forms and surveys have been fixed/improved. VoiceOver on Chrome announces a BR tag in a field label as an "Empty Group", breaking the reading flow of the field label's text. This issue only occurs with Chrome.
  • Improvement: Accessibility - Keyboard users are now able to navigate to the date/time-picker for date/time fields on surveys and forms. Previously, they were not able to do so because tabbing would skip over the date/time-picker entirely. Additionally, screenreader users are now able to navigate inside the date/time-picker.
  • Improvement: For CDIS projects using Clinical Data Pull, the CDP adjudication flow and user interface have been greatly improved that provides a cleaner layout and easier interaction.
  • Change: General optimizations for the CDP Dashboard.
  • Change: The CDP/DDP mapping page has been refactored to use a form-based workflow with better performance on large mapping sets and event-aware tools for managing and copying mappings across events. (Ticket #269290)
  • Change/improvement: In a CDP adjudication context, more feedback is now provided to users when no data is returned from the EHR, such as suggesting next steps for the user to take to help troubleshoot the situation.
  • Improvement: When using Clinical Data Pull for CDIS, validation display improvements have been added in the CDP Adjudication Workflow. These changes make the display of adjudication values clearer when fields use date or phone validation. This includes the following: 1) Dates now match the format specified by their validation rules, and valid EHR dates no longer trigger warnings, 2) Phone numbers with a +1 prefix are automatically cleaned for consistency, and 3) When the display value differs from the raw value, both are now shown in the table for clarity.
  • Improvement: More improvements for Clinical Data Pull's adjudication flow - Item counts now reflect transformer-adjusted values, the modal always offers Save when selections are possible, forced reloads after saving are gone, and each launch pulls fresh data from the EHR.
  • Improvement: The CDIS-based functionality that interfaces with Epic's "Break the Glass" (BTG) feature has been improved. Previously, BTG tokens were requested immediately when a protected patient was detected, but these tokens (in some conditions) expired too quickly to be useful. Now, REDCap waits to request a token until the user actually chooses to break the glass, ensuring that it is always valid. In addition, identified patients will now remain on the list for five days (instead of just one day), thus giving users more time to review and take action.
  • Change: When using CDIS with Epic, the cached Break-the-Glass (BTG) protected patient list TTL was increased from 5 days to 10 days to give project owners more time to detect and unlock data access for patients in selected CDIS-enabled projects. Additionally, the BTG-protected patient list is now managed in one place, which makes the list consistent across the app and avoids mismatches caused by multiple storage paths.
  • Change/improvement: Improved handling of empty data in Clinical Data Pull adjudication - Fixed an issue where the adjudication interface in CDP/DDP projects displayed error messages when no clinical data was available for a patient record. The system now gracefully displays an empty results screen with a count of 0 items instead of showing confusing error text.
  • Improvement: Multi-race mapping support in CDIS - CDIS projects can now map every race sent by the EHR without breaking existing single-value setups. A new optional "Race (all coded values)" field captures multiple race codes and surfaces them throughout Data Mart, Clinical Data Pull, and Mapping Helper so downstream workflows can store and review the full set of available races.
See also: Upgrade Notes