Upgrade 9.5.5 LTS Detailed Features Changes List New

Owned by Christopher Sorensen
Last updated: Jan 26, 2024
44 min read

LTS (Long Term Support) Version 9.5.5 LTS

BUG FIXES & OTHER CHANGES:

The previous version of LTS (v9.5.4) did not get released with the proper code and thus might be missing many things that should have been included in LTS 9.5.4. This version (9.5.5) is a replacement that represents what should have been 9.5.4. Our apologies for the mishap.

Version 9.5.4 LTS

New LTS branch based on REDCap 9.5.3 (Standard)

Standard

Version 9.5.3 Standard

BUG FIXES & OTHER CHANGES:

Improvement: New content was added to the "Help & FAQ" page

Version 9.5.2

BUG FIXES & OTHER CHANGES:

New feature: Built-in acUvaUon process for external modules (system-level setting - enabled by default)

All modules that have been set as “Discoverable” in the system will now have a “Request Activation” button displayed next to them when viewing the list of available modules on the External Modules page in a project. If a user with Project Setup/Design privileges in the project clicks the button, it will add a new item to the To-Do List in the Control Center (and also send an email to the REDCap administrator if admin email notifications are enabled) that will ask the admin to activate the module. Once the admin has activated the module for the user, the user will receive an email informing them that the module has been activated for the project.

Note: This option can be disabled to hide this button for all discoverable modules (e.g., if you wish to use your own module activation process) at the top of the “Modules/Services Configuration” page in the Control Center.

New feature: Users can self-acUvate an external module for a project (module level setting - disabled by default) For any given module that has been enabled in the system and that has also been set as “Discoverable”, a REDCap administrator may optionally set a module setting (in the Configure Module popup for the module in the Control Center) that will allow any user with Project Setup/Design privileges in a project to activate the module in their project on their own (i.e., without an administrator having to enable it for them). Since this is a module-level setting, it is completely opt-in by the REDCap administrator for any given discoverable module. New feature: Standalone Launch for CDP and Data Mart - When using the Clinical Data Pull or Clinical Data Mart functionality, it is no longer required for users to have to log in to the EHR and launch the embedded REDCap window inside the EHR interface as a means of establishing a connection between their REDCap account and the EHR. This is now optional. Users may now alternatively establish a connection with the EHR by logging into to the EHR via a prompt while inside REDCap. If a user in REDCap attempts to pull clinical data from the EHR, in which it determines that the user has not established a connection yet with the EHR, it will prompt them to log into their EHR directly in their web browser, after which it will redirect them back to REDCap to begin pulling the clinical data from the EHR. Thus setting up a REDCap launch button in the EHR interface is no longer required but optional since the connection can now be completely established on the REDCap side alone. NOTE: For those using Epic, this means that creating an FDI Integration Record and Menu Record are no longer mandatory as part of the general CDIS setup process.

Improvement: In Alerts & Notifications when clicking the "Preview Message by Record" option, it now displays the Custom Record Label and/or Secondary Unique Field value in the record drop-down list in the dialog.

Improvements and changes when exporting data from REDCap into SAS Full integration of the Missing Data Code functionality in the SAS data export syntax file to prevent issues when loading data containing Missing Data Codes into SAS. Note: The SAS Pathway Mapper file has been removed and is no longer utilized. Users exporting data to SAS will now need to manually modify the path of the CSV data file in their .SAS syntax file to reflect its locally saved path on the device.

Version 9.5.1

BUG FIXES & OTHER CHANGES:

Improvement: When using the Data Resolution Workflow and exporting all data queries in a CSV file, the following attributes are now all exported as their own separate columns in the CSV file: record name, event name, data access group, data quality rule, and field name. In previous ## Versions, some of these attributes existed together in a single column and thus were harder to parse out individually. Additionally, the following columns have been added to the CSV export file: Current Query Status, Time Raised, and Time Resolved. (Ticket #30092)

Major bug fix: When clicking the "Remove file" link on a data entry form or survey page when attempting to delete a file or signature for a File Upload field or Signature field, it would mistakenly fail and prevent the user from successfully deleting the file. Bug emerged in v9.5.0. (Ticket #75030)

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered, in which a malicious user could potentially exploit it by manipulating the POST request parameters of a specific HTTP request.

Version 9.5.0

BUG FIXES & OTHER CHANGES:

New Acton Tag: @HIDDEN-PDF - Hides the field only in the downloaded PDF of one or more instruments (including blank PDFs, PDFs with data, and compact PDFs with data). Note: Other @HIDDEN acGon tags will not hide fields inside PDF exports, so @HIDDEN-PDF must be used specifically to hide fields in PDFs.

New hook functions

redcap_pdf - Allows for the interception of a PDF being generated or the manipulation of the $metadata or $data arrays that will be used to generate the PDF.

redcap_email - Allows REDCap's normal email-sending process to be intercepted or have the email parameters manipulated prior to sending.

The parameters passed into this hook function are the exact same ones utilized by the REDCap::email() method.

Improvement: More rich text editors - The rich text editor is now available when composing survey invitations. This includes composing Automated Survey Invitations or invitations to be sent via the Participant List or via the Survey Options on data entry forms.Improvement: The rich text editor is now available on the Email Users page in/ the Control Center and also for the Survey Confirmation Email option on the Survey Settings page.

Improvement: The Configuration Check page now checks if any hook functions are missing from the Hook Functions file used by the REDCap installation. If any are missing, instructions are provided in order to add them. Medium security fix: If a very tech-savvy user knows how the data dictionary upload process works, then they could manipulate certain POST parameters in a request to REDCap and thus be able to bypass the protection that prevents regular users from adding or modifying a Dynamic SQL Field on an instrument. If they are successful, they could potentially add a Dynamic SQL Field with whatever SQL query they wish and thus possibly extract sensitive information from the REDCap database (from any project or database table), albeit in a very limited format (i.e., in the form of drop-down field choices). (Ticket #20988) Major bug fix: When exporting a Project XML file for a project containing a survey that utilizes the Survey Confirmation Email setting, in which a file attachment exists for the confirmation email, it would mistakenly export the docid value as-is in the XML file and thus create a new project having that same docid value for the confirmation email's attachment. This would cause the new project's attachment to point to the other project's file (rather than to a newly created file), and so if the attachment got deleted in the new project, it would mistakenly also remove the file in the original project and vice versa (assuming these projects exist on the same REDCap server). And if the Project XML file originated from a different REDCap server, then there is a chance that the file attachment in the new project might mistakenly point to any file stored in the entire REDCap system, including a file that might contain sensitive information (PHI). This could potentially expose sensitive information to a survey participant who is not authorized to access it.

Change/improvement: The HTML tags THEAD and TFOOT are now officially allowed for use in HTML-based user-provided input, such as field labels, survey instructions, etc. (Ticket #74574)

Improvement: Major performance improvement with regard to web server RAM usage when using the method REDCap::evaluateLogic() a lot in a module, hook, or plugin. In some cases where it was being called hundreds of times in a single request, it might cause PHP to run out of memory. Change: If the "File Upload field enhancement: Password verification & automatic external file storage" setting has been enabled in a project, then when a user attempts to delete a file for a File Upload field (including the deletion of older revisions for that field), it is now required for users to provide a reason (in the text box in the "Delete file?" popup) in order delete the file. In previous ## Versions, providing a reason was only optional.

Version 9.4.2

BUG FIXES & OTHER CHANGES:

Improvement: Line breaks may be preserved in data values in CSV data exports - When creating/editing a report, the section "Additional report options" contains a new setting: "Remove line breaks/carriage returns in all text data values (only applicable for CSV Raw and CSV Label data exports)". This setting will be enabled by default for all existing reports and for any new reports being created. The option will effectively enabled (i.e., will remove line breaks) when exporting Reports A and B in order to be consistent with their current behavior in previous ## Versions. This option is only used for CSV data exports and not for reports or exports to statistical analysis packages. (Ticket #32418)

Improvement: Added “Copy” and “Paste” options to the [right-click] context menu for all rich text editors.

Version 9.4.1

BUG FIXES & OTHER CHANGES:

Improvement: A custom email “display name” can be set for the email sender when sending an email for Alerts & Notifications, the Survey Email Confirmation option on the Survey Settings page, and when sending survey invitations via Automated Survey Invitations, via the Participant List, or via the Compose Invitation option on a data entry form.

Improvement: The email “display name” for most outgoing emails is now automatically populated and thus is able to be displayed in the recipient’s email client. Previous ## Versions did not use the display name but left it blank for outgoing emails. For user requests that are triggered by users, such as production change requests, API token requests, etc., the user’s first and last name from their My Profile page will be used automatically as the display name in those emails. For emails originating from REDCap administrators that are automated by the system, the email display name will the “Name of REDCap Administrator” setting (from the General Configuration page) or else the “Contact name to display on Home page” (from the Home Page Configuration page), which is dependent upon the type of email being sent.

Improvement: New system-level setting “Suppress usage of the Universal FROM Email address for specified email domains” on the General Configuration page - If the setting “Universal FROM Email address” is enabled for the system, then the Universal FROM Email address will be used for all outgoing emails. But if one or more domain names (e.g., http://vanderbilt.edu (http://vanderbilt.edu/ )) are specified for “Suppress usage of the Universal FROM Email address for specified email domains”, then the Universal FROM Email address will NOT be used for any outgoing emails in which the FROM/sender's email address matches one of those domains. Instead the FROM/sender's email address will remain as-is.

Improvement: The module/plugin method REDCap::email now has new parameters that can be passed to it: BCC, FromName, and Attachments. The parameter BCC represents the email address of someone being BCC'd on the email (if using more than one email address they must be separated by commas and/or semicolons).The parameter FromName represents the sender's email display name that will be displayed in ther ecipient's email client next to the sender's email address(e.g.,"Rob Taylor"). And the parameter Attachments should be an array of one or more file attachments, in which the array keys will represent the file name as seen in the email clientandthecorrespondingarrayvalueswillrepresentthefullfilepathoftheattachmentfileontheREDCapserver.Anewexampleis provided on the "Developer methods for Plugins, Hooks, & External Modules" page to illustrate how to use these new parameters. Minor security fix: An SQL Injection vulnerability was found on the File Repository page, in which a malicious user could potentially exploit it by manipulating the query string of certain HTTP requests utilized within that page.

Change: The popup for displaying Project Notes on the My Projects page might not behave correctly under certain conditions. It is now displayed in a better format to avoid these issues. (Ticket#71813)

Version 9.4.0

NEW FEATURES, BUG FIXES, & OTHER CHANGES:

New feature: Missing Data Codes (i.e., “Data Missingness” functionality) Fields that have a blank/missing value may be marked with a custom 'Missing Data Code' to note why the value is blank. These missing codes may be used to aid in data analysis by specifying why a field lacks a value. Users may enable custom missing data codes at the project-level in the Additional Customizations popup on the Project Setup page. The missing codes should be coded just like the choices of a multiple choice field with code + comma + label, in which the codes can only have letters, numbers, dots, dashes, and underscores (e.g., '-999, Not asked' or 'UNK, Unknown'). If no codes are entered, this feature will remain disabled. After missing data codes have been set up in a project, you will see an 'M' icon next to each field when viewing a data entry form. Click the icon to open your list of missing data codes, and select one. Once selected, it will save the missing code as the literal data value for the field. Missing data codes can be used for any field type (e.g., date, slider, file upload fields). If utilizing missing data codes, the functionality will be enabled on all fields by default, and the code will be saved as the literal data value for the field. New action tag @NOMISSING can disable the missing data option for a given field Behavior with branching logic – If a field should be hidden by branching logic, REDCap will ask the user (except on surveys) if they wish to delete the value of the field being hidden. But if the field has a missing data code saved for it, it will still hide the field but will not remove the missing data code as the field’s value. This allows a field to still be “blank” and have a missing code while being hidden by branching logic. New isblankormissingcode() function for branching logic, logic, and calculations - Returns a boolean (true or false) if the field value is blank/null/"" or if the value is a Missing Data Code, in which Missing Data Codes have been explicitly defined in the project on the Project Setup page under Additional Customizations. E.g. isblankormissingcode([age]), in which if "age" has a value of "UNK" (which might be a Missing Data Code in a project), then it will return TRUE. And if the field has any non-blank/non-null value that is also not a Missing Data Code, it will return FALSE. Missing data codes can be imported via API, Data Import Tool, or REDCap::saveData (for plugins/hooks/modules) All the missing data codes are displayed for reference at the top of the Codebook page When creating/editing a report, a new option exists under the “Addition report options” section: “Display any Missing Data Codes in place of blank values (where applicable)”. This option will allow users (based on their preference) to show or not show the Missing Data Codes (if they have been saved for any field in any record) in the report or export.Note: In PDF exports of data collection instruments, any Missing Data Codes will be represented as blank values in the PDF. Changes for Data Quality Rules DQ rule A and B (for finding blank values) will continue to return only truly blank values and thus will not return fields with missing data codes saved as the value. New rule - DQ “Rule I (Fields containing missing data codes)” has been added as a new rule for specifically finding fields with missing data codes saved as the value. DQ rule F (Hidden fields that contain values) will ignore fields that have a missing data code saved as the value because it is allowable for such fields to be hidden by branching logic while still maintaining a missing data code as a value.

Improvement: If the Clinical Data Mart has been enabled for the system, the Control Center's System Statistics page now lists the following stats related to Data Mart under the "Modules Utilized" section: 1) Records with data values imported via Data Mart, and 2) Projects with data values imported via Data Mart.

Improvement/change: If a user is viewing a data entry form that has been enabled as a survey and then clicks "Compose survey invitation" in the survey options at the top right of the page, if they compose and send an invitation that is marked to be sent "Immediately", it will display a popup to inform the user that it is recommended that they leave the page very soon before the respondent has a chance to enter any data on the survey page. This is done because if the respondent begins entering data on the sur/vey immediately aker receiving the invitation, and then the user (while still viewing the data entry form) saves the form, the user could unwittingly erase the respondent's data values that were just entered.

Change: When enabling the Twilio telephony services in a project, REDCap no longer performs a check to ensure that Twilio's "Request Inspector" feature is disabled. Due to technical issues with not being able to automatically disable the Request Inspector via Twilio's API for some REDCap server configurations, REDCap no longer forces the Request Inspector to be disabled but instead provides text to inform users during the Twilio setup process that it is highly recommended that they disable the Request Inspector manually in their Twilio account (especially if collecting identifying information) and provides information on where/how to do such.

Change: REDCap now utilizes PHPMailer for all emails sent out.

Improvement/change: If the Universal “From” Email Address option is being utilized for the system, the sender’s email address now gets set as the Display Name in the email received. In previous ## Versions, no Display Name is ever set for outgoing emails. So instead of the recipient only seeing that the sender is no-reply@vumc.org (mailto:no- reply@vumc.org) (assuming this to be the catch-all universal address, for example), it instead will appear to be from “joe.user@gmail.com (mailto:joe.user@gmail.com) EMAIL: no- reply@vumc.org (mailto:no-reply@vumc.org). This is an improvement because it provides the recipient with more context with regard to who the sender is.

Version 9.3.8

BUG FIXES & OTHER CHANGES:

Improvement: When using the CDIS services Clinical Data Pull and Clinical Data Mart, users may now import medications with statuses other than “active”, such as “stopped”, “on-hold”, and “completed” medications. (Previous ## Versions only imported “active” medications.) In CDP, these have been added as three new fields that can be mapped on the project mapping page. In Data Mart, medications with any of the four statuses now get imported into the Medications repeating instrument, and a new field named “Medication status” was added to the Medications instrument to store the status value for each medication.

Version 9.3.7

BUG FIXES & OTHER CHANGES:

Improvement: Major performance improvement when loading the Participant List page for projects with surveys. For projects with thousands of records or more, this page should be significantly faster.

Improvement: Performance improvement for record searching on the "Add/Edit Records" page when entering part of a record name in the "Enter a new or existing [Record ID]" text box. For projects with thousands of records or more, this functionality should be much faster.

Improvement: Performance improvement for projects using record auto-numbering, in which the process of generating the record name of the next potential record is much faster, especially for projects with many records.

Change: The "Data Search" feature on the "Add/Edit Records" page will no longer allow users to search over "All fields" if a project contains more than 20,000 records. This is done for performance reasons so that it does not bog down the database server.

Change: When creating a new Clinical Data Mart project, all the text fields for labs and vital signs values no longer have number validation on them. The field validation has been removed in order to handle some of the newer non-numerical data types that might be output by FHIR for labs and vitals.

Version 9.3.6

BUG FIXES & OTHER CHANGES:

Improvement: Performance improvement for large data exports that might have previously taxed the REDCap servers or might have failed to complete altogether for some large projects. An internal auto-batching mechanism is now utilized to limit the performance hit to the servers (both database and web server) when exporting large quantities of data (via API or user interface) in order to improve the user experience and to prevent REDCap processes from using up too many server resources. Note: This does not necessarily mean that data exports will be faster; in fact, some exports might be slightly slower as a means of preserving server resources used by REDCap processes.

Improvement: Performance improvement for when REDCap is generating the record list cache for a project, especially for projects with Data Access Groups. For each project, REDCap maintains a record list in a database table that is used throughout a project. This record list improves overall performance, especially for large projects. Every few days the record list cache is automatically rebuilt internally. The process of rebuilding the record list is now more efficient, faster, and less error-prone than in previous ## Versions. Improvement/change: The Codebook now denotes if an instrument is enabled as a survey, in which it is noted immediately to the right of the instrument name. Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on survey pages, in which a malicious user could potentially exploit it by manipulating the URL on the page as a means of injecting JavaScript into a calculated field on the page.

Change: Users will no longer be allowed to display all pages of a report (by selecting “ALL” from the report’s page selection drop-down list) if it has been determined that such a report would display more than 500,000 data points (i.e., table cells) on the report page. This is to help prevent users from causing performance degradation to the REDCap server and also to improve user experience (assuming the page would take a very long time to load and might even cause the user’s web browser to crash). Fixes and updates to the External Module Framework

Change: If any projects have enabled both the Randomization module and the Double Data Entry module together in the same project, it now displays a warning at the project.

Change: Added new database table indexes for improved performance.

Improvement/change: The API method "Export Project Info" now includes a new attribute named "external_modules", which will output a comma-delimited list of all External Modules that are enabled in that project. Note: It will include only the unique module name (not the module title or module ## Version).

Change: The drop-down record list near the top of the Data Quality module now only displays the first 10,000 record names for projects containing more than 10,000 records. This is to prevent excessive load on the server and also to prevent the user's browser from crashing for very large projects.

Version 9.3.5

BUG FIXES & OTHER CHANGES:

Improvement: If the "File Upload field enhancement: Password verification & automatic external file storage" setting has been enabled in a project, then when a user attempts to delete a file for a File Upload field (including the deletion of older revisions for that field), it will provide a text box in the "Delete file?" popup in order to allow the user to optionally provide a reason for why they are deleting the file (if they wish), after which this reason will be logged on the Logging page.

Improvement: The bottom of the "Clinical Data Interoperability Services" page in the Control Center has a new setting "Allow the patient's email address to be imported from the EHR?". It is initially set to "No", but if changed to "Yes", it will display the "email address" field in the field mapping tree for both Clinical Data Pull and Clinical Data Mart, thus allowing users to import a patient's email address into REDCap, if they desire. Previous ## Versions of REDCap did not allow the patient email address to be imported. (Ticket #70967)

Version 9.3.4

BUG FIXES & OTHER CHANGES:

Major bug fix: If a user is importing data via the API into a locked instrument, it might mistakenly allow the data to be modified. It should not allow data to be modified once an instrument is locked. Bug emerged in REDCap 9.1.6 (LTS) and 9.2.3 (Standard).

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on the "Customize & Manage Locking/E-signatures" page, in which a malicious user could potentially exploit it by manipulating the Lock Record Custom Text values on the page in a very specific way.

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on the "Alerts & Notifications" page, in which a malicious user could potentially exploit it by manipulating an alert's email subject in a very specific way.

Improvement: On the Survey Settings page, the "Redirect to a URL" option now allows the Smart Variable [survey-url] to be used - e.g., [survey-url:other_survey]. (Ticket #70613)

Change: If the "Name of REDCap Administrator" setting is set to something other than blank/null on the "Edit a Project's Settings" page in the Control Center for a given project, then the blue button on the project's left-hand menu will have the button text as "Contact X" (where X is the name entered) rather than the hard-coded text "Contact REDCap Administrator". (Ticket #70799)

Version 9.3.3

BUG FIXES & OTHER CHANGES:

Major bug fix: Some code in the External Modules Framework was not compatible with PHP 5.5, thus causing every page to crash after installing or upgrading to REDCap 9.1.11 (LTS) or 9.3.2 (Standard Release). (Ticket #70186)

Version 9.3.2

BUG FIXES & OTHER CHANGES:

Improvement: The "Cancel" button on data entry forms now displays a confirmation prompt after being clicked to ask the user if they truly wish to cancel and lose all their changes. (Ticket #22360)

Version 9.3.1

BUG FIXES & OTHER CHANGES:

Improvement/change: When an administrator is reviewing the email from a user requesting to have a project deleted (via a button click on the Other Functionality page for production projects), the email subject now includes the project ID (PID) to allow admins to track emails for projects more easily and not get them confused with one another. Fixes and updates for the External Modules Framework

Version 9.3.0

NEW FEATURES, BUG FIXES, & OTHER CHANGES:

New feature: File ## Version History for File Upload fields (project-level setting) This feature allows a new file to be uploaded onto a File Upload field that already has a file uploaded for it. If a file has already been uploaded, the field will have a new link “Upload new ## Version”, and after being clicked, it will allow the user to upload another file without having to delete the existing one. The old/existing file will not be deleted but will still be accessible as an older ## Version of that file in the Data History popup (by clicking the “H” icon next to the field). Within the Data History popup, a user may view, download, or delete any existing ## Version of the file that exists, in which all ## Versions of the file will be displayed in a table format and listed in chronological order with regard to being uploaded. “Import File” API behavior: When the File ## Version History feature is enabled for a project, and the “Import File” API method is used to import a file into a File Upload field that already has a file saved for it, the new file will overwrite the existing file but keep the existing file in the File ## Version History, thus not deleting it. This is different for projects that have the File ## Version History disabled, in which importing a new file will delete the existing file. For all upgrades/installs, this feature will be enabled for the system and for all projects. It may be disabled for all projects by disabling the system-level setting, which is located on the Modules/Services Configuration page in the Control Center. Alternatively, it may be left enabled at the system level, and you may set it so that all new projects (created in the future) will have the feature enabled or disabled, which can be done on the Default Project Settings page in the Control Center. While this feature will be enabled by default for all projects, if you wish to disable it for all existing projects, then you may run the following SQL on the database after the upgrade: UPDATE redcapprojects SET fileupload## Versioningenabled = 0;

New feature: File Upload field enhancement: Password verification & automatic external file storage (project-level setting) - requires PHP 5.6.0 This feature allows users to utilize extra functionality regarding the use of File Upload fields in a project. It must first be enabled at the system level (at the bottom of the Modules/Services Configuration page in the Control Center). It is disabled by default for all projects, but users with 'Project Setup & Design' rights can enable it for a project in the Additional Customizations popup on a project's Project Setup page.

How it works: Any user that is uploading a file for a File Upload field on a data entry form or survey will be asked to confirm that the file is the correct file. And when on data entry forms specifically, it will additionally ask the user to enter their REDCap password as part of the verification process. Once confirmed, the file will successfully upload, and in addition to saving the file normally in REDCap, it will also store a duplicate copy of the file on a secure, external server using the configuration settings defined in the Control Center. The connection to the external file server can be set up as WebDAV or SFTP, in which the details/credentials must be provided when enabling this system-level setting at the bottom of the Modules/Services Configuration page in the Control Center. This feature may be utilized for projects wishing to adhere to certain regulatory compliance, such as 21 CFR Part 11 for FDA trials. Please note that enabling this feature does not make the feature or your REDCap installation automatically “Part 11 compliant”. It is assumed that if using this for Part 11 compliance that you have already gone through all the processes of documenting and validating your REDCap environment (or parts of it) to validate it as “Part 11 compliant” beforehand.

Improvement: The Control Center's left-hand menu now contains a text field for entering a project's PID (project ID), after which it will direct the user to that project. This provides a quick way of navigating to a project when you have the PID.

Improvement: The Data History Popup for File Upload fields now provides more detailed information, such as the filename of the uploaded file.

Improvement: When using the Clinical Data Mart feature and fetching data from the EHR, it now provides to the user a summary of all the types of data that were imported during the fetch and how many data points were imported for each category (e.g., Demographics, Medication Order). Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on the Data Import Tool page, in which a malicious user could potentially exploit it by manipulating the CSV data import file in a very specific way and then uploading it on the page. Note: This issue does not occur for administrator accounts but only for regular users. Minor security fix: Some SQL Injection vulnerabilities were found on the Calendar and Scheduling pages, in which a malicious user could potentially exploit them by manipulating the query string or POST parameters of an HTTP request.

Version 9.2.5

BUG FIXES & OTHER CHANGES:

Change: Minor changes to Clinical Data Mart When creating a Data Mart project, it is now optional for a user to provide a list of MRNs when setting the initial Data Mart configuration. If some MRNs are provided, empty records containing only those MRNs will be automatically created/seeded in the project after the first Data Mart revision has been approved by an administrator. After the first Data Mart revision has been approved, the MRN list on the Data Mart page will no longer be visible because the Fetch button will now fetch data based solely on the MRNs associated with records in the project (rather than using an MRN list from the configuration page, which was the case for older ## Versions of Data Mart). So from this point on, the Data Mart will fetch data for ALL records in the project that have an MRN associated with it.

Version 9.2.4

BUG FIXES & OTHER CHANGES:

Major bug fix: When attempting to send/schedule an email manually via the Participant List, it would mistakenly fail to do so and would note that "0" invitations were scheduled/sent. Bug emerged in REDCap 9.2.3 (Standard).

Version 9.2.3

BUG FIXES & OTHER CHANGES:

Medium security fixes: Several SQL Injection vulnerabilities were found on certain pages related to the Mobile App, the API, Shared Library, Data Comparison Tool, and the Calendar, in which a malicious user could potentially exploit them by manipulating the query string or POST parameters of an HTTP request.

Major bug fix: Some pages related to the Calendar, such as the calendar popup and some background AJAX requests for setting calendar event attributes, were mistakenly not checking to ensure that the user had "Calendar" user privileges when accessing those pages. This was also true for the "Scheduling" module, in which no user privileges at all were being applied to any pages related to Scheduling. All pages related to Scheduling should have been applying the "Calendar" user privileges. They have been changed so that now all Scheduling pages are connected to "Calendar" user privileges, and the User Rights page now lists "Calendar & Scheduling" together as a user right option (only display "& Scheduling" for that item when the Scheduling module is enabled) to help re-enforce to the user that the same user rights are applied to both Calendar and Scheduling, which is how it was intended to behave originally.

Improvement: In a project with repeating instruments, the Record Home Page now displays a count of total instances of a given repeating instrument next to the instrument name in the tables of instances displayed at the bottom of that page. Improvement/change: When an administrator is reviewing drafted production changes, the pre-filled "confirmation email" option on that page now includes the project ID (PID) in the subject of the email to the requester to allow admins to track emails for projects more easily and not get them confused with one another.

Version 9.2.2

BUG FIXES & OTHER CHANGES:

Major bug fix: When using a Data Quality Rule with Real-time Execution enabled in a project with the Randomization module enabled, in which during the randomization process the DQ rule returns a discrepancy for one or more strata fields used in the randomization configuration, it would properly prevent the randomization process from occurring but would mistakenly remove that whole allocation row from the allocation table, which means that that particular randomization allocation could never be used afterward because it was permanently deleted. This could cause major problems for the project. (Ticket #67062)

Major bug fix: If a user has access to a project but does not have "File Repository" access in that project, then if they know how to manipulate certain URLs in REDCap, they might be able to download files uploaded into the "User Files" section of the File Repository page in that project. Note: They would not be able to download files from the "Data Export Files" section or "PDF Survey Archive" section, but only from the "User Files" section. (Ticket #22974)

Version 9.2.1

BUG FIXES & OTHER CHANGES:

Version 9.2.0

NEW FEATURES, BUG FIXES, & OTHER CHANGES: 10 new Smart Variables

[project-id] - The Project ID (i.e., PID) of the current REDCap project. [user-fullname] -The current user's first and last name (as listed on their My Profile page). [user-email] - The current user's primary email address (as listed on their My Profile page). [redcap-base-url] - The base web address for the REDCap installation.

[redcap-## Version] - The current REDCap ## Version number of the REDCap installation. [redcap-## Version-url] - The base web address of the current REDCap ## Version directory for the REDCap installaGon. [survey-base-url] - The base web address for surveys for the REDCap installation.

[instrument-name] - The unique instrument name of the current survey or data entry form. It will return a blank value if not in an instrument context. [instrument-label] - The instrument label of the current survey or data entry form. It will return a blank value if not in an instrument context.

[survey-title] - The survey title of the instrument specified by the 'instrument' parameter (if provided). If the 'instrument' parameter is not provided, the current survey instrument will be used, else it will return a blank value if not in an instrument/survey context.

4 new Action Tags

@NOW_SERVER - Loads the REDCap server's date+time into a blank Text field - similar to the @TODAY tag but additionally includes the time portion. If the field has validation, the value will adjust to match the date format. NOTE: The time used will be the REDCap server's local time, which might be different from the user's local time if in another timezone. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.

@TODAY_SERVER - Loads the REDCap server's date into a blank Text field - similar to the @NOW tag but without the time portion. If the field has validation, the value will adjust to match the date format. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.

@NOW_UTC - Loads the current UTC/GMT date+time into a blank Text field - similar to the @TODAY tag but additionally includes the time portion. If the field has validation, the value will adjust to match the date format. NOTE: The time used will be the current UTC/GMT time, which might be different from the user's local time if in another timezone. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.

@TODAY_UTC - Loads the current UTC/GMT date into a blank Text field - similar to the @NOW tag but without the time portion. If the field has validation, the value will adjust to match the date format. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.

Improvement: The email sent to the REDCap administrator that contains a link to the page for reviewing production project changes now includes the project ID (PID) in the email subject to allow admins to track emails for projects more easily and not get them confused with one another. (Ticket #48141)

Version 9.1.2

NEW FEATURES, BUG FIXES, & OTHER CHANGES:

New feature: Rich text editor for field labels and section headers

For any field on an instrument in the Online Designer, users may optionally utilize the rich text editor for styling field labels or section headers with many text- formatting options. The rich text editor allows users to change the color of text (including background color), create tables, add text of varying sizes, bullet lists, and more. For any field labels that were originally created without the rich text editor, users may optionally enable the rich text editor for any field by clicking the 'Use the Rich Text Editor' checkbox. It may also be disabled afterward at any time just the same. Rich text is enabled by default for any new fields being created via the Online Designer.

Note: The PDF export of surveys/instruments will not reflect all the styling of the rich text editor, so keep in mind that line breaks and paragraphs should be represented well in PDFs, but other text-formatting options, such as large text, bullet points, and colors are not able to be translated into the PDF export of the instrument. This is a current limitation in REDCap.

Improvement: For "Clinical Data Mart" projects, a new option was added on the Project Setup page to enable a process that will auto- fetch all clinical data twice a day (based on Data Mart configuration) using a cron job. Similar to the other project-level Data Mart options on Project Setup, this option can only be enabled or disabled by a REDCap administrator. This feature will be useful in cases where new data is being entered into the EHR, after which that data needs to be imported into the project without having a person manually fetch the data for each record one at a time. Medium security fixes: Cross-Site Scripting (XSS) vulnerabilities were discovered on several pages, in which a malicious user could potentially exploit them by manipulating user inputs in various locations throughout the application.

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on the Data Import Tool page, in which a malicious user could potentially exploit it by manipulating the CSV data import file in a very specific way and then uploading it on the page.

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on the page that displays the error message whenever any REDCap page fails the Cross-Site Request Forgery (CSRF) check, in which a malicious user could potentially exploit it by manipulating the HTTP referrer being sent to the webpage.

Change/improvement: Added the security headers "X-XSS-Protection" and "X-Content-Type-Options" to provide more protection for each web request made to REDCap. Change: A new setting has been added called “Can REDCap server access the web (make outbound HTTP calls)?” on the General Configuration page in the Control Center. This setting can be set to "No" if the REDCap server has no connectivity to the World Wide Web. This helps prevent some REDCap pages from becoming very slow to load because they are making background requests to external websites.

Change: On the Clinical Data Pull’s project list page (seen after launching REDCap inside an EHR), it now displays a link “View EHR patient identifier keys” that (when clicked) displays all possible EHR patient identifier strings for the institution’s EHR. This is to aid in setup of CDP and/or Clinical Data Mart since this value must be entered on the configuration page for Clinical Data Interoperability Services to be able to work properly for most EHR vendors.

Version 9.1.1

BUG FIXES & OTHER CHANGES:

Medium security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on many pages, in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.

Minor security fix: Updated the Bootstrap and jQuery libraries, which were outdated and contained minor security vulnerabilities. Improvement: The file attachment option for data queries in the Data Resolution Workflow popup can now be disabled at the system level for all projects. This option is located on the "File Upload Settings" page in the Control Center as "Allow file attachments to be uploaded for data queries in the Data Resolution Workflow?". If set to "Disabled", it will merely not display the "Upload document" option for an open data query in the Data Resolution Workflow popup on a data entry form.

Improvement: For "Clinical Data Mart" projects, users may now download and upload the Data Mart configuration as a CSV file on the "Clinical Data Mart" page. This CSV file may be used to create a new revision of the Data Mart configuration.

Change: Removed unnecessary "error_log" statements throughout the code. (Ticket #64858)

Version 9.1.0

BUG FIXES & OTHER CHANGES:

New feature: Clinical Data Mart

The Data Mart module can pull clinical data from the EHR in bulk (i.e., dozens or hundreds of patients at once), as compared with the Clinical Data Pull (CDP) that pulls patient data from the EHR just one patient at a time. Both Data Mart and CDP utilize REDCap’s “Clinical Data Interoperability Services” infrastructure, which can interface with any EHR system that has FHIR web services enabled. If CDP has already been set up and enabled in REDCap, then enabling Data Mart is very simple and requires no further setup other than enabling it on the CDIS page in the Control Center. Overview To use the Data Mart feature and create a Data Mart project, a user must be given explicit permissions for this by a REDCap administrator on the Browse Users page in the Control Center. Once they have been given permissions, they can navigate to the Create New Project page in REDCap to see a new option to create a Clinical Data Mart project. Note: If they have not yet launched the REDCap window from inside their EHR, it will inform them that they must first do so before proceeding. This must be done because launching the REDCap window inside the EHR, which is always the first step before a user can use either CDP or Data Mart. When creating the Data Mart project, the user defines the data pull configuration when creating the project - e.g., chooses specific MRNs, date range, and data fields from the EHR. Once the project has been created, the whole structure of the project (i.e., the fields and forms) will be pre-defined. To begin pulling clinical data from the EHR, the user must navigate to the Clinical Data Mart page using the link on the left-hand project menu. On that page, they may request changes to their existing Data Mart configuration (if they wish to add new MRNs, new fields, or modify the date range) and/or pull data from the EHR using the “Fetch clinical data” button near the top of the page. By default, users will only be able to pull data just one time and will not be able to modify the Data Mart configuration after initially being set when the project is created. However, an administrator can change these settings (see below) on the Project Setup page so that they may pull data as often as they wish or to allow them to make configuration changes when needed. Field mapping is not required for Data Mart projects since the project structure/instruments are pre-defined when the project is created. Demographics is created as a single data collection form, and the following forms are created as repeating instruments: Vital Signs, Labs, Allergies, Medications, and Problem List. Each data value on the repeating instruments are represented as a separate repeating instance of the form. User permissions

A user's REDCap account must be given Data Mart privileges by a REDCap administrator on the Browse Users page in the Control Center, after which the user will be able to create a Data Mart project and pull EHR data. (Note: This is not a project- level user right but a REDCap user account privilege.) Also, there is no optional User Access Web Service as there is with CDP to further control user access for pulling data. In order to pull data from the EHR, users must have access to the EHR and must have launched at least one patient in the REDCap window inside the EHR user interface. Users with Project Setup/Design rights in a Data Mart project will be able to request changes to the data pull configuration (if needed and if the project-level setting has been enabled).

For more details about Data Mart and CDP, see the information on the CDIS page in the Control Center in v9.1.0 (including the downloadable Overview PDF), which is also available here:https://redcap.vanderbilt.edu/redcapv9.1.0/Resources/misc/ redcapfhiroverview.pdf (https://redcap.vanderbilt.edu/redcapv9.1.0/Resources/misc/redcapfhiroverview.pdf)

Improvement: When using the Clinical Data Pull module, it now displays the patient's MRN inside the adjudication popup dialog. This makes it easier to confirm that a user is looking at the correct patient's data.

Improvement: When using the Clinical Data Pull module, the process of determining which FHIR access token is the best to use and still viable for a given user/patient has Fixes and updates for the External Module framework, including a fix for module icons not displaying correctly on the left-hand project menu.

Version 9.0.3

BUG FIXES & OTHER CHANGES:

Major bug fix: Users are not able to create new projects (or request new projects be created) if they are using any ## Version of Internet Explorer. Bug emerged in REDCap 9.0.2. (Ticket #64135)

Medium security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on many pages, in which a malicious user could potentially exploit it by adding specific user- defined HTML that gets displayed on certain webpages throughout the application (e.g., in field labels on instruments; in survey instructions).

Improvement: Added support for Traditional Chinese in exported PDFs. Previous ## Versions only supported Simplified Chinese in exported PDFs of instruments/surveys if the project encoding was set to “Chinese (UTF-8)”. Now on the “Edit a Project’s Settings” page and “Default Project Settings” page in the Control Center, it lists both “Simplified Chinese (UTF-8)” and “Traditional Chinese (UTF-8)” in the “Character encoding for exported files” option. Note: The only difference between the two Chinese encoding options are the fonts embedded inside exported PDFs; it does not affect other exported file types, such as CSV files.

Improvement: On the Alerts & Notifications page, the email "From" address is now displayed in the right-hand Email box for each alert. Change: For Alerts & Notifications, in Step 2B ("send it how many times?"), the "Just once" option now has more clarifying text for longitudinal projects or projects with repeating instruments/events to explain that that the alert will be triggered at a per-event and per-repeating-instance level.

Version 9.0.2

BUG FIXES & OTHER CHANGES:

Improvement: Force e-Consent signature fields to be erased when modifying responses - The e-Consent Framework setup on the Survey Settings page has a new option to allow users to specify up to five signature fields in the current survey, in which it will force all signature field values to be erased in the survey if the participant clicks Previous Page button while on the certification page (i.e.,the last page of the survey). In many situations when using e-Consent, it is required that if the participant completes all the survey responses and gets to the certification page but then decides to go back to modify some responses, the field (or multiple fields) where they supplied their signature must first be erased, thus forcing them to re-sign the survey before they complete it. This new e-Consent Framework option helps to comply with this particular situation. Note: Only freeform text fields, signature fields, and number fields may be used as e-consent signature fields here, and those fields must be Required fields.

Improvement: Custom message for e-Consent Framework settings - In the e-Consent Framework section on the Modules/Services Configuration page in the Control Center, an administrator may define custom text (including HTML styling), in which that custom text will be displayed at the bottom of the e-Consent Framework section on the Survey Settings page in every project. This may be utilized for informing users of some information surrounding the use of the e-Consent Framework at the local institution, for example.

Version 9.0.1

BUG FIXES & OTHER CHANGES:

Change: Replaced many of the older icons in the user interface with Font Awesome icons, especially on the left-hand project menu and left-hand Control Center menu. Change: Consolidated the two project pages “Record Locking Customization” and “E- signature and Locking Mgmt” into a single two-tabbed page named”Customize & Manage Locking/E-signatures”. Note: If user only has access to one of these pages, they will simply not see the other page/tab. )

Version 9.0.0

NEW FEATURES, BUG FIXES, & OTHER CHANGES:

New feature: Alerts & Notifications

The Alerts & Notifications feature allows you to construct alerts and send customized email notifications. These notifications may be sent to one or more recipients and can be triggered or scheduled when a form/survey is saved and/or based on conditional logic whenever data is saved or imported. When adding/editing an alert, you will need to 1) set how the alert gets triggered, 2) define when the notification should be sent (including how many times), and 3) specify the recipient, sender, message text, and other settings for the notification. For the message, you may utilize customized options such as rich text, the piping of field variables (including Smart Variables), and uploading multiple file attachments. While similar in many respects to Automated Survey Invitations, Alerts & Notifications allow for greater complexity and have more capabilities. For example, alerts apply to both data entry forms and surveys, and they also allow for more options regarding who can be the recipient of a notification (project users, survey participants, etc.). System-level permission settings – On the “Modules/Services Configuration” page in the Control Center (at bottom of page), administrators may adjust the settings that determine if normal users are able to use email field variables in an alert’s To/CC/BCC field and/or use email addresses entered manually as freeform text into an alert’s To/CC/BCC field. These settings will be determined based on the comfort level and/or policy of the local REDCap institution. By default, REDCap will allow normal users to use email fields and freeform text emails (i.e., both are enabled by default), but this can be easily changed immediately after installation or upgrading. Additionally, if Yes is chosen for allowing freeform emails to be entered, the admin may limit those emails to a specific whitelist of email domain names (e.g., http://vumc.org ( ), ( )) to provide some additional restriction there. Converting existing Email Alerts into Alerts & Notifications – If your REDCap installation currently has the Email Alerts external module installed and is being used in projects, there will be an option (a green button) at the top left of the Email Alerts configuration page to convert all the Email Alerts in a given project into Alerts & Notifications. This is an opt-in setting, and must be done foreach project one at a time. It will present a dialog popup with information so that the user understands that there are some differences between EA and A&N, but overall, everything will be able to be converted, although the alerts might look slightly different afterward as A&N’s. Once the Email Alerts are converted, the Email Alerts module will be automatically disabled for the project, and the user will be redirected to the A&N page.

Note: The con## Version instructions notes that if (for whatever reason) the A&N’s are not behaving like the user anticipated, they can easily revert back to using Email Alerts again by 1) deactivating all the A&N’s that were created from the con## Version, and 2) have an administrator re-enable the Email Alerts module.

Improvement: The rich text editors on the Survey Settings page have now been updated to a newer ## Version of the TinyMCE package. (Note: IE9 and IE10 will still use the older ## Version of the rich text editor because they are not compatible with the newer one.)

Improvement: New records can now be created directly from the Record Status Dashboard. If record auto-numbering is enabled, it will display an “Add new record” button, otherwise it will display a text field for users to enter a new record name to create. Improvement: Links to the Online Designer, Data Dictionary Upload page, and Codebook were added to the left-hand project menu for easier navigation. Also, a new section “Project Home and Design” was added on the left-hand menu to contain all these links, as well as the Project Home and Project Setup page links.

Change: The Quick Tasks box on the Project Home page was removed since all the pages listed inside it are now located on the left- hand project menu, thus making the Quick Tasks box redundant.

Version 8.11.11

BUG FIXES & OTHER CHANGES:

Version 8.11.10

BUG FIXES & OTHER CHANGES:

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on the Data Import Tool page, in which a malicious user could potentially exploit it by manipulating data values for a specific field being imported in the CSV data file.

Change: The Data History Widget on data entry pages now displays the "seconds" component of the "Date/Time of Change" timestamp for when the data value was added/modified. This allows users to view the logging items with greater granularity for when data changes are made in narrow windows of time.

Version 8.11.9

BUG FIXES & OTHER CHANGES:

Major bug fix: The DateDiff+Today/Now cron job would sometimes crash due to a fatal PHP error caused when processing the [survey-link] Smart Variable in the message of an Automated Survey Invitation. This would occur only under very specific conditions, and it would result in many projects/records not having their ASI datediff logic being processed, thus the ASI's survey invitations would not get successfully scheduled in these cases and might cause invitations from other unrelated projects not to get scheduled either. (Ticket #61346, #61213)

Major bug fix: When a project is using a public survey that has "Save & Return Later" enabled with "Allow respondents to return without needing a return code" enabled, then if a participant clicks the "Save & Return Later" button on the public survey and leaves the survey open on the "Your survey responses were saved!" page while another participant partially or fully completes the survey, and then if the original participant clicks the "Continue Survey Now" button on the "Your survey responses were saved!" page, then the original participant will mistakenly create a brand new record/response whenever they submit survey page again after returning. (Ticket #61764) Improvement: Added links to "select all" or "deselect all" for the checkbox options on the "Copy Project" page.

Change: Added note about e-Consent feature on the REDCap Home Page.

Change: More explanatory info was added on the Survey Settings page for Question Numbering, Question Display Format, and Response Limit.

Version 8.11.8

BUG FIXES & OTHER CHANGES:

Minor security fix: If a malicious user is able to find the URL endpoint at which REDCap Messenger's message history can be downloaded as a CSV file for a given conservation, they could potentially exploit it by manipulating the query string of the HTTP request, which might allow them to download other users' conversations to which they do not have access.

Minor security fix: If the hook functions file (as defined on the General Configuration page in the Control Center) begins with "http" or "ftp", then REDCap will not attempt to call/include that path.

Major bug fix: When using Smart Variables in the conditional logic of an Automated Survey Invitation, in which the logic also contains a datediff function using "today" or "now" as a parameter in the function, it would often cause the ASI cron job to not correctly parse the logic and thus not schedule the invitations at the correct time, or it might mistakenly cause the cron job to crash unexpectedly without finishing scheduling all other ASIs for other surveys.

Version 8.11.7

BUG FIXES & OTHER CHANGES:

Medium security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on many pages, in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.

Major bug fix: When the Clinical Data Pull (CDP) is enabled on a project, if extra data is imported from the EHR for several patients at one time via the cron job (after a user has already pulled some patient data from the EHR for those patients), in certain cases it might mistakenly not clear out data from another patient whose data is being fetched and thus inadvertently add one patient’s data to another patient.

Version 8.11.6

BUG FIXES & OTHER CHANGES:

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on certain pages, in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.

Bug fix: Incorrect text was displayed in the Edit User popup on the User Rights page that mistakenly referenced "Clinical Data Pull" instead of "DDP" in projects with DDP Custom enabled.

Change: Support was added to External Module framework to support return values for hooks. Specifically, the hook redcapcustomverify_username was modified so that if it returns result “status” of “1” or TRUE, it will display a green message box containing the return “message”, whereas if return “status” is “0” or FALSE, it will display a red message box containing the return “message”.

Version 8.11.5

BUG FIXES & OTHER CHANGES:

Version 8.11.4

BUG FIXES & OTHER CHANGES:

Text changes: The “DDP on FHIR” feature was renamed “Clinical Data Interoperability Services”. The main (and currently only) feature under the “Clinical Data Interoperability Services” umbrella of services is the “Clinical Data Pull” (CDP). Other services will be added in future ## Versions of REDCap, such as “Clinical Data Mart”.

Version 8.11.3

BUG FIXES & OTHER CHANGES:

Improvement: When copying a project, there are now separate options for copying users and/or user roles. In previous ## Versions, these were combined as a single choice "Copy users and roles", but now users may decide to copy one or the other. (Ticket #36687)

Change: If the current date or current timestamp is used in the REDCap upgrade script with regard to storing the date of the upgrade and when setting the send-time of system notifications via Messenger, it will now use the database's date and time at the time of the SQL script execution instead of the hard-coded values generated by the web server on the Upgrade page. (Ticket #57079)

Version 8.11.2

BUG FIXES & OTHER CHANGES:

Major bug fix: When a project is using a public survey that has "Save & Return Later" enabled with "Allow respondents to return without needing a return code" enabled, then if a participant clicks the "Save & Return Later" button on the public survey and leaves the survey open on the "Your survey responses were saved!" page while another participant partially or fully completes the survey, and then if the original participant clicks the "Continue Survey Now" button on the "Your survey responses were saved!" page, then the original participant will mistakenly have the other participant's response loaded for them on the survey page.

Change/improvement: When using the e-Consent Framework, a new option was added to the Survey Settings page: "Allow e-Consent responses to be edited by users?". If left unchecked (default), then users will not be able to edit a completed e-Consent response (although it can be locked or e-signed by a user with locking/e-signature privileges). If the setting is checked, then users will be able to modify the survey response so long as they have "Edit survey responses" privileges for that survey instrument. Note: If the e-Consent survey response is modified after being completed, this will not affect the e-Consent PDF file that was stored in the File Repository.

Change/improvement: In the popup dialog for moving a project to production, it now displays the number of records in the project to help the user decide if they wish to keep all data or have all records deleted when moving to production.

Version 8.11.1

BUG FIXES, & OTHER CHANGES:

Version 8.11.0

NEW FEATURES, BUG FIXES, & OTHER CHANGES:

New feature: Microsoft Azure Quick Start – Method for quickly deploying a full, production-ready REDCap server environment on Microsoft Azure Cloud Platform. This includes a completely automated way for deploying the server infrastructure as well as a fully automated installation of REDCap. For details, see the top of the pagehttps://projectredcap.org/software/requirements/ ( ) (Note: The REDCap “Easy Upgrade” feature does not yet work with Azure but is expected to in a later REDCap ## Version).

New feature: The "Survey Link Lookup" external module was integrated into REDCap This feature allows administrators to take a survey URL and find and navigate to the corresponding project, survey, record and data entry form. The Survey Link Lookup page is located under the “Projects” section on the left-hand menu in the Control Center.

If this external module was already enabled on the REDCap installation, it will automatically be disabled during the upgrade process to prevent any possible conflicts. New feature: The "REDCaptcha" external module was integrated into REDCap This feature allows users to utilize the Google reCAPTCHA functionality to help protect public surveys from abuse from “bots”, which are automated software programs that might enter trash data into surveys. The feature must first be enabled at the system level on the Modules/Services Configuration page in the Control Center since it requires an administrator generate a new Google API pair of keys that will be used for this functionality. Once the site key and secret key are set, users will then be able to choose to enable the Google reCAPTCHA functionality on the Public Survey page in their project, after which the public survey will display the reCAPTCHA checkbox and “I’m not a robot” text on a survey page prior to allowing the participant to view the public survey. This feature is not employed on any private survey links because those are unique to a record and thus would never be made publicly available like a public survey link would.

Note: A survey participant will never have to pass the reCAPTCHA test more than once per day on a given device/computer. Additional note: If this external module was already enabled on the REDCap installation, it will NOT automatically be disabled during the upgrade process. Thus you may consider disabling the module after the upgrade if you wish the utilize this new integrated feature.

New feature: The "Sticky Matrix Header" external module was integrated into REDCap. This feature will cause matrix headers to float and stick to the top of a page on either a survey or data entry form so that the matrix headers are always visible, which is helpful for matrices with many rows. If this external module was already enabled on the REDCap installation, it will automatically be disabled during the upgrade process to prevent any possible conflicts.

New feature: The "Codebook Concertina" external module was integrated into REDCap. This feature will display Expand and Collapse buttons for each instrument listed on the Codebook page in a project. If this external module was already enabled on the REDCap installation, it will automatically be disabled during the upgrade process to prevent any possible conflicts.

Minor security fix: A Cross-Site Scripting (XSS) vulnerability was discovered on certain pages, in which a malicious user could potentially exploit it by manipulating the query string of an HTTP request.

Improvement: When enabling an instrument as a survey or editing an existing survey's survey settings, it now displays a "Save Changes" button at the top of the page (next to the Cancel button) so that the user does not necessarily have to scroll all the way to the bottom to submit the page.

Change: PHP 5.5 is now the minimum required PHP ## Version. In previous ## Versions, the minimum required PHP ## Version was PHP 5.3. Change/improvement: When viewing a survey response on a data entry form that had been completed using the E-consent Framework, users with Record Locking privileges will now be able to Lock and E-sign the instrument. Previously in all ## Versions of REDCap ## Version 8.10.X, the entire instrument was read-only, including the Locking and E- signature options. (Ticket #54874)

Improvement: If a URL is included in a message posted on REDCap Messenger (including those sent via General Notifications from an administrator), the URL will be displayed as a clickable link to the user in the Messenger panel.

Change/improvement: The Custom Record Label and Secondary Unique Field values are now displayed with the record name in the table on the "PDF Survey Archive" tab in the File Repository if the "PDF Auto-Archiver" is enabled for one or more surveys in a project. In previous ## Versions, it did not display them next to the record name.

Change: For projects in production, the settings on the Record Locking Customization page can now be edited by any user that has "Record Locking Customization" privileges in the project. In previous ## Versions, only REDCap administrators could modify this page's settings while in production. This change will alleviate the burden of administrators for many production projects needing to make changes on this page.