REDCap New Features – Version 11.4.4 to 13.1.25 LTS

New feature: Redesign of the File Repository:

Overview: The File Repository page has been redesigned to make it easier to store, organize, and share the files in your projects.Users now have the ability to create folders and sub-folders to help organize their files more effectively. If using Data Access Groups or user roles, users may optionally limit access to a new folder so that it is DAG-restricted and/or role-restricted. Uploading multiple files is much faster with a new drag-n-drop feature that allows for uploading dozens of files at a time. Sharing files is better too, in which users may obtain a public link to conveniently share a file with someone. New API methods also exist that allow users to upload, download, and delete files programmatically using the API. Additionally, the File Repository has a new built-in Recycle Bin folder that makes it easy to restore files that have been deleted. Users can upload as many files as they wish. There is no limit. Additionally, there is no limit to how many folders and sub-folders that can be created (or how deep that they can be nested within other folders).
Sharing: Files can be shared via Send-It or using a public link. If you do not want users to be able to share files using the public link functionality, this may be disabled on the File Upload Settings page in the Control Center. Once disabled, users will only be able to share files using Send-It.
Recycle Bin: Files that are deleted from the File Repository will be put in the Recycle Bin folder where they will be kept for up to 30 days before being permanently deleted. Any file in the Recycle Bin can be restored back to its original location (so long as doing so does not surpass the project’s file storage limit, if enabled). Administrators can “force delete” any file in the Recycle Bin, which deletes it immediately and permanently.
New API methods for the File Repository: 1) Create a New Folder in the File Repository, 2) Export a List of Files/Folders from the File Repository, 3) Export a File from the File Repository, 4) Import a File into the File Repository, and 5) Delete a File from the File Repository.

New feature: Integration of the MyCap External Module

Introduction: MyCap is a participant-facing mobile application (on iOS and Android) used for data collection and the automated administration of active tasks (activities performed by participants using mobile device sensors under semi-controlled conditions). All data collected in the MyCap app is automatically sent back to the REDCap server as soon as internet connection is available (i.e., it can also be used for offline participant data collection). MyCap is a no-code solution for research teams conducting longitudinally-designed projects or projects with frequent participant contact. MyCap also facilitates participant engagement and retention by providing quick access to project staff and two-way communications (e.g., messaging and announcements) within the app. MyCap is available on any iOS
device (iOS v11.0 ) and any Android device (Android v8.0 ). For more information about MyCap, check out the MyCap website, publication, resources, and a list of MyCap use cases.
System-level settings: The MyCap feature will be enabled globally by default after upgrading or installing REDCap, but it can be disabled (so that no users see the option in their projects) on the Modules/Services Configuration page in the Control Center. That page also contains a setting where, assuming MyCap is enabled globally, an admin can set it so that 1) users can enable MyCap in their projects on their own, or 2) users will need to click a button in their project to send a request requiring admin approval to enable MyCap in the project.
Project-level settings: The ability to enable or request to enable MyCap in a project will be in the Main Project Settings section at the top of the Project Setup page. There is an informational dialog there that can be opened that contains helpful links to many resources, including the MyCap website, the MyCap Help document (a detailed 16-page instruction manual on setup and usage), and three videos.
Project Utilization: Utilizing MyCap in a project consists of two main parts: 1) design, and 2) managing participants. The design portion is where users can enable instruments as MyCap tasks, import active tasks, and design the look and feel of the MyCap app (as the participant sees it). These things pertaining to design are performed in the Online Designer and thus require “Project Design and Setup” rights. The participant portion requires a new user right “Manage MyCap Participants” that appears on the User Rights page after MyCap has been enabled in a project. Having this privilege, a user will have access to the “MyCap Participant Management” page on the left-hand menu. This page will allow users to view, invite, and message their MyCap participants. In many ways, it is very similar to the “Survey Distribution Tools” page when using surveys.
External Module Migration: If users have been using the MyCap external module, there is an upgrade path to import all the MyCap EM settings into the built-in MyCap feature. In projects with the MyCap EM enabled, users will see a “Migrate to REDCap” button on the left-hand menu, which opens a dialog with plenty of information about the new built-in MyCap feature. As the dialog will note, users themselves cannot perform the migration, but a REDCap admin must do so for them. The migration is fast and only requires a couple button clicks, after which it will disable the MyCap EM in the project. Note: Currently, the MyCap EM is planned to be supported only until June 2023, so it is recommended that users using the EM attempt to fully migrate well before that time.
Smart Variables and Action Tags: Several new Smart Variables and Action Tags can be used with MyCap, some of which are a required, integral part of how users invite participants and also how MyCap imports data into a project. See the documentation for Smart Variables containing the prefix “mycap-” and Action Tags containing the prefix “@MC-”.
Stats: System-level MyCap statistics can be seen on the System Statistics page in the Control Center.

New feature: Download all files on a report - When viewing a report (including public reports) that contains one or more File Upload fields or Signature fields, a “Download Files (zip)” button will appear on the page to allow users to easily download all the report’s uploaded files into a single zip file for those fields for the records in the report.

New Feature: SendGrid Template Advanced Settings for Alerts & Notifications

Introduction - A new “advanced settings” section was added to the Alerts & Notifications interface when building an alert using the relatively new SendGrid Template alert type that gives users more control over the underlying SendGrid API call being made when REDCap triggers a SendGrid Template alert. Note that all of the advanced settings are optional, and they are all disabled by default. If “SendGrid Template email services for Alerts & Notifications” are enabled for a project on the Project Setup page, then these advanced settings will appear in the alert creation dialog after selecting “SendGrid Template” as the alert type. The new advanced settings are all listed in detail below.
SendGrid Unsubscribe Groups - SendGrid can allow recipients of its emails to unsubscribe from all emails being sent from a sendgrid account, or from emails associated with specific unsubscribe groups in a sendgrid account. To take advantage of custom unsubscribe groups, you can create unsubscribe groups in your sendgrid account then associate them with alerts in your REDCap project. When a recipient unsubscribes from an email that has been associated with a specific unsubscribe group, they get added to that unsubscribe group's list and any future emails that are associated with that unsubscribe group will not be delivered to them. An alert can be associated with at most one unsubscribe group. Here is SendGrid's documentation on unsubscribe groups: https://docs.sendgrid.com/ui/sending-email/unsubscribe-groups.
SendGrid Categories - SendGrid allows you to associate arbitrary categories to each email you send from your account, effectively giving you the ability to tag each individual email sent with different metadata about the email like the email type. Unlike unsubscribe groups, categories don't have to be made in your sendgrid account before associating them with an alert in REDCap. You can define your categories in REDCap as you create your REDCap alert, and your sendgrid account will automatically detect new categories as emails get sent with them. In your SendGrid account's Category Stats page, you'll be able to see data about your emails by category. You can associate up to 10 unique categories per email, and a category name cannot be longer than 255 characters.
SendGrid Mail Settings - Full documentation for the SendGrid bypass settings can be found at https://docs.sendgrid.com/ui/sending-email/index-suppressions#bypass-suppressions.
Bypass List Management - When enabled, your email will be delivered regardless of any other existing suppression management control in your account. For example, if a recipient is in an unsubscribe group or the global unsubscribe group, they will still receive the email if bypass list management is enabled. Bypass List Management can't be combined with any other bypass option.
Bypass Spam Management - Allows you to bypass the spam report list to ensure that the email is delivered to recipients. Some email services allow recipients to mark emails as spam. In some cases, sendgrid will be notified when a recipient marks an email as spam and will maintain a spam report list.
Bypass Bounce Management - Allows you to bypass the bounce list to ensure that the email is delivered to recipients. A bounce occurs when a receiving mail server rejects an incoming email. This can happen if the recipient address is bad, for example. If sendgrid sees too many bounces happening, it will add that recipient to a bounce list and it will stop trying to send mail to that recipient. Enabling this will bypass that bounce list and force sendgrid to retry delivery.
Bypass Global Unsubscribe Management - When enabled, your email will be delivered even if the recipient is on your account's global unsubscribe list.
Sandbox Mode - Sandbox mode lets you check for errors in the SendGrid API call used to send an email without the potential of delivering the email. If you're unsure about your sendgrid configuration, you can run a test by enabling sandbox mode for an alert and triggering it. If your project's logs state that the alert was sent successfully and you don't see any errors, then your configuration is good to go. However, since sandbox mode was enabled for that alert, an email was not actually sent. After you're satisfied with your tests, you can disable sandbox mode and start sending real emails with your alert.
SendGrid Tracking Settings
Click Tracking - SendGrid has the ability to detect when a recipient clicks on links in an email. The count of clicks for a given email can be seen in the email activity section of your sendgrid account.
Open Tracking - SendGrid has the ability to detect when a recipient opens an email by embedding a single pixel image in an email. Enabling this setting will make sendgrid include this tracking pixel in your emails. You can view the count of opens for a specific email in the email activity section of your sendgrid account.
Subscription Tracking - If subscription tracking is enabled and configured on your sendgrid account, this setting lets you choose whether or not you want to include the global unsubscribe link associated with the subscription tracking feature in your emails. Note that you can utilize unsubscribe groups without using the more general subscription tracking feature. I believe subscription tracking is disabled by default on a sendgrid account. Here is some documentation from sendgrid about unsubscribe methods: https://support.sendgrid.com/hc/en-us/articles/1260806604209-Unsubscribe-Methods
Miscellaneous Additions
Added an External Service Check for https://api.sendgrid.com/v3 in the Control Center's Configuration Check page.
Added a line in the Modules utilized section of the Systems Statistics page to keep track of how many non-practice projects are utilizing sendgrid for Alerts & Notifications.
Additional SendGrid API Token Requirements - To fully support SendGrid Advanced Settings, the SendGrid API token used in the project's setup needs the permission for getting an account's unsubscribe groups through the API. This permission is mapped to the asm.groups.read scope. You can
add this permission to your existing API token by editing its permissions in your SendGrid account and giving it Read Access to Unsubscribe Groups in the Suppression section.

New feature: Repeating Automated Survey Invitations (ASIs)

Users can now set ASIs to send multiple times on a recurring basis for any repeating survey in a project. If the survey is a repeating instrument or if it exists on a repeating event, then users will see a new section "How many times to send it" in the ASI setup popup in the Online Designer. There users may set the ASI to send survey invitations repeatedly at a regular interval, in which it can repeat forever or a set number of times. This new repeating ASI feature works similarly to how recurring alerts have always worked for Alerts & Notifications.
Note: If an instrument is not a repeating survey, then this new section will not appear for that survey in the ASI setup dialog.
When an ASI is set up to recur for a repeating survey, the [survey-link] Smart Variable in the invitation text will always point to a different repeating instance of the survey for each time the invitation is sent. For example, if the ASI is set to recur daily, then the first day’s invitation will have a link pointing to instance #1 of the survey, the next day’s invitation will point to instance #2, then the next to #3, and so on.

New Smart Variable: 

This new Smart Variable [new-instance] can be appended to [survey-link], [survey-url], [form-link], and [form-url] to create a URL that points to a new, not-yet-created repeating instance for the current record. In this way, [new-instance] functions essentially as [last-instance] 1. This new Smart Variable works for repeating instruments and also for instruments on repeating events.
[new-instance] can also be used as stand-alone, in which it will return an integer. But it will only work when used within the context of a repeating instrument or repeating event, in which it will essentially return [last-instance] 1 for the current repeating context.
[new-instance] will auto-append “&new” to the end of the form link or survey link (when used with [form-link/url] or [survey-link/url]) and thus will cause the user/participant to be redirected to the next repeating instance if the current repeating instance (i.e., the instance number in the URL) already exists for the record. Thus, using [form-link] or [survey-link] appended with [new-instance] will ensure that you always end up on a new, not-yet-created instance. And if two participants arrive at the same repeating survey instance with both using the exact same link created by [survey-link][new-instance], then the second participant to submit the survey page will not override the first participant’s response. Instead, it will add the second participant’s response as another repeating instance that does not exist yet.
TIP: One of the main intended usages of [new-instance] is to utilize it as [survey-link:instrument][new-instance] inside the text of a recurring alert to allow users/participants to enter data easily into a repeating survey. In this way, it works very similarly to a repeating ASI. However, repeating ASIs do not need their survey link appended with [new-instance] because it is already implied from the ASI setup.

New feature: Embedding images in text & emails

Users may now embed one or more inline images into the text of a survey invitation, an alert, or a field label on a form/survey, among other things, by clicking the image icon in the rich text editor and then by uploading an image from their local device. Anywhere that the rich text editor is used, users may embed an image into its text (with one exception: the @RICHTEXT action tag on public surveys).
If you wish to disable the ability to embed images in text via the rich text editor, you may disable this functionality at the system level on the Modules/Services Configuration page in the Control Center.

New feature: Calendar Sync

Users may sync their REDCap project calendar or perform a one-time import of their project calendar events to external calendar applications such as Google Calendar, Outlook, Office 365, Zoho, Apple Calendar, or any application that supports iCal or ICS files. They may choose one of the two options below to sync or import their project calendar events to an external calendar application.
Live calendar feed: Add calendar from URL/Internet - A unique web address will be displayed in a dialog on the Calendar page, in which the URL represents a real-time live feed of the REDCap project calendar. Users may copy the URL to paste it as the calendar URL in their calendar application using the option "Add calendar from URL/Internet". This will subscribe their external application to the REDCap project calendar. Privacy Note: This calendar feed URL on the Calendar page is unique to the user in the project. So if the user gets expired, removed from the project, or deleted from the system, their unique calendar feed will go blank and will not output anything anymore (for privacy purposes).
One-time import: Download ICS file - Download and open the calendar ICS file below to import REDCap calendar events manually into the calendar application on your computer, or upload the file to a web-based calendar service. Notice: This is not a live feed but a one-time import. Thus, any new events added to the REDCap calendar in the future will not be automatically added to the external calendar application.
Disabling: The Calendar Sync feature can be disabled at the system level on the Modules/Services Configuration page in the Control Center.
Feed-syncing Notice: Different calendar applications have different refresh rates. So if new events are added to the calendar in REDCap, they may not immediately appear in the external application that is consuming the feed but will appear after the next refresh interval, which might be some time later that
day or the next day (depending on the calendar application). Additionally, the calendar feed represents a one-way feed. This means that while changes made to the calendar in REDCap will automatically show up in the external calendar application, users will not be able to modify them in the external calendar application because they will be read-only.
Privacy Note: When viewing events from the Calendar page’s feed or downloadable ICS file, any data from Identifier fields will be automatically removed from the feed/file (e.g., if identifier fields are included in the Custom Record Label or Secondary Unique Field, or if the record name is an identifier), in which their data will be replaced with the text “**DATA REMOVED**”.

New calendar-specific Smart Variables

[calendar-url] - The web address (URL) of the calendar feed or downloadable ICS calendar file belonging to the current record.
[calendar-link:Custom Text] - The HTML web link that, when clicked, will navigate to the calendar feed or downloadable ICS calendar file belonging to the current record. 'Custom Text' is an optional parameter whereby you can specify the visible link text, and if it is not provided, it defaults to simply displaying the URL as the link text.

New feature: SendGrid Dynamic Templates for Alerts & Notifications

SendGrid Dynamic Templates give users significantly more control over the style and design of emails when compared to the standard email alert type. Enabling this feature on the Project Setup page will give users another alert type to choose from on the Alerts & Notifications page called “SendGrid Template”. Thus, similar to Twilio, this feature is a project-level feature that users may enable on individual projects (or users can have administrators enable it for them).
DISABLING: The SendGrid Dynamic Templates feature can be disabled at the system level on the Modules/Services Configuration page in the Control Center. There are also other additional features on that page that determine who can enable the SendGrid services in a given project.
SETUP & CONFIGURATION: This integration requires that you have an account setup on sendgrid.com. After creating a SendGrid account, you'll need to configure senders for the account, create the dynamic templates you wish to use for REDCap alerts, and generate an API Key with appropriate permissions for REDCap to use. When configuring senders on your SendGrid account, you may specify individual senders, authenticate an entire domain so that any email address associated with that domain may be a sender, or both. Please refer to SendGrid's documentation on how to set up Domain Authentication and how to add individual Verified Senders. To create a dynamic template in your SendGrid account, login to your SendGrid account and use the sidebar to navigate to Email API→Dynamic Templates. Here you can create a dynamic template, give it a name, and associate an email design with it. Please reference SendGrid's documentation on Dynamic Templates and Handlebars to learn more about creating templates in your SendGrid account. Lastly, to create an API Key for REDCap, login to your SendGrid account and use the sidebar to navigate to Settings→API Keys. Here you can create a new API Key and specify its permissions. It is recommended that you create a Restricted Access API Key and only give the
API Key the permissions REDCap needs to function. REDCap will need Full Access to Mail Send, Read Access to Sender Authentication, and Read Access to Template Engine. Once you have your API Key, you may use it to configure SendGrid Template email services for alerts & notifications through the REDCap Project Setup page.
ALERTS & NOTIFICATIONS: The SendGrid Template alert type will allow you to specify a sender email address that's in your SendGrid account's list of Verified Senders or an email address that matches an Authenticated Domain associated with your SendGrid account. You'll also have an interface to choose which of your SendGrid account's dynamic templates you'd like to use for the alert as well as an interface to specify key/value pairs that will be used to populate your template with REDCap data. Lastly, choosing recipients for SendGrid alerts works the same way as choosing recipients for email alerts.
COST: As REDCap makes API calls to SendGrid's Email API using your account's API Key, your SendGrid account will keep track of REDCap's usage and your SendGrid account will be charged accordingly. This is not done by REDCap but is done internally by SendGrid as you use its services. In this way, no monetary transactions are made by REDCap, and thus it is your responsibility to maintain the funds in your SendGrid account in order to ensure that the service continues to work for your REDCap project. If your SendGrid account runs out of funds, the SendGrid services in REDCap will cease to function. You may reference SendGrid's pricing page to get their latest pricing.
Thanks to Remi Frazier and Kaizen Towfiq at University of California San Francisco for their code contributions, which made this new feature possible.

New feature:Integration of many features from the “Survey UI Tweaks” External Module

Thanks to Andy Martin and his team at Stanford for their creation and support of the EM. Several (but not all) of the features in the Survey UI Tweaks EM have been integrated as-is. Some features from the EM have actually existed in REDCap for a while. As such, the Survey UI Tweaks EM will not be disabled for any projects or even at the system level when upgrading to this version.
Improvement: If custom question numbering is used on a survey page in which no questions have a custom question number defined, the extra space on the left of the questions will be removed to give the questions more room for display on the page.
Improvement: On the Survey Settings page, the setting “For Required fields, display the red 'must provide value' text on the survey page?” now has a new option: "Display only the red asterisk". This provides an additional option rather than having to choose between the binary options to hide or not hide the text.
Improvement: When taking a survey while on a mobile device, the survey page will auto-scroll whenever selecting a value for a drop-down or radio button field to help the participant scroll down the page more easily.
Improvement: New survey setting allows users to set a custom width of the survey displayed on the page between 50% and 100%. The default value for the setting is “Fixed width (default)”.
Improvement: New survey setting allows users to display or hide the font resize icons at the top of the survey page. By default, it is set to display the font resize options.
Improvement: New survey setting allows users to show or hide the Submit buttons displayed at the bottom of every survey page (including the 'Next Page' and 'Previous Page' buttons).
Improvement: New survey setting allows users to provide alternative text for the 'Submit', 'Next Page', and 'Previous Page' buttons displayed at the bottom of every survey page.

New feature: When using the survey setting “Save a PDF of completed survey response to a File Upload field”, users can now optionally set this feature to store the translated version of the PDF if the Multi-language Management feature is being utilized for the survey. This can be enabled by checking the “Store the translated version of the PDF” checkbox below the “Save a PDF…” setting on the Survey Settings page for the desired survey. (Ticket #121955)

New feature: Instrument-level Data Export Rights

Users may specify instrument-level privileges regarding a user's data export capabilities on the User Rights page in a project. A user may be given "No Access", "De-Identified", "Remove All Identifier Fields", or "Full Data Set" data export rights for EACH data collection instrument. This improvement will make it much easier to match a user's Data Exports Rights with their Data Viewing Rights, if you wish, and will give users more granular control regarding what data a user can export from your project.
Note: Whatever a user’s data export right was in the previous version, that export right will be subsequently extrapolated to all instruments after upgrading. Thus, their export privileges will behave exactly the same as before.
Improvement: The table displayed on the User Rights page that lists all users’ privileges now includes an instrument count for each category for both Data Viewing Rights and Data Export Rights - e.g., “3 No access, 2 Full Data Set”. This helps provide summary information regarding the user’s instrument-level rights.
Improvement: When adding/editing a user’s or user role’s privileges in the popup on the User Rights page, as a convenience, users may click the table headers for each Data Export Rights setting or Data Viewing Rights setting to set that setting for all instruments in the project (i.e., as a “check all checkboxes”).
Note: When adding a new data collection instrument to a project, if the project is in development status, all users will automatically receive "Full Data Set" data export rights for that new instrument. Whereas if the project is in production, all users will automatically receive "No Access" data export rights for the new instrument. This behavior matches how instrument-level rights currently work for Data Viewing Rights when adding a new instrument.
Change: When importing or exporting users and/or user roles (whether as a CSV file on the User Rights page or via the API), the new instrument-level data export rights are represented as a new column named “forms_export” and are formatted exactly how instrument-level Data Viewing Rights (“forms”) are currently formatted in comma-delimited fashion - e.g., “demographics:1,baseline_data:2,prescreening:3”. In this format, the following represents each data export rights level: 0=No Access, 2=De-Identified, 3=Remove Identifier Fields, 1=Full Data Set.

New feature: Survey Start Time and related Smart Variables

REDCap now collects when participants begin a survey (i.e., the initial time the survey page is opened). Going forward, any responses collected (partial or completed) will have their start time displayed at the top of the data entry form when viewing the response. NOTE: If the start time is a blank value, it implies that the response began while on an earlier version of REDCap when start times were not yet collected.
New Smart Variables for Survey Start Date/Time: Users can access the start time via piping by using the new Smart Variables [survey-time-started:instrument] and [survey-date-started:instrument], which can be used inside the @DEFAULT or @CALCTEXT action tags, among other places. If users wish to have them return the raw value, which will be in 'YYYY-MM-DD HH:MM:SS' format and would be more appropriate for conditional logic or calculated fields, simply append ':value' after the unique instrument name - e.g., [survey-date-started:instrument:value].
New Smart Variables for Survey Duration: Users can obtain the total amount of time that has elapsed since the survey was started (in seconds, minutes, etc.) by using [survey-duration:instrument:units] and [survey-duration-completed:instrument:units]. The Smart Variable [survey-duration] represents the difference between the survey's start time and either its 1) completion time (if completed) or 2) the current time (if not completed), whereas [survey-duration-completed] represents the difference between the survey's start time and completion time, in which a blank value will be returned if the survey has not been completed. Options for 'units': 'y' (years, 1 year = 365.2425 days), 'M' (months, 1 month = 30.44 days), 'd' (days), 'h' (hours), 'm' (minutes), 's' (seconds).

New feature: Conditional logic for Survey Auto-Continue - When enabling Survey Auto-Continue on the Survey Settings page for a survey, users may now optionally specify conditional logic to determine whether or not the auto-continue should be applied. As such, REDCap will auto-continue to the next survey *only* if the conditional logic is TRUE or if the logic textbox has been left blank. This new option can be used as a simpler alternative to the Survey Queue, which can require more complex instrument-event level configurations for longitudinal projects.
New feature: Dynamic min/max range limits for fields - Instead of using exact values as the minimum or maximum range of Textbox fields (e.g., "2021-12-07"), you may now also use "today" and "now" as the min or max so that the current date or time is always used. These can be used to prevent a date/time field from having a value in the past or in the future. Additionally, you can now pipe a value from another field into the field's min or max range setting - e.g., [visit_date] or [event_1_arm_1][age]. This
can help ensure that a Textbox field (whether a date, time, or number) has a larger or smaller value than another field, regardless of whether the field is on the same instrument or not.

New feature: Multi-Language Management

Summary: Users can create and configure multiple display languages for their projects for surveys, data entry forms, alerts, survey invitations, etc. Users can design data collection instruments and have them be displayed in any language that they have defined and translated so that their survey participants or data entry persons can view the text in their preferred language. This eliminates the need to create multiple instruments or projects to handle multiple languages. NOTE: The MLM feature will not auto-translate text, but provides tools so that users may easily translate them themselves.
Usage: When entering data on a data entry form or survey, users and participants will be able to choose their language from a drop-down list or buttons on the page to easily switch to their preferred language for the text displayed on the page. This feature allows users to translate all text related to the data entry process, both for surveys and for data entry forms. Even various survey settings and email text can be translated. For users on data entry forms, if a language is selected, that selection is stored in the user’s user account settings internally (in the REDCap backend database), whereas a survey participant’s selected language will be stored in a cookie in their web browser as a way to remember their language preference if they return in the future (and also to maintain their selected language from page to page). The language can be pre-selected for a participant, if desired, using the “Language preference field” setting on the MLM page in the project or via the @LANGUAGE-FORCE action tags (seen below).
User Rights: Users must have Project Design/Setup privileges in a project in order to see the link to the Multi-Language Management page on the left-hand menu.
System-level Configuration: The MLM feature can be completely disabled at the system level, if desired, via the MLM page in the Control Center (on the Settings tab). On this page in the Control Center, admins can optionally seed any User Interface (i.e., stock language) translations for the entire REDCap installation, in which users could import any activated User Interface translations into their project. This will only import the User Interface elements (since those are universal to each project), but it can be a big time saver to prevent the user from having to translate those common elements in their project. These can be imported via the Create New Language process in a project (or via the Edit Language setting also).
Note: The MLM feature works seamlessly with SMS messages sent via Twilio. Additionally, the MLM feature works with the e-Consent Framework, in which the archived PDF of the participant’s consent form will be stored in the File Repository in the same language in which the participant took the survey.
Note: When a project is in production, the MLM page and all translations can only be modified when the project is in Draft Mode. So if the user desires to make edits or additions to their translations, they must first enable Draft Mode via the Online Designer, and then return to the MLM page to make translation changes while in Draft Mode. When the drafted changes are approved, their translation changes made while in Draft Mode will automatically be approved together with them.
New Action Tags for Multi-Language Management
@LANGUAGE-CURRENT-FORM - Allows you to capture the currently used language in projects where multilingual data is enabled on data entry forms. The @LANGUAGE-CURRENT-FORM action tag can be used on fields of type 'Text Box' (no validation), and 'Drop-down List', or 'Radio Buttons' (these need to have choices whose codes correspond to the IDs of the defined languages - e.g., 'en'). This action tag is only active on data entry forms and will always, when possible, set the field's value to the currently active language.
@LANGUAGE-CURRENT-SURVEY - Same as @LANUGAGE-CURRENT-FORM, but works only on survey pages. For multi-page surveys, @LANGUAGE-CURRENT-SURVEY needs to be used on a field of each page where capture of the language is relevant (e.g. for performing branching).
@LANGUAGE-FORCE - When used on a field, the data entry form or survey on which the field is located will be rendered in the specified language (which must have been set up using the Multi-Language Management feature). The format must follow the pattern @LANGUAGE-FORCE="???", in which the ID of the desired language should be inside single or double quotes - e.g., @LANGUAGE-FORCE="de". Piping is supported - e.g., @LANGUAGE-FORCE="[field_name]". When the language is forced successfully (i.e., it exists and is active), the language selector is hidden. Using this together with @LANGUAGE-CURRENT-FORM/SURVEY on the source field for @LANGUAGE-FORCE may be used to 'lock in' a user to their selected language.
@LANGUAGE-FORCE-FORM - Same as @LANGUAGE-FORCE, but the effect is limited to data entry forms (i.e. this does not affect surveys).
@LANGUAGE-FORCE-SURVEY - Same as @LANGUAGE-FORCE, but the effect is limited to surveys (i.e. this does not affect data entry forms).
@LANGUAGE-SET - When used on a Drop-down or Radio Button field only, this action tag will allow the field's value to control the currently shown language (in the same way as switching the language via the buttons at the top of the page). Tip: When used in a survey, this field could be prepopulated (and thus auto-selected) by embedding a participant's language ID in the survey URL itself (for details, see the FAQ's "How to pre-fill survey questions" section).
Thanks to Günther Rezniczek for all his work to help us build the new Multi-Language Management feature.

New feature: Form Display Logic

Form Display Logic is an advanced feature that provides a way to use conditional logic to disable specific data entry forms that are displayed on the Record Status Dashboard, Record Home Page, or the form list on the left-hand menu. You might think of it as 'form-level branching logic'. Form Display Logic can be very useful if you wish to prevent users from entering data on a specific form or event until certain conditions have been met. The forms will still be displayed on the page, but they will be disabled in order to prevent users from accessing them. Below you may define as many conditions as you want. A
form may be selected in multiple conditions, but if so, please note that the form will be enabled if at least one of the conditions is met. The Form Display Logic does not impact data imports but only operates in the data entry user interface to enable/disable forms. Additionally, Form Display Logic is not utilized by the Survey Queue at all but can affect the behavior of the Survey Auto-Continue feature if the checkbox for it is enabled in the setup dialog. The Form Display Logic setup can be found by clicking the “Form Display Logic” button at the top of the instrument list in the Online Designer.
This feature serves as the official integration of the Form Render Skip Logic external module created by Philip Chase and his team. Thanks to them for their work on this module. Note: When upgrading REDCap to v12.0.0 or higher, if the Form Render Skip Logic is installed and is being used by any projects, all the configuration settings for the module will automatically be translated into the new Form Display Logic settings format, after which the external module will be disabled for each project and also for the entire system (since it will no longer be needed). This all happens automatically during the upgrade.

Version 11.4.4

CHANGES IN THIS VERSION:

• Improvement: New parameter "repeat_instance" was added to the API method "Export PDF file of Data Collection Instruments" to allow users to export a PDF of an instrument for a specific repeating instance of a repeating instrument/event. (Ticket #117182)
• Change/improvement: When a survey participant partially completes a survey that has the Save & Return Later feature enabled, and an email is then sent to the participant to remind them to finish their survey later, instead of sending that email from the system-level "Email Address of REDCap Administrator" (as in previous versions), the "From" email address of the "Survey partially completed" email will be set to the sender's address from the most recent survey invitation received by the participant. This will create more consistency and will reduce confusion for participants when attempting to reply back to the email, as has been a problem in the past.

Version 11.4.0

CHANGES IN THIS VERSION:

• New action tag: @IF- Allows various action tags to be set based on conditional logic provided inside an @IF() function - e.g., @IF(CONDITION, ACTION TAGS if condition is TRUE, ACTION TAGS if condition is FALSE). Simply provide a condition using normal logic syntax (similar to branching logic), and it will implement one set of action tags or another based on whether that condition is true or false. For example, you can have @IF([yes_no] = '1', @HIDDEN, @HIDE-CHOICE='3' @READ-ONLY), in which it will implement @HIDDEN if the 'yes_no' field's value is '1', otherwise, it will implement the two action tags @HIDE-CHOICE='3' and @READ-ONLY. If you wish not to output any action tags for a certain condition, set it with a pair of apostrophes/quotes as a placeholder - e.g., @IF([my_radio]='1', @READONLY, ''). You may have multiple instances of @IF for a single field. You may also have multiple nested instances of @IF() inside each other. Both field variables and Smart Variables may be used inside the @IF condition. The @IF action tag is also evaluated for a given field when downloading the PDF of an instrument/survey, in case there are any PDF-specific action tags used inside of @IF(). Note: The conditional logic will be evaluated only when the survey page or data entry form initially loads; thus the action tag conditions will not be evaluated in real time as data is entered on the page.
• New feature: Protected Email Mode
  • Users can enable the Protected Email Mode on any project on the Project Setup via the Additional Customization dialog. This setting prevents identifying data (PHI/PII) from being sent in outgoing emails for alerts, survey invitations, and survey confirmation emails.
  • If enabled, either A) all alerts, survey invitations, and survey confirmation emails or B) those whose email body is attempting to pipe data from Identifier fields will be affected, in which it will not send the full email text to the recipient but will instead send a surrogate email containing a link that leads them to a secure REDCap page to view their original email. If someone is accessing an email in the Protected Email Mode for the first time (or for the first time in the past 30 days), it will send a security code to their inbox that will allow the recipient to view any protected emails for up to 30 days on that same device. The Protected Email Mode is similar to Microsoft Outlook's "sensitivity label" feature.
  • When enabled in a project, users may specify custom text/HTML to display at top of the sent email and web page where the original email is viewed. This will allow users to also display logos/images pertaining to their project or institution.
  • This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
• New feature: Email Logging page
  • This is a new project page that contains a search interface to allow users with User Rights privileges to search and view ALL outgoing emails for that project (also includes searching and viewing of SMS messages if using Twilio services).
  • This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
  • “Re-send email” feature - When viewing an individual email after performing a search on the page, a “Re-send email” button will be displayed in the dialog to allow users to re-send the email. Note: If the original email contained email attachments, the attachments will not be included in the email that is re-sent.
  • Only users with User Rights privileges in the project may access the page, and additionally they must opt-in and agree to a disclaimer before being able to view the page. The following text will be presented to the user before accessing the page: “Before viewing and accessing this page, you must first agree that you understand the following important information and conditions. This page is only accessible by users having User Rights privileges in this project. The Email Logging feature allows users to search and view *all* outgoing emails related to this project, and this includes being able to view all aspects of any given email (i.e., the recipient(s), sender, subject, message body, attachment names). If you are using anonymous surveys in this project, keep in mind that viewing this page and the emails displayed therein might inadvertently cause anonymous survey responses to be identifiable/de-anonymized. Additionally, if the project is using Data Access Groups, you will be able to view the emails related to all DAGs in this project (and thus possibly any data piped into the body of those emails). If you understand and agree to these conditions, click the button below. Please note the act agreeing to this disclaimer will be documented on the project Logging page.”
• Improvement: New "Banned IP Addresses'' pagein the Control Center allows administrators with "Manage User Accounts'' privileges to add or remove IP addresses to/from the blocklist of banned IP addresses for the REDCap installation. The IP addresses listed on that page are IPv4 or IPv6 addresses that have been blocked manually using that page or have been banned automatically via the Rate Limiter feature (enabled on the General Configuration page in the Control Center).
• Improvement: When using the ''Reason for Change'' feature in a project, a new button is displayed underneath each "reason for change" textbox on the Data Import Tool summary page. Users can simply click the button to copy the text to all other "reason for change" textboxes on the page, thus saving lots of time of having to add text to each individually. This feature is the integration of Luke Steven’s “Copy Change Reason” external module, which will be automatically disabled at the system-level when upgrading to (or past) REDCap 11.4.0 to prevent any conflicts.
• Improve: New data export option - Export blank values for gray instrument status
  • All instrument complete status fields having a gray icon can be exported either as a blank value or as "0"/”Incomplete”. In previous versions, they could only be exported as “0”. By default, they are now exported with a value of “0”, but this option can be changed via a drop-down option in the “Advanced data formatting options” section of the data export dialog.
  • When exporting the Project XML file with both metadata & data, the option to export gray instrument status as a blank value will be preselected by default, whereas in other data export contexts (e.g. My Reports & Exports page), the option to export them as “0” will be preselected by default.
  • The API method “Export Records” has a new optional parameter “exportBlankForGrayFormStatus” that can accept a boolean (true/false) with default value = false, and it functions the same as its equivalent data export option in the user interface.
  • Note: Exporting gray instrument statuses as blank values is recommended if the data will be re-imported into REDCap. For example, when users export a Project XML file for a project and then create a new project with it, all the gray instrument status icons will be preserved in the new project, whereas in previous versions they were all converted into red status icons.
• Improvement: New option “Allow normal users to edit their primary email address on their Profile page” on the User Settings page in the Control Center. This setting will be enabled by default, but an admin can disable it if they wish to prevent any users from modifying their primary email address for their user account.
• Improvement:The developer methods REDCap::getSurveyLink() and REDCap::getSurveyQueueLink() now have an optional parameter "project_id" that (when provided) allows one to call the method outside of that target project's context. If project_id is not explicitly provided, then the methods must still be called within their target project's context.
• Minor security fix:A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way as user-defined text on the Project Setup page.
• Major bug fix: When a repeating instrument has data entered on multiple repeating instances, and then afterward the instrument is made to no longer be repeatable, then any new data entered on that data entry form for fields that already have data on other instance might mistakenly get stored in the wrong repeating instance (i.e., get orphaned in the "redcap_data" database table) and thus would fail to be seen when reloading the form again. (Ticket #115308)
• Improvement/change: New LOINC codes were added for CDIS-related functionality.
• Change: All CDIS-related features and functionality now utilize a centralized set of assets in the code, rather than each feature having only their own private set of assets. This change reduces the entire size of the REDCap code by half, thus saving lots of space on the REDCap web server.
• Various updates and fixes for the External Module Framework, such as the following: PID parameter safety improvements, Documentation updates, Prevented unnecessary errors from the Portable UTF-8 library's auto-redirection, Increased the setting lock timeout, and Fixed a getSafePath() case with absolute paths.

Changelog LTS version 10.2

Improvements to 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 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.

REDCap-Branded URL Shortener (https://redcap.link)

• 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. 

Project Life Cycle Changes

• “Inactive” project status renames to “Analysis/Cleanup.”
• 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.
• 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 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.

Surveys to Capture Custom Information During Project Status Transition 

• On the User Settings page in the Control Center, four optional fields have been added to allow you to utilize public surveys to capture custom information from users when projects transition to a new status (i.e., move to Analysis/Cleanup status, mark as Completed). This allows administrators to create custom surveys to capture all the info they desire from users during these project transitions. The survey will be presented inside an iframe on the page. The user must complete the survey before completing the process on the page. You may use any or none of these fields.

 DAG Switcher  

• 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 themselves 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 optional and can be used in any project that has Data Access Groups.
• NOTE: The DAG Switcher feature does not override a user's current DAG assignment, as set on the Data Access Groups page or the User Rights page.
• This feature is the result of integrating the “DAG Switcher” external module built by Luke Stevens. We thank him for his contribution and for agreeing to let us integrate this useful module into REDCap. NOTE: Because the “DAG Switcher” external module is not compatible with this integrated functionality in v9.9.0, when upgrading REDCap to 9.9.0 or higher, if the “DAG Switcher” external module is already installed and enabled on your REDCap system, it will be automatically disabled at the system level during the upgrade process to prevent a conflict.

 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.
• Change/improvement: 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.
  

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 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 entirely 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 position fields close together in a group if they are related.
• To use Field Embedding, users 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 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).
• We wish to thank Andy Martin (Stanford) because his popular Shazam external module served as the conceptual inspiration of the Field Embedding feature.
• Note: When installing or upgrading to v10.0.0, a new project “Field Embedding Example Project” will be automatically added as a project template to easily allow users and admins to see some examples of Field Embedding in action.

 Online Designer’s “Add/Edit Branching Logic” 

•  A new feature was added dialog to help users modify branching logic for many fields at once if they had the same branching logic.

 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 Online Designer page with instructions on how to use this.

Changelog LTS Version 8.10.11