What’s new – REDCap

Coming soon – 14.5 (Winter 2024 / Early 2025)

New features

Enhanced e-Consent Framework and PDF Snapshot Functionality

Overview – A new page named “Settings for e-Consent & PDF Snapshots” (linked from the Online Designer) serves as the new location where users can enable and set up the e-Consent Framework for a given survey and also set up triggers for storing PDF Snapshots. In previous versions, the e-Consent Framework and PDF Snapshot settings all existed on the Survey Settings page as several disparate options, but now they have been consolidated on this new page as two separate tabs. While these two exist as separate features, there is some overlap of functionality since the e-Consent Framework does ultimately store a copy of the PDF Snapshot for the e-Consent response. In addition to moving these features to the new page, both have been given enhancements, which are detailed below. View a 5-minute overview video of the new features: https://redcap.link/econsent2vid
Overall Benefits of the New Features – Streamlined Consent Process: Simplify and enhance the electronic consent process for both researchers and participants. Improved Data Integrity: Ensure secure and organized storage of consent forms and survey responses. Enhanced Compliance: Meet regulatory standards such as ICH and FDA requirements with robust version control and audit trails.

Background Data Import option for the API

Similar to using the Background Data Import on the Data Import Tool page, users may now utilize the feature when making a call to the Import Records API method. They can simply pass the API parameter “backgroundProcess” with a value of 1 (for Yes) or 0 (for No, which is the default) to invoke this option. The API will return a “success” message with “true” or “false” regarding if the data was successfully accepted. Note: This option works with any data format: CSV, JSON, or XML.

New Action Tag

New action tags:@MC-PARTICIPANT-JOINDATE-UTC and @MC-PARTICIPANT-TIMEZONE – These action tags will capture the MyCap participant’s timezone and also the install date/time (in UTC time) of the MyCap participant whenever the participant joins a project via the MyCap mobile app. NOTE: This is used only for the MyCap mobile app. The fields’ values are not generated when viewing the data entry form but only when the MyCap app is making a call to REDCap when the participant joins the project. Additionally, while these action tags can be added to a new field in already-existing MyCap projects, a field with this action tag will be auto-added to any projects where MyCap is enabled in the project after the fact and for any new projects created using the MyCap project template.
New action tag: @CONSENT-VERSION – This action tag represents the version of the consent form being used by the e-Consent Framework for the current e-Consent survey context (i.e., current record, event, survey, data access group, MLM language, etc.). NOTE: This action tag only adds a new value to the field when its field value is blank and only when the instrument is being completed in an e-Consent survey context. Also, this action tag can only be used if the e-Consent Framework has been enabled for a survey and only if one or more consent forms have been defined for that survey.

14.0 New features

Background Data Import

In the Data Import Tool, users may now alternatively import data using an asynchronous background process (as opposed to the existing real-time process). The background process is better for large data files. The background process will email the user after the data file has been fully imported, and the email will note any errors that may have occurred during the import process.
During the background data import process, which is performed by several simultaneous cron jobs, each record will be imported one at a time. If there is any error with a record being imported, none of that individual record’s data will be imported, after which the user will be able to view all the errors with the option to re-download the records/data that failed to import, thus allowing the user to fix the data and attempt to import it again.
Note: The background data import works with the “Reason for Change” project-level feature, which requires a reason for any changes made to an existing record.
The feature is currently only available in the user interface (not in the API), but it may be available for the API in the future.
If the background data import has begun, the user who initiated the import (or an administrator) can cancel the import process at any time. However, any data that was imported by the import process prior to it being canceled will not be undone after it is canceled. All changes made by the process up until cancellation are permanent.

Longitudinal functionality for MyCap-enabled projects

In previous versions, longitudinal projects could not utilize MyCap (the feature would be disabled automatically). Now with the release of the new MyCap mobile apps on Android and iOS, longitudinal functionality is possible and is supported in the new MyCap mobile app. For any projects currently using MyCap, there will be a “transition” button on the MyCap Participants page that will allow the users to transition the project and any existing participants to use the new MyCap mobile app (note: this transition process is completely optional and not required unless wanting to use longitudinal functionality and other new MyCap features). The older MyCap mobile apps will still be available and updated in the Apple App Store and Google Play Store for the time being.

New special functions for date/datetime fields

year() – Returns the year component of a date/datetime field – e.g., year([dob]).
month() – Returns the month component of a date/datetime field – e.g., month([visit_datetime]).
day() – Returns the day component of a date/datetime field – e.g., day([visit_date]).

New piping parameters for date/datetime fields

:year – Returns the year component of a date/datetime field – e.g., [dob:year].
:month – Returns the month component of a date/datetime field – e.g., [visit_datetime:month].
:day – Returns the day component of a date/datetime field – e.g., [visit_date:day].

New text string functions

replace_text (haystack, search, replace) – Replaces parts of a text value with a specified replacement text value – Finds text (“search”) inside another text (“haystack”) and replaces all found occurrences with the given text (“replace”). For example, assuming [field1] has a value of “Paul Taylor, Rob Taylor”, replace_text([field1], “Taylor”, “Harris”) would result in “Paul Harris, Rob Harris”. Note: This function performs a case-sensitive replacement. Additionally, you can search for line breaks (e.g. in Notes fields) with “\n”.
concat_ws (separator, text, text, …) – Joins the text from multiple text strings with a separator – This works exactly like concat but inserts the separator in between each concatenated item. For example, concat_ws(” and “, [veggie1], [veggie2], “Tomatoes”) might result in “Peas and Carrots and Tomatoes”.

New math functions

mod (dividend,divisor) – Modulo – Returns the remainder of the (integer) division (modulo) dividend/divisor. Both values must be integers. E.g. mod(10,4) will result in 2 because 2 is the remainder of 10 divided by 4.
exponential (number) – Exponential of e – Returns “e” (Euler’s Number) raised to the power of a number: e^x. Note: The value of the exponent x must be a number. E.g. exponential(1) will return 2.718281828459045.

New Action Tag

New action tag: @SHOWCHOICE – When applied to a multiple-choice field, this action tag will hide all choices except for the ones listed in its argument. This action tag is useful if you wish to only show a subset of choices depending on some logic (e.g., depending on data access groups) via the IF action tag. The format must follow the pattern @SHOWCHOICE=’??’, in which the coded values should be inside single or double quotes for the choice(s) you wish to show. If more than one choice needs to be shown, then provide all the coded values separated by commas. For example, to show the choice ‘Monday (1)’, you would have @SHOWCHOICE=’1′, but if you wanted to additionally show ‘Tuesday (2)’, you would have @SHOWCHOICE=’1,2′. NOTE: The @SHOWCHOICE action tag supports piping into its argument – e.g., @SHOWCHOICE=”[my_checkbox:checked:value]”.

13.7 New features

New Multi-Language Management workflow for adding new languages to projects, plus many other improvements

Improved workflow and user interface for adding new languages to projects.
Project languages can now “subscribe” to system languages (i.e., any changes/additions to UI translations made in the Control Center will automatically be visible in projects).
Editing/updating of existing languages has been redesigned and split into separate edit (rename, etc.) and update (sync with system languages or import translations from files) dialogs.
Added an option to download (empty – i.e. without data) PDFs of all or individual instruments.
The default setting for the ASI Language Source is not “Language preference field” (instead of “User’s or survey respondent’s active language”).

Embedding file attachments in text & emails

Users may now attach one or more files into the text of a survey invitation, an alert, or a field label on a form/survey, among other things, by clicking the file attachment (paperclip) icon in the rich text editor and then by uploading a file from their local device.
This feature is available for every rich text editor *with the exception* of non-project pages (e.g., the Email Users page) and also any field with the @RICHTEXT action tag.
Note: All files uploaded via the rich text editor will be represented in the text of the editor as a public file-sharing link, which allows the file to be downloaded in any context (e.g., on surveys, on authenticated REDCap pages, and in public areas like emails and public dashboards). This means that if anyone has possession of this link, they will be able to download the file (at least, until the file has been deleted). All files uploaded via the rich text editor will be automatically stored in a special “Miscellaneous File Attachments” folder in the File Repository where they can be accessed and/or deleted, if necessary. If any such file is deleted from the “Miscellaneous File Attachments” folder in the File Repository, the associated download link for the file will cease to be active and thus will become a dead link wherever it has been used.

Mosio SMS Services

REDCap has the capability to send SMS text messages for surveys and for Alerts & Notifications by using a third-party web service named Mosio (www.mosio.com). In this way, users can invite a participant to take a survey by sending them an SMS message, in which the data would be collected in REDCap directly from their phone without having to use a webpage. There are two ways REDCap currently works with Mosio: 1) Surveys – Sending survey invitations and also sending questions and getting replies via text message, and 2) Alerts – Sending one-way Alerts & Notifications via text message.
The Mosio Two-Way Text Messaging (SMS) Services work exactly the same as the current Twilio functionality, with the exception of the Voice Call features. Mosio can only send and receive SMS messages. If a user wishes to switch a project from using Twilio to using Mosio, the only thing that needs to be done is for them to get a Mosio account and API key, then disable Twilio and enable Mosio in their REDCap project using their API key. That’s all that needs to be done to migrate from Twilio.
For more information and to get a Mosio account, visit https://www.mosio.com/redcap. Mosio specializes in research communications automation, helping researchers improve engagement, adherence, and data collection in studies. The service is both HIPAA and 21 CFR Part 11 compliant and willing to sign BAAs.

New Action Tag

@INLINE-PREVIEW – When this action tag is added to File Upload fields or Description Text fields, a preview button will be displayed next to the field on survey pages and data entry forms if the uploaded file is an image or PDF file. Clicking the preview button will immediately display the image/PDF inline on the page, after which it can be closed again, if desired. This allows users/participants to view the file without having to download it to their local device.

13.1 (Spring 2023)

New features

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.

Integration of the MyCap External Module

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+).

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

New Smart Variables

[new-instance]

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.

12.4 (Summer 2022)

New features

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.

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.

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.

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.

New Smart Variables

[survey-time-started:instrument], [survey-date-started:instrument] – 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].
[survey-duration:instrument:units], [survey-duration-completed:instrument:units] – 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).
[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 Action Tag

@FORCE-MINMAX – The action tag @FORCE-MINMAX can be used on Textbox fields that have a min or max validation range defined so that no one will not be able to enter a value into the field unless it is within the field’s specified validation range. This is different from the default behavior in which out-of-range values are permissible. Note: @FORCE-MINMAX is also enforced for data imports to ensure the value is always within the specified range.

12.0 (Spring 2022)

New features

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.

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.

Project-level setting “Prevent branching logic from hiding fields that have values”

This setting can be enabled by any project user with Project Setup/Design privileges in the Additional Customizations popup on the Project Setup page.
This setting affects both data entry forms and surveys. If it is not enabled (default), then whenever a field is to be hidden by branching logic on a data entry form, it will always ask the user if they wish to hide the field and erase its value, whereas on survey pages it will automatically erase the value of the field being hidden without displaying the confirmation prompt, which has always been the default behavior for surveys. If this setting is enabled, the branching logic behavior will change so that fields with values will not cause the ‘Erase the Value of the Field?’ confirmation prompt to ask the user if they wish to keep the value or hide the field, and instead fields with values will not be hidden by branching logic and will stay visible. Thus they will be exempt from branching logic. This will prevent data from being erased as it normally does if fields are hidden by branching logic.
When a field should be hidden by branching logic but is not hidden because it has a value, an icon will be displayed on the field to indicate this to the user.
This project-level setting is included in the API Export Project Info method as “bypass_branching_erase_field_prompt”. The REDCap Mobile App will soon have this same functionality, but it will only work if the REDCap server is on REDCap 11.2.0 or higher.
The name of Data Quality rule F has been slightly changed when this setting is enabled from “Hidden fields that contain values” to “Fields that contain values that should be hidden”.

New Smart Variables

[event-number] – The current event’s ordinal number as listed on the Define My Events page that denotes the order of the event within a given arm.
[event-id] – (longitudinal only) The event id number of the current event.
[survey-access-code:instrument] – The Survey Access Code of the specified survey for a given record/event/instance. The format must be [survey-access-code] or [survey-access-code:instrument], in which ‘instrument’ is the unique form name of the desired instrument. This can be used simply as [survey-access-code] inside the content of a survey invitation, in which ‘instrument’ is assumed to be the current survey instrument.
[survey-return-code:instrument] – The Survey Return Code of the specified survey for a given record/event/instance in order to allow a participant to return to a completed or partially completed survey response when using the ‘Save & Return Later’ survey feature. The format must be [survey-return-code] or [survey-return-code:instrument], in which ‘instrument’ is the unique form name of the desired instrument. This can be used simply as [survey-return-code] inside the content of a survey invitation, in which ‘instrument’ is assumed to be the current survey instrument.

New Action Tag

@RICHTEXT – Adds the rich text editor toolbar to a Notes field to allow users/participants to control the appearance (via styling and formatting) of the text they are entering into the field.
@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.
@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).

11.1 (Summer 2021)

New features

Project Dashboards

Project Dashboards are pages with dynamic content that can be added to a project. They can utilize special Smart Variables called Smart Functions, Smart Tables, and Smart Charts (described below) that can perform aggregate mathematical functions, display tables of descriptive statistics, and render various types of charts, respectively. User access privileges are customizable for each dashboard, and anyone with Project Design privileges can create and edit them. A Wizard is provided on the Project Dashboard creation page to help users easily construct the syntax for Smart Functions, Smart Tables, or Smart Charts, and a basic list of helpful examples is also included. Example dashboard: https://redcap.link/dash1
Each project dashboard can be exported as a one-page PDF file.
To prevent server performance degradation, each project dashboard will have its content cached (stored temporarily) automatically for up to 10 minutes at a time rather than generating its content in real time every time the dashboard is loaded. It will note at the top right corner of the dashboard page when the dashboard content was last cached. If a user is viewing the dashboard inside a project (i.e., not via a public dashboard link), they have the option at the top right to “Refresh” the dashboard at will, which will refresh/generate its content in real time. Note: The refresh option will only be displayed on the page when the dashboard content is at least 30-seconds old.

Smart Functions

Smart Functions are aggregate mathematical functions that are utilized as Smart Variables. The following Smart Functions exist: [aggregate-min], [aggregate-max], [aggregate-mean], [aggregate-median], [aggregate-sum], [aggregate-count], [aggregate-stdev], and [aggregate-unique]. Each represents the mathematical functions minimum, maximum, mean/average, media, sum, count, standard deviation, and unique count, respectively. Each must have at least one field attached to it that follows a colon – e.g., [aggregate-mean:age]. Multiple fields may be used in each one, which will perform the function over all the data values of all the fields. By default, the functions will utilize all data values for all records in the project. To limit the data values being utilized to a subset of the total project data, see the Smart Variable documentation on how to apply filters, such as attached unique report names, DAGs, and other parameters
Note: When using [aggregate-count:record_id], in which “record_id” in this example represents whatever the variable of the Record ID field is, it performs a special count that does not literally count the number of data values but instead returns a count of the total number of records in the project. This is a quick way to display the total record count of the project.
Smart Functions can be used anywhere in a project where piping is allowed, and can even be used inside calculations, branching logic, and other conditional logic (report filters, alert conditions, etc.).

Smart Tables

Smart Tables are tables displaying aggregate descriptive statistics in which the results of any or all of the following stats functions can be displayed for one or more fields: minimum, maximum, mean/average, media, sum, count, standard deviation, count of missing values, and count of unique values.
Smart Tables are represented with the Smart Variable [stats-table], which accepts as a parameter the variable names (comma delimited) of all the fields to be displayed as separate rows in the table. There is no limit to the number of fields that can be used. For example, [stats-table:field1,field2,field3].
By default, all available columns will be displayed in the table and are as follows: Count, Missing, Unique, Min, Max, Mean, Median, StDev, Sum. To display only a subset of the columns, you may provide any of the following designations (comma-separated) that represent a specific column in the table: count, missing, unique, min, max, mean, median, stdev, sum. For example, [stats-table:field1,field2,field3:mean,max].
By default, each stats table will have an “Export table (CSV)” link displayed immediately below it to allow users to download the table as a CSV file. But if users wish to hide the export link, they can simply attach “:no-export-link” to the Smart Variable, which will cause the link not to be displayed. For example, [stats-table:field1,field2,field3:no-export-link].
Smart Tables can be used anywhere in a project where piping is allowed.

Smart Charts

Smart Charts are various aggregate plots and charts utilized as different Smart Variables. The following plots are available for use: bar charts, pie charts, donut charts, scatter plots, and line charts. These are all represented by the following Smart Variables, respectively: [bar-chart], [pie-chart], [donut-chart], [scatter-plot], and [line-chart]. These Smart Variables accept one or more field names and also other optional parameters, as described below for each.
Bar charts – Displays a bar chart for a single multiple choice field. It can optionally perform color grouping if a second field (multiple choice only) is provided. The fields must be comma-separated. For example, [bar-chart:field,grouping-field:parameters]. Bar charts have optional parameters that can be applied to alter their appearance. By appending the parameter “:bar-stacked” when two fields are used, the bars in the chart will appear stacked on top of each other rather than side by side. By default, bar charts are displayed with their bars going horizontally, but by appending the parameter “:bar-vertical”, the orientation will be changed to display vertically instead.
Pie charts – Displays a pie chart for a single multiple choice field. For example, [pie-chart:field:parameters].
Donut charts – Displays a donut chart for a single multiple choice field.Note: A donut chart is essentially the same as a pie chart but with the center removed. For example, [donut-chart:field:parameters].
Scatter plots – Displays a scatter plot of one number/date/datetime field for the x-axis and a second field (number field only) for the y-axis. (If a second field is not provided, a random value will be assigned for the y-axis.) It can optionally perform color grouping if a third field (multiple choice only) is provided. All fields must be comma-separated. For example, [scatter-plot:x-axis-field,y-axis-field,grouping-field:parameters].
Line charts – Displays a line chart of one number/date/datetime field for the x-axis and a second field (number field only) for the y-axis. It can optionally perform color grouping if a third field (multiple choice only) is provided. All fields must be comma-separated. Note: A line chart is essentially the same as a scatter plot except with dots connected with a line. For example, [line-chart:x-axis-field,y-axis-field,grouping-field:parameters].
Color blindness accessibility: Pie charts and donut charts have the ability for the user to enable color blindness accessibility, via a gray link displayed immediately below each chart, in which it overlays different patterns onto the colored pieces of the chart to make each color more distinct for many types of color blindness. This option to enable color blindness accessibility is stored in a secure cookie on the user’s device and will be used to remember this choice anytime a pie/donut chart is displayed on any page for any REDCap project for that REDCap server.
The colors displayed in each chart/plot are preset and are not modifiable.
Smart Charts can be used anywhere in a project where piping is allowed *except* for inside the body of outgoing emails.

CSV Delimiter as a user-level preference

The My Profile page now has a new user preference to allow a user to set their own preferred CSV delimiter (e.g., comma, semi-colon) that will be used as the delimiter character in all CSV file downloads throughout REDCap, such as data dictionary import/export, event import/export, user rights import/export, etc. This setting is not used by data imports and exports because those already have a way to specify the CSV delimiter manually. The system-level default value for this user preference can be set on the User Settings page in the Control Center, in which all new users created afterward will have their user-level preference set with this system-level default value. To modify all existing users’ preference after upgrading (if your users would not want a comma delimiter), it will require running an “update” query in the database, such as this: UPDATE redcap_user_information SET `csv_delimiter` = ‘;’ ;

Import/export alerts via CSV file on Alerts & Notifications page

Users may export and import alerts to the same project or another project using a CSV file. If updating an existing alert, the unique alert ID must be included in the CSV file to identify the alert that the user wishes to modify. If the unique alert ID is left blank in the CSV file being uploaded, it is assumed that the user wishes to create a new alert.

Reorder alerts on Alerts & Notifications page

In the options menu for any given alert, a user can select an alert to be moved to another position on the Alerts & Notifications page. When this is done, it notifies the user that moving the alert will in most cases cause the alert numbers to be renumbered for many existing alerts (since they are numbered based on their order). However, their alert title and unique alert ID will not change during this process.