This page contains release notes from previous REDCap upgrades.


Tufts CTSI upgraded REDCap to version 9.5.5 in February 2020.

Improvements include:

  • New feature: Missing Data Codes (i.e., “Data Missingness” functionality)
    • REDCap now allows you to designate certain codes to indicate if data is missing, uncertain, or otherwise problematic. These allow you to mark individual fields as having suspect data, and are used in new Data Quality rules and functions.
  • New feature: Rich text editor for field labels, headers, and survey invitations
    • A Rich Text Editor has been integrated into REDCap to make it easier to format forms, surveys, and emails. You can now also view and modify the HTML of fields, allowing for much more customization.
  • New feature: Alerts & Notifications
    • REDCap now has an Alerts and Notifications section in the left-hand column, allowing you to send emails to users and participants when certain conditions are met. These allow you to create reminders, notify study staff of issues, and much more.
  • Improved Reports
    • Reports have been improved to include descriptions and user rights, as well as searchable folders, making it much easier to manage projects with large numbers of reports. There are also new filters and an option to consolidate checkbox options into a single column for cleaner viewing.
  • Data Privacy (ie GDPR) Options
    • New options allow you to bring your REDCap project into compliance with European Union Data Privacy and Right-to-be-Forgotten guidelines by removing certain data from the auditing log
    • These options fundamentally change the nature of the auditing log; make sure to contact if you have any questions!
  • New Smart Variables and Action Tags
    • New Smart Variables let you capture user and project information, such as usernames, instrument names, and the REDCap version/URL (for creating links between or within projects)
    • New action tags allow you to hide fields on PDF’s and accurately capture the time a form/survey is filled out by using UTC or server time.
  • …And many more!


Tufts CTSI upgraded REDCap to version 8.6.5 in April 2019. Improvements include:

  • REDCap Messenger
  • PDF Download for Survey Respondents
    • On an instrument’s survey settings page, a user may enable the option “Allow participants to download a PDF of their responses at end of survey?”. This option will display a button for the survey participant to download a PDF file of their responses for the survey they just completed. Users may also download this same copy of the PDF since it has been added as a new PDF download option at the top of data entry forms.
  • New Action Tags
    • @CHARLIMIT – Sets the maximum number of characters that can be entered into a Text field or Notes field, and also displays the number of characters remaining.
    • @WORDLIMIT – Sets the maximum number of words that can be entered into a Text field or Notes field, and also displays the number of words remaining.
    • @RANDOMORDER – Randomizes the order of multiple choice field options as displayed on survey pages and data entry forms, in which their order will be different each time the page is loaded. NOTE: This action tag can only be used for the Checkbox, Radio, Drop-down, Yes-No, and True-False field types.
    • @HIDECHOICE – Hides one or more choices of a multiple choice field. This action tag is useful if you wish to retire a particular choice after utilizing it for a while in data collection, thus allowing you to hide the choice from that point after without orphaning any of the choice’s data, which would happen if you simply deleted the choice. NOTE: This action tag can only be used for the Checkbox, Radio, Drop-down, Yes-No, and True-False field types. NOTE: This action tag works only in limited fashion with a matrix of fields, in which it will simply hide the checkbox/radio but still display the column for that choice in the matrix.
    • @NONEOFTHEABOVE – Allows for the designation of a checkbox choice to be a ‘none of the above’ option, thus ensuring that no other choices are checked if that one choice is selected. NOTE: This action tag can only be utilized by Checkbox fields.
    • @MAXCHOICE – 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 example, @MAXCHOICE(0=50,1=75,2=50) would imply that once 50 records have selected the ‘0’ coded choice, that choice will become disabled for any record viewed afterward that does not have that choice saved, such as when the form/survey is opened for a new record, and thus 75 records for choice ‘1’, 50 for choice ‘2’, etc.
    • @MAXCHECKED – Allows a checkbox field to have a maximum number of checkboxes that can be checked. If other checkbox options are clicked after the maximum has been reached, those choices will not be able to be checked. NOTE: This action tag can only be utilized by Checkbox fields, and it does not get enforced during data imports.
  • Sponsor Dashboard
    • The Sponsor Dashboard can be used by users who have been designated as a sponsor for another REDCap user. In many cases a sponsor is a secondary contact person for the user or someone that helps manage the account. The Sponsor Dashboard allows sponsors to manage their sponsored users by viewing some of their account information and making requests to REDCap administrators to help manage their sponsored users.
  • External Modules
    • External Modules are individual packages of software that can be downloaded and installed by a REDCap administrator. Modules can extend REDCap’s current functionality, and can also provide customizations and enhancements for REDCap’s existing behavior and appearance at the system level or project level. Modules can utilize REDCap hooks and also can have REDCap plugin pages as part of them. Only administrators may enable modules, either at the system level or project level. Each module has its own set of configuration options, which are all defined by the creator of the module.
  • Respondents Can Return to a Survey Response Without Needing a Return Code
    • When enabling “Save & Return Later” for a survey on the Survey Settings page, it will still default to requiring a return code in order for a respondent to continue the survey where they left off. But a user may opt to allow respondents to return to and continue their survey with only the survey link (i.e., without needing a return code in addition to the link) to view and modify their previous responses on that survey. NOTE: A warning exists in bold text in the informational popup for this feature that states the following: “If you are collecting identifying information (e.g., PII, PHI), for privacy reasons it is HIGHLY recommended that you leave the option unchecked so as to enforce a return code.”
  • Smart Variables
    • Smart Variables are dynamic variables that can be used in calculated fields, conditional/branching logic, and piping. Similar to using project variable names inside square brackets – e.g., [heart_rate], Smart Variables are also represented inside brackets – e.g., [user-name], [survey-link], [previous-event-name][weight], or [heart_rate][previous-instance]. Instead of pointing to data fields, Smart Variables are context-aware and thus adapt to the current situation. Some can be used with field variables or other Smart Variables, and some are meant to be used as stand-alone. Refer to the Help and FAQ for more information. Total of 35 Smart Variables are available. They can reference things with regard to users, records, forms, surveys, events/arms, or repeating instances. Documentation and examples for using Smart Variables are included on the Project Setup page, Online Designer, and other places throughout REDCap in a popup and alternatively as a standalone page. NOTE: While Smart Variables can be used for filters in reports and for filters for Custom Record Status Dashboards, they are not yet able to be utilized in Data Quality rule logic.
  • Repeating Instances in Piping, Logic, and Calculations: New Syntax for Referencing Fields
    • Fields that exist on a repeating instrument or on a repeating event can be referenced using a new syntax (NOTE: repeating events and instruments are used the exact same way). This is done by appending the “repeat instance” number to the field inside square brackets – e.g., [weight][2], which points to repeating instance #2 for the field “weight.”
    • Please note the distinction that unique event names should be *prepended* to variables whereas repeating instance numbers must be *appended* to them. For example, if the field “weight” exists on a form in the event “Visit Data” in a longitudinal project, you might reference instance #2 for that field on that specific event with the following: [visit_data_arm_1][weight][2].
    • Smart Variables can be used in place of the repeating instance number, in which there are 5 instance-related Smart Variables: [previous-instance], [next-instance], [current-instance], [first-instance], and [last-instance]. For example, if you wish to use @DEFAULT action tage to carry over data from the previous instance of a repeating instrument, it might be set up as follows: @DEFAULT=”[weight][previous-instance]”.
  • Survey-specific Email Invitation Fields
    • New option on the Survey Settings page can be enabled for any given survey, where a user may designate an email field for sending survey invitations for that survey only.
    • The email field being utilized for the survey can exist on any instrument in the project, and you may use a different email field on each survey. You may also use the same email field for multiple surveys.
    • This feature is similar to the project-level email invitation field except that it is employed only for the survey where it has been enabled. This allows users to have data entry workflows that require multiple surveys where the participant is different for each survey. Using this feature, multiple people can be emailed a survey invitation, after which all the survey data they enter goes into the same record in the project.

For more information, please review this REDCap Presentation (PDF).


Tufts CTSI upgraded REDCap to version 7.3.6 in July 2017. Improvements include:

  • Updated REDCap look and feel
  • Updated Help & FAQ page.
  • New Action tags
  • New API methods
  • Usability and communication improvements
  • Security and bug fixes

New Features

  • Response Limit for surveys: Users may set a response limit for any given survey to prevent respondents from starting the survey once a set number of responses have been collected. NOTE: It can be set so the response count includes completed responses only or partial and completed responses. Users may also set custom text to be displayed to respondents on the survey page when the response limit has been reached.
  • Time Limit for Survey Completion: Users may set the amount of time (in days, hours, and/or minutes) that each respondent has to complete a given survey based upon when they were initially sent the survey invitation. NOTE: This feature excludes public survey links. When enabled, a new column is displayed on the Participant List where it denotes if a participant’s survey link has expired and also displays the expiration time if you hover over the icon. If the icon is clicked, the user can permanently override the link expiration time by setting it further in the future (to give the respondent more time), or to expire the link sooner (or even immediately).
  • Custom Record Status Dashboards: Users can build and save custom versions of the Record Status Dashboard to customize the dashboard to their liking.
    • Custom dashboards have many configuration options. Users can give each dashboard a title and a description/instructions, and can choose the instruments to include or exclude in the dashboard’s display. Similar to building reports in REDCap, Custom Record Status Dashboards allow users to sort the records in the dashboard by another field’s value, and one can set filter logic to filter the records displayed in the dashboard to a specific subset of the total records (e.g., [age] > 30 and [diabetes] = “1”). There are aesthetic controls as well, such as being able to display the dashboard headers vertically, which will transpose them 90 degrees for a more compact display on the page.
    • Only users with Project Setup/Design privileges may create custom dashboards. Once a custom dashboard has been created, it will be viewable and usable by all users in the project. Users may create as many custom dashboards as they like in a project. To create a custom dashboard, navigate to the Record Status Dashboard in a project, and click the blue “Create custom dashboard” button to get started.
  • Text searching and ordering on reports: Users now have a search box displayed at the top of every report where they can type text to search the report, in which it will only show the rows in the currently viewed report that match the search string that is typed. Additionally, any column in a report can have its column header clicked to sort the table according to the values in that column (in ascending or descending order).
  • Repeating Instruments and Events: REDCap can repeat a data collection instrument or an entire event of instruments an unlimited number of times without having to specify the amount needed. This is sometimes called one-to-many data collection, in which a project can have one or more repeating parts. The repeating instruments/events feature can be enabled and set up by clicking the Enable button in the Optional Modules section on the Project Setup page.
    • Enabling Surveys for Repeating Instruments: If you want to allow survey respondents to enter their responses in a repeating fashion in survey mode alone, you must enable an optional setting near the bottom of the Survey Settings page (in the survey termination options section) *after* an instrument has been set as a repeating instrument. So it is one additional step to do after enabling the instrument itself as a repeating instrument. When the repeat survey setting is enabled, it will display a button at the end of the survey so that the respondent can choose to enter another response for the survey, thus essentially allowing them to take the survey multiple times in a row. In this way, they will be able to enter as many responses for that same survey as they need.
    • Reports and Data Exports with Repeating Instruments and Events: If you create a report that contains data from a repeating instrument or repeating event, a field named ‘redcap_repeat_instance’ will be included that represents the instance number, which is an auto-numbered value (starting with ‘1’) that gets incremented each time the instrument/event is repeated. If the report contains data specifically from a repeating instrument (as opposed to a repeating event), then a field named ‘redcap_repeat_instrument’ will additionally be included that represents the instrument name that denotes to which instrument the row of data belongs. These two fields will only be included automatically in the report or data export if data originates from a repeating instrument or event. NOTE: Each repeated instance of an instrument or event will be displayed as a new row in the report or export file.
    • While repeating instruments/events are fully supported when using Double Data Entry with regard to data entry workflow, please see the following Notice for the Data Comparison Tool: “The Data Comparison Tool does not *fully* support the Repeating Instruments and Events feature, which appears to be enabled in this project. Data can be compared (and even merged if using Double Data Entry), but it will only allow comparison and merging of Instance #1 of a repeating instrument or repeating event. Thus all other repeating data will be ignored on this page. Also, all non-repeating data can still be compared and merged.”
  • Field name (variable) auto-suggest when typing branching logic, calculations, or general conditional logic (Survey Queue, Automated Survey Invitation, Data Quality rule, report filter’s advanced logic): While typing logic/calculations into the text box, it will auto-suggest a REDCap variable name from your project that is clickable to inject into the text box. If the project is longitudinal, it will also suggest event names to inject unique event names.
  • Real-time validator for branching logic, calculations, or general conditional logic (Survey Queue, Automated Survey Invitation) that allows you to run your logic/calculation on a specific record in the project, and it returns the result: For example, if typing branching logic in the Add/Edit Branching Logic popup in the Online Designer, you can select a record, and it will tell you if the field will be displayed or hidden for that record based upon the record’s currently saved values. When typing calculations, it will return the actually calculated value of the field for a selected record. This makes it easier to formulate your logic and calculations so that you get them right the first time.
  • Data dictionary snapshot: Users can now click a button on the Online Designer to create a snapshot of their instruments (i.e., CSV data dictionary) that gets stored on the Project Revision History page. A data dictionary snapshot is also created automatically whenever a data dictionary is uploaded on the Data Dictionary Upload page or via the API metadata import.
  • Preview email: When composing survey invitations (e.g., the Participant List, Automated Survey Invitations set up), there is now a Preview option for viewing the fully-rendered HTML preview of the email that is being composed. Additionally, there is an option to for you to send a test email to yourself.
  • Custom Event Labels: Custom Event Labels can now be optionally added for any event in a longitudinal project when adding/editing events on the Define Events page. These custom labels can be used for piping data from a given event into the event’s table header on the Record Home Page (i.e., Event Grid). For example, if each event represents a single visit of a person, then if you are collecting the date in a field called ‘visit_date’ on each event, then you can set the Custom Event Label as ‘[visit_date]’ for all of those visit events. This will provide useful context for each event when viewing all the events of the record. You can also get more advanced with the piping by using multiple fields and even static text. For example, ‘[visit_date], [weight] lbs’.
    • The custom_event_label attribute for events has been added to the Export Events API method
  • Enhanced radio buttons and checkboxes for surveys: A new survey option “enhanced radio buttons and checkboxes” can be found on the Survey Settings page in the Online Designer in which you can enable the feature so that radio buttons and checkboxes are displayed differently on the survey page, in which they appear as large animated buttons that look more modern and stylish than traditional radios and checkboxes. This new feature can be enabled for any given survey in a project where it will transform *all* radios and checkboxes on the survey into the enhanced version. Note: This feature does not work for radios and checkboxes in a matrix.
  • Create custom public survey link: On the “Public Survey Link” page in a project that utilizes surveys, users now have the option to create their own custom public survey link that begins with “” (e.g.,, in which the custom URL will simply redirect to the public survey in their project. They may enter a desired URL, and it will check if the URL has already been taken. If not, it will store that custom URL in the project so that it is always able to be obtained on the Public Survey Link page.

New Action Tags

  • @PLACEHOLDER: Is used to specify a short hint that describes the expected value of a Text field or Notes field (e.g., a sample value or a short description of the expected format). The placeholder is displayed inside the field before a value is entered. The format must follow the pattern @PLACEHOLDER=’????’, in which the text to be displayed should be inside single or double quotes. This action tag is compatible with all browsers, including Internet Explorer 8 and 9.
  • @HIDEBUTTON: Hides the ‘Now’ or ‘Today’ button that is typically displayed to the right of date, time, and date/time fields.
  • @INPUTMATRIX: a new custom tag to support displaying a table of input, or data entry, fields. This custom hook utility is designed to allow such a table to be created, using an arbitrary number of rows and columns (as REDCap is not yet “responsive” in its design, consider the width of the browser window when determining the number of columns to display.) NOTE: This hook utility does NOT use the “Matrix of Fields” infrastructure, but rather makes use of an instrument’s “Descriptive Text” field and a custom “Action tag.”

New API Methods

  • “Generate Next Record Name” (content=generateNextRecordName): To be used by projects with record auto-numbering enabled, this method exports the next potential record ID for a project. It generates the next record name by determining the current maximum numerical record ID and then incrementing it by one. NOTE: This method does not create a new record, but determines what the next record name would be. If using Data Access Groups (DAGs) in the project, this method accounts for the special formatting of the record name for users in DAGs (e.g., DAG-ID); in this case, it only assigns the next value for ID for all numbers inside a DAG.
  • “Import Project Information”: Users may now update certain project-level settings via the API, such as the project’s title, if it is longitudinal, if surveys are enabled, etc. The following project attributes can be updated: project_title, project_language, purpose, purpose_other, project_notes, custom_record_label, secondary_unique_field, is_longitudinal, surveys_enabled, scheduling_enabled, record_autonumbering_enabled, randomization_enabled, project_irb_number, project_grant_number, project_pi_firstname, project_pi_lastname, display_today_now_button.
  • “Delete Records”: Users may now delete individual records using the API. One or more records may be deleted using a single API request, in which the record name must be explicitly specified. For longitudinal projects having multiple arms, the optional “arm” parameter may be passed in the request so that the record is only deleted from the specified arm, whereas by default it will delete the record from all arms if the record exists in more than one arm.


Tufts CTSI upgraded REDCap to version 6.14.1 in August 2016. The new features include:

General Enhancements

  • Updated the Help & FAQ page.
  • Users can now be notified when their user rights for a given project are changed. A new check-box to notify the user by email was added.
  • Project data can now be exported as CDISC format.

Project Set-up/Online Designer/Data Entry/Data Import

  • New action tag @USER: sets a field’s value to the username of the current REDCap user. If this is used on a survey, the value will be “[survey respondent].” Once the value is captured, it will not change when visiting the page later.
  • New action tag @DEFAULT: sets a field’s initial value. This action tag allows a field to have a specified default value when viewing the field on a survey or data entry form that has not yet had any data saved (i.e., when the form status icon is gray or when a survey has not been started).

Project Reports

  • Live Filter for reports:
    • Any report can now have up to three fields designated as a Live Filter.
    • Live Filters are displayed as drop-downs when viewing a report at the top-right of the page.
    • Selecting a Life Filter will cause the report to be re-run in real time using the Live Filter value as a filter.
    • If exporting a report that has a Live Filter selected, the export pop-up window will provide an extra choice to allow the user to export the full report data set or to apply the currently selected Live Filter to the report when exporting. Note: currently only multiple choice fields can be used as Live Filters (as well as Events, if longitudinal, and Data Access Groups, if any exist).

Administrator Dashboard

  • Administrator To-Do List: lists all outstanding tasks for the REDCap administrator (e.g., approving project changes, API token requests, and moving projects to production status).

For details about the new features, please view our REDCap slide presentation (PDF).