New Features REDCap version 11.1.29 (July 15, 2022)

New Feature: Project Dashboards 

  • Project Dashboard: 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 
  • Setting project dashboard as “public”: If enabled at the system-level (described in detail below), any project dashboard can be enabled as “public”, which means it can be accessed at a unique URL that does not require any authentication. Making a dashboard public is useful if you wish for people to view it without having to be REDCap users or log into REDCap. Public dashboards are simply standalone pages that can be viewed by anyone with a link to them. 

New feature: 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.). 

New feature: 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. 

New feature: 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. 

Optional parameters for Smart Functions, Smart Tables, and Smart Charts 

  • There exist various optional parameters that can be used with Smart Functions, Smart Tables, and Smart Charts to either filter the data used in them (e.g., via a unique report name) or to change their appearance (e.g., bar-vertical). See the descriptions for each below, which are all documented in the Smart Variables documentation. 
  • :R-XXXXXXXXXX Unique Report Name - For Aggregate Functions, Charts, and Tables, filter the data being used by appending a Unique Report Name. Next to each report on the 'My Reports & Exports' page is its unique report name, which has 'R-' following by alphanumeric characters. By default, all Aggregate Functions, Charts, and Tables will use the values of all records in the project, but if a unique report name is appended to any of them, only data from that specific report will be used. Using a report as a surrogate to filter data is a very useful technique of performing complex filtering logic for Aggregate Functions, Charts, and Tables. 
  • :record-name "record-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the *current record* by using the literal value 'record-name'. Note: This parameter will only work in a context where a single record is being viewed/accessed, such as on a survey page, data entry form, etc. This parameter can be used with any of the other parameters except unique report names. 
  • :event-name "event-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the *current event* (longitudinal projects only) by using the literal value 'event-name'. Note: This parameter will only work in a context where a single record/event is being viewed/accessed, such as on a survey page, data entry form, etc. This parameter can be used with any of the other parameters except unique report names. 
  • :unique-event-names Unique Event Names - For Aggregate Functions, Charts, and Tables, filter the data being used to specific events (longitudinal projects only) by providing an event's unique event name (found on the Define My Events page). You may use one or more unique event names (comma-separated). Note: This parameter can be used with any of the other parameters except unique report names. 
  • :user-dag-name "user-dag-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the records assigned to the *current user's Data Access Group* by using the literal value 'user-dag-name'. Note: This parameter will only work in a context where an authenticated user belongs to a project and has been assigned to a DAG in the project (this excludes survey pages and public project dashboards). This parameter can be used with any of the other parameters except unique report names. 
  • :unique-dag-names Unique DAG Names - For Aggregate Functions, Charts, and Tables, filter the data being used to the records assigned to specific Data Access Groups by providing a DAG's unique group name (found on the Data Access Groups page). You may use one or more unique DAG names (comma-separated). Note: This parameter can be used with any of the other parameters except unique report names. 
  • :bar-vertical "bar-vertical" - Display a bar chart with the bars going vertically instead of horizontally (the default) by using the literal value 'bar-vertical'. Note: This parameter can be used with any of the other parameters. 
  • :bar-stacked "bar-stacked" - Only for bar charts using two fields, display the bar chart with the bars stacked on top of one another for each choice. Whereas the default view is that the bars of each field are displayed side by side to show the color grouping. To enable this, use the literal value 'bar-stacked'. Note: This parameter can be used with any of the other parameters. 
  • :no-export-link "bar-stacked" - Only for bar charts using two fields, display the bar chart with the bars stacked on top of one another for each choice. Whereas the default view is that the bars of each field are displayed side by side to show the color grouping. To enable this, use the literal value 'bar-stacked'. Note: This parameter can be used with any of the other parameters. 

NOTE: Using Smart Functions/Tables/Charts elsewhere in a project - While project dashboards are an excellent place to use Smart Functions, Smart Tables, and Smart Charts, it is important to know that Smart Functions/Tables/Charts can actually be used *almost anywhere* in a project, such as on data entry forms, on survey pages, and in report instructions (to name a few). You can use Smart Functions/Tables/Charts anywhere that piping can be used. Click the green "Smart Variables" button on the Project Setup page to learn more about them. Note: The only place that Smart Charts cannot be used is inside the body of outgoing emails. 

NOTE: Smart Functions/Tables/Charts do not yet work in the REDCap Mobile App; however, it is planned that they eventually will (to a certain degree). 

NOTE regarding permissions for Smart Functions/Tables/Charts: 

  • DAG permissions (i.e., filtering out records not assigned to the current user’s DAG) are NOT applied by default to Smart Charts/Tables/Functions but are only applied when the Smart Chart/Table/Function utilizes a unique report name as a parameter (thus mimicking the natural DAG-filtering behavior of reports themselves) OR when the Smart Chart/Table/Function utilizes the “user-dag-name” parameter. This means that if a user is assigned to a DAG and views a project dashboard with the Smart Chart [scatter-plot:weight], for example, the plot will display data for ALL records in the project and not just the user’s DAG. To limit the plot to just data in the user’s DAG, it could be changed to [scatter-plot:weight:user-dag-name] in this case. 
  • Smart Charts/Tables/Functions that utilize a unique report name as a parameter for data filtering purposes will still function and display normally even if the user does not have explicit access to view that specific report referenced as a parameter. 

New feature: 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` = ';' ; 

New feature: More clinical data available via FHIR R4 endpoints for CDIS - The CDIS services Clinical Data Pull and Clinical Data Mart can now utilize version 4 (called “R4”) of the FHIR web services from their local EHR system. The new R4 endpoints include the existing data that could be pulled in earlier versions as well as the following: Adverse Events, Core Characteristics (Observation), Encounters, and Immunizations. Note that "Adverse events" are only available for "research" projects where an IRB number is specified, in which the project’s IRB number corresponds to the “Study ID” value from the EHR interface for a particular study (which is often the same as the study’s IRB number). 

New feature: Fields that are "sql" field type (Dynamic Query - SQL field) now work in the REDCap Mobile App. In previous versions, they were not functional at all in the mobile app. Now when a project is loaded into the mobile app, any "sql" fields will be converted into static drop-down fields in the app. If new choices get dynamically added to the sql field on the server afterward, the project will need to be loaded again in the mobile app to obtain those choices for the sql field. 

New feature: 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. 

New feature: 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. 

New feature: Ability to make reports accessible at a public link 

  • Summary: When editing a report, users can now set a report as “public” and can obtain a public link to the report if they have User Rights privileges in the project. When a report is public, this means that all data in the report will be fully accessible (with no authentication required) to anyone with the public link to the report. 
  • In order to make a report public, all the following must be true: 
  • The user must have User Rights privileges in the project or be a REDCap administrator. 
  • The report cannot have any Identifier fields in it. 
  • The user is required to view the report during their current REDCap session. 
  • The user must agree to and check off the following statements: 1) I understand that making this report "public" means that all data in the report will be fully accessible to anyone with the public link to the report, and 2) I understand that I am responsible if any private, sensitive, or identifying data in the report is exposed to persons who should not have access to such data. 
  • The behavior of how reports are made public can be controlled at the system level near the bottom of the User Settings page in the Control Center using the setting “Allow reports to be made 'public'?”. Admins may completely disallow reports to be made public (although admins will still have this ability to do so). But if enabled, they may choose to allow users to make reports public on their own or enable the To-Do List approval process by which an admin will need to approve their request to make a given report public (similar to the same system level approval process for Project Dashboards being made public). 
  • Once a report has been made public, its configuration cannot be modified while it is public (users cannot add new fields, modify filter logic, etc.). In order to modify a public report, the user will need to make it no longer public, then make their changes, and then make it public again. 

New Smart Variables 

  • [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. 
  • [user-role-id] - The Role ID of the user role to which the current user is assigned (blank if not assigned to any user role). This value is auto-generated for each user role. NOTE: This value is not just unique for all roles within the project but is also unique across all REDCap projects. Thus, if the project and its user roles are copied, the Role IDs of the user roles in the resulting copy will be different from the ones in the original project. 
  • [user-role-name] - The unique role name of the user role to which the current user is assigned (blank if not assigned to any user role). This value is auto-generated for each user role. NOTE: This value is only unique for roles within the project. Thus, if the project and its roles are copied, the new project will retain the same unique role names, which allows you to utilize the unique role names in conditional logic, calculations, branching logic, etc. that will not break when the project is copied. 
  • [user-role-label] - The name/label of the user role to which the current user is assigned (blank if not assigned to any user role). This value is defined by the user that creates the user role. 

New Action Tag: @MAXCHOICE-SURVEY-COMPLETE - Similar to @MAXCHOICE but only counts choices on completed survey responses (does not count data entered as data entry only or on partial responses). Causes one or more specified choices to be disabled (i.e., displayed but not usable) for a checkbox, radio button, or drop-down field after a specified amount of records have been saved with that choice for completed survey responses only. 

New feature: Tableau Data Export- Extract all records into Tableau via the REDCap API. 

  • This feature enables Tableau (v10.0+) users to connect Tableau to a REDCap project using an API token. Project data can be exported on demand and be available for use within Tableau to produce summaries and visualizations. The Other Export Option page in any given project has instructions to export project data into Tableau. 
  • NOTICE: It is required for a user to have an API token generated for the project in order to use this feature. 

New feature: 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 action tag: @DOWNLOAD-COUNT - The @DOWNLOAD-COUNT action tag provides a way to automatically count the number of downloads for a File Upload field or a Descriptive field attachment. It can be used on a Text field or Notes field so that its value will be incremented by '1' whenever someone downloads the file for either a File Upload field or a Descriptive field attachment. The variable name of the File Upload field or Descriptive field whose downloads are to be counted should be provided inside the @DOWNLOAD-COUNT() function. For example, the Text field 'my_download_count' might have its action tag defined as @DOWNLOAD-COUNT(my_upload_field), in which 'my_upload_field' is the variable of a File Upload field. Whenever the file is downloaded on a data entry form, survey page, or report, the value of the field with this action tag will be incremented by '1'. If that field has no value or has a non-integer value, its value will be set to '1'. NOTE: The download count field must be in the same context as the File Upload field or a Descriptive field. This means that in a longitudinal project the two fields must be on the same event, and in a repeating instrument context, they must be on the same repeating 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. 

New features: New drop-down options on the User Rights page to allow users to perform the tasks listed below using a CSV file in the user interface. 

  • Upload users and their privileges 
  • Download users and their privileges 
  • Upload user roles and their privileges 
  • Download user roles and their privileges 
  • Upload user role assignments 
  • Download user role assignments 

New feature: “DAG Switcher” API method - When using the DAG Switcher functionality in a project, this method allows users to move themselves in and out of a Data Access Group at will using the API just as they would do the same thing in the user interface (assuming they have been assigned to multiple DAGs on the DAG Switcher page). 

New API method “Rename record” and new developer method REDCap::renameRecord() allows users/developers to rename a record in a project. For multi-arm longitudinal projects where a record might exist on multiple arms, the $arm number can be specified to rename the record only on the specified arm, otherwise by default it will rename the record in all arms in which it exists. 

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, user’s 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.” 

 

Improvements: 

Improvement: Report “description” text now utilizes the rich text editor. Additionally, users may perform piping into a report’s description, such as project-level Smart Variables, including Smart Charts, Smart Functions, and Smart Tables. 

Improvement: New option for Project Templates called “copy records”, which will copy any existing records in the template to the new project created from the template. This option can be enabled for any new or existing Project Templates. 

Improvement: A new Project Template was added to illustrate new features in 11.0+. The new template is named “Project Dashboards, Smart Functions, Smart Tables, & Smart Charts”. 

Improvement: The Smart Charts [pie-chart] and [donut-chart] now display the percentage value on top of each colored slice in the chart. 

Improvement: On the Calendar page when viewing the "View/Edit Calendar Event" popup for a calendar event that is attached to a record, the popup now displays a "View Record Home Page" link next to the record name to allow the user to easily navigate to the record. 

Improvements: Other FHIR/CDIS additions 

  • Clinical Data Mart 
  • A new template is used for new DataMart projects when REDCap is set to use R4, including new forms for Encounters, Immunizations, Core Characteristics, Adverse Events. 
  • New option to fetch data in a background process and receive an email when completed. 
  • MRNs can be searched and fetched individually on the Clinical Data Mart page. 
  • Epic institutions using the "legacy" app on the Epic App Orchard will be notified on the CDIS Control Center page with info about how to upgrade to the new R4 enabled version. 
  • While on the CDIS Control Center page, changing the FHIR client ID will now automatically remove all existing FHIR access tokens stored in the backend. Note: This will not impact any data but will require each CDIS user to perform a standalone launch again or else launch REDCap via the CDP embedded window in the EHR interface before they can begin to pull data again from the EHR. 
  • The FHIR statistics in the Control Center now displays CDP instant adjudication. 

Improvement: If using Twilio for SMS/Voice Call verification for Two Factor Authentication, there is now a new alternative phone number field on the Security & Authentication page for providing a number only to be used for the Voice Call option for 2FA. This is useful if you are in a country where a single phone number cannot be used for both voice calls and SMS. If the new field is left blank, then the existing number will be used for both SMS and voice calls, but if this new field is utilized, its value will be used for the 2FA voice call option while the first number will only be used for the 2FA SMS option. 

Improvement: The Easy Upgrade process should now take much less time to complete due to the implementation of a faster unzipping method used when extracting the source code files on the server from the REDCap upgrade zip file that was downloaded. (Note: This faster Easy Upgrade process may not be seen in this upgrade but in the upgrade after this one.) 

Improvement: New alternative PDF print option in the "Download PDF" drop-down at the top of data entry forms, in which there is a new PDF export choice: "This data entry form with saved data (send to printer: select "Save as PDF" for Printer/Destination)". This will produce a much improved browser-based print option to print/save the webpage as a PDF that serves as a suitable alternative to the existing server-side PDF rendering options, which can sometimes be very limited and inaccurate (e.g., when representing field embedding). Note: This “Print to PDF” does correctly hide fields that have the @HIDDEN-PDF action tag. 

Improvement: Reports A and B now have built-in Live Filters: 1) the record ID field, 2) a list of all events (if the project is longitudinal), and 3) a list of all Data Access Groups (if the project contains DAGs and the current user is not assigned to a DAG). 

New videos: Added two new videos for Project Dashboards and Smart Charts/Functions/Tables on the Training Video page, Project Dashboards page, and Smart Variable popup documentation. 

Improvement: If the value of a Text field or Notes field contains a URL or email address, the URL or email address will be converted into clickable link and mailto link, respectively, when viewing the data in a report. 

Improvement: More detailed logging descriptions on the Logging page for report-related logged events, such as mentioning the report name and report ID. 

Improvement: When users download an Instrument ZIP file for a given instrument in the Online Designer, the zip file now includes all survey settings for the instrument if the instrument has been enabled as a survey, including various files (e.g., survey logo, confirmation email attachment). The downloaded Instrument ZIP can then be uploaded into any project to transfer both the fields and all the survey settings. 

Improvement: In the Online Designer, the "Custom text to display at top of survey queue" now utilizes the rich text editor to make it easier to style the custom text. 

Improvement: New piping parameter “:ampm” - When piping a time, datetime, or datetimes w/ seconds Text field, appending “:ampm” to the variable name (e.g., [visit_time:ampm]) will display the time in am/pm format (e.g., 4:45pm, 10:35am) instead of military time. 

Improvements for report display and/or data exports- When creating/editing a report, the “Additional report options” section in Step 2 now contains the new options below: 

  • For projects that have repeating instruments and/or repeating events, the repeating fields that are automatically added (e.g., redcap_repeat_instrument and redcap_repeat_instance) can now be excluded from the report and data export. These fields are displayed by default in reports/exports. 
  • Users may choose to display the field label, variable name, or both (default) in the header of a report. Note: This is only used when viewing reports and thus is not applicable for exports since there already exist options for choosing raw vs label format in data exports. 
  • Users may choose to display the field label, raw data value, or both (default) for multiple choice fields in the data displayed in a report. Note: This is only used when viewing reports and thus is not applicable for exports since there already exist options for choosing raw vs label format in data exports. 

Improvement: If a user is not assigned to a Data Access Group in a project, the user will now see a new "[No assignment]" option in the "Displaying Data Access Group" drop-down list on the Record Status Dashboard, in which selecting that option will display only records that have not been assigned to any DAG. 

Improvement: More options/parameters for the API Delete Record method - Users can now specify instrument, event, and/or repeat_instance to delete the data from a specified instrument, event, or repeating instrument/event for the records specified in the API request. In previous versions, the only option was to delete the entire record. 

Improvement: The Project Revision History page now displays icons next to each production revision and snapshots, and after being clicked, will display options to compare that revision/snapshot with any other revision/snapshot in the project. (This feature represents the integration of the "Data Dictionary Revisions" external module created by Ashley Lee at BC Children's Hospital Research Institute). 

Improvement: When using the eConsent Framework in a project, the "PDF Survey Archive" tab on the File Repository page now displays a "Download all" button that will download all PDF files displayed on the page in a single zip file. Additionally, there is a record filter drop-down list and a "file type" drop-down list, which distinguishes between general "PDF Auto-Archiver" PDFs and "eConsent Framework" PDFs. Note: If a user is in a Data Access Group, they will only be able to download and filter on records in their DAG. 

Improvement: When executing many data quality rules at once, the total time to finish all the rules occurs 3X faster. Instead of running only one rule at a time in a serial fashion, REDCap now executes three rules simultaneously when clicking the "All", "All except A&B", and "All custom" buttons at the top of the Data Quality page. 

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. 

Improvement: New option for Protected Email Mode - Users may now upload a custom logo that they wish to be displayed on the webpage and in emails utilizing the Protected Email Mode. This feature is supplementary to the existing custom text option for Protected Email Mode. This option is located in the Protected Email Mode section of the Additional Customizations popup on the Project Setup page. 

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. 

 

Changes: 

  • Change/improvement: The Logic Editor popup is now utilized when editing the "Action Tags/Field Annotation" text box in the Online Designer. 
  • Change: The alphanumeric hash that exists in all survey links has been increased in length from 10 to 16. Any new survey links created will have a 16 character length hash. 
  • Change: Due to concerns about sending identifying information from REDCap in outgoing emails, Survey Notification emails will no longer include the Participant Identifier in the email body (if a Participant Identifier was entered in the Participant List for a given participant). 
  • Change: Small change to add clarity to the text of Step 1A when creating/editing an alert on the Alerts & Notifications page. 
  • Change: Updated setup instructions zip file for Clinical Data Interoperability Services by including a new CDIS Manual (PDF) in the zip file. 
  • Change/improvement: Any HTML used in the value of a Text field or Notes field will no longer be escaped on a report (i.e., displayed as-is) but instead the HTML will be interpreted on the report to allow for the styling of text on the page. This means that while previous versions would have displayed the text value "<b>Word</b>" literally as "<b>Word</b>" (without quotes) on a report, it now instead displays "Word" as bolded text on a report. Note: This does not affect data exports or any pages other than reports. 
  • Change/improvement: "Previous instrument" and "Next instrument" buttons were added at the top right of the Online Designer field-view page to allow easier navigation between instruments. 
  • Change: Renamed the "My Profile" page to "Profile". 
  • Change: The email that users receive from an administrator that has just approved their production changes now reminds them that the default Data Viewing Rights for any newly added instruments will be 'No Access (Hidden)'. 
  • Change/improvement: A button to open the Codebook page as a floating popup window was added inside the Logic Editor popup to allow users to easily find and reference fields they want to use in their logic while in the editor. 
  • Change/improvement: The underlying business logic of REDCap’s cron job processing methods have been changed so that long-running cron jobs will not block other jobs from running at their scheduled time. 
  • 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.