REDCap Version 6.5.15 Vanderbilt to Release Oct. 6, 2015HSPH Upgrade Oct. 23, 2015

NEW FEATURES and IMPROVEMENTS:

REDCap Mobile App for iOS and Android - The REDCap mobile app is an app that can be installed on a tablet or mobile device so that data may then be collected in an offline fashion on that device, after which it may then be synced back to this project on the REDCap server. The app is most useful when data collection will be performed where there is no internet service (e.g., no WiFi or cellular service) or where there is unreliable internet service. Once a user is given 'REDCap Mobile App' privileges in a project, they can navigate to the mobile app page on the left-hand menu and set up the project inside the mobile app on their device. Once the mobile project is set up on the device, the user can collect data (which is stored locally on the device), and then at some point sync that data back to their project on the REDCap server.

Documentation: iOS app:   https://itunes.apple.com/us/app/redcap-mobile-app/id972760478 Android app:   https://play.google.com/store/apps/details?id=edu.vanderbilt.redcap About the REDCap Mobile App (PDF):   http://projectredcap.org/app/about.pdf Security in the REDCap Mobile App (PDF):   http://projectredcap.org/app/security.pdf

Before users can use the mobile app for a project, they must first be given "Mobile App" user privileges, after which they will be able to see the "REDCap Mobile App" link on the project's left-hand menu and then be able to access that page, which will provide links to download the Android and iOS app and instructions for initializing that project in the app on their mobile device. Note: When a user creates a new project, they will automatically be given "Mobile App" privileges by default.

There is an additional user privilege "Allow user to download data for all records to the app?" that specifically governs whether or not the user is allowed to download records from the server to the app. This may be done to prevent users from unwittingly (or wittingly) downloading lots of sensitive data to their mobile device. If a user is given this privilege, then when they initialize the project in the app and the project contains at least one record, then the app will prompt the user to choose if they wish to download all the records to the app or not.

Syncing data back to the REDCap server: When the user has collected some data in the app and now wishes to send the data back to the server, they will go to the "Send data to server" page in the app. If there are any possible issues that might arise when sending the data to the server, the app will prompt the user to make a decision before sending the data. For instance, if the project uses record auto-numbering, and a record already exists on the server with the same record name, then it will let the user know that it will rename the record accordingly during the sync process in order to prevent any overwriting of the record already on the server. There are many different scenarios that can occur in which a user might be prompted to make a decision, and the app is fully capable of providing the user with just the right amount of guidance so that they feel confident sending their data to the server with no issues.

Remote lockout: If a user sets up a REDCap project on the mobile app, and then another user revokes their "REDCap Mobile App" user privileges on the User Rights page in that project, then it will prevent them from accessing it on their mobile device by locking them out of that particular project. In this way, you may perform "remote lockout" to further protect data stored on mobile devices. Additionally, a user can revoke/delete their API token for the project, which will also cause a remote lockout, although the lockout will be permanent and will cause all data currently stored in the app to be lost.

o Copy Instrument - On the Online Designer, users can click the "Choose action" drop-down next to a given instrument to copy the instrument. They will be given the choice to name the new instrument and to also provide the suffix text that gets appended to each variable name to prevent duplication of variable names.

o Instrument ZIP Upload and External Instrument Libraries In the Online Designer, if a user clicks the "Choose action" button in the Instruction Actions

column and selects "Download Instrument ZIP", they can download a zip file of that data collection instrument, which also includes any attachment files for descriptive fields in the instrument. Using this feature makes it easy to share in individual instrument with colleagues or to keep for yourself if you want to re-use it and re-upload it into another REDCap project.

If user has obtained an instrument zip file from another project, from another user, from an institutional library of recommended zips, or from an External Instrument Library, they may upload the instrument on the Online Designer using the "Upload" button to add the instrument to the list of data collection instruments in the project.

External Instrument Libraries now exist in which REDCap users can navigate to an external website that can provide them with an instrument in the REDCap instrument zip format so that they can then take that zip file and upload the instrument into their REDCap project. It is somewhat similar to how the Shared Library works, except these external libraries are not associated with the REDCap consortium but are advertised as REDCap-friendly libraries or tools for creating instruments. The Online Designer contains a link to the current list of recommended external libraries where instrument zip files can be downloaded by users.

o Auto-scoring Instruments - A new class of instruments called "auto-scoring instruments" were recently added to the REDCap Shared Library. They cannot be used by previous REDCap versions but only by v6.5.0 and later. An auto-scoring instrument is a type of survey that contains scoring that is automatically performed and saved once the survey has been completed. Most of them are referred to as "short forms". An auto-scoring instrument is static (not adaptive), and can only be implemented in survey format as one question at a time. Similar to CATs (computer adaptive tests) downloaded from the Shared Library, users will not be able to modify any fields on the instrument at any time. This auto-scoring instrument can only be taken in survey form. If the data entry form is viewed for this instrument, all fields will be displayed as read-only. Also similar to CATs, auto-scoring instruments utilize the external CAT server hosted by Vanderbilt University. The external server provides the auto-scoring functionality once the survey has been completed. Users can find these auto-scoring instruments by searching the REDCap Shared Library.

o Field Annotation - Can be used to add explanatory notes or commentary about a given field. An annotation can be added to any field via the Online Designer or Data Dictionary (column R). It can be used for several purposes, such as for the bookkeeping of a project's field structure (as metadata about the given field) for reference purposes regarding what the field represents or how it should be used (during data entry, analysis, etc.). Field annotations are not displayed on any page but are merely for reference. Field annotations can also be used to map the field to various standards (e.g., CDISC, SNOMED, LOINC) using whatever notation the user sees fit (e.g., using a simple ID code for the standard or a complex XML structure containing information about how to transform the data to the standard). Since it is just an annotation for reference purposes, REDCap will not do anything with the field annotation text on its own, but the annotation can be obtained by users at any time for any purpose (typically accessed via the Data Dictionary download or via the API metadata export). Summarily, field annotations are essentially open-ended, so users may use them in whatever way they so choose.

o Project Notes - When creating a new project, users may optionally provide project notes, which are comments describing the project's use or purpose for documentation purposes. Once a project has been created, its project notes can be edited in the "Modify project title…" popup on the Project Setup page. Also, any projects having project notes will have a small icon displayed next to the project title on the My Projects page, and if a user moves their cursor over the project title, it will display the project notes in a hovering tooltip so that it can be quickly viewed. The project notes text can also be useful for other things, such as if someone is utilizing the Field Annotation attributes of fields in the project for standards

mapping, in which the project notes fields could be used as a way to store project-level metadata about how the Field Annotation is being used (e.g., what type of standard is being used).

o New delete buttons at the bottom of data entry forms allow users to delete all data on the current form of a given record and also (for longitudinal projects) to delete all data on the current event of a given record. The user must have "Delete records" user privileges in order for these buttons to be displayed and utilized.

o Improvement/change: Negative values can now be used as the raw coded values for checkbox fields with regard to their usage in data exports and data imports. In previous versions, negative values for checkbox choices would save successfully on surveys and data entry forms, but due to certain limitations, they would not work when importing values for those choices using the Data Import Tool or using the API data import. In the same regard, they would also cause problems when exporting data into a statistical analysis package. Now negative signs can be used for checkbox options, in which the negative sign will be replaced by an underscore in the export/import-specific version of the variable name (e.g., for a checkbox named "meds", its choices "2" and "-2" would export as the fields "meds_2" and "meds2", respectively).

o Improvement: Dots/periods are now allowed in the raw coded values of multiple choice fields (with the exception of checkbox fields). In previous versions, dots/periods were only allowed for non-checkbox multiple choice fields if the coded value was numeric, but now dots/periods can be used anytime (e.g., ".a", "b.3_e", "code...Code"). Checkbox fields still cannot have dots/periods due to technical limitations

o Improvement: When viewing a survey's Participant List or the Survey Invitation Log, if a participant's email or identifier was too long, it would get truncated and not be fully visible in the table. It now wraps the text to the next line for better viewing of the whole text.

The Survey Queue The Survey Queue displays a list of surveys to a participant all on a single page, in which the queue

comprises all surveys that are to be completed (like a "to-do" list) as well as the surveys that the participant has already completed.

Surveys can be set to appear in the Survey Queue based upon the following conditions: 1) if the participant has completed a particular survey, and/or 2) if certain conditions are met based upon data values (similar to branching logic).

If any surveys have been activated for the Survey Queue, they will be displayed to the participant after completing a survey (displayed below the survey acknowledgement text on the page). Using conditional logic in the Survey Queue can be very powerful because, similar to how one may use branching logic to show or hide certain questions, a user may use conditional logic in the Survey Queue to show or hide whole surveys. For example, if the first survey asks if the participant is male or female, the user may use conditional logic to display a survey specific to males versus displaying a survey specific to females.

To enable the Survey Queue for surveys in a REDCap project, navigate to the Online Designer where the user will see the Survey Queue button above their list of data collection instruments. If the Survey Queue is enabled in a project, a user can obtain the survey queue links for participants at the top of the data entry form when viewing a response and also as a new column in the Participant List.

To see a quick demo of the Survey Queue and how it can be used, follow this survey link: https://redcap.vanderbilt.edu/surveys/?s=RrbTNCiuQo

o Improvement: When exporting a survey's Participant List as a CSV file, it now includes the Survey Link for each participant in the downloaded file. And if the Survey Queue has been enabled in the project, it will additionally include the Survey Queue Link for each participant.

o Improvement: On the Copy Project page, users now have the option to copy all the settings for the Survey Queue and Automated Survey Invitations for that project.

o Change/improvement: In the Data Quality module, users may now use the Calculated field version of the "datediff" function in their rule logic. The "datediff" function for Calculated fields requires the date

format (e.g., ymd, mdy, dmy) as the fourth parameter. So if 'ymd', 'mdy', or 'dmy' is used as the fourth parameter in the "datediff" function in a Data Quality rule, it will then assume the fifth parameter to be the returnSignedValue.

o Auto-calculations - When performing a data import (via Data Import Tool or API), REDCap will now perform the calculations for any calculated fields that are triggered by the values being imported. For example, if you have a BMI field whose calculation is based off of a height field and a weight field, then if you perform a data import of height and weight values, it will automatically calculate the BMI for each record that is imported and also save those calculations (and thus log them too on the Logging page). Auto-calculations are now also triggered when using cross-form calculations in the case where the calculated field exists on a different instrument than the fields being entered that are used in the calculation. So while in previous versions users would have to go to the instrument where the calculated field existed and would have to click Save to store the calculation, users now no longer have to do that because the calculation is performed and saved automatically at the time when the trigger fields are initially entered or changed. So essentially, users never have to worry that calculations are not being performed or saved in certain situations. They should expect that calculations are now always being saved silently in the background.

o New feature: New data quality rule to fix all incorrect values for calculated fields - New Data Quality rule (rule H) will help users find and fix all incorrect values for calculated fields in a project. If any calc fields have ended up with incorrect values (whether due to field changes in the project or due to previous data imports), users can now run rule H not only to find any incorrect calculated values, but it will additionally display a button that, when clicked, will auto-fix ALL of them for the user. This is very powerful, and we have made it as easy as the single click of a button to fix all calculations in an entire project.

o New feature: Filter data quality rules by a specific record - In the Data Quality module, users can now choose to execute a data quality rule for only a specific record in the project (rather than for all records) by selecting the record from a drop-down list.

o Improvement: New log() function for logarithms has now been added as a new advanced function for calculating the logarithm of a number for a specified base. It can be used in calculations, report filtering logic, data quality rule logic, etc. For details, see the table of advanced functions at the bottom of the Help & FAQ page.

o Improvement/change: When a user is logging in to REDCap on a mobile device in which the page is a project URL (as opposed to logging in at the My Projects page), it now takes them to that project in the mobile web view rather than taking them to the mobile web view's My Projects page, which it did in previous versions. (The only exception for this is when a super user is logging in directly to a project's Project Modification module for viewing/approving production changes, in which case it will always take them to the desktop web view after logging in.) Additionally, when a user is on a mobile device and is viewing a project in the mobile web view, it now displays the "Desktop Site" button at the top right of the page to allow them to easily jump to the desktop web view for that project. Previous versions did not display this button.

o Survey Invitation Reminders - In addition to sending or scheduling survey invitations, users may now set reminders for a given invitation to help remind respondents that they need to complete a survey if it has not been completed by a specified time. A single reminder may be sent at an exact date/time, or a user may schedule up to 5 reminders to be sent according to a set time schedule, such as a recurring time lapse (e.g. every 12 hours after the original invitation) or on a recurring day/time (e.g., every day at 10:00AM after the original invitation; every Monday at 4:00PM). If the survey is completed, then any unsent reminders will be erased and will not be sent. Survey invitation reminders can be set in the Compose Survey Invitations popup on the Participant List page, as well as in the Automated Survey Invitations popup on the Online Designer.

o Survey Confirmation Email - On the Survey Settings page in the Online Designer, a survey administrator can now set up an email that will automatically be sent to the respondent when they complete the survey. They may optionally add one attachment to the email, if they wish. Also, piping can

be used in the email's subject and message to help personalize the email. If the respondent's email address is not on file and thus the confirmation email cannot be sent automatically, then when displaying the survey acknowledgement text at the end of survey, it will display an option for the respondent to enter their email address so that they may receive the confirmation email.

o New feature: The red Required field text (i.e., "*must provide value") can now be hidden on survey pages, if desired. So if you would rather your respondents not see that red text beneath all your required fields on the survey page, then you may use this setting to hide it. This setting can be found on the Survey Settings page in the Online Designer.

o New feature: The "Previous Page" button (i.e. Back button) on multi-page surveys can now be hidden, if desired. Hiding this button may be useful if you wish to prevent respondents from going back to previous pages in the survey. The setting to enable this can be found on the Survey Settings page in the Online Designer.

o Improvement: New survey option to display or hide the page number displayed at the top of the survey page. This option can be found under the "Question Display Format" section of the Survey Settings page in the Online Designer.

o Improvement: Inline image attachments for Descriptive fields now get displayed in the downloaded PDF of a survey or data entry form.

o Improvement: The project Logging page now has the ability to filter logged events within a specified range of time in which the user can provide a begin time, end time, or both a begin and end time to limit the results to a specific window of time.

o Improvement: Form labels can now contain two-byte unicode characters (e.g., Chinese, Japanese). This is true for the labels of forms as you see them displayed on the left-hand project menu, but the unique form name (column B in the data dictionary) must still be only numbers, underscores, and lower case Latin characters.

o Improvement: When entering data on a form or survey for an integer-validated Text field when using a mobile device (tablets included), it will display the device's number keypad instead of the default QWERTY keyboard in order to make data entry easier.

o New feature: In the Add/Edit Field popup on the Online Designer page, there is a new "Choose existing choices" link for multiple choice fields that will display a popup containing the options of all other multiple choice fields in the project to allow the user to quickly choose one set of options to use for a new field. This can make the process of creating fields quicker if there happen to be several fields that will have the same multiple choice options.

o Improvement: When viewing a REDCap page in the Mobile Safari browser on an iOS device, drop-down menus would appear as text fields on the page, which is the default style for Mobile Safari. This could be confusing to users or participants since you cannot tell that it is a drop-down until you tap it. The style of all drop-downs in Mobile Safari has been changes so that they are now displayed with a right-aligned triangle background image to make it more clear that they are drop-downs.

o New "Signature" field type - Allows a person to draw their signature on a survey or data entry form using a mouse, pen, or finger (depending on whether using a desktop computer or mobile device). Once captured, the signature will be displayed as an inline image on the survey page or data entry form. While this option appears as a "Signature" field type in the Online Designer, it is specified in the Data Dictionary as a "file" type field with validation type of "signature". Thus, it is essentially a special type of File Upload field. Note: The signature image for Signature fields cannot be imported via the API, although they can be downloaded or deleted via the API using the "Export a File" and "Delete a File" API methods, respectively.

New feature: Survey Access Code and Short Code for surveys When email is not an option, Survey Access Codes can be used to get a respondent started quickly on

a survey. They are especially useful if sending a survey invitation to a physical mailing address, or if the respondent is sitting nearby and needs to start the survey on another device.

There will be a Survey Access Code for every survey link in a project that utilzes surveys, so users will see a button or icon to retrieve a Survey Access Code on the Public Survey Link page, on the Participant List, and in the survey options at the top of data entry forms that are enabled as surveys.

To get a quick, temporary access code (just 5 characters long), there is an option to generate a Short Code to make it even faster to start a survey.

New feature: QR Code for surveys As an alternative to Survey Access Codes, users can get a respondent navigated to a survey page

quickly by using a QR code. If the respondent is physically nearby and has a QR code scanner app on their device, they can quickly scan the QR code for any survey link, which will immediately open the survey webpage on their device.

The QR code option is found alongside the Survey Access Code option on the Public Survey Link page, on the Participant List, and other places. If the user or respondent is familiar with using QR codes, QR codes make it very easy to quickly get to a survey page on another device.

New feature: Survey Login Survey administrators can now provide improved security their surveys with a survey login form, in

which respondents will be required to enter some login credentials in order to begin a survey or (if the "Save & Return Later" feature is enabled) to return to a previously entered survey response.

To enable the Survey Login feature, there is a new button at the top of the instrument list on the Online Designer that will open up the Survey Login settings popup. Users who wish to enable Survey Login may choose one, two, or three fields in their project to be used as the login credential fields for surveys in their project.

The Survey Login can be enabled for ALL surveys in a project or just selected surveys (in which it can be enabled for each on their Survey Settings page). There are also several other features to allow users to customize the behavior of the Survey Login feature.

Note: If a survey has the "Save & Return Later" feature enabled, Return Codes will not be used to return to the survey, but it will use the Survey Login's login credentials instead.

New feature: Ability for survey respondents to return and modify *completed* responses In previous versions, once a survey was fully completed, the respondent could not return to make any

further edits. (Although users could modify the response on a data entry form if they have appropriate user privileges, but the respondents could not make modifications *on the survey page*.) But now, this new survey option will allow respondents to return after they have fully completed the survey.

This feature can be enabled on the Survey Settings page under the "Save & Return Later" section for a given instrument in the Online Designer. Once enabled, a respondent will be able to return to their response and make any edits to it even if they have fully completed the survey.

As part of the "Save & Return Later" feature, respondents will need to provide a Return Code in order to make edits (as is the case in previous versions when returning to partially completed responses). When the feature is enabled, they will be given their Return Code when they finish the survey, after which they may return to that survey link at any time in the future to make edits to their response. If the Survey Login feature is enabled for the survey, then instead of using a Return Code, they will use their login credentials to return to the survey.

If enabled, participants who have completed the survey will still appear in the Participant List in the Compose Survey Invitations popup to allow them to be invited again to edit their completed response. Additionally, their survey link and survey access code will also remain in the Participant List for this same purpose.

Note: If Survey Notifications have been enabled for a survey that has the "Edit Completed Responses" option enabled, then whenever the respondent returns to the survey again and completes the survey again, it will again trigger the Survey Notifications to send an email to those users selected.

o Improvement: Data can now be piped into the URL when using the "Redirect to a URL" option for surveys. This allows users to pass along respondent-specific data in the URL when the respondent gets redirected to a webpage after completing a survey.

o Improvement: Data can now be piped into the "href" attribute of an HTML link. In previous versions, if this was attempted, it would not work and would instead create a malformed HTML link that was unusable.

New "Data Exports, Reports, and Stats" module - This single module now replaces the old Report Builder, reports, Data Export Tool, and Graphical Data View & Stats page, so that all their functionality now exist in this new module, including even more new features and functionality.

This new module allows users to create or edit reports, view reports, export all data in the project, export data for a given report, view the descriptive statistics and data plots for a given report, and perform other kinds of exports (e.g., PDF export of all records/all fields, ZIP file export of all uploaded files for all records). Please note that user privileges are applied appropriately throughout this module. For example, if a user has "No Access" data export rights, they will not be given any options to export data, and similarly if they do not have "Add/Edit Reports" privileges, then they will not be given the ability to create, edit, delete, copy, or reorder any reports on the page. Thus the things they are able to do and see in this module depends completely on what their user privileges are.

When performing a data export, users must now choose up front in which format they wish to export their data (e.g. Raw CSV, SPSS, R). This is different from the old Data Export Tool, in which you would choose the format/files *after* the export had completed.

Improvements when creating/editing reports: □ Each report now has its own user access setting so that users may choose specific users, User

Roles, and/or Data Access Groups that can view that specific report. If a user does not have access to a specific report, then that report will not appear on their left-hand menu in the project. Note: This user access setting does not alter in any way the user's ability to see certain data in the report. It merely gives them access to view the report as a whole, although their user rights might limit the data in the report that they are able to see. For example, if the user is in a DAG, they will only see records assigned to their DAG in the report. And if they do not have form-level access to certain instruments, then they will not be able to view data for fields from those instruments. Thus, reports will not allow users to view data to which they do not already have access.

□ "Limiters" in reports will now be called "filters" in version 6.0 and higher. □ Filters in a report now do not have to be included as a field in the report itself, and they can be

set up using complex AND/OR logic. There is even an advanced filter logic format that allows users to hand-type the logic to make it as complex as they wish if the simple format is not powerful enough for what they desire (similar to advanced branching logic syntax).

□ In the list of projects on the "Data Exports, Reports, and Stats" page, reports can now be easily reordered in a project using drag-n-drop functionality.

□ Fields included in a report can now be easily reordered within the report using drag-n-drop functionality.

□ The Data Access Group name and/or the survey identifier and survey timestamp fields can now be displayed in the report, which was not possible in previous versions.

□ All fields from a whole data collection instrument can be easily added at once to a report by selecting the instrument from a drop-down list. This makes it much faster to add a lot of fields to the report very quickly.

□ New "Additional Filters" section allows reports to be easily filtered so that they only return records assigned to specific Data Access Groups and/or data from specific events (in longitudinal projects) by allowing the user to select one or more DAGs and/or events from a multi-select drop-down list.

□ The data displayed in reports can now be ordered by third field, whereas previous versions only allowed sorting by two fields.

Improvement Reports: When building reports in a longitudinal project, Step 3 now contains a new checkbox option: "Show data for all events for each record returned". If this option is CHECKED, then *all* events are returned for each record, but if UNCHECKED, then some events in each record *may* get removed (depending on the filters defined in the report). This option provides users with more control when using report filters, in which it allows them to apply filters to return a group of records (e.g., a cohort) and then optionally filter those records returned even further, such as by removing specific events. This will make report filtering much more palatable for longitudinal projects.

Improvement: When building a report on the "Data Exports, Reports, and Stats" page, a new "Quick Add" button has been added to Step 2, in which it opens a popup window to allow users to select fields for the report very rapidly using the old-style checkboxes (similar to the Data Export Tool in REDCap version 5.X).

Improvement: On the "Data Exports, Reports, and Stats" page, users can now create a new report based on the custom selections made in Report B. This makes it much easier to create a report that includes all fields from many instruments and/or events.

Change: In previous versions, if a user was viewing a report that contained one or more fields that existed on a data collection instrument to which they did not have form-level privileges, then it would simply not show any of the report and display an error message. This was a bit heavy handed. It will now display the report for them, but for any fields that they do not have form-level access to, it will gray those columns out and not display their data. This is much better because it allows the users to view the data to which they do have access.

Change: When exporting the "Return Codes for Surveys" CSV file, which is available on the Additional Export Options tab when the project contains surveys that have the "Save & Return Later" feature enabled, the resulting CSV file no longer includes *all* fields from the project but instead only includes the following fields: Survey Identifier field, Survey Timestamp field for each survey, Survey Return Code field for each survey, Form Status field for each survey, Event Name (if project is longitudinal), and Data Access Group field (if project contains DAGs and the user downloading the file is *not* assigned to a DAG).

Improvement: Double Data Entry users will now be able to fully utilize the new "Data Exports, Reports, and Stats" module, whereas in previous versions, they were not able to access reports or the Data Export Tool. (Note: If data is exported, records will still end with --# in the resulting export file, but reports will display the records without the --# when viewing the report on the webpage in order to maintain consistency in the user interface.)

New user rights privilege for Data Export rights: "Remove all tagged Identifier fields" - If a user is given this data export privilege setting, then it will be applied to *all* data export files in all modules where data is exported (e.g., PDFs, reports, API). In reports and in API data exports, any fields that have been tagged as Identifier fields will simply be removed from the export file. However, in PDF exports, it will include the Identifier fields in the PDF, but it will remove and replace any saved data values with the text [*DATA REMOVED*] for such fields.

New features: New functions exist that can be used in logic for Report filtering, Survey Queue, Data Quality Module, and Automated Survey Invitations. Each of these are explained in detail at the bottom of the Help & FAQ page.

□ contains() - Does text contain another text string? □ not_contain() - Does text not contain another text string? □ starts_with() - Does text start with another text string? □ ends_with() - Does text end with another text string?

New additions to the API:

See API Help page for full details "Export PDF file of Data Collection Instruments" - Returns a PDF file of one or all instruments in the

project, either with no data (blank), with a single record's data, or with all records from the project. "Export a Survey Link for a Participant" - Returns a unique survey link (i.e., a URL) in plain text

format for a specified record and data collection instrument (and event, if longitudinal) in a project. "Export a Survey Queue Link for a Participant" - Returns a unique Survey Queue link (i.e., a URL) in

plain text format for the specified record in a project that is utilizing the Survey Queue feature. "Export a Survey Return Code for a Participant" - Returns a unique Return Code in plain text format

for a specified record and data collection instrument (and event, if longitudinal) in a project with surveys that are utilizing the "Save & Return Later" feature.

"Export a Survey Participant List" - Returns the list of all participants for a specific survey instrument (and for a specific event, if a longitudinal project).

"Export List of Export Field Names" - Returns a list of the export/import-specific version of field names for all fields (or for one field, if desired) in a project. This is mostly used for checkbox fields because during data exports and data imports, checkbox fields have a different variable name used than the exact one defined for them in the Online Designer and Data Dictionary, in which *each checkbox option* gets represented as its own export field name in the following format: field_name + triple underscore + converted coded value for the choice.

New "Export REDCap Version" API method - Returns the current REDCap version number as plain text (e.g., 4.13.18, 5.12.2, 6.0.0). Set the parameter content="version" in the API request, and it will return the REDCap version number.

New API method for exporting data: "Export Reports" - Any report created by a user can be exported via the API in JSON, XML, or CSV format. Needed for the API request is the report ID number, which is listed next to the report name on the "Data Exports, Reports, and Stats" page (only displayed there if the user has API Export privileges). In order to export a report via the API, the user must have been given access to that report, must not have "No Access" data export rights, and must have API Export rights. More details regarding the API Export Reports method can be found on the API Documentation page.

New optional parameter for API data exports: "rawOrLabelHeaders" parameter for "Export Records" and "Export Reports" API methods. Possible values: "raw" (default) or "label". Parameter is valid for "csv" format only (and only works for "flat" type output). Allows one to have the API return the CSV headers in the data export either as the variable/field names (rawOrLabelHeaders=raw, or if rawOrLabelHeaders is not specified) or instead as the field labels (rawOrLabelHeaders=label).

New API export optional parameter: "exportCheckboxLabels" parameter for "Export Records" and "Export Reports" API methods. Possible values: "true" or "false" (default). Parameter is only valid for "flat" type output. Allows one to set the format of checkbox field values when specifically exporting the data as labels (i.e., when rawOrLabel=true). When exporting labels, by default (without providing the exportCheckboxLabel flag or if exportCheckboxLabel=false), all checkboxes will either have a value "Checked" if they are checked or "Unchecked" if not checked. But if exportCheckboxLabel is set to true, it will instead export the checkbox value as the checkbox option's label (e.g., "Choice 1") if checked or it will be blank/empty (no value) if not checked.

API method "Export Project Information" - Exports some of the basic attributes of a given REDCap project, such as the project's title, if it is longitudinal, if surveys are enabled, the time the project was created and moved to production, etc. See the official API documention/help page in 6.5.0 for all the details.

Survey Invitation Log Improvement: The Survey Invitation Log has a different default display, in which it now defaults to

displaying all future invitations when the page is first loaded and displays all invitations by send time in ascending order. In previous versions, it displayed them in descending order by default, and also

displayed all invitations prior to 11:59pm of the current day. This should make it less confusing for users when they first load the page.

Improvement: The Survey Invitation Log now has two buttons ("View past invitations" and "View future invitations") at the top of the table on the page to allow users to quickly view past or future invitations without having to use the "begin time" or "end time" filter, which can be a bit more complicated.

o New feature: Users may now download CATs (computer adaptive tests) from the REDCap Shared Library. Over three dozen of these CATs have been added to the Shared Library, in which these include PROMIS instruments provided by the Assessment Center API software (  https://www.assessmentcenter.net/ ). Once downloaded from the Shared Library, CATs are rendered in REDCap as surveys that are displayed one question at a time. CATs are dynamic and adaptive, which means that the next question to be displayed in the CAT survey is decided upon by the previous answers in that survey, in which a third-party web service (hosted by a server at Vanderbilt University in a way similar to how the REDCap Shared Library is hosted) is utilized to provide this dynamic functionality seamlessly for the survey participant. For more information on PROMIS instruments, see http://www.nihpromis.org/.

o Improvement: The choice options for radio button fields and drop-down fields are now properly displayed as circles in PDF exports rather than as squares, which would often make it difficult to discern if a field was a checkbox or radio/drop-down when viewing the PDF.

o Improvement: Double Data Entry now works with the Scheduling module and also works with surveys that are initiated by clicking the link on a data entry form.

Data Resolution Workflow / Field Comments Improvement: Field Comments may now be edited and deleted. For all existing projects and all new

projects created, the ability to edit/delete a field comment will be enabled by default. If users do *not* wish to allow this functionality, they may disable it for the project in the Optional Customizations popup on the Project Setup page.

Improvement: For projects using the Data Resolution Workflow (data queries module), two new user privileges were added: 1) Open queries only, and 2) Open and respond to queries. In previous versions, if a person were given the ability to open queries, it also included their ability to close and respond to queries. These new user privileges allow users to just open or both open and respond to queries without having the ability to close them.

BUGS & OTHER CHANGES:

Major bug fix: When utilizing datediff() and some other advanced logic functions in the logic used in Data Quality rules, Automated Survey Invitations, Survey Queue, report filters, etc., it might mistakenly evaluate the logic as true when it should return false. This could cause Automated Survey Invitations to get sent prematurely or cause surveys to appear in the Survey Queue prematurely, among other things.

Improvement: When viewing reports in longitudinal projects, any fields displayed in the report that are not designated for that particular event (i.e., row in the report) will be grayed out to show that the field is not designated. This makes it easier for users to discern if a field's value is not applicable or if it is missing.

Change: Record auto-numbering is enabled by default for new projects that are created from scratch. Change: When creating Project Bookmarks in a project (or Custom Application Links in the Control Center),

the "Link URL / Destination" is no longer required to be full URL (beginning with "http") but can now be a relative link (i.e., beginning with "/") or can begin with another non-http protocol. This adds flexibility for users creating bookmarks.

Bug fix: When using the Data Comparison Tool for a project with Double Data Entry enabled, if the records entered by DDE person 1 and person 2 had a record name that was in a different case than the other in the pair, then it would mistakenly not allow the user to compare the pair of records nor merge them together.

Bug fix: When using the Scheduling module in a longitudinal project containing more than one arm, in which either the Custom Record Label or Secondary Unique Field is being used, then it would mistakenly display the Custom Record Label or Secondary Unique Field for only the records from the first arm. For all other arms, there would not be a value displayed for the Custom Record Label or Secondary Unique Field for a given record in that arm.

Change/bug fix: When editing the record ID field (i.e., first field in project) in the Online Designer when record auto-numbering has been enabled in the project, it would not allow you to set the validation as "Integer" even though "Integer" is technically a valid option when record auto-numbering is enabled. It will now allow you to set it as "Integer" but will display an error message if changed to any other validation type. In previous versions, the field validation for the record ID field could be changed via the data dictionary but not in the Online Designer.

Bug fix: For longitudinal projects that utilize surveys in which a survey is not designated for the first event in the project, when a user first navigates to the Participant List page (i.e., by clicking the "Participant List" tab), it would mistakenly not have the first option selected in the drop-down list of surveys in the Participant List. This might cause the user to think they are viewing the Participant List of a different survey if they are not paying close attention.

Improvement: It now does a better job of not removing "<>", "<=", or "<"+number in text, which in previous versions might mistakenly get removed on certain pages (e.g. field labels on forms/surveys) because they were assumed to be an illegal HTML tag.

Bug fix: On certain rare occasions, such as when a user is assigned to a Data Access Group and records have been created via a data import of only the record ID field and no other fields, the Record Status Dashboard might mistakenly not display all the records that it should on the page.

Bug fix: Any users that were suspended from the system but still had a user-level expiration date set would mistakenly receive an email warning letting them know that their account would expire soon, which is confusing because their account had already been suspended. It now no longer sends the expiration warning email to suspended users.

Change: The font size of some of the text on the main login form was increased. Bug fix: When adding new arms or renaming arms on the Define My Events page in a longitudinal project,

certain non-Latin (UTF-8) characters would not save correctly in the arm name, thus resulting in a black question mark symbol for that character.

Bug fix: When viewing a PDF export of a survey or data entry form in which non-Latin (UTF-8) characters are used in a Slider field's field label or in its slider labels, the text would not display correctly in the PDF.

Bug fix: When creating a new instrument from scratch in the Online Designer, if a new instrument's name is very close to an existing instrument's name, in which the name is also very long (>50 characters), then there is a chance that when the instrument is being created it will get stuck in an infinite loop and never actually create the instrument.

Change: The "Help & FAQ" page was updated. Change/improvement: When using the Scheduling module in a project with multiple arms, if a user chooses

to schedule an existing record by selecting the record from the drop-down on that page, it will now auto-select the arm in the arm drop-down based on the arm on which that record exists. If the record exists on multiple arms, it will auto-select the first arm on which it exists. This will prevent users from inadvertently scheduling a record on the wrong arm while also giving the user the flexibility to schedule the record on another arm, if they choose to do so, why changing the arm selection from the one that is auto-selected for them.

Change: When the recipient of a Send-It file loads the webpage to download their file, the password field now has the autocomplete="off" attribute to prevent web browsers from possibly auto-filling the password, if the browser had somehow stored it.

Bug fix: When using record auto-numbering in a longitudinal project, there is a chance that when two users are creating a record at the same time in which one user clicks the "Save and Continue" button on the form to create the record, they will mistakenly get locked out of that record until the other user saves their record and leaves the data entry form. It does not appear that data gets overwritten for the record nor that records get duplicated. It merely locks a user out of a record mistakenly when it should not.

Bug fix: The field validation type "Phone (U.S.)" was modified to be more inclusive of more area codes. Also, it was renamed to "Phone (North America)" since it actually applies to all of North America and not just the United States.

Change/improvement: When navigating to the Data Quality module in a project, the record drop-down list on that page now loads via AJAX after the page has been fully loaded. This makes the page load much faster for projects containing lots of records.

Change/improvement: The Stata syntax file that is produced during data exports now explicitly defines the minimum version as Stata 12. This reduces the number of issues that might occur when loading REDCap data into Stata by setting the first line of the syntax file as "version 12".

Bug fix: When a user that is assigned to a Data Access Group is accessing a longitudinal project via the mobile web view, it would mistakenly display all the records for the project in the record drop-down list on the page when instead it should only display the records belonging to the user's DAG. If the user clicked any records not in their DAG, it would not allow them to access them, as expected.

Change: When uploading a data dictionary containing a Text field with a min or max validation range in which the validation type of the field is a "number_Xdp" validation, it will accept values for the min or max if it is a number even though it does not follow the validation rule explicitly (e.g., it will allow a min of 5.6 even though the validation requires 3 decimal places). This is done because Microsoft Excel often removes any trailing zeros after decimals when opening the data dictionary and re-saving it. So this serves as a workaround for Excel's undesirable behavior without compromising anything with regard to data quality.

Bug fix: The "email" field validation type was modified to be more inclusive so that it now allows for plus signs (+) in email addresses, which is allowable for certain email services.

Bug fix: Some language was mistakenly not abstracted (i.e., was hard-coded in English) in the "Return Code" popup on a survey's "Save & Return Later" page.

Bug fix: The JavaScript functions that enable Slider fields and reset their value were mistakenly employing branching logic prior to calculations when it should have been performing calculations first for calc fields.

Change: When the API crashes due to exceeding web server memory during a data export or import, it now returns a 500 error code with the message "REDCap ran out of server memory. The request cannot be processed. Please try importing/exporting a smaller amount of data." In previous versions, it would return different status codes, which could be confusing and not helpful for the user to troubleshoot the situation.

Change: The file_import.php file inside the API Example ZIP file was updated to work with PHP 5.5.0 and higher.

Bug fix: When a Table-based user resets their own password and is setting a new one, in which they attempt to enter a password that has fewer than 9 characters, which is the minimum, it displays an error message that mistakenly says it must be "10 characters" at minimum when it should instead say "9 characters".

Bug fix: If the Participant List for a survey contains more than 50 participants, and a user goes to remove a participant, then after removing the participant, it would mistakenly reset the list back to the first page of participants rather than keeping it on the current page of participants. This would make it very difficult to remove many participants in some cases.

Change: The API method "Export Users" will now return two new attributes for each user: "mobile_app" and "mobile_app_download_data". If mobile_app's value is "1", then the user has privileges to use the REDCap Mobile App for that project. If "0", then not. If mobile_app_download_data's value is "1", then the user has the ability to download all records from the project to the mobile app, but if "0", then the user will not have the option in the app to download any records to the app.

Improvement/bug fix: If a survey's title is blank (has no text), then the row for this survey in the Survey Queue would show up as blank, which could be confusing to participants. This also occurs when in the

Automated Survey Invitation setup popup, in which the survey's option shows up as blank in the drop-down list of surveys. In these cases, it now displays the instrument name in place of the title if the title is blank.

Change: Replaced the "Detailed Overview" video Bug fix: When importing a file via the API File Import method for a longitudinal project in which the event

to which the file is being imported does not yet have any data, although the record does exist, it would mistakenly give the error message "The record 'XX' does not exist. It must exist to upload a file", which is not true. This error would prevent the file from being uploaded.

Major bug fix: If a survey respondent completes the last page of a multi-page public survey and then they click the Back button in their browser and then reload the survey page, it would mistakenly allow them to re-submit their survey results and even change some survey responses after having completed the survey already. This does not apply to one-page surveys and does not apply to unique survey links.

Bug fix: In a longitudinal project, if Automated Survey Invitations are set up for surveys not on the first event, and then the project is converted back to a non-longitudinal project, it would mistakenly schedule and send invitations for those events that are now orphaned and no longer utilized in the classic project.

Bug fix: If a project has surveys enabled and has an active survey in which participants have already received a survey link to take the survey, then if a user in the project disables surveys in the project via the "Main project settings" section on the Project Setup page, the surveys will mistakenly still load and function normally for participants when instead they should display an error message that the survey is not active.

Change: The "Export PDF" API method's optional parameter "allrecords" has been changed to "allRecords" to be more consistent with API parameter naming conventions. Note: To be backward compatible, the older version "allrecords" will still work the same as before if it is used.

Change: If a project contained only one data collection instrument, then a user would mistakenly be able to delete the instrument on the Online Designer. It now prevents the user from deleting the only instrument but instead recommends that they add a new instrument and then delete the old one.

Bug fix: When sending a survey invitation that utilizes piping in the content of the email (when sending the invitation from the Participant List, Automated Survey Invitation, or top of data entry form), then if the user later went to the Participant List to compose another invitation and clicked the "load message box with text from a previous email?" option, it would mistakenly include some HTML "span" tags around the piped data value when loading in the message from that previous email.

Bug fix: When using the "user" drop-down filter on the Field Comment Log page in a project, it would mistakenly not filter properly by user if the user's username for their user account was in a different case than how their username appears in the drop-down list.

Bug fix: In a longitudinal project when using cross-event logic in report filters, Data Quality rules, Survey Queue logic, Automated Survey Invitations, etc., the logic might mistakenly not get evaluated correctly. This occurs on certain occasions where all the fields used in the logic do not have a value (i.e., they are blank) for a certain event for a given record, even though that particular event has had some data entered (i.e., data entered for other fields not used in the logic). This would cause it to think that that event has no data and thus prevent the logic from getting evaluated correctly.

Bug fix: When exporting data to SAS, the SAS syntax file produced will no longer remove apostrophes contained in the option labels of multiple choice fields but instead will escape them as a double apostrophe. This allows for a more proper viewing of the option labels in SAS.

Bug fix: If using cross-event logic for a calculated field in a longitudinal project that contains more than one arm, the auto-calculations that get triggered each time a form/survey is saved or when a data import is performed would mistakenly cause that record to get created in the other arm that is referenced in the cross-event calculation if the record does not already exist in the other arm.

Change: Choices for multiple choice fields are now allowed to have a blank option label. In previous versions, choices with no option label would be automatically removed unless "&nbsp;" was used as the option label.

Bug fix: When saving a Signature field or uploading a file for a File Upload field for an existing record in a project, it was mistakenly not displaying the document ID number (corresponding to the primary key of a database table) on the Logging page as the value of that field. This was inconsistent with how it was

displayed on the Logging page when saving a Signature field or uploading a file for a File Upload field for record that was being created.

Bug fix: The "Close survey" button that is displayed at the top of a completed survey was mistakenly not closing the tab/window in certain web browsers. Note: There are some cases where the window/tab simply cannot be closed if the window was opened with the survey as the first tab in the window (due to restrictions by the web browser itself), in which case it will instead revert to displaying a blank web page instead.

Major bug fix (post-release patch): If a user is sending a survey invitation to a participant by using the Compose Survey Invitation option at the top of a data entry form, in which they choose to enter a new email address rather than using the email address that originates from either the Participant List or the Designated Survey Email Field, then it will mistakenly not send the invitation to the new email address specified but instead to the one from the Participant List or the Designated Survey Email Field.

Major bug fix: The advanced functions sum(), median(), and stdev() would mistakenly return a "0" value (instead of a blank/null value) from an auto-calculation after saving a calculated field using those functions where all the field values that were passed into those functions were blank/missing values.

Bug fix: The Data Dictionary Codebook page would mistakenly display stop actions for choices on multiple choice survey fields even if those choices had been deleted.

Change: Added a couple new paragraphs of helpful text on the Plugin FAQ page on the Plugin & Hook Documentation page.

Bug fix: When a calculated field in a longitudinal project is utilizing a Cross-Form or Cross-Event calculation, then if the user clicks the "Save and go to Next Form" button on the data entry page, it might on certain occasions mistakenly take them to another event for that record when instead it should take them to the next instrument in the same event.

Bug fix: If an M-D-Y or D-M-Y formatted date or date/time field is set as the Secondary Unique Field in a project, then the check to prevent unique values for that field would fail whenever a duplicate value was entered on a survey or data entry form.

Bug fix: If a field has been given the validation "Number (X decimal place - comma as decimal)" with either a minimum or maximum range value defined, then it would mistakenly always display the range check error on a survey or data entry form whenever a valid value was entered into that field.

Bug fix: If a Text field has field validation with either a minimum or maximum range value defined, then if a user is in the Online Designer and changes the validation to another validation type that cannot utilize the min/max range check (thus hiding the min/max input fields in the popup), then it would mistakenly retain the min/max values and save them, which could cause the "out of range" error to popup mistakenly during data entry.

Improvement: When uploading a data dictionary that contains a field with a minimum and/or maximum validation value, it now checks to make sure that the min/max value is in the correct format for that field's particular validation type. Previous versions did not check the format of the min/max values.

Major bug fix: At the top of data entry forms, it would mistakenly display the two PDF export choices for downloading PDFs containing data even if the user had "No Access" data export privileges. This would mistakenly allow the user to export data in a PDF file even though they do not have privileges to be exporting data. It now does not allow them to export data in PDFs unless the user has data export privileges of some kind, and it also no longer displays those two options at the top of the page to download PDFs containing data. In spite of this, users will still be able to download blank PDFs (i.e. with no data).

Bug fix: When a user is downloading a PDF file (either blank or containing data) at the top of a data entry form, it would mistakenly remove any data collection instruments from the PDF that the user does not have access to on the web interface (i.e. if they do not have instrument-level privileges to an instrument). Since instrument-level privileges only apply to viewing web pages in the web interface, it should not have been removing any instruments from an export file, such as PDF files. Thus, in order to be consistent with how user rights are implemented throughout the rest of REDCap, users will no longer have any instruments removed from the PDF exports due to their instrument-level privileges.

Bug fix: When a user is downloading a PDF containing data at the top of a data entry form when the user's data export privileges is "De-Identified" or "Remove all tagged Identifier fields", it would mistakenly hash

the record ID value in the PDF for the first field in the first instrument. It would, however, not do this when displaying the record ID value in the top right corner of the PDF. This bug is only seen when the first instrument is included in the PDF.

Bug fix: In a project with Double Data Entry enabled, calculated fields would mistakenly get displayed on the page where values are merged from the two records. It now no longer displays calc fields on the merge page, and it now also performs an auto-calculation after the merge takes place in order for all calc field values to be correct for the newly created record.

Bug fix: In a project with Double Data Entry enabled, if the user was merging two records on the Data Comparison Tool page, in which one of the fields was a Text field whose value contained an apostrophe, then when the user chose the value from the first or second value, it would throw a JavaScript error and thus would mistakenly not merge that value into the newly created record.

Bug fix: When using the designated survey email field in a project in which an email address was first entered into the Participant List and then a different email address was entered for the designated survey email field for that same record, then the Participant List would mistakenly display the original email address entered into the list when instead it should have displayed the email address from designated survey email field's value.

Bug fix: If a multi-page survey is being administered in a longitudinal project, in which *all* fields on a given page in the survey contain branching logic that explicitly references fields on other events, then if any of those events referenced in the logic do not have any data saved for them yet for that record (i.e., those events do not show up in reports or exports for that record), then the branching logic might mistakenly return a FALSE value when it should evaluate as TRUE. The overall effect of this is that it could cause entire pages to be skipped in the survey mistakenly when viewing the survey in multi-page mode.

Bug fix: When a datediff() function is used inside the equation of a calculated field, in which a literal date or date/time value (as opposed to a variable name or "today" - e.g., "01-01-1970") exists as the first parameter, the second parameter, or both the first and second parameters in the function, then if the date format parameter is either "mdy" or "dmy", the auto-calculation that is performed when the record is saved will actually result in a different value than the one displayed on the form/survey prior to the save.

Major bug fix: If the advanced functions "isnumber" and "isinteger" were used in branching logic or a calculation for a calc field, it would mistakenly display an error on a survey or data entry form and thus not execute successfully.

Change: The Help & FAQ page was updated with minor changes. Bug fix: If the Secondary Unique Field or Custom Record Label is enabled in a project, then they would not

display correctly on a report in a classic project or in a longitudinal project that contained only one arm. Bug emerged in version 6.3.0.

Major bug fix: In certain specific situations where calculated fields are used, in which a user is importing data via Data Import Tool or API or is saving data on a survey or data entry form, the Auto-Calculation feature would mistakenly go into a very long loop (or sometimes an infinite loop) and would take many minutes to actually save all the data and finish.

Major bug fix: If a user was uploading a data dictionary with branching logic or a calculated field's equation that was malformated in a certain way, or if a user was attempting to add such logic/calculation to a field in the Online Designer, then it would mistakenly go into an infinite loop and never fully process the action. Bug emerged in version 6.3.0.

Bug fix: If a user downloads an instrument from the Shared Library and then later attempts to download another instrument that is similarly named for that same project, then on certain occasions REDCap will mistakenly go into an infinite loop and will not be able to successfully add that new instrument to the project.

Change: Some outdated language on the longitudinal event grid was updated. Change: The form status icons that appear on the Record Status Dashboard, left-hand project menu, and

longitudinal event grid now behave slightly differently for the gray status icons. The gray icons denote that no data has been entered on the data collection instrument, but due to the new auto-calculation feature in 6.3.0, calculated values can get stored on other forms even though a user has never navigated to that form. This could cause confusion if the icon is red when no one has ever entered the form. So now calc fields are

excluded when determining if an icon should be gray. This allows the behavior of the colored icons to remain the same as it did in prior versions with regard to user experience and workflow.

Change: Changed the language and added a detailed explanation in the User Access section on the Create New Report page that more clearly explains how a report's user access controls work and how they are different from a user's user rights.

Change: The disclaimer text for calculated fields that was displayed on data entry forms, on the Online Designer, and on the Data Dictionary Upload page has been removed from those pages due to the introduction of newer features (e.g. the auto-calculation feature and Data Quality rule H) and is additionally due to a general ideological softening of extreme prejudice against calc fields by the REDCap development team.

Change: When new Table-based users have their account created, in which an account expiration date is set, in addition to listing the date/time of expiration in the email text, it now also specifies how many days from now that will be. This provides greater clarity of when the expiration will occur for some users.

Change: When a user receives an email letting them know that their REDCap account will expire soon, the following text has been added to the email to explain why their account will expire: "Your account has been set to expire because a REDCap administrator has chosen this date as the expiration date for your account."

Improvement/change: A "print page" button was added to the top of the User Access Dashboard page to allow users to print the page in order to review it offline.

Bug fix: When viewing a report containing over 1000 rows, in which it displays the "displaying record" drop-down to allow paging, then in some particular cases it would mistakenly not load the desired page of the report after being selected due to a JavaScript error.

Bug fix: Users whose username contains only numbers would mistakenly not be able to be assigned to Data Access Groups.

Bug fix: When clicking the Add Signature link or Upload Document link in order to capture a signature or upload a file on a form or survey, respectively, it would mistakenly not employ piping in the field's label when displaying it in the popup that appears.

Bug fix: When using a numerical field validation where a comma is used as the decimal character, the Add/Edit Field popup on the Online Designer would mistakenly not display the min and max text fields to allow one to enter range values for the field.

Bug fix: If a checkbox field has an option label that contains a double quote, then it would prevent that field from being displayed on the Stats & Charts page of a report and would thus cause all other charts below it not to display as well.

Bug fix: For a longitudinal project containing more than one arm, in which either the Custom Record Label or Secondary Unique Field is enabled, it would mistakenly only display the Custom Record Label and/or Secondary Unique Field that belongs to the first arm when viewing a report, and if the record did not exist in the first arm but did exist in another arm, then the label would not display at all in the report. It now displays the label that belongs to the current arm for the row of data being displayed in the report. Also, in this case, the Record Status Dashboard would mistakenly display the Custom Record Label and/or Secondary Unique Field for only one of the arms (often the last arm containing data for the label) even when the record existed on multiple arms. It now displays the label for every arm for a given record on the Record Status Dashboard.

Major bug fix: When a user is viewing a partially completed or fully completed survey response on a data entry form, it would mistakenly display the Save buttons at the top right of the page even if the user did not have "Edit survey response" user privileges. This would not allow the user to modify any responses on the form because all the fields would remain locked and read-only, but if they clicked one of those Save buttons, it would inadvertently cause some of the data values on that page to get erased.

Change/improvement: Small improvements to speed up the sending of survey invitations when sending large batches (i.e., thousands) of invitations all near the same time.

Bug fix: When uploading a file for a File Upload field on a data entry form on an iOS device, it would not upload successfully but instead return an error message. This would not occur on survey pages but only on forms.

Bug fix: When using the Real Time Execution aspect of a custom Data Quality rule in a longitudinal project, then when a rule violation occurs on a data entry form, in which one of the fields in the rule's logic occurs on that instrument but on a different event, it would mistakenly make the data value into a clickable link in the violation popup. And when that link is then clicked, it puts focus on that field on the current instrument, which can be confusing because it really refers to a different event. It now only makes the data value into a clickable link in the violation popup if the field exists on that instrument on that same event.

Major bug fix: When using the datediff() function inside branching logic, calc fields, Data Quality rules, Automated Survey Invitations, etc., it would not work correctly if "TODAY" was used in capitalized form inside quotes (single or double quotes) for either of the two date parameters in the function. It would work, however, if not surrounded by quotes (in either upper case or lower case) and also if lower case surrounded by quotes.

Major bug fix: When using the datediff() function inside branching logic, calc fields, Data Quality rules, Automated Survey Invitations, etc., it would not work correctly if "today" (in upper or lower case, either surrounded by quotes or not) was used as the second date parameter when the first date parameter in the function is today's date as a literal value (e.g., "2014-11-18").

Bug fix: On the "Stats & Charts" page, the descriptive stats for "counts/frequency" would mistakenly display as "0, 0.0%" for any choices of a multiple choice field where the choice's coded value was non-numeric.

Bug fix: When importing XML data in an API data import request when the XML data is not formatted correctly, it could sometimes throw a fatal PHP error, thus mistakenly returning a HTTP 500 or 200 error rather than a 400 error with an appropriate error message.

Bug fix: When creating or editing a report that contains an "SQL" type field as a filter in the report, it would mistakenly not display a drop-down of the SQL field's choices after choosing it as a filter but instead would just display a text box for entering the filter value. It now displays a drop-down with the field's choices.

Bug fix: When a user in a project has no access to any of the data collection instruments, it would still mistakenly display the "Add/Edit Records" link on the left-hand menu, and whenever they clicked that link, it would mistakenly take them outside the project to REDCap's Home page. It now no longer displays that link on the left-hand menu if they do not have access to any instruments.

Bug fix: If a user in a project has no access to the first data collection instrument, then it should display "View/Edit Records" for the link text on the left-hand menu, but instead it mistakenly displays the link text as "Add/Edit Records" if the user has "Record Create" rights but has no rights to the first instrument, which is the only place a record can be created in the web interface.

Bug fix: When sending a survey invitation from a data entry form using the "Survey options"->"Compose survey invitation" popup and manually providing an email address in the text box even though one or more existing email addresses are displayed as a drop-down choice in the popup, it would mistakenly not send the invitation to the email address that was manually entered but would instead send it to the email address originating from either the Participant List or (if applicable) designated survey invitation field.

Bug fix: When viewing the participant list of an initial survey (i.e., first instrument), the "Remove all participants" button was mistakenly removing participants who had already completed the survey (partially or in whole), which could incidentally cause some "ghost" participants to appear in the list afterward and cause confusion. It should only be removing participants that have not started the survey yet and thus do not have a corresponding record in the project.

Bug fix: If a project contains a field with the variable name "page", then if a user is viewing a survey response on the data entry form and clicks the "Edit response" button at the top, it will take them to a non-existent page (i.e. a 404 error).

Bug fix: If a user with "Full Data Set" data export privileges performs a data export on the "Data Exports, Reports, and Stats" page and checks the "Hash the Record ID field" checkbox option, it would mistakenly not hash the Record ID unless the Record ID field had been tagged as an Identifier field. In this case, it should always hash the Record ID if the checkbox is checked when the user has "Full Data Set" data export privileges.

Bug fix: When executing rules on the Data Quality page when the project contains data access groups, if a user excluded a particular discrepancy that was returned from one of the rules, it would mistakenly not

deduct that excluded discrepancy from the DAG discrepancy counts when the rules were executed again (although the total discrepancy count would be accurate).

Bug fix: In very rare instances where Field Labels with special characters (e.g. non-Latin, UTF-8 encoded) are being displayed on certain pages, the Field Label's text might mistakenly not display on the page at all but appear as blank.

Major bug fix: When using Automated Survey Invitations to send survey invitations, if the ASI's "Conditions" section only uses the conditional logic option and does not use the "when the following survey is completed" option, then on certain occasions invitations might be mistakenly re-sent to respondents even though they had already completed that survey, which would result in a "survey has already been completed" message when the respondent clicks the survey link in the invitation.

Change: When uploading a file for a File Upload field on a survey or data entry form, it now auto-closes the popup after a couple seconds as a convenience. It does this also when deleting a file for a File Upload field.

Change: In reports, any headers (i.e. field labels) that are over 100 characters long will be truncated to prevent the header row from getting too tall.

Change: Small aesthetic changes to the look and behavior of the Compose Survey Invitations popup on the Participant List page.

Major bug fix: If a user has user privileges of either "De-identified" or "Remove all tagged Identifier fields" as their data export rights, then when using the "Export Records" API method, in which no fields are explicitly provided in the API request, then it will mistakenly not perform the de-identification process or remove Identifier fields as is dictated by their user rights. However, in this situation, if instead some fields are manually provided as an array in the API request, this issue does not occur.

Major bug fix: When a user with "De-identified" data export rights performs a data export on the "Data Exports, Reports, and Stats" page, it would mistakenly hash the Record ID in the resulting CSV data file, even though the Record ID field is not an Identifier field. It should only do this when the Record ID field is an Identifier.

Bug fix: If Automated Survey Invitations are enabled for surveys in a project, and a survey invitation has been scheduled to send but has not sent yet, then if a user clicks the "Save and Mark Response as Complete" button on the data entry form, it mistakenly does not prevent the scheduled survey invitation from sending later on, even though the survey has already been completed. So the respondent will mistakenly receive the invitation to their survey that has already been completed. If the survey is completed on the survey page itself (rather than on the data entry form), then this issue does not occur.

Bug fix: If the designated survey email field was enabled in a project that uses surveys, then it would mistakenly allow the user to edit the email address in the Participant List of an initial survey when the email address displayed in the list originated from the designated survey email field. In this case, the email address should only be modifiable on the data entry form to which it belongs.

Bug fix: When adding a new field on the Online Designer, if the "Descriptive" field type had been selected in the drop-down list in the "Add New Field" popup window, after which the user saved or canceled that popup, then before leaving the page if the user clicked the "Add Field" button immediately afterward to re-open the popup window, it would mistakenly display the Required, Identifier, Custom Alignment, and Field Note sections. In this case, it should instead be hiding those sections in the popup since they do not apply to Descriptive fields.

Major bug fix: If using the "Export Records" API method, it sometimes would not hash the record name in the exported data set when it should if the user whose API token is being used has "De-identified" or "Remove all tagged Identifier fields" user privileges. If the user has "De-identified" rights, it would mistakenly hash the record name in all cases every time, regardless of whether or not the record ID field is an Identifier field. Also, if the user has "Remove all tagged Identifier fields" rights, it would mistakenly never hash the record name, even when the record ID field is an Identifier field. It now correctly hashes the record name if the record ID field is an Identifier field AND if the user has either "De-identified" or "Remove all tagged Identifier fields" user privileges.

Major bug fix: The "simultaneous users" check that prevents two different users from viewing the same record/instrument/event in the same project would not successfully stop a user from viewing the data entry

form if they had been assigned to a user role, but *prior* to being assigned to the role, the user had either No Access or Read-Only user privileges for that instrument. This issue would not occur if the user possessed Edit user privileges for that instrument prior to being assigned to the role.

Bug fix: If a project is using the Custom Record Label, but it has been set up incorrectly in which no variable names are including in the custom record label at all, then it could cause some pages to crash (e.g., data entry page, record status dashboard) if a large amount of records exist in the project.

Bug fix: When viewing the Participant List in a project containing surveys, in certain situations it would mistakenly allow the user to remove a participant from the list even when the record exists. It should only let users remove it if the record does not exist yet. Also, it would mistakenly allow users to edit a participant's email address even if the email was missing and thus displayed the text "[No email listed]". In this case, it should not allow anyone to edit the email address since it is assumed to be pulling the email address from the designated survey email field.

Bug fix: When adding/editing a report that contains hundreds of fields, especially when the project itself contains hundreds or thousands of fields, the page may load very slowly or may not load completely at all.

Bug fix: When viewing the Participant List in a project containing multiple surveys while utilizing the "designated email field for survey invitations" feature, it would mistakenly not allow the user to click the checkmark icon in the "Responded?" column in order to navigate to the record on the data entry form (assuming the response is either partially completed or fully completed). This issue only occurs for the first instrument in the Participant List.

Major bug fix: The Survey Login feature was mistakenly being case sensitive with regard to the respondent's login credentials entered on the survey when it should instead have been case insensitive.

Major bug fix: If Data Access Groups are being used in a classic project (excludes longitudinal projects) when a given DAG does not contain any records yet, if a user assigned to that DAG navigates to the Add/Edit Records page, then the user will mistakenly see a list of ALL records in the project from all DAGs rather than an empty drop-down list. If they attempt to view a record in the list that is not in their DAG, they will not be able to access or view any data from it, but it could be confusing as to why records from other DAGs have their record names displayed. This bug would only cause data access issues if the record ID field for the project is an identifier field (i.e. PHI), which is always discouraged.

Bug fix: Some computers/networks were forcing Internet Explorer to always use Compatibility Mode when viewing REDCap, which would cause some functionality not to work properly. REDCap now disables Compatibility Mode in Internet Explorer to prevent such issues.

Improvement: When a user exports an instrument as a PDF file, it now displays the current date/time at the bottom left of each page in the PDF representing when the file was downloaded.

Improvement: The text boxes for Text field types are now 50% wider as displayed on data entry forms and surveys to allow for more text to be seen.

Major bug fix: When creating a new record in the Scheduling module in a longitudinal project, it would mistakenly allow users to add records whose record name began or ended with spaces, which causes various issues in other modules. It now trims the record name (client-side and server-side) when scheduling a new record.

Bug fix: In certain cases, the form name and form label of an instrument can get inadvertently lost, which either causes the instrument to become invisible and inaccessible or it causes the form label to be replace with an "[X]". It now does a better job of recovering the form name or label if it somehow gets lost.

Bug fix: In the user/role list displayed on the User Rights page, it would sometimes mistakenly show a user as not being suspended when in fact their account had been suspended. This would occur due to case sensitivity mismatching of their username as recorded for their REDCap user account compared to their username when it was added to the project's User Rights page.

Bug fix: When using piping when doing the Post Pre-fill method to pre-fill survey questions (documented on the "How to pre-fill survey questions" section of the Help & FAQ page), the piping would mistakenly not work when the survey page loaded.

Bug fix: When adding a new field to a data collection instrument on the Online Designer when the project is in production status and in Draft Mode, if the new field is added as the first field in the instrument, it will

mistakenly cause the instrument name (which is displayed on the left-hand project menu and in the Online Designer list) to get removed and thus end up as "[ ? ]" if that instrument does not exist in the project yet but only exists in Draft Mode.

Major bug fix: When a respondent returns to a survey to enter their Return Code, it might take an extremely long time before it would display their survey after entering a valid Return Code.

Bug fix: When viewing the Survey Invitation Log in a project containing surveys, in the "Invitation send time" column it might mistakenly display the time that the email was scheduled to send rather than the time the email actually got sent, in which these two times might be slightly different due to various valid reasons.

Bug fix: If a date or date/time field is chosen as the Secondary Unique Field in a project, it would mistakenly display the value of the Secondary Unique Field in Y-M-D date format on the page even if that field had been designated to display as M-D-Y or D-M-Y format. It now displays its value according to its designated date format.

Bug fix: When using a Custom Record Label and/or Secondary Unique Field in a longitudinal project, it would mistakenly not display those values for a given record in the record drop-down list in the mobile web view of the project. For classic projects, however, it would correctly display the Custom Record Label and/or Secondary Unique Field in the mobile web view.

Bug fix: If a date or datetime field is used as a filter in a report and the value of that filter field is left blank/empty, then it would not return the correct results in the report. And if the report were edited, the value of the date/time filter in the report would mistakenly appear as "0000-00-00", which might accidentally get saved when the report is re-saved.

Bug fix: If survey responses are collected using a Public Survey link and the designated email field is enabled but is left blank (thus no email address was entered for the person), then that survey will have an incorrect number of participants listed at the top of its Participant List, in which it is mistakenly including all the responses with no email addresses even though it is not displaying them on the page. This can cause confusion if the user tries to navigate to the last page of the Participant List (if there are many participants), in which the Participant List will show up as empty for those latter pages.

Bug fix: When importing XML-formatted data via the API data import, it would mistakenly truncate any text being imported if the text contained an ampersand (even if the ampersand was properly escaped in the XML). Note: This only occurs when the text is not put inside a CDATA block in the XML.

Bug fix: When creating a new record on a data entry form, the "download PDF" option to download "this data entry form with saved data" would mistakenly be displayed even though the record does not exist yet. And if the user clicked that option, it would result in a completely blank PDF file.

Bug fix: If the HTML character code for non-breaking spaces (&nbsp;) is included in the field label, field note, section header, or multiple choice label of a field, then a PDF export of the instrument containing that field will mistakenly display the HTMl character code as-is in the PDF rather than rendering it properly as a space in the PDF.

Change: Email addresses in the Participant List now order correctly as case insensitive natural ordering. In previous versions, they ordered as case sensitive natural ordering.

Bug fix: When using the Randomization module and performing the randomization of a record, if the "Randomize" button in the popup window is clicked rapidly several times, it might allow the request to be sent multiple times, which could cause issues.

Bug fix: If REDCap was in the process of being upgraded to a newer version, in which the new REDCap version directory had been moved to the web server prior to the upgrade SQL script being executed, then users making API requests might have their results returned from the API as a doubled response, where it would return the expected API response concatenated with itself.

Bug fix: When attempting to import data via the API Import Records method, in which one or more of the import fields is a Descriptive field, which cannot have data, it was mistakenly not returning an error message in this instance and would mistakenly add the data to the redcap_data table as orphaned data, although this does not affect anything ultimately. It now returns an error message and halts the import if a Descriptive field is included in the imported data.

Change: The Participant List for initial surveys now displays all responses that have been created - either partial or fully completed - including those initially created via a Public Survey link. In previous versions, those responses that were not created via the Participant List were not displayed for initial surveys, although they would appear in the Participant List of follow-up surveys (i.e., non-initial surveys). Tangential to this, only participants that have *not* begun the initial survey yet will have the "remove" link displayed for them in the Participant List, which means that if a response is either partial or complete, it will not be able to be deleted from the Participant List as it was in previous versions. This is to keep the behavior for initial surveys more consistent with behavior of other surveys in the project. Note: The email address for responses created via a Public Survey link will not to be editable in the Participant List because if there is an email address, it will be originating from the Designated Email Field, which is a data value.

Change: Merged all survey options at top of data entry forms into a single all-purpose drop-down Change: Survey links generated for public surveys will now have a human-readable hash in the URL to make

them more easily typed by hand for respondents. (This applies only to public survey links and not to survey links that are unique to participants.)

Major bug fix: If users have enabled the feature to display aggregate survey results to respondents after completing a survey, it would mistakenly display a drop-down list of records from the project on that page, which should only be visible on the "Stats & Charts" page in the "Data Exports, Reports, and Stats" page. And if a respondent selected an option from that drop-down, it would lead to a survey page displaying an error message. (Bug emerged in version 6.0.0.)

Change/improvement: Data that is piped from a Text or Notes field whose data values (i.e. text) contains HTML tags will now be displayed on the page as interpreted HTML rather than as the exact text (i.e. HTML-escaped text, which is how it was displayed in previous versions). This means that if "<u>text</u>" was the data value being piped on the page, it would display the word "text" as an underlined word rather than displaying it exactly as "<u>text</u>" with the HTML tags visible.

Change: Validation codes for the "Save & Return Later" functionality for surveys are now displayed in all capital letters now. This does not change anything because they have always been case insensitive, but this should make them easier to read by participants.

Change: When performing a data export for the Stata statistical software package, if the resulting CSV data file is UTF-8 encoded, then it would prepend a Byte Order Mark (BOM) to the beginning of the syntax file, which might cause it to have issues when loading it into Stata. Instead, it no longer prepends the BOM to the CSV data file for Stata.

Change: For any date/time fields used as filters in a report, it would mistakenly not display the date/time format text (e.g., M-D-Y) to the right of the filter value text box, thus making it difficult to know in what format the date/time value should be entered. It now displays the date/time format for such fields used as filters.

Bug fix: When a user is randomizing a record on the mobile web version of the data entry form, the randomization popup dialog will sometimes not display properly, which makes it impossible to see the whole dialog and may thus prevent the user from performing randomization.

Bug fix: If a user clicks on an attachment link for a Descriptive field on a data entry form after some data has been entered on the page, it would mistakenly display the "save your changes?" popup prompt before allowing the user to download the attachment. It now no longer displays the prompt when downloading an attachment for a Descriptive field.

Bug fix: When a user is using the Data Resolution Workflow module and is opening, responding to, or closing a query, after clicking the save button in the Data Resolution Workflow popup, the text of the button would mistakenly change back to its original value when the popup was first opened, which could be confusing to the user if they notice it.

Bug fix: If two or more users are modifying a project at the same time, in which they enable Draft Mode for the project at the same time or they submit drafted changes for approval at the same time, it now performs some extra checks so that those users do not overlap in their actions and accidentally end up having all their fields deleted.

Bug fix: In some rare cases, the section header of a Form Status field will for unknown reasons get mistakenly merged with another existing section header. If this occurs now, it will auto-fix itself and set the section header text back to "Form Status".

Bug fix: If an instrument had been locked for a given record and that instrument had been enabled as a survey, then if someone returned to the survey page for that record, they would mistakenly be allowed to modify and re-save the responses on the survey page, thus allowing a respondent to bypass the record locking feature completely.

Bug fix: When viewing a report that is sorted in descending order by the record ID field, in which the project has "record auto-numbering" enabled but the record ID has not been explicitly set with "number" or "integer" field validation, the report would mistakenly sort the records using string/text sorting methods rather than sorting it numerically, so the records would not appear sorted in the correct order.

Bug fix: When performing an API data export (using either "Export Records" or "Export Reports" method) in "xml" format, if a Text field or Notes field contained the text string "]]>", it would make the XML output invalid because "]]>" is never allowed inside a CDATA section in XML. In this case, it now replaces "]]>" with "]]]]><![CDATA[>" so that it splits that text string into two CDATA sections (ending the first with "]]" and beginning the next with ">", thus avoiding the issue of producing invalid XML.

Bug fix: Typo in text on a project's Data Access Group page that mistakenly stated that user roles could be assigned to DAGs, which is incorrect.

Major bug fix: When exporting data via the "Export Records" API method in "eav" format for an "sql" type field, it would mistakenly return the value as blank even if it contained a value. This only affects "sql" type fields and does not affect it in "flat" export format.

Major bug fix: If a value existed for a field previously but was later removed (set to blank), after which a user imported data for that field via the Data Import Tool, it would mistakenly leave two rows in the redcap_data database table for that field (one row with a blank value and another with the new value) rather than simply updating the existing row with the new value. Currently, there does not appear to be any evidence that this causes any issues within the application with regard to the entering or exporting of data. (Note: This does not affect the API data import but only the Data Import Tool.)

Change: Data Export rights (from the User Rights page) are now applied to *all* modules where data can be downloaded. In previous versions, it would correctly prevent users from downloading data in all places if they had "No Access" data export rights, but if the user has De-Identified data export rights, it would not apply such rights within certain data exports, such as PDF exports and report exports. This was known behavior and was not considered a bug, but was regarded merely as the Data Export rights being applied inconsistently thoughout REDCap. It now fully applies such rights and thus employs data de-identification on *all* data downloads if the user has "De-Identified" rights or "Remove all tagged Identifier fields" rights.

Change: "De-Identified" data export rights are now applied in PDF exports, in which any data for Notes fields, unvalidated Text fields (free-form text), and date/time fields will have their data values removed and replaced with the text [*DATA REMOVED*].

Change/improvement: More detail is now provided for data exports on the Logging page, includes API data exports. In addition to displaying the fields that were exported, it will now also note if the export was a "raw" or "label" export, it will note the export format (e.g., SPSS, CSV, SAS), if the Data Access Group field was exported, if survey timestamps and the survey identifier field were exported, if "De-Identified" or "Removed Identifiers" user rights were applied to the export, and if it is a report being exported, it will list the report ID number.

Change/improvement: Slight reorganization of user privilege options on User Rights page (in comprehensive user grid and in popup) for better user experience.

Changes to the API: o Change: For the "Export Records" API method when using "flat" type output while exporting the

data as labels (i.e., when rawOrLabel=label), it now no longer defaults to exporting checkbox field values as their choice label (i.e., "Choice 1") as it did in previous versions, but instead it returns "Checked" or "Unchecked" as the checkbox values by default. So if any users depend upon checkbox values being exported as their choice label, they should add the new parameter

"exportCheckboxLabels" to their script as exportCheckboxLabels=true to maintain continuity after the upgrade to REDCap 6.0 or higher.

o Change: Data Export user rights are now applied to API data exports. In previous versions, the data export rights had no effect on API data exports. Now if a user has No Access export rights, they will not be able to export data from the API (this includes the "Export Records" API method, the new "Export Reports" API method, and also the "Export a File" API method). And if the user has either "De-Identified" export rights or "Remove all tagged Identifier fields" export rights, then fields will be removed from the export data set accordingly in the API export request. If a user attempts to use the "Export a File" API method on a File Upload field that has been tagged as an Identifier when that user has either "De-Identified" export rights or "Remove all tagged Identifier fields" export rights, then it will return an error.

o Change: For the "Export Records" API method, "both" will no longer be an option for the "rawOrLabel" parameter. The only valid options for rawOrLabel will be "raw" and "label". This is also true for the new "Export Reports" API method.

o Change: "eventName" will no longer be used as a parameter in API data exports. In previous versions, users could manually set whether an API data export would return the event name for longitudinal projects as the event label text or instead as the unique event name (generated automatically from the event label). It now simply returns the event label text if rawOrLabel=label, whereas it will return the unique event name if rawOrLabel=raw (or if rawOrLabel is not provided). If "eventName" is provided in the API request, it will be ignored.

o Change: When doing an API data export where a list of fields or forms are explicitly provided in the API request to REDCap, the record ID field will now only be included in the exported result if the record ID field is explicitly specified in the list of fields or if its form is explicitly specified in the list of forms. In previous versions, if *any* form or field was explicitly provided in the API request, it would return the record ID field. So for users who depend upon the Record ID field to be returned in the exported data set, they should go ahead and add the Record ID to the "fields" array parameter in their API request to maintain continuity after the upgrade to REDCap 6.0 or higher.

o Bug fix: When exporting data via the Export Records API method with rawOrLabel="label" (instead of "raw") for Yes/No or True/False fields, it would mistakenly return the label in all lower case (instead of with the appropriate label where the first letter is capitalized - e.g. "yes" instead of "Yes").

Change/improvement: The "Add/Edit Records" link on the left-hand menu of a project now points to the first data collection instrument to which the user has access. In previous versions, it would always point to the project's first instrument, to which the user might not have access and would display an "access denied!" message to the user if they clicked the link, which could be confusing.

Change/improvement: If a user does not have "Create Records" privileges, then the link on the left-hand menu of a project will not display "Add/Edit Records" but instead will display "View/Edit Records" to better convey their privileges.

Change/improvement: When exporting data to SAS, the SAS syntax file produced will no longer remove apostrophes contained in the option labels of multiple choice fields but instead will escape them as a double apostrophe. This allows for a more proper viewing of the option labels in SAS.

Bug fix: On the User Access Dashboard, if a user clicks the "fetch" link for a project to view the users' last time accessing that project, it might mistakenly display "never" for a user even though that user has indeed accessed the project before. This would often occur when the user's username in the project list contained a capital letter.

Bug fix: If using a relatively new /redcap/api/index.php file, which would come in a relatively new installation of REDCap, then if a new REDCap version directory from an upgrade package was added to the main "redcap" folder on the web server, then all API requests would mistakenly point to the API files in the new version folder even though the upgrade process had not yet been completed. This would mean that during the window of time where the version folder was added and the upgrade was completed, the API requests would mistakenly be routing to the wrong version, which could cause issues if the API behavior changed in the newer version.

Bug fix: The plots on the Stats & Charts view of a report would mistakenly not get displayed on the page if the field contained a multiple choice option with a non-numerical coding.

Bug fix: In older versions of Internet Explorer, if an inline image was displayed in a Descriptive field that was initially hidden by branching logic, then if that field became visible at some point due to branching logic, the image would mistakenly stay hidden.

Bug fix: When automated survey invitations are triggered due to a respondent completing a survey or due to a user setting a data collection instrument with Complete status, it would appear on the Logging page that the survey invitation for the next survey was scheduled before the first one was completed. However, both events have the same timestamp, in which the "Automatically schedule survey invitation" event happens to be listed first on the Logging page, which can be confusing to users. It now lists the invitation scheduling event last and also sets its "username" attribute as "SYSTEM" since in previous versions it would say "[survey respondent]", which is really who triggered the invitation scheduling but is confusing because it may seem to imply the the respondent performed some kind of action to trigger it, which is not the case.

Bug fix: When using the "Export Arms" API method, in which the "arms" parameter is explicitly supplied in the API request, it would mistakenly ignore that parameter. Thus it would not export only the arms supplied in the "arms" parameter as it should, but it would instead export all the arms in the project.

Bug fix: When using the Copy Project functionality for a project containing surveys, in which one or more surveys had a logo (via the Survey Settings page), then some or none of the surveys would get copied over to the new project successfully, in which the instruments in the new project would appear to only be data collection forms and would not be enabled as surveys.

Bug fix: When viewing the Survey Notifications popup for all surveys in a project on the Online Designer page, it would mistakenly not display the surveys in their correct order.

Bug fix: When using the "designated email field for invitations to survey participants" in a project containing surveys that is also a longitudinal project, it would mistakenly not display the record name next to the participant's email address in the Participant List on certain occasions.

Bug fix: When using the Secondary Unique Field in a project, there is a remote possibility that a duplicate value could mistakenly be entered successfully by a user into the Secondary Unique Field on a data entry form and then save the form's data before the popup error message could be displayed regarding the duplicate value issue. This can only occur within a very small window of time, although the window of time increases based upon the slowness of the REDCap server. It now halts all processes on the data entry form and waits for the duplicate value check to complete before allowing the user to perform any other actions on the page.

Bug fix: When uploading a Data Dictionary, it would mistakenly allow users to import fields with a field type of "attachment", which is not a valid field type. It now displays an error message if a user attempts this.

Improvement: For longitudinal projects, the record name on the Record Status Dashboard is now a link to that record's event grid page.

Major bug fix: If a field in a project has branching logic that utilizes a field from another data collection instrument (but within the same event), then if the saved data value for the field used in the logic contains an apostrophe, then if a user saves the data on the instrument containing the field with branching logic, it will mistakenly truncate the other field's data to the location of the apostrophe

Change: When reviewing production changes made in Draft Mode, if the Record ID field has been moved and is thus no longer positioned as the first field in the project, then it will now consider it to be a critical issue if one or more records exist in the project. This will also be the case when REDCap is determining whether or not to auto-approve any production changes that are submitted by a user. Previous versions did not consider this to be a critical issue.

Bug fix: When viewing a partial or completed survey response on a data entry form in a longitudinal project, it was mistakenly not displaying the current event name at the top of the page when not in "edit response" mode, which could make it difficult to quickly determine which event you are currently viewing. It now always displays the event name at the top of the form for longitudinal projects.

Bug fix: In a longitudinal project that contains surveys, if the first data collection instrument is enabled as a survey and is designated for at least one event but not the first event, then the Manage Participants page

would mistakenly provide an incorrect Public Survey Link that would not point to the first event but instead to another event. (The Public Survey Link must always point to the first event.) It now does not display the Public Survey Link in a longitudinal project unless the first instrument has been designated for the first event, and instead displays an error to the user on how to fix this issue.

Bug fix: For some large tables where the "Enable floating table headers" button appears (e.g., Record Status Dashboard, reports), the "Loading..." progress message would display forever and would never finish after clicking the "enable" button.

Bug fix: The "Graphical Data View & Stats" page would mistakenly not display the Total Count and Missing values for a field if they field contained no data for any records but instead would display the message "This field cannot be displayed because no data exists for it".

Bug fix: If using multiple fields within the Custom Record Label in a project in which some (but not all) of the fields used in the Custom Record Label had blank/null values for a given record, then it would mistakenly display the variable name in square brackets on the page instead of just omitting that value in the displayed text.

Bug fix: When renaming a record in a longitudinal project, in which the new record name already exists, it mistakenly does not give any notice regarding why the record cannot be renamed but simply displays the "record successfully edited" message.

Bug fix: For longitudinal projects, the "Graphical Data View & Stats" page might display incorrect values for "Total Count (N)" and "Missing" on the fields displayed on the page.

Bug fix: If an "if()" function or exponent logic, e.g. ([field])^(3), was used in the branching logic of a field, it would mistakenly not parse it correctly when loading a data entry form or survey and instead display an error message. These work fine in calculated field equations, but only did not work in branching logic.

Major bug fix: If a user possesses an API token in a project and has also been assigned to a user role in that project and then copies the project while leaving the "copy all users and roles" option unchecked on the "Make a Copy of the Project" page, then if they request an API token for the new project, that new API token will mistakenly point back to the old project, which means that there could be an issue with regard to data being imported into the wrong project or exported from the wrong project in this specific scenario.

Bug fix: Survey invitations that were sent via Automated Survey Invitations and were triggered by the REDCap cron job would mistakenly not link that logged event to the project, thus the event "Automatically schedule survey invitation" would never show up on the project's Logging page, which might be confusing. It now gets logged properly in the project, and additionally, it lists the username as "SYSTEM" on the project Logging page, in which the username was missing/blank in previous versions for this scenario.

Bug fix: If attempting to utilize the PROMIS CATs functionality on a REDCap server that has SSL disabled (e.g., a test server), it might not function successfully but displays an error that it cannot communicate with the Vanderbilt CATs server.

Change: When attempting to use the PROMIS CAT functionality for a survey, it will now display an error on the page if the cURL library in PHP has not been enabled on the web server (since the CAT functionality utilizes cURL and cannot function without it).

Bug fix: The "Graphical Data View & Stats" page would mistakenly display a value of "0, 0%" for Counts/Frequency for a multiple choice option that had a non-numerical coding (e.g., "M" for "Male"), which could cause some confusion by providing incorrect statistics for multiple choice fields (radio, dropdown, yesno, truefalse, and checkbox fields).

Bug fix: Fixed typo in API documentation for the "Export Instruments" method. Bug fix: Fixed typo in the "What is 'exclusion'?' popup on the Data Quality page. Bug fix: If a project-level REDCap plugin that displays the project header/footer forces a user to log in to

REDCap (because that is the first page they are accessing in their session), then if they click a Project Bookmark link on the left-hand menu, on certain occasions it would not redirect the user to that bookmark page but instead display a "woops" error. This only occurs when the first page they come to after logging in is a plugin page that displays REDCap's header/footer.

Bug fix: When viewing the Data History popup for a field on a data entry form, it would sometimes return no results if a space existed in the record name.

Bug fix: If a field on a survey had branching logic that utilized the Form Status field (e.g., form name + "_complete"), it would work fine on a data entry form, but it would mistakenly cause a branching logic error on the survey page.

Bug fix: When a user with "de-identified" data export rights is viewing the Advanced Data Export view of the Data Export Tool and the record ID field in the project had been tagged as an Identifier field, then the option to "Hash the Record ID field" at the bottom of the page would mistakenly not be checked. This would not affect anything during the export process because it would still correctly hash the Record ID field's value in the exported data file, but it could be confusing because that checkbox option was not originally checked.

Bug fix: When downloading a PDF containing saved data, any date/time fields with DMY or MDY date formatting would mistakenly be displayed in YMD format in the PDF. They now display in the PDF in their desired date format

Improvement: The Record Status Dashboard now displays options to view the lock status and/or e-signature status (if e-signatures are enabled) for any given record-instrument[-event] listed in the table.

Change/improvement: If the Survey Queue is enabled in a project and a survey participant returns to a survey that they have already finished (excluding public surveys), it now displays their Survey Queue directly below the message "Thank you for your interest, but you have already completed this survey", whereas before it simply stated the message without displaying the Survey Queue. This will make it easier for participants to return to the Survey Queue on occasions where they cannot find the link to the Queue itself or to their next survey.

Change: The ordering of records has been slightly changed in many places throughout REDCap where a list of all records is displayed so that records are now ordered using case insensitive natural ordering. This is to improve consistency because different places displayed a list of records in slightly different orders (e.g., case sensitive natural ordering). Reports are one of the few places that still displays records in case sensitive natural ordering, but this will change in future soon.

Bug fix: When a person copies a project, that person will not be in a role in the new project even if they were in a role in the original project. This mimics the behavior when a user creates a new project from scratch or from a template. In previous versions, a user assigned to a role that had Setup/Design privileges but no User Rights privileges could copy a project and then inadvertently end up with no User Rights privileges in the new project, which could be very confusing.

Bug fix: In the Scheduling Module, when changing the date of an event on a generated schedule or changing the date of an event on a saved schedule, after selecting a new date it would mistakenly determine the wrong day of the week to display next to the date text box, which could be confusing.

Bug fix: Made language correction due to spelling error in the "What is 'exclusion'?" popup on the Data Quality page.

Bug fix: On the API page in a longitudinal project, the list of unique events names displayed on the page would diverge slightly on certain occasions from the event list seen in other places, such as the Define My Events page. For example, if there existed more than 26 events all with a very similar name, the appended alphabetical characters on the unique event name would mistakenly get displayed as indecipherable characters (black diamonds with a question mark inside). Ultimately, this would prevent any users from importing data into those events using the API.

Bug fix: When uploading an attachment for a Descriptive field in the Online Designer, after the file has finished uploading, it provides a button that says "Cancel" to allow the user to close the popup, which could be confusing, when instead it should say "Close".

Bug fix: When using the User Access Dashboard to expire or delete a user from a project, the expiration/deletion action would not take place successfully if the user's username contained a period/full stop.

Major bug fix: For users that are able to access the User Access Dashboard, it might mistakenly display some projects on the UAD to which the user does not have User Rights privileges (i.e., access to the User Rights page in the project). This would only seem to occur if the user had access to the User Rights page in the project at one point but was then later added to a user role that itself did not have User Rights privileges.

This bug would not allow the user to add or edit the user privileges in the project, but would simply mistakenly allow them to delete or expire users from the project when they should not be able to.

Major bug fix: For web servers running certain versions of PHP, users would not be able to access projects to which they had access, in which it would mistakenly display the "access denied!" message when attempting to access the project.

Bug fix: When piping data into a label on a data entry form when utilizing Double Data Entry, in which the current user is either DDE user 1 or 2, the piping would mistakenly not work when the page is loaded but instead would display a blank line where the piped data should be.

Bug fix: Occasionally, a survey that has question auto numbering enabled and also has a question on the survey with branching logic, it would not automatically disable the question auto numbering like it should (in order to prevent confusion due to question numbers not appearing on the page because they are hidden by the branching logic). It will now automatically disable question auto numbering if any questions on the survey contain branching logic.

Bug fix/change: Certain REDCap operations (e.g., uploading files into File Upload fields or adding/editing fields in the Online Designer) would fail to complete successfully if REDCap itself was hosted inside an iframe on another website. Attempting to perform such operations would cause JavaScript errors, which would cause it not to complete. It should now work fine even if a survey page or if all of REDCap is used inside an iframe on another website.

Bug fix: If a radio button field on a data entry form or survey page has only one multiple choice option to choose from, then the user's cursor would mistakenly not place focus on the radio button when tabbing through the page but instead would skip it (or more accurately the cursor would disappear between fields). And in addition, in some particular browsers (e.g., Firefox), it would allow a user to attempt to tab into the radio button (in which the cursor would actually disappear), and if the user entered text via their keyboard before clicking Tab again, it would mistakenly store the text entered as the radio button field's value, although it would never be displayed anywhere except in a report or data export.

Bug fix: If a user belongs to a Data Access Group in a project and is viewing a report, the "total number of records queried" at the top of the report would mistakenly always be reported as "0" rather than the correct number.

Bug fix: When executing a user-defined rule on the Data Quality page, in which a discrepancy is found and returns a field with no value, the link that points back to the data entry form for that record would not be visible because of the missing value. Now in such cases it simply displays "[no data]" as a gray link so that the user has something to click on to take them back to the data entry form when a value is missing.

Improvement: The buttons used in the dialog popup for survey Stop Actions (e.g., "End the survey now") have now had their language abstracted, so they can now be displayed in different languages.

Change: The following project-level settings will now only be explicitly utilized in a project when their value differs from their corresponding system-level values: project contact/email, production approval person/email, institution/organization name, grant name, and custom project logo. This will not change any behavior whatsoever in any projects. However, it will make it much easier to change these values for all projects at once by simply changing the system-level values, whereas in previous versions the only way to change these values for all projects was to execute SQL queries against the database directly, which is not ideal. In connection with this, the system-level counterparts of these fields are no longer listed on Default Project Settings page in the Control Center, but have now been moved to the General Configuration page.

Bug fix: When editing an individual participant schedule on the Scheduling page, in which the date value is being modified for a specific scheduled event for that participant, it would cause a JavaScript error in Internet Explorer 8 only when it attempted to calculate the number of days between the original date and the new date that the user just modified.

Bug fix: When viewing a single calendar event in the popup window in the Calendar module, in which the calendar event is attached to a record, on some occasions it may display an incorrect Form Status icon/value for certain data collection instruments.

Bug fix: When using record auto-numbering in a project with data access groups, in which a user in a DAG creates a record and then another user that is not assigned to a DAG un-assigns that record so that it is no

longer assigned to any DAG, then when a user in a DAG then goes to create a new record, the data entry page goes into an infinite loop of redirecting itself.

Bug fix: If using very specific types of UTF-8 encoded special character sets (e.g., Icelandic characters) in a survey's instruction text or acknowledgment text, it would sometimes not render the text correctly on either the survey page or on the Modify Survey Settings page in the Online Designer but instead would display black triangle icons to denote that the browser could not interpret the character.

Improvement: When viewing the Edit Field popup in the Online Designer for Yes-No and True-False fields, it will now display a static, unmodifiable box of text below the Field Label text box where it will display both the coded value and label for the multiple choice options for those two field types (e.g., 1, True; 0, False). This will help make it more clear to users what the stored/coded values are for Yes-No and True-False fields, which is not really documented in many places.

Major bug fix: When using the "today" variable inside the datediff() function in the conditional logic of an Automated Survey Invitation, the invitation would mistakenly not get scheduled and would instead throw a PHP error when the process was executed by the cron job, which runs every 12 hours.

Bug fix: If an instrument is created in a project and then enabled as a survey, after which the instrument itself is deleted, then when copying a project it will mistakenly list the deleted survey instrument in the yellow "notice" box, which could be confusing.

Bug fix: When creating a new calendar event using the popup window in the Calendar module, a database query would silently fail in the background. This would not be displayed on the page or affect anything adversely though.

Change/improvement: All comments entered for the Field Comment Log and Data Resolution Workflow are now logged on the Logging page. In previous versions, the project Logging page noted the action performed and the record/event/field, but it did not explicitly display the comment entered.

Change: Users with read-only rights to a data entry form can now add, edit, and delete Field Comments for fields on that form. In previous versions, users with read-only form-level rights could only view Field Comments but could not add any new ones. (This does not affect users' ability to view or add comments in the Data Resolution Workflow, which has its own explicit user permissions for this. This change only affects projects using the Field Comment Log.)

Change: When a person copies a project, that person will now automatically have User Rights privileges in the new project, even if they did not have them in the original project. This mimics the behavior when a user creates a new project from scratch or from a template. In previous versions, a user with Setup/Design privileges but no User Rights privileges could copy a project (and thus all the user rights in the project, including theirs) and then inadvertently end up no User Rights privileges in the new project, which could be very confusing.

Major bug fix: If survey invitations were scheduled to be sent for a record using the Automated Survey Invitations and later a user renamed the record, the invitations that had been scheduled for that record would become disassociated with the record, and would then be triggered and scheduled again at that point, which might cause the invitations to now be scheduled to be sent at incorrect times. Because of this disassociation, it would also cause issues displaying the invitations in the Survey Invitation Log.

Bug fix: If the same survey invitation was sent one or more times to the same participant, in many cases all the invitations would mistakenly show up in the Survey Invitation Log with "[Email not listed]" in the Participant Email column with the except of the most recent invitation sent to that participant.

Bug fix: If a survey invitation was sent to a participant using the Compose button at the top of the data entry form, in many cases it would mistakenly show up in the Survey Invitation Log as having not been sent even if it had been sent to the participant.

Bug fix: "elements" was added to the illegal variable name list because it would prevent branching logic or calculations to function properly on data entry forms and survey pages in certain browsers.

Bug fix: Certain UTF-8 character sets (e.g., Icelandic) would mistakenly not display correctly on the webpage when used in survey instructions or survey acknowledgments.

Bug fix: In longitudinal projects in the Additional Customizations popup on the Project Setup page, users would seemingly be allowed to "enable" the "Order the records by another field" setting, despite the note that

says it does not work for longitudinal projects. It would not really enable this setting but would appear as if it did since it displays a "Success" message after clicking the Save button. This settings is now completely disabled in that popup for longitudinal projects so that there is no confusion to users regarding whether or not it can be enabled.

Bug fix: If using conditional logic for Automated Survey Invitations in a longitudinal project, in which unique event names are explicitly used in the logic, then if an event is referenced where no data exists for any fields in that event yet, then the logic would never get fully evaluated and would thus prevent the survey invitation from being scheduled when it should. For example, if the logic is [screening_arm_1][email]<>"" and [visit_2_arm_1][visit_2_date]="", in which event "visit_2_arm_1" has no data collected for it yet, then the logic will not get fully evaluated even when "email" has a non-null value.

Bug fix: If importing a CSV data file on a longitudinal project's Data Import Tool page, in which the "Record format" is set to "Columns" and the record names in the CSV file are on the second row, it might mistakenly display an "invalid event name" error for some of the empty columns in the file.

Bug fix: When adding or modifying a checkbox field on the Online Designer or Data Dictionary Upload, if a coded value for a checkbox option contained a dot/period (e.g., "1.08"), it would mistakenly allow it to be saved. Having a dot/period in a checkbox's coded value causes several problems, including the ability to save data and export data to certain stats packages properly. Although it is fine for a dropdown or radio button field to have a dot/period in its coded values, it is not allowed for checkboxes, and thus it now displays an error to the user if a user attempts to do this on the Online Designer or when uploading a Data Dictionary.

Bug fix: The "Export Users" API method was not exporting the correct user privileges if the user had been assigned to a user role, but instead it was mistakenly exporting the privileges that the user had prior to being assigned to a role.

Bug fix: On a data entry form or survey page where the record has not been initially saved yet, it would make a query to the redcap_edocs_metadata table for each File Upload field, in which the query would always fail. However, once the record had been created, the query would no longer fail on that page or other data entry forms/survey pages. There was no error displayed on the page due to this failed query though. But now it no longer executes the query unless the record already exists.

Bug fix: When viewing the Data History of a field on a data entry form, if the username of the user is very long, it will mistakenly spill over into the next table column, which can make the text unreadable by having the username piled on top of the other text. It now wraps the username to another line if it is too long for the table cell.

Bug fix: When a user clicks on an email address a participant in the Participant List, on certain occasions it would not automatically pre-fill that email address into the editable text box that appears but instead would leave the text box blank.

Bug fix: The survey instructions and/or survey acknowledgment of some surveys might mistakenly display a black diamond character in some web browsers because a non-breaking space was invisibly added by the rich text editor on the Modify Survey Settings page, in which the non-breaking space character gets mangled before being output to the webpage.

Major bug fix: When using the Data Comparison Tool to merge records for a Double Data Entry project, it would mistakenly enforce YMD date format validation for the text box in the "New Value" column for any kind of date- or datetime-validated field, which could be confusing if the date field is defined with an MDY or DMY format. It now properly enforces the proper date format that has been specified for the field when validating the value entered into the text box on the Data Comparison Tool.

Major bug fix: If a project has a date or datetime field as the record ID field, it would mistakenly enforce only YMD date format validation when entering a new record name, even if the field had been defined with an MDY or DMY date format.

Bug fix: When creating a User Role that contains an apostrophe in its name, it would not save correctly if someone attempted to edit the role afterward.

Change: Slightly better handling of displaying matrixes of fields in the mobile survey view when the matrix column headers or question labels contain a lot of text, in which their text could overlap or get mashed together.

Bug fix: If Automated Survey Invitations have been set up for a survey on a project's Online Designer page, then when setting an ASI as "not active", it would mistakenly display error messages saying that it could not save the changes since not all the fields had been completed in the pop-up, which could be confusing if the user is simply deactivating it. It now does not display any error messages when setting an ASI as "not active" in this case.

Bug fix: If the record ID field in a project has min/max range validation, it would mistakenly display the popup warning message temporarily but then would quickly redirect the user to the "create record" data entry form page. Not only would the warning not prevent the user from creating the record, but the user would not even have time to view the validation warning when it was being displayed, which is only for a quick moment. If a range validation occurs for the record ID field, it now properly displays the warning popup and forces the user to enter another value inside the range before they can create a record.

Bug fix/change: If a user attempts to leave a field comment in the Field Comment Log popup on a data collection instrument, it would simply not display the textbox and "save" button for adding a new field comment if the user did not have form-level user privileges for the instrument. So no explanation was given as to why they could not add a new comment, which could be confusing. It now displays a note in the popup to explain this in this scenario.

Bug fix/improvement: Checkboxes on data entry forms and survey pages will now tab correctly if the user is tabbing from field to field on the page. In previous versions, it would mistakenly skip checkboxes when tabbing. It will tab through each checkbox option individually. The user can check or uncheck each checkbox option by clicking the space bar on their keyboard.

Bug fix: If using the real-time execution feature for Data Quality rules on a longitudinal project, in which a Data Quality rule utilizes cross-event logic, then if a violation is triggered and displayed after saving a record on a data entry form, it would mistakenly not display any data from the other events in the DQ violations popup but instead leave them blank as if they have no value, even if the record does contain data on the other events.

Bug fix: "focus" was added to the illegal variable name list because it would prevent branching logic or calculations to function properly on data entry forms and survey pages in certain browsers.

Bug fix: When copying a project, if the user selects to copy the settings for the Survey Queue and Automated Survey Invitations, it would failed to copy those settings on certain occasions.

Bug fix/change: If a user has set up Automated Survey Invitations in a project, if they go back to modify those settings later (especially after some invitations have been scheduled), it might not be obvious to the user that those modifications will not be applied to invitations already scheduled but only apply to invitations that are scheduled after the modification. To reduce confusion about this behavior, which may not be obvious to many users, some new text will appear in red below the instructions in the automated invitation popup to notify the user of this.

Bug fix: When importing data via the Data Import Tool or API data import, it would mistakenly not update a number value for a field being imported if the new number had an equivalent numerical value but had a different precision (e.g., 100 being changed to 100.0).

Bug fix: When using calculated fields in longitudinal projects, a processing bottle-neck was discovered that was causing unnecessary slowdown when performing auto-calculations when a user clicked the Save button on a data entry form or survey page. This fix allows the page saving to be processed about 3x-10x faster than before.

Bug fix: When using calculated fields that utilize cross-event calculations in longitudinal projects, it may have mistakenly not been performing the calculation for other events. Thus, some events containing calc fields with cross-event calculations may not have gotten their value saved. (Note: The values can be fixed retroactively by running Data Quality rule H.)

Bug fix: When adding a filter field to a report, in which the field has some form of field validation (e.g., date_ymd, email), then if the user selects the operator to be "contains", "not contain", "starts with", or "ends with", then it would prevent the user from entering a value into the text field to the right unless the value entered adhered to the field validation format. For example, if a user selected "Email" as the filter field, then

selected "contains" as the operator, and entered "gmail.com" into the text box as the filter value, it would display the validation error message.

Bug fix: If on the User Access Dashboard page and click the Reset link at the bottom of the page, any selected radio buttons would not have their cell background changed back to green but would mistakenly be changed to a white background instead.

Bug fix: When using the Survey Login feature on a CAT (computer adaptive test - e.g., PROMIS assessment), the questions on the survey page would mistakenly not be displayed at all.

Bug fix: In a project utilizing Data Access Groups, if a user does not have "View & Edit" permissions for any instrument in the project and also does not have "Create Record" privileges, then the user could still navigate to an instrument on a record and change the DAG assignment of the record. This could be done if the user changes the DAG selection drop-down on the instrument, in which the page will not allow them to click the Save button but it will mistakenly prompt them to save their changes if they attempt to click a link somewhere in order to navigate off the page.

Bug fix: If a user clicked the "Lock all forms" or "Unlock all forms" link for a record in a project, it would mistakenly lock/unlock forms to which the user does not have form-level access.

Bug fix: In a longitudinal project, if a record is created via the Scheduling module (rather than via form or survey), then the record would mistakenly not display on the Record Status Dashboard until some data was entered for it on a form or survey.

Bug fix: If using a cross-event calculation for a calculated field on a data entry form or survey in a longitudinal project, in which a non-text field (e.g. drop-down, radio) used in the calculation has a negative value, then the calculation would mistakenly return a blank value instead of the correct calculated number.

Bug fix: In longitudinal projects only, the "Total survey responses" count was mistakenly being displayed on a project's "Add/Edit? Records" page when it should not have because it only refers to the first survey (even though it does not specify that) and also is not always accurate. Displaying the total survey response count made sense in version 5.X of REDCap, but it no longer makes sense after version 6.0, which allows for multiple surveys.

Bug fix: When viewing a survey response on a data entry form, it notes at the top of the page all the users who have contributed to the response data, but it may mistakenly list users that contributed to other forms or surveys for the record but not necessarily that particular survey. This is now fixed for all survey responses collected hereafter. However, this issue is not able to be fixed retroactively for already completed responses.

Bug fix: When clicking the Upload Document link for a File Upload field or when clicking the Add Signature link for a Signature field on a data entry form or survey, if data values are to be piped into the field's label inside the popup that is displayed, it would mistakenly only pipe saved values and would not pipe unsaved values that had been entered on the page.

Medium security fix: The Password Recovery page, which is only available if using Table-based authentication, was found to have a Blind SQL Injection vulnerability that could be exploited if a malicious user sends a specially crafted request to that page to spoof certain client values that REDCap receives in the request.

Bug fix: When a user is viewing a project-level plugin, it would mistakenly display the auto-logout popup after being on the page for 3 minutes and would tell them that their session has expired, even thought it had not. Also, it would sometimes mistakenly display an error popup if the user attempted to click a project bookmark on the right-hand menu while viewing a project-level plugin, thus preventing them from navigating to the bookmark page.

Bug fix: If any survey invitations were sent from the data entry form for a record (rather than via the Participant List) on a version of REDCap before v6.5.0, then the invitations would mistakenly no longer display in the Survey Invitation Log after upgrading to v6.5.0 or higher.

Bug fix: If data is being piped into the option of a drop-down field on a survey page or data entry form, then it would mistakenly not get updated if a user on that page changed the value of a field whose value is being piped into a drop-down option. Instead it would pipe into the drop-down only data values that had already been saved prior to loading the page.

Bug fix: Calculated fields may mistakenly throw an error on a survey or data entry form if multiple round() and multiple if() statements are nested together in the calculation.

Bug fix: The Participant Identifier of a given participant in a survey's participant list would mistakenly not be editable after the participant had started or completed the survey if the identifier was not blank. For privacy reasons, users are prevented from adding an identifier to a participant if the identifier was originally left blank, but it should allow it to be editable (either before or after taking the survey) if not blank. This fix will now allow the identifier to be editable at any time if the identifier is not blank.

Bug fix: If the randomization module is enabled and set up for a classic project and then the user converts the project into a longitudinal project, then the Randomize button will mistakenly not appear on the data entry form but instead display the randomization field as a disabled field.

Bug fix: When viewing the Compose Survey Invitations popup for a survey's participant list, it would note that the participants being displayed in the popup are "those who have not responded" (assuming that the option "Allow respondents to return and modify completed responses?" has not been enabled), which is confusing because the list does include those who have partially responded. To prevent confusion, the text has been changed to "those who have not responded completely" to signify that partial responses are included. Bug fix: On certain random occasions where a record was mistakenly saved with a blank record name, in which the record would then get orphaned and become inaccessible on the front-end web application, if that blank record were somehow assigned to a Data Access Group, the Data Access Groups page would mistakenly include it in the count of records for each DAG, even though the blank record is not viewable or accessible anywhere else.

Bug fix: Duplicate rows mistakenly appear in a survey's participant list when records are created via data entry form or via data import and when more than one person then goes to view the participant list at the exact same time. This can cause a race condition, which generates duplicate rows in the back-end database tables for each record being populated in the table. There is unfortunately no way to fix the duplicates retroactively except by exporting all data in the project, then erasing all records, and then re-importing all the exported data.

Bug fix: If the "redcap_save_record" hook function is being used on a survey, in which the hook will redirect the page or stop page execution while at the same time a survey question that is required has not had a value entered, then it will mistakenly not set the survey response as being partially completed but leave it as if the survey had not been started yet.

Major bug fix: If Automated Survey Invitations had been set to be triggered via conditional logic based upon the changes of data values, then the ASIs would mistakenly not get triggered when they should during an API data import. This issue would not manifest when importing data via the Data Import Tool page but only via the API data import method.

Bug fix: When a project has record auto-numbering enabled and a user opens a data entry form to create a new record, instead of clicking one of the Save buttons on the page, the user clicks another form on the left-hand menu, after which if they click the "Save changes and leave" option, it will redirect them to the desired form but will advance to the next record number as if they are going to create a new record on that form. In this way, they unwittingly navigate off of the record they just created, which could be confusing and could cause new records to get inadvertently created when they shouldn't.

Bug fix: If using the Real Time Execution feature for a Data Quality rule, in which it determines on a data entry form that a DQ rule was violated while at the same time a required field was left empty/blank on the form after clicking a Save button, it would only display the "Some fields are required!" popup and would mistakenly not display the "Data Quality rules were violated!" popup, which could cause some confusion and might accidentally cause a user to not be aware of a DQ rule that was violated. It has been changed so that if both issues occur at the same time, it will now display both popups at the same time on the page so that the user is aware of them both.

Bug fix: When utilizing Automated Survey Invitations in a project in which an ASI has the option "Ensure logic is still true before sending invitation?" enabled and the ASI is using only conditional logic as the Condition in Step 2 and *not* basing it off of whether a survey has been completed, then it would

mistakenly display empty duplicate rows in the Survey Invitation Log. Note: This would not affect how or when survey invitations were sent.

Bug fix: If the Double Data Entry module is enabled for a project, then the correct form status icons will mistakenly not display correctly on the Record Status Dashboard for DDE user 1 or 2, but instead it will only display gray icons for all forms/records.

Bug fix: An SQL query that would get executed after a user logged in might be really slow for some server configurations. It has been optimized to reduce any slowness.

Bug fix: When downloading a PDF of a data entry form with data, in which all the field's in a section are hidden by branching logic, it might mistakenly display the section header for that section in the PDF instead of hiding it if the section would have spilled over onto the next page if it would have been displayed.

Bug fix: If a drop-down field on a survey or data entry form has a very long choice label, then the drop-down would mistakenly spill out of the table and could crowd other fields and text on the page, thus distorting the whole form/survey.

Minor security fix: A cross-site scripting vulnerability was found on the Install page that could possibly be exploited if a malicious user knows how to append certain characters into the web address for the page. However, the ability of a user to take advantage of this vulnerability is severely limited.

Bug fix: If the user is creating a new record on a data entry form (i.e., record auto-numbering is not enabled), then after they place their cursor inside the text box to enter a new record name, it would mistakenly not allow them to remove their cursor in order to do something else on the page if they have not entered anything yet, in which the only way to get the cursor out of the text box is the refresh the page.

Bug fix: If a project using the randomization module has the randomization field set as "required" and also has Left/Vertical? or Left/Horizontal? custom alignment, then the red "*must provide value" label for the field as displayed on the survey page or data entry form would mistakenly not display correctly but get appended as black text onto the end of the Field Label.

Bug fix: If a user's project has drafted changes that are currently awaiting approval by an administrator, the user could mistakenly still upload a data dictionary before the administrator has reviewed and approved the changes. This would not cause any data loss but could cause confusion as to how the user made field changes while the project was in review.

Bug fix: When using the datediff() function in a custom data quality rule in the Data Quality module, if a record is missing a value for one of the dates used in the datediff() function in the DQ rule, it will mistakenly get returned as a discrepancy when in fact it should not return it as a discrepancy. This does not appear to affect any other advanced functions but only datediff() and only when used in the Data Quality module.

Bug fix: If HTML tags are used in the record ID field' Field Label in a project, then it would mistakenly display those tags as visible on the Record Status Dashboard table and (if a longitudinal project) also on the event grid after a record has been chosen.

If the Mcrypt PHP extension has not been installed on the REDCap web server, then the Stats & Charts page for reports would mistakenly not display correctly if the report contains any filters. The report would instead display plots representing *all* records in the project rather than just the records after applying the filter.

Change: Since the REDCap Mobile App is now available on the Amazon Appstore for Android, a link was added on the REDCap Mobile App page in each project to download the mobile app from the Amazon Appstore.

Bug fix: If a super user is on the Manage All Project Tokens section of the API page in a project or on the API Tokens page in the Control Center, if a user's username contains either a period/dot (.) or an "at" sign (@), then the Last Used column for that user will mistakenly never display the timestamp but will continually say "Loading...".

Bug fix: When using some non-English languages (specifically French) for a project's language, it might mistakenly not allow a production project to be moved to inactive status on the Other Functionality page because of a JavaScript? error that occurs.