Major bug fix: In the event that a public survey is being taken by a very large number of respondents simultaneously (e.g., hundreds or thousands of respondents per minute), there is a chance that some responses might mistakenly get merged together under the same record name when being saved, thus corrupting the data and making it difficult to manually split the separate responses into individual records. New methods have been implemented to ensure that this never happens.
Bug fix: When a user attempts to use the alternative method to obtain a mobile app initialization code on the REDCap Mobile App page in a project, if the REDCap web server is not able to communicate with redcap.vanderbilt.edu, which generates the code, then it would mistakenly return an incorrect 4-digit number to the user rather than the correct 10-character alphanumeric code.
Bug fix: In a longitudinal project containing multiple arms, if a user attempts to rename a record to a record name that exists in another arm, it would mistakenly display an error saying that the record could not be renamed. Instead, it should allow the record to be renamed for the current arm regardless of whether or not that same record name exists in other arms.
Bug fix: When using the Randomization module in a project and viewing the randomization dashboard page, the record names that appear in the "Allocated records" column of the table would mistakenly not wrap to the next line in the table cell but would instead be truncated.
Bug fix: When the cron job is expiring user accounts that have an expiration time set, it might mistakenly CC the sponsor of another user who is getting expired in that same batch of emails.
Bug fix: Confusing or incorrect instructions were given when exporting data into SPSS or SAS on a non-Windows operating system with regard to modifying the CSV data file's path in the syntax file.
Bug fix: When copying a project that has surveys, some survey attributes would mistakenly not get copied to the new project. This would include "display page numbers at top of page", "allow respondents to return and modify completed responses", "hide the Previous Page button", and the confirmation email settings.
Change: For clarity, a new note was added on the Security & Authentication page in the Control Center to denote that the Login Settings section is not applicable to Shibboleth authentication.
Post-release fix: If a project has record auto-numbering enabled and a user opens a data entry form to create a new record but instead clicks the Cancel button, then it would mistakenly skip a record number in the sequence when the next record was created.
Version 6.6.0 - codename "Frosted Sugar" (released 05/29/2015)
New features:
Twilio telephony/IVR services (SMS surveys and phone surveys)
Other changes in this version:
Bug fix: When using Rule H in the Data Quality module and clicking the "Fix calcs now" button, it would mistakenly not exclude any results that the user had explicitly excluded for that rule.
Bug fix: When using Rule H in the Data Quality module, in which one or more results had been excluded and then the rule was run again at a later time, then if the user clicked the "view" link in the results popup to view the exclusions, the "Fix calcs now" button would fail to work if the user tried to click it afterward.
Bug fix: When utilizing the Randomization module in a project that has UTF-8 encoded field labels for the randomization field or the strata fields used (especially if multi-byte characters are used in the label), then on certain occasions the Randomization Dashboard page would not display correctly.
Bug fix: When survey participants returned to a partially completed survey, in which it displayed the "Start Over" button to allow them to erase their current responses and start the survey over from the beginning, it was too easy for them to accidentally click this button without realizing the repercussions of data loss. It now gives them an extra confirmation dialog that they must click so that they more fully understand the repercussions before starting the survey over.
Version 6.5.0 - codename "Oatmeal Raisin" (released 05/22/2015)
NEW FEATURES & IMPROVEMENTS:
New feature: 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.
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.
Admins: If you do not want your REDcap end-users to be able to use the mobile app at all, the mobile app can be disabled at the system level, if desired. When disabled, it will hide all information and all pages that mention the mobile app as if it does not exist. This setting is located on the Control Center's Modules Configuration page.
New feature: 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.
New features: 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.
New feature: 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 searcing the REDCap Shared Library.
New feature: 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.
New feature: 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).
New feature: 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.
Improvements to the REDCap Upgrade Module
Improvement: The REDCap Upgrade module now has an option to download the SQL upgrade script as a file, which can be saved on the database server and then executed by MySQL command line. The upgrade module displays instructions on how to execute that file in MySQL, which sometimes may be preferable to executing all the SQL upgrade commands in a window in a MySQL client, which could time out if it runs too long.
Improvement: REDCap can now (on certain occasions) be upgraded to a newer version without being taken offline. The upgrade module now has the ability to let an administrator know if an upgrade can be performed without setting REDCap's online status to "offline" beforehand. If the upgrade module detects that this is possible, it will provide a note about it in Step 1 of the upgrade page. In instances where REDCap is upgraded without being taken offline, there are special safeguards in place to prevent loss of data while users are using REDCap during the upgrade. Being able to upgrade REDCap without taking it offline will be a great asset to institutions that upgrade often.
New feature: 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.
Improvement: 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.
Improvement: On the Browse Users page in the Control Center, a new user account setting called "Display user on 'Email Users' page?" can be set to "No" so that an individual user will no longer be displayed on the Email Users page in the Control Center, thus preventing them from receiving any emails sent using that page. This can be useful if a user requests to opt out of system-wide announcements sent to REDCap users by administrators, for example.
Improvement: The Data Entry Trigger now sends the parameter "username" to the defined URL. This corresponds to REDCap user that is triggering the Data Entry Trigger. Note: If it is triggered by a survey page (as opposed to a data entry form), then the username that will be reported will be '[survey respondent]'.
Improvement: New option for Automated Survey Invitations to ensure that the ASI's conditional logic is still true before sending the survey invitation. When enabled, REDCap will re-evaluate the logic against the record's data values whenever the record values are changed AFTER the invitation has been scheduled but BEFORE it has been sent to the respondent. And if the logic is no longer true (i.e., if the data values have changed during the time after the survey invitation was scheduled), it will not send the invitation to the respondent but will instead delete it (as if it had never been scheduled). Additionally, if the invitations get deleted due to this setting, then the invitations *may* get scheduled again later if data values are changed such that the logic evaluates as true again. Enabling this setting provides you with greater control over when and how invitations get sent when using conditional logic for Automated Survey Invitations.
BUGS & OTHER CHANGES:
Major bug fix: For user-uploaded files on the File Repository page in a project, it is possible for a user to manipulate the URL of a given uploaded file and be able to view the name/label, filename, and upload date of files in the File Repository of other projects to which the user does not have access. The user would not be able to edit or delete the files from other projects, but could only view the file's associated metadata information.
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.
Major bug fix: If any data had been imported into REDCap using the Dynamic Data Pull (DDP) module, it would no longer be able to display the data in the DDP adjudication popup. This is due to an inadvertent, recent change in REDCap to accommodate issues with Mcrypt in PHP 5.6. REDCap will have to refresh the cache of all non-adjudicated data imported via DDP from the source system. This will not affect any data that has already been imported via DDP. The data refresh may take several hours to complete after the REDCap upgrade has finished.
Major bug fix: When using the round() function in a calculated field, in which the calculation results in a value of "0", it might get mistakenly reverted back to a blank/null value if running Rule H on the Data Quality module or if an auto-calculation is triggered when using cross-form or cross-event calculations. This bug emerged in REDCap 6.3.0.
Improvement: Longitudinal projects using lots of calc fields should now experience a speed improvement when it comes to performing and saving auto-calculations on data entry forms/surveys and also for Rule H on the Data Quality page.
Improvement: General speed improvement when it comes to performing and saving auto-calculations on data entry forms/surveys. In versions 6.3.0 till 6.4.6, it would evaluate *all* fields on a form/survey when performing auto-calculations, but it now only evaluates fields on the page whose value was changed, deleted, or added. This will allow it to ignore irrelevant fields and thus increase the processing speed of calculated fields in general.
Improvement/change: On the "Data Exports, Reports, and Stats" page, the multi-select boxes (e.g., those in User Access or in Additional Filters section) now behave more intuitively when users select choices from them. Users no longer need to hold down the Ctrl/Command button when clicking multiple choices, but instead simply clicking a choice adds it as selected without de-selecting the other options already selected.
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.
Improvement: Added new "Edit project settings in Control Center" link at the top of every project's Project Setup page (can be seen only by super users), which allows them to navigate to the Control Center in order to modify any project-level settings that only administrators are allowed to modify (e.g., enable Double Data Entry).
Change: The parent-child functionality (i.e. project linking feature) has been removed in REDCap 6.5.0 and all versions thereafter. Any projects that were using the parent-child functionality will now operate as normal projects do and will no longer be linked to each other in any way. All functionality related to the parent-child feature (e.g., being able to export parent data from the child Data Export page, viewing parent or child forms on the left-hand menu of the other project) will cease to work and will be removed automatically. However, during the REDCap upgrade process, a project bookmark will be added to both the parent and child project so that users can navigate back and forth easily from the parent project to the child (and vice versa). And if a record is being viewed in the child, then clicking the bookmark will take the user to that same record in a data entry form in the parent project (and vice versa). For the announcement and discussion of why this feature was removed, please see https://groups.google.com/d/msg/project-redcap/CqXDO2JjawU/Kokyz4vhu6wJ
Change: Temporary passwords are no longer sent in emails when resetting passwords for Table-based users or when creating new Table-based user accounts. Instead, a unique link is sent in the email that will allow the user to set a new password for their REDCap account.
Improvement/change: The Browse Projects page in the Control Center no longer displays Archived projects by default but instead displays a "Show Archived Projects" link at the top of the page that, when clicked, will display the Archived projects in the project list.
Improvement: If using the Dynamic Data Pull (DDP) module in a project, and the value of the source identifier field (e.g., MRN) for a given record is changed *after* REDCap has already imported and cached the data from the source system for that record, then it will now purge the previously cached values for the record, after which it will begin to import new data from the source system for the new value of the source identifier field.
Change: Information on the "sql" field type is no longer located on the REDCap consortium wiki but has been integrated into the Online Designer (for super users only).
Change: Record auto-numbering is enabled by default for new projects that are created from scratch.
Change: When performing a fresh installation of REDCap, all the template projects now have record auto-numbering enabled. (Note: This will not enable record auto-numbering for template projects that already exist.)
Change/improvement: When an administrator is approving production changes to a project, the optional feature to send the user an email so that they may confirm the pending changes now has slightly modified text for the pre-filled confirmation email in order to improve clarity regarding what the user should do.
Change: The auto-suggest functionality for searching for users on the Browse Users page, Browse Projects page, or User Rights page in a project now ignores commas so that more accurate results are returned in cases where a user enters "LastName, FirstName", for example.
Improvement: Added user's "sponsor" and "Institution ID" field for their user account to the popup that lists users on the Browse Users page in the Control Center.
Change: Due to the fact that Google is deprecating OpenID 2.0, which was used by REDCap in versions prior to REDCap 6.5.0, the "OpenID (Google)" authentication method in REDCap will now utilize Google OpenID Connect (OAuth2), which uses a different protocol. So as far as the REDCap user is concerned, their login process will not change at all. However, this change to using OAuth2 requires an extra setup step, in which a REDCap administrator must go to the Security & Authentication page in the Control Center and enter a Client ID and Client Secret if they are using the "OpenID (Google)" authentication method. If they upgrade to REDCap 6.5.0 and then log in, they will immediately see an error message giving the administrators instructions on how to obtain a Client ID and Client Secret for the Google API, which should only take a few minutes.
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.
Change: When adding the URL for a Data Entry Trigger for a project, it is no longer required to be full URL (beginning with "http") but can now be a relative link that begins with "/".
Change/improvement: New instructional text was added to the top of the "Help & FAQ" page to inform the user that they can use Ctrl+F (or Command+F) on their keyboard to do a keyword search on the page.
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. (Ticket
