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

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

1. Randomization: Randomization has gone through a number of improvements with this version of REDCap. Note: Thanks to Luke Stevens (Murdoch Children's Research Institute) for his contribution in building these new randomization features. The best documentation of the new Randomization 2.0 features comes courtesy of the REDCap Team at Seattle Children's Hospital.

Multiple randomizations in a project - Users may now define more than one randomization model in a single project. Each randomization model has its own settings (e.g., strata, randomization field, allocation table), and is completely independent of the other models.
Blinded randomization support - Users may now create a randomization model that is blinded/concealed as a means of concealing the allocation (randomization value) from users to be able to have a truly blinded randomized clinical trial, for example. Users may still choose to create an "open" randomization model (as they always could) by choosing a single-select multiple choice field (e.g., drop-down or radio) to be the randomization field. Alternatively, users may now choose any text field [that does not have field validation] to represent the "randomization number". The randomization number can be uploaded as part of the allocation table, and when a record is then randomized, the field is given the randomization number as its value.
New Smart Variables for Randomization:
- [rand-number] - The randomization number assigned to the record. For randomization in a text field (blinded allocation), this is equivalent to piping the randomization field. For randomization in a categorical field (open allocation), this will be the randomization number associated with the randomization group allocation, if one has been uploaded (this is optional). Use :n to refer to a specific randomization where a project has more than one (default=1).
- [rand-time] - The server date and time at which a record was randomized. In a piping context, such as in a field label, survey invitation, or inside the @default action tag, the format of the date and time will be displayed based on the current user's date/time display preferences. If you wish to have it return the raw value, which will instead be in 'YYYY-MM-DD HH:MM:SS' format and would be more appropriate for conditional logic or calculated fields, simply append :value. Use :n to refer to a specific randomization where a project has more than one (default=1).
- [rand-utc-time] - The UTC date and time at which a record was randomized. In a piping context, such as in a field label, survey invitation, or inside the @default action tag, the format of the date and time will be displayed based on the current user's date/time display preferences. If you wish to have it return the raw value, which will instead be in 'YYYY-MM-DD HH:MM:SS' format and would be more appropriate for conditional logic or calculated fields, simply append :value. Use :n to refer to a specific randomization where a project has more than one (default=1).
Real-Time Trigger Logic - Randomization can be automated to occur in real time when an instrument is saved and a specified logic expression becomes True, in which all required stratification information must be present. At the bottom of the randomization setup page for a given randomization model, the following options are displayed.
- Manual only (default) - A user with "Randomize" user permissions must click the "Randomize" button on the data entry form where the randomization field is located.
- Trigger logic, for users with Randomize permissions only - When the Save button on a specified data entry form is clicked, if the logic expression provided evaluates to True and the current user has "Randomize" user permissions, the record will automatically be randomized (i.e., without clicking a "Randomize" button).
- Trigger logic, for all users (including survey respondents) - When the Save button on a specified data entry form or survey page is clicked, if the logic expression provided evaluates to True (despite the user's permissions if on a data entry form), the record will automatically be randomized.
Project XML & Copy Project - Randomization model settings have now been added as an optional component to copy when doing a "Copy Project" action or when exporting->creating a project via a Project XML file.
Randomization training video - A new Randomization video was added to the Training Videos page. (Must be logged in to REDCap to view; Training Videos link at the top of the My Projects page. )

2. New feature: Draft Preview Mode - Draft Preview Mode allows users to preview their data entry forms with their current drafted changes as if they were live. This allows users to fully test the changes they have made in Draft Mode, including all branching logic, calculations, action tags, and embedded fields, before submitting their drafted changes for approval.

Draft Preview Mode will simulate live data entry on data entry forms, thus allowing users to enter ephemeral data that is stored only in their session; however, no data will actually be saved to the project. Once a user leaves Draft Preview Mode, all ephemeral data that has been entered will vanish.
Limitations: While in Draft Preview Mode, the following limitations exist: No new records can be created. No data can be changed or stored in the project (all data changes are transient and are bound to the user's login session). Only changes to already existing forms can be previewed. Delete operations (deleting whole records or deleting data for forms/events) are disabled. Several more limitations exist and are delineated in the Online Designer before enabling Draft Preview Mode.
Note: Draft Preview Mode only operates on data entry pages, the Record Status Dashboard, and the Record Home Page. It does not impact any other pages, and it currently does not work on survey pages.

3. New feature: Descriptive Popups - Descriptive popups are custom popups of text that become visible after hovering over a specific word or phrase on a data entry form or survey. They have two main components:

the link text, which should match a word or phrase used on a form or survey, and
the custom text for the popup content. Users may set a descriptive popup to work on all instruments/surveys (default) or on specific ones.

Descriptive popups are a great way to convey extra information on a form or survey without the text taking up space on the page. Users may configure their descriptive popups to be activated only on specific instruments. By default, they are enabled on all instruments. Additionally, if the popups are enabled to work on a survey, especially a multi-page survey, users can specify specific page numbers on which the popups will be activated.

Web accessibility: Descriptive popups are WCAG compliant, thus they will work with screen readers.
MLM: Both the link text and popup content text of descriptive popups can be translated using Multi-Language Management.

4. Data Dictionary - The user interface of the "Data Dictionary" page in a project has been simplified and improved to help users better understand the general process of editing and uploading a data dictionary. Additionally, buttons have replaced the links for downloading the data dictionary for improved web accessibility and for a better user experience.

5. Record Home Page

Logging Links: The "Choose action for record" drop-down list on the Record Home Page now lists links to the Logging page, Notification Log, and Survey Invitation Log (if the user has privileges to those pages), in which the current record will already be preselected when navigating to those pages.
Survey Queue Added: The "Choose action for record" menu on the Record Home Page now always displays the "Survey Queue" option for a given record, even if the record's queue currently contains no items. In previous versions, the option would only be displayed if the record's queue contained one or more items. Additionally, the "Survey Queue" option in the drop-down now has a sub-option to allow the user to copy the survey queue link to their clipboard.

6. Data Resolution Workflow

Assign user has auto-complete: When using the Data Resolution Workflow, the "assign user" drop-down list in the DRW dialog is now displayed as an auto-complete drop-down to help users more easily select a user from the list in projects that have a large number of users.
DAG Switcher Awareness: When a user is opening a data query in the Data Resolution Workflow and is assigning the query to a user, if the project contains Data Access Groups and is also using the DAG Switcher, users that can access the current record due to DAG Switching (but are not currently assigned to the record's DAG) will be displayed in the user assignment drop-down for assigning the data query. In previous versions, the user assignment drop-down would only display the users that were currently in the record's DAG and did not respect possible DAG Switcher assignments.
Warning for Data Quality Rule Deletion: When deleting a data quality rule when the Data Resolution Workflow feature is enabled in a project, the rule deletion dialog will now display a red warning to the user to inform them that deleting the rule will also delete any data queries (open or closed) that are currently associated with that data quality rule.

7. Misc

New piping option ":hideunderscore" - If a field value or Smart Variable value is blank/null (i.e., does not exist), then by default the blank value will be piped as six underscore characters (literally ______) as a placeholder to visually indicate that no value exists. However, if this behavior is not desired, users may append :hideunderscore to the variable name inside the square brackets (e.g., [first_name:hideunderscore], [race:value:hideunderscore]), and this will cause value to be piped as-is, that is, as a blank/null/invisible value. Note: The :hideunderscore notation may be appended to both field variables and Smart Variables.
New piping option ":field-label" Users may now pipe the field label of a given field (instead of its data value) by appending ":field-label" to the variable name inside the square brackets.
Spell Check: All rich text editors now utilize the browser's native spell check functionality by putting a red underline under a misspelled word.