Display v11 Update Info Display v12 Update Info Display v11 Update Info
Display v12 Update Info
Multi-Language Management (MLM) Overview Summary:
Users can create and configure multiple display languages for their projects for surveys, data entry forms, alerts, survey invitations, etc. Users can design data collection instruments and have them be displayed in any language that they have defined and translated so that their survey participants or data entry persons can view the text in their preferred language. This eliminates the need to create multiple instruments or projects to handle multiple languages. NOTE: The MLM feature will not auto-translate text, but provides tools so that users may easily translate them themselves.
Configuration:
Each language must be "initialized" within the project before translations can be configured. When adding a new language to a project, it should be selected from the Language Library (vs. starting from scratch). When adding from the Language Library, all of the User Interface translations (see below) are included, as these translations are common to all projects. Currently, JH REDCap has the following languages avaialble in the Language Library:
English Spanish / Español Portuguese Korean Chinese / Mandarin French There are three translation components associated with each language translation.
Instrument Translations Survey Language Translations *User Interface (UI) Translations (see note below) Instrument Translations: These are the translations associated with each instrument in the project (Demographics, History/Physical...). For each instrument, the language translations are provided for every field. If a translation is not provided for a field, it will default to your default translation (typically, this is English). If the field has menu items (radio buttons, dropdowns, checkboxes), the translation for each option is also configured.
Survey Language Translations: These are fewe additional translations for an instument when it is enabled as a survey. Included are items like "Survey Title" and "Survey Instructions".
User Interface (UI): There are MANY items on a typical REDCap data entry screen or a survey that are common to ALL REDCap projects and instruments. Examples include "Must provide a value" and "Reset". Additionally, there is a long list of messaging that may be displayed during data entry ("Next Page", "Previous Page", "Save and Return Later"). There are approximately 500 items to be translated.
*NOTE: When adding a new language to a project from the Language Library, all of the UI translations are included. These translations have been provided by JH Language Services are are pre-approved.
Usage:
When entering data on a data entry form or survey, users and study participants have the ability to select their preferred language from a drop-down list or buttons on the page (for languages available within that project). When a user selects a language on a data entry forms, that selection is stored in the users account settings (under the hood). When a survey participant selects a language, their language preference is stored in a cookie in their web browser to be used if/when they return in the future (and also to maintain their selected language from page to page). It is also possible to pre-select the language for a participant. To do this, a field is added to the project where the preferred language can be prefilled. Then, that field is referenced as the Language preference field setting on the MLM page for the project. Alternatively, the @LANGUAGE-FORCE action tags (described further below) can be used.
User Rights:
A user must have Project Design/Setup privileges in a project in order to see the link to the Multi-Language Management configuration page (left-side menu).
Notes:
The MLM feature works seamlessly with SMS messages sent via Twilio. Additionally, the MLM feature works with the e-Consent Framework, in which the archived PDF of the participants consent form will be stored in the File Repository in the same language in which the participant took the survey.
When a project is in production, the MLM page and all translations can only be modified when the project is in Draft Mode. If edits or additions/deletions are necessary, the project must first be put into Draft Mode via the Online Designer. Then, return to the MLM page to make translation changes while in Draft Mode. Once submitted and approved, the translation changes made in Draft Mode will be applied.
Back to Top
Multi-Language Management (MLM) (Related Action Tags)
Several new action tags have been added relating to the new MLM functionality.
@LANGUAGE-CURRENT-FORM - Allows you to capture the currently used language in projects where multilingual data is enabled on data entry forms. The @LANGUAGE-CURRENT-FORM action tag can be used on fields of type 'Text Box' (no validation), and 'Drop-down List', or 'Radio Buttons' (these need to have choices whose codes correspond to the IDs of the defined languages - e.g., 'en'). This action tag is only active on data entry forms and will always, when possible, set the field's value to the currently active language. @LANGUAGE-CURRENT-SURVEY - Same as @LANUGAGE-CURRENT-FORM, but works only on survey pages. For multi-page surveys, @LANGUAGE-CURRENT-SURVEY needs to be used on a field of each page where capture of the language is relevant (e.g. for performing branching). @LANGUAGE-FORCE - When used on a field, the data entry form or survey on which the field is located will be rendered in the specified language (which must have been set up using the Multi-Language Management feature). The format must follow the pattern @LANGUAGE-FORCE="???", in which the ID of the desired language should be inside single or double quotes - e.g., @LANGUAGE-FORCE="de". Piping is supported - e.g., @LANGUAGE-FORCE="[_name]". When the language is forced successfully (i.e., it exists and is active), the language selector is hidden. Using this together with @LANGUAGE-CURRENT-FORM/SURVEY on the source field for @LANGUAGE-FORCE may be used to 'lock in' a user to their selected language. @LANGUAGE-FORCE-FORM - Same as @LANGUAGE-FORCE, but the effect is limited to data entry forms (i.e. this does not affect surveys). @LANGUAGE-FORCE-SURVEY - Same as @LANGUAGE-FORCE, but the effect is limited to surveys (i.e. this does not affect data entry forms). @LANGUAGE-SET - When used on a Drop-down or Radio Button field only, this action tag will allow the field's value to control the currently shown language (in the same way as switching the language via the buttons at the top of the page). Tip: When used in a survey, this field could be prepopulated (and thus auto-selected) by embedding a participant's language ID in the survey URL itself (for details, see the FAQ's "How to pre-fill survey questions" section). Back to Top
Multi-Language Management (MLM) (FAQ's) What if I am currently using the Multilingual External Module (EM)
The multilingual EM will be supported for the foreseeable future. Projects using currently using the EM will need to decide if migrating to the new MLM is best for their project needs. If the project will be ending in the short-term, migrating to the new MLM is not necessary. Projects expecting to run for a longer period may want to consider moving to the new MLM. Look for more informatoin soon on how to migrate from the EM to the new MLM feature.
Will the current EM be maintained going forward and is it compatible with the most recent updates?
Like all EM's, the Multilingual EM was written by a third-party (another institution who wrote the code for their needs and made it available to the larger REDCap community. It is one of the most utlilized EM's. However, that site has not maintained it over time. So, there are some issues that need to be addressed to accommodate core REDCap changes that have happened over time. There is discussion about having this EM taken over by another group in order to address some of the existing issues. From what we can tell, none of these issues will "break" the EM. However, it can (in certain situations) create some unanticipted formatting. More information will be made available on this topic in the near future.
The new MLM looks/sounds complicated!
Like most new features, it takes a little time to get your bearings when navigating the MLM configuraiton pages. But after working with it for a bit, the navigation becomes more familiar and intuitve. Dive in. It won't be long before you become familiar with it.
It looks like I can create my own language from scratch - While it is possible to create (initialize) your own language from scratch, we strongly advice not doing so. Initialize your language by importing from the Language Library. This brings over approximately 500 User Interface (UI) translations that are common to all REDCap projects. These have been provided by JH Language Services and are approved for use. This allows you to focus on the translations for your specific project content.
What if I need a translation that is NOT in the Language Library
The JH REDCap team works closely with JH Language Services. If you need a language that is not currently in the Language Library, reach out to the REDCap Admin Team. They will work the JH Language Serices to create the core content for the needed language. This will not only benefit your project, but all future projects that might need the same language translation.
Can I create the project specific translations myself?
All translations require JH Language Services approval. This is JH policy. You can create your own project/instrument translations and have them approved by JH Language Services... or you can ask them to do the translations for you.
Back to Top
Form Display Logic (FDL) Overview Summary:
Form Display Logic is an advanced feature that provides a method for using using conditional logic to disable specific data entry forms. When utilized, FDL disables instruments on the Record Status Dashboard, Record Home Page, and the form list on the left-hand menu. It is best thought of as 'form-level branching logic'. With FDL, it is possible to block access to an instrument under certain conditions (or until certain conditions are met). The instrument "bubbles" will still be displayed, but they will be disabled.
Usage Examples:
Disabling a "post surgery" instrument until the surgery has actually occurred. Disabling a "Women's Health" instrument when the participant is male (and vice-versa). Disabling intsruments until a participant is consented. Some Considerations:
The FDL does not impact data imports but only operates in the data entry user interface to enable/disable forms. FDL is not utilized by the Survey Queue, but can affect the behavior of the Survey Auto-Continue feature if the checkbox for it is enabled in the Survey Queue setup. Configuration:
The FDL configuration is pretty straightforward.
Click the "Form Display Logic button (on the Online Designer Page). Select the intended instrument(s) Note that multiple instruments may be selected for specific events or "all events". Enter the logic (the condition under which the instrument should be enabled) Save the "Condition" Create as many "Conditions" as necessary, keeping in mind that an instrument will be displayed if any of the "Conditions" evaluates to "True".
@IF Action Tag Overview Summary:
The @IF() action tag allows various action tags to be set based on conditional logic provided inside an @IF() function. For example, there is another action tag @HIDE-CHOICE that hides an option in a menu field (radio button, dropdown, checkbox). The @IF() action tag can be used in conjuction with the @HIDE-CHOICE action tag to hide certain menu options under various conditions.
Usage Examples:
Example 1: A "Clinic" field has two options for various clinic sites. A "Physician Seen Today" field has a master list of all physicians. However, the physicians may not work at both clinics. Use the @IF() action tag for the physicians field to limit the displayed menu options based on the selected clinic: @IF([clinic]='1', @HIDE-CHOICE="1,3,7,8", @HIDE-CHOICE="2,4,9") Note that if the clinic is "1", physicians 1, 3, 7, and 8 are hidden. Otherwise, hide choices 2, 4, and 9. Example 2: Field A collects the type of surgery Field B collects the complications You might use the @IF() action tag to only display certain complications based on the type of surgery. Example 3: You can "nest" @IF() statements to cover multiple situations. For example, if Example 1 had 3 clinic sites, the logic might look something like this: @IF([clinic]='1', @HIDE-CHOICE="1,3,7,8", @IF([clinic]='2',@HIDE-CHOICE="2,4,9, @HIDE-CHOICE="5,6")) Note that the "else" side of the first @IF() contains another @IF(). Nesting @IF() statements allows for more than just 2 conditions. Some Considerations:
You may have multiple instances of @IF for a single field. You may also have multiple nested instances of @IF() inside each other. Both field variables and Smart Variables may be used inside the @IF condition. The @IF action tag is also evaluated for a given field when downloading the PDF of an instrument/survey, in case there are any PDF-specific action tags used inside of @IF(). Note: The conditional logic will be evaluated only when the survey page or data entry form initially loads; thus the action tag conditions will not be evaluated in real time as data is entered on the page. Back to Top
Tableau Data Export Extract all records into Tableau via the REDCap API.
This feature enables Tableau (v10.0+) users to connect Tableau to a REDCap project using an API token. Project data can be exported on demand and be available for use within Tableau to produce summaries and visualizations. The Other Export Option page in any given project has instructions to export project data into Tableau. NOTICE: It is required for a user to have an API token generated for the project in order to use this feature. Back to Top
New Action Tags Several new Action Tags have been added.
New Action Tags for Multi-Language Management (click HERE for a detailed explanation) @IF (click HERE for a detailed explanation) @RICHTEXT Adds the rich text editor toolbar to a Notes field to allow users/participants to control the appearance (via styling and formatting) of the text they are entering into the field. @DOWNLOAD-COUNT The @DOWNLOAD-COUNT action tag provides a way to automatically count the number of downloads for a File Upload field or a Descriptive field attachment. It can be used on a Text field or Notes field so that its value will be incremented by '1' whenever someone downloads the file for either a File Upload field or a Descriptive field attachment. The variable name of the File Upload field or Descriptive field whose downloads are to be counted should be provided inside the @DOWNLOAD-COUNT() function. For example, the Text field 'my_download_count' might have its action tag defined as @DOWNLOAD-COUNT(my_upload_field), in which 'my_upload_field' is the variable of a File Upload field. Whenever the file is downloaded on a data entry form, survey page, or report, the value of the field with this action tag will be incremented by '1'. If that field has no value or has a non-integer value, its value will be set to '1'. NOTE: The download count field must be in the same context as the File Upload field or a Descriptive field. This means that in a longitudinal project the two fields must be on the same event, and in a repeating instrument context, they must be on the same repeating instrument. @MAXCHOICE-SURVEY-COMPLETE Similar to @MAXCHOICE but only counts choices on completed survey responses (does not count data entered as data entry only or on partial responses). Causes one or more specified choices to be disabled (i.e., displayed but not usable) for a checkbox, radio button, or drop-down field after a specified amount of records have been saved with that choice for completed survey responses only. Back to Top
DAG: Identify Unassigned Records There are scenarios where a project using Data Access Groups (DAG's) can end up with records that are not assigned to any of the data access groups. Some examples of how this can happen include:
A record is created (in a project using DAG's) by a user who is not currently assigned to a DAG and the user fails to manually assign the record to a DAG. A record is created via a Survey. Data is imported without being assigned to a DAG. Identifying unassigned records can be difficult. Previously, the "Record Status Dashboard" provided a DAG filter allowed the user to filter records assigned to a specific DAG. v12 introduces a filter option for records that are NOT currenlty assigned to a DAG. This should make it easier for projects to identify these records and assign them to the appropriate DAG.
New Smart Variables Several new Smart Variables have been added.
46136 (longitudinal only) The event id number of the current event. 1 The current event's ordinal number as listed on the Define My Events page that denotes the order of the event within a given arm. PJLK3P9D7 The Survey Access Code of the specified survey for a given record/event/instance. The format must be PJLK3P9D7 or PJLK3P9D7, in which 'instrument' is the unique form name of the desired instrument. This can be used simply as PJLK3P9D7 inside the content of a survey invitation, in which 'instrument' is assumed to be the current survey instrument. ______ The Survey Return Code of the specified survey for a given record/event/instance in order to allow a participant to return to a completed or partially completed survey response when using the 'Save & Return Later' survey feature. The format must be ______ or ______, in which 'instrument' is the unique form name of the desired instrument. This can be used simply as ______ inside the content of a survey invitation, in which 'instrument' is assumed to be the current survey instrument. ______ The Role ID of the user role to which the current user is assigned (blank if not assigned to any user role). This value is auto-generated for each user role. NOTE: This value is not just unique for all roles within the project but is also unique across all REDCap projects. Thus, if the project and its user roles are copied, the Role IDs of the user roles in the resulting copy will be different from the ones in the original project. ______ The unique role name of the user role to which the current user is assigned (blank if not assigned to any user role). This value is auto-generated for each user role. NOTE: This value is only unique for roles within the project. Thus, if the project and its roles are copied, the new project will retain the same unique role names, which allows you to utilize the unique role names in conditional logic, calculations, branching logic, etc. that will not break when the project is copied. ______ The name/label of the user role to which the current user is assigned (blank if not assigned to any user role). This value is defined by the user that creates the user role. Back to Top
Live Filters for Reports A and B Reports A and B now have built-in Live Filters for the following:
The Record ID Field A List of Events - applies only to longitudinal projects A List of all Data Access Groups - for projects using Data Access Groups where the current user is NOT assigned to a Data Access Group (meaning that user has access to ALL records in the project).
Generate a PUBLIC Link to a Report When editing a report, users can now set a report as public and can obtain a public link to the report if they have User Rights privileges in the project. When a report is public, this means that all data in the report will be fully accessible (with no authentication required) to anyone with the public link to the report.
Configuration:
In order to make a report public, all the following must be true: The user must have User Rights privileges in the project or be a REDCap administrator. The report cannot have any Identifier fields in it. The user is required to view the report during their current REDCap session. The user must agree to and check off the following statements: 1) I understand that making this report "public" means that all data in the report will be fully accessible to anyone with the public link to the report, and 2) I understand that I am responsible if any private, sensitive, or identifying data in the report is exposed to persons who should not have access to such data. The behavior of how reports are made public can be controlled at the system level near the bottom of the User Settings page in the Control Center using the setting Allow reports to be made 'public'?. Admins may completely disallow reports to be made public (although admins will still have this ability to do so). But if enabled, they may choose to allow users to make reports public on their own or enable the To-Do List approval process by which an admin will need to approve their request to make a given report public (similar to the same system level approval process for Project Dashboards being made public). Once a report has been made public, its configuration cannot be modified while it is public (users cannot add new fields, modify filter logic, etc.). In order to modify a public report, the user will need to make it no longer public, then make their changes, and then make it public again. NOTICE: Just because a report does not contain any identifiers, that does NOT mean that the content of the report is not confidential and/or proprietary. Also, keep in mind that certain fields may not be tagged as identifiers in your project, but can most definitely be used as identifiers in certain circumstances. Some examples...
Data that identifies a patient as being 90+ years old (age, year of birth...) Many dates are considered by HIPAA to be identifiers, but are not tagges as identifiers
How To Generate a PUBLIC Report Link Configuration:
Create the report View the report during the current session Enable the Set as "public" option Next, you must agree to the terms of making a report public
Once complete, a public facing link (url) is provided
HTML Now Applied to Text / Note Fields in Rpts Summary: Any HTML formatting that exists in the value of a Text field or Notes field will no longer be ignored on a report (i.e., displayed as-is). Instead, the HTML will be interpreted on the report to allow for the styling of text on the page. While previous versions would have displayed the text value "<b>Word</b>" as "Word" (not bold) on a report, v12 now interprets and applies the HTML. In the example above, REDCap will now display "Word " (bold) on a report.
Note: This does not affect data exports or any pages other than reports.
(For more information on allowing the use of rich text in data entry (allows for formatting of text and note fields), click HERE.)
Email / SMS Logging Page Summary: This new project page contains a search interface to allow users with User Rights privileges to view ALL outgoing emails for that project (also includes searching and viewing of SMS messages if using Twilio services). It provides the following features
Search: Search all outcoing emails for the project (also includes searching / viewing of SMS messages if using Twilio services). Re-send: When viewing an individual email after performing a search on the page, a Re-send email button will be displayed in the dialog to allow users to re-send the email. Note: If the original email contained email attachments, the attachments will not be included in the email that is re-sent. Failure Logging: Failed email (or SMS) messages can be reviewed and evaluated. Note:
Only users with User Rights privileges may access this page. Additionally they must opt-in and agree to a disclaimer before being able to view the page.
The following text will be presented to the user before accessing the page: Before viewing and accessing this page, you must first agree that you understand the following important information and conditions. This page is only accessible by users having User Rights privileges in this project. The Email Logging feature allows users to search and view *all* outgoing emails related to this project, and this includes being able to view all aspects of any given email (i.e., the recipient(s), sender, subject, message body, attachment names). If you are using anonymous surveys in this project, keep in mind that viewing this page and the emails displayed therein might inadvertently cause anonymous survey responses to be identifiable/de-anonymized. Additionally, if the project is using Data Access Groups, you will be able to view the emails related to all DAGs in this project (and thus possibly any data piped into the body of those emails). If you understand and agree to these conditions, click the button below. Please note the act agreeing to this disclaimer will be documented on the project Logging page .
Miscellaneous Updates / Improvements Summary: REDCap v12 brings several updates and improvements to increase the value it brings to research projects. Below is a list of several new updates / improvements included in v12.
Help & FAQ Page: New feature: New design for the "Help & FAQ" page. Branching Logic: New feature: Project-level setting "Prevent branching logic from hiding fields that have values" This setting can be enabled by any project user with Project Setup/Design privileges in the Additional Customizations popup on the Project Setup page. This setting affects both data entry forms and surveys. If it is not enabled (default), then whenever a field is to be hidden by branching logic on a data entry form, it will always ask the user if they wish to hide the field and erase its value, whereas on survey pages it will automatically erase the value of the field being hidden without displaying the confirmation prompt, which has always been the default behavior for surveys. If this setting is enabled, the branching logic behavior will change so that fields with values will not cause the 'Erase the Value of the Field?' confirmation prompt to ask the user if they wish to keep the value or hide the field, and instead fields with values will not be hidden by branching logic and will stay visible. Thus they will be exempt from branching logic. This will prevent data from being erased as it normally does if fields are hidden by branching logic. When a field should be hidden by branching logic but is not hidden because it has a value, an icon will be displayed on the field to indicate this to the user. This project-level setting is included in the API Export Project Info method as "bypass_branching_erase_field_prompt". The REDCap Mobile App will soon have this same functionality, but it will only work if the REDCap server is on REDCap 11.2.0 or higher. The name of Data Quality rule F has been slightly changed when this setting is enabled from "Hidden fields that contain values" to "Fields that contain values that should be hidden". Report Display / Data Exports: Improvement: When creating/editing a report, the "Additional report options" section in Step 2 now contains the new options below: For projects that have repeating instruments and/or repeating events, the repeating fields that are automatically added (e.g., redcap_repeat_instrument and redcap_repeat_instance) can now be excluded from the report and data export. These fields are displayed by default in reports/exports. Users may choose to display the field label, variable name, or both (default) in the header of a report. Note: This is only used when viewing reports and thus is not applicable for exports since there already exist options for choosing raw vs label format in data exports. Users may choose to display the field label, raw data value, or both (default) for multiple choice fields in the data displayed in a report. Note: This is only used when viewing reports and thus is not applicable for exports since there already exist options for choosing raw vs label format in data exports. Improvement: If the value of a Text field or Notes field contains a URL or email address, the URL or email address will be converted into clickable link and mailto link, respectively, when viewing the data in a report. Improvement: New data export option - "Export blank values for gray instrument status" All instrument complete status fields having a gray icon can be exported either as a blank value or as "0"/"Incomplete". In previous versions, they could only be exported as "0". By default, they are now exported with a value of "0", but this option can be changed via a drop-down option in the "Advanced data formatting options" section of the data export dialog. Note: Exporting gray instrument statuses as blank values is recommended if the data will be re-imported into REDCap. For example, when users export a Project XML file for a project and then create a new project with it, all the gray instrument status icons will be preserved in the new project, whereas in previous versions they were all converted into red status icons. Improvement: When printing a report, the "Number of results returned" and "Total number of records queried" counts are now included in the printout of the page. Piping: Improvement: New piping parameter ":ampm" - When piping a time, datetime, or datetimes w/ seconds Text field, appending ":ampm" to the variable name (e.g., [visit_time:ampm]) will display the time in am/pm format (e.g., 4:45pm, 10:35am) instead of military time. Data Access Groups (DAG's): Improvement: If a user is not assigned to a Data Access Group in a project, the user will now see a new "[No assignment]" option in the "Displaying Data Access Group" drop-down list on the Record Status Dashboard, in which selecting that option will display only records that have not been assigned to any DAG. Online Designer: Improvement: "Previous instrument" and "Next instrument" buttons were added at the top right of the Online Designer field-view page to allow easier navigation between instruments . Improvement: When users download an Instrument ZIP file for a given instrument in the Online Designer, the zip file now includes all survey settings for the instrument if the instrument has been enabled as a survey, including various files (e.g., survey logo, confirmation email attachment). The downloaded Instrument ZIP can then be uploaded into any project to transfer both the fields and all the survey settings. Improvement: In the Online Designer, the "Custom text to display at top of survey queue" now utilizes the rich text editor to make it easier to style the custom text. Improvement: The Project Revision History page now displays icons next to each production revision and snapshots, and after being clicked, will display options to compare that revision/snapshot with any other revision/snapshot in the project. (This feature represents the integration of the "Data Dictionary Revisions" external module created by Ashley Lee at BC Children's Hospital Research Institute). Improvement/change: The Online Designer now denotes whether a field on the instrument contains embedded fields inside its label, choices, notes, etc. by displaying a blue box saying "Contains embedded fields". This is similar to the green "Field is embedded elsewhere on page" boxes for embedded fields themselves. Project Setup Improvement/change: The Define My Events page now displays a new column to display each event's Event ID number. Also, the Smart Variable corresponding to each column in the table on the Define My Events page (e.g., 1, [event-label) are displayed in small gray text below the header text in the table to help users more easily learn where the values of those Smart Variables originate. Logging: Improvement: More detailed logging descriptions on the Logging page for report-related logged events, such as mentioning the report name and report ID. Improvement: Errors displayed in the Survey Invitation Log when sending SMS or Voice Calls via Twilio will now display the full error message returned by Twilio's API to provide the user with more information regarding why the SMS/Voice Call failed to send successfully. User Rights: New features: New drop-down options on the User Rights page to allow users to perform the tasks listed below using a CSV file in the user interface. Upload users and their privileges Download users and their privileges Upload user roles and their privileges Download user roles and their privileges Upload user role assignments Download user role assignments eConsent: Improvement: When using the eConsent Framework in a project, the "PDF Survey Archive" tab on the File Repository page now displays a "Download all" button that will download all PDF files displayed on the page in a single zip file. Additionally, there is a record filter drop-down list and a "file type" drop-down list, which distinguishes between general "PDF Auto-Archiver" PDFs and "eConsent Framework" PDFs. Note: If a user is in a Data Access Group, they will only be able to download and filter on records in their DAG. Data Quality: Improvement: When executing many data quality rules at once, the total time to finish all the rules occurs 3X faster. Instead of running only one rule at a time in a serial fashion, REDCap now executes three rules simultaneously when clicking the "All", "All except A&B", and "All custom" buttons at the top of the Data Quality page. Improvement: When using the ''Reason for Change'' feature in a project, a new button is displayed underneath each "reason for change" textbox on the Data Import Tool summary page. Users can simply click the button to copy the text to all other "reason for change" textboxes on the page, thus saving lots of time of having to add text to each individually. This feature is the integration of Luke Steven's "Copy Change Reason" external module, which will be automatically disabled at the system-level when upgrading to (or past) REDCap 11.4.0 to prevent any conflicts. SQL Fields: Improvement: SQL fields can now be used in the following Smart Charts: bar-chart, pie-chart, and donut-chart. Improvement: SQL fields can now be used as Live Filters in reports. Surveys Change/improvement: When a survey participant partially completes a survey that has the "Save & Return Later" feature enabled, and an email is then sent to the participant to remind them to finish their survey later, instead of sending that email from the system-level "Email Address of REDCap Administrator" (as in previous versions), the "From" email address of the "Survey partially completed" email will be set to the sender's address from the most recent survey invitation received by the participant. This will create more consistency and will reduce confusion for participants when attempting to reply back to the email, as has been a problem in the past. Significant Bug Fixes (v12.0.8)
Major bug fix: When the "Enable support for Survey Auto-Continue" option is checked in the Form Display Logic setup dialog, the feature might mistakenly fail to evaluate the logic correctly during the Survey Auto-Continue process. Thus, it could cause some surveys to get skipped unintentionally Major bug fix: When using Twilio SMS or Voice Call functionality on a survey, field labels or section headers might mistakenly not get included in the SMS message or Voice Call message unless one or more languages have been defined and are active on the Multi-Language Management page. Major bug fix: When a field is embedded on a multi-page survey, in which the embedded field's parent field is used in branching logic on a later page, the embedded field's value might mistakenly get erased when a later survey page is submitted if the embedded field is set as a Required field. Major bug fix: When a repeating instrument has data entered on multiple repeating instances, and then afterward the instrument is made to no longer be repeatable, then any new data entered on that data entry form for fields that already have data on other instance might mistakenly get stored in the wrong repeating instance (i.e., get orphaned in the "redcap_data" database table) and thus would fail to be seen when reloading the form again. Major bug fix: If using the AWS S3 file storage option, a fatal PHP error would occur when uploading or downloading documents, including on the Configuration Check page. Major bug fix: Fields embedded inside radio button and checkbox choices would fail to appear on data entry forms and survey pages. Project Dashboards (scroll down to view example)
INTRO: Project Dashboards are pages with dynamic content that can be added to a project. They can utilize special Smart Variables called Smart Functions, Smart Tables, and Smart Charts (described below) that can perform aggregate mathematical functions, display tables of descriptive statistics, and render various types of charts, respectively. User access privileges are customizable for each dashboard, and anyone with Project Design privileges can create and edit them. A Wizard is provided on the Project Dashboard creation page to help users easily construct the syntax for Smart Functions, Smart Tables, or Smart Charts, and a basic list of helpful examples is also included. To view a sample dashboard, click HERE.
Setting project dashboards as "public"
If enabled at the system-level (described in detail below), any project dashboard can be enabled as "public", which means it can be accessed at a unique URL that does not require any authentication. Making a dashboard public is useful if you wish for people to view it without having to be REDCap users or log into REDCap. Public dashboards are simply standalone pages that can be viewed by anyone with a link to them.
If a dashboard is made "public", the URL (link) can be customized using a url link service such as tinyurl.com.
System-level setting to allow/disallow public dashboards (on the User Settings page in the Control Center) - By default, normal users will be able to set any project dashboard as public. If you do not want users to do this or even know about this feature, you can completely disable it on the User Settings page. Alternatively, it can be set to "Allow public dashboards with admin approval only". If set to allow public dashboards after approval by an admin, the admin will receive the request from the user via the To-Do List page (and via email, if the email notification setting is enabled on the To-Do List page), and after the admin approves the request, the user will receive an email regarding the response to their request.
Setting to control data privacy on public dashboards and other public pages
The User Settings page in the Control Center has a setting to define the "Minimum number of data points required to display data for any Smart Charts, Smart Tables, and Smart Functions on a *public* project dashboard, survey queue, or survey page". By default, it is set to a value of "11". While only aggregate data is displayed in Smart Charts, Smart Tables, and Smart Functions, if any of these utilize very few data values, it might pose a threat to an individual's data privacy if these are being displayed on *public* dashboards and other public pages (i.e., where authentication is not used).
If someone is viewing a public page that has Smart Charts, Smart Tables, and Smart Functions that utilize data that does not meet the minimum data point requirement, instead of displaying the chart/table/number on the page, it will instead display a notice saying "[ AMOUNT OF DATA FOR DISPLAY]" with a pop-up note with details about the minimum data requirements.
Project-level override: While this behavior is controlled by a system-level setting, the system-level setting can be modified by an administrator via a project-level override for any given project on the "Edit A Project's Settings" page.
Note: This setting does not get used when viewing project dashboards inside a project (i.e., at a non-public URL).
PDF export: Each project dashboard can be exported as a one-page PDF file.
Dashboard cache: To prevent server performance degradation, each project dashboard will have its content cached (stored temporarily) automatically for up to 10 minutes at a time rather than generating its content in real time every time the dashboard is loaded. It will note at the top right corner of the dashboard page when the dashboard content was last cached. If a user is viewing the dashboard inside a project (i.e., not via a public dashboard link), they have the option at the top right to "Refresh" the dashboard at will, which will refresh/generate its content in real time. Note: The refresh option will only be displayed on the page when the dashboard content is at least 30-seconds old.
To view a sample dashboard, click HERE.
Back to Top
Smart Charts (scroll down to view examples)
Back to Top
Smart Charts are various aggregate plots and charts utilized as different Smart Variables. The following plots are available for use: bar charts, pie charts, donut charts, scatter plots, and line charts. These are all represented by the following Smart Variables, respectively: [-chart], [-chart], [-chart], [-plot], and [-chart]. These Smart Variables accept one or more field names and also other optional parameters, as described below for each.
Bar charts - Displays a bar chart for a single multiple choice field. It can optionally perform color grouping if a second field (multiple choice only) is provided. The fields must be comma-separated. For example, [-chart:field,grouping-field:parameters]. Bar charts have optional parameters that can be applied to alter their appearance. By appending the parameter ":bar-stacked" when two fields are used, the bars in the chart will appear stacked on top of each other rather than side by side. By default, bar charts are displayed with their bars going horizontally, but by appending the parameter ":bar-vertical", the orientation will be changed to display vertically instead.
Pie charts - Displays a pie chart for a single multiple choice field. For example, [-chart:field:parameters].
Donut charts - Displays a donut chart for a single multiple choice field.Note: A donut chart is essentially the same as a pie chart but with the center removed. For example, [-chart:field:parameters].
Scatter plots - Displays a scatter plot of one number/date/datetime field for the x-axis and a second field (number field only) for the y-axis. (If a second field is not provided, a random value will be assigned for the y-axis.) It can optionally perform color grouping if a third field (multiple choice only) is provided. All fields must be comma-separated. For example, [-plot:x-axis-field,y-axis-field,grouping-field:parameters].
Line charts - Displays a line chart of one number/date/datetime field for the x-axis and a second field (number field only) for the y-axis. It can optionally perform color grouping if a third field (multiple choice only) is provided. All fields must be comma-separated. Note: A line chart is essentially the same as a scatter plot except with dots connected with a line. For example, [-chart:x-axis-field,y-axis-field,grouping-field:parameters].
Color blindness accessibility: Pie charts and donut charts have the ability for the user to enable color blindness accessibility, via a gray link displayed immediately below each chart, in which it overlays different patterns onto the colored pieces of the chart to make each color more distinct for many types of color blindness. This option to enable color blindness accessibility is stored in a secure cookie on the user's device and will be used to remember this choice anytime a pie/donut chart is displayed on any page for any REDCap project for that REDCap server.
The colors displayed in each chart/plot are preset and are not modifiable.
Smart Charts can be used anywhere in a project where piping is allowed *except* for inside the body of outgoing emails.
Smart Tables Back to Top
Smart Tables are tables displaying aggregate descriptive statistics in which the results of any or all of the following stats functions can be displayed for one or more fields: minimum, maximum, mean/average, media, sum, count, standard deviation, count of missing values, and count of unique values.
Smart Tables are represented with the Smart Variable [-table], which accepts as a parameter the variable names (comma delimited) of all the fields to be displayed as separate rows in the table. There is no limit to the number of fields that can be used. For example, [-table:field1,field2,field3].
By default, all available columns will be displayed in the table and are as follows: Count, Missing, Unique, Min, Max, Mean, Median, StDev, Sum. To display only a subset of the columns, you may provide any of the following designations (comma-separated) that represent a specific column in the table: count, missing, unique, min, max, mean, median, stdev, sum. For example, [-table:field1,field2,field3:mean,max].
By default, each stats table will have an "Export table (CSV)" link displayed immediately below it to allow users to download the table as a CSV file. But if users wish to hide the export link, they can simply attach ":no-export-link" to the Smart Variable, which will cause the link not to be displayed. For example, [-table:field1,field2,field3:no-export-link].
Smart Tables can be used anywhere in a project where piping is allowed.
Smart Functions Smart Functions are aggregate mathematical functions that are utilized as Smart Variables. The following Smart Functions exist: [-min], [-max], [-mean], [-median], [-sum], [-count], [-stdev], and [-unique]. Each represents the mathematical functions minimum, maximum, mean/average, media, sum, count, standard deviation, and unique count, respectively. Each must have at least one field attached to it that follows a colon - e.g., [-mean:age]. Multiple fields may be used in each one, which will perform the function over all the data values of all the fields. By default, the functions will utilize all data values for all records in the project. To limit the data values being utilized to a subset of the total project data, see the Smart Variable documentation on how to apply filters, such as attached unique report names, DAGs, and other parameters
Note: When using [-count:record_id], in which "record_id" in this example represents whatever the variable of the Record ID field is, it performs a special count that does not literally count the number of data values but instead returns a count of the total number of records in the project. This is a quick way to display the total record count of the project.
Smart Functions can be used anywhere in a project where piping is allowed, and can even be used inside calculations, branching logic, and other conditional logic (report filters, alert conditions, etc.).
Back to Top
Smart Charts / Tables / Functions (Optional Parameters) There exist various optional parameters that can be used with Smart Functions, Smart Tables, and Smart Charts to either filter the data used in them (e.g., via a unique report name) or to change their appearance (e.g., bar-vertical). See the descriptions for each below, which are all documented in the Smart Variables documentation.
:R-XXXXXXXXXX Unique Report Name - For Aggregate Functions, Charts, and Tables, filter the data being used by appending a Unique Report Name. Next to each report on the 'My Reports & Exports' page is its unique report name, which has 'R-' following by alphanumeric characters. By default, all Aggregate Functions, Charts, and Tables will use the values of all records in the project, but if a unique report name is appended to any of them, only data from that specific report will be used. Using a report as a surrogate to filter data is a very useful technique of performing complex filtering logic for Aggregate Functions, Charts, and Tables.
:record-name "record-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the *current record* by using the literal value 'record-name'. Note: This parameter will only work in a context where a single record is being viewed/accessed, such as on a survey page, data entry form, etc. This parameter can be used with any of the other parameters except unique report names.
:event-name "event-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the *current event* (longitudinal projects only) by using the literal value 'event-name'. Note: This parameter will only work in a context where a single record/event is being viewed/accessed, such as on a survey page, data entry form, etc. This parameter can be used with any of the other parameters except unique report names.
:unique-event-names Unique Event Names - For Aggregate Functions, Charts, and Tables, filter the data being used to specific events (longitudinal projects only) by providing an event's unique event name (found on the Define My Events page). You may use one or more unique event names (comma-separated). Note: This parameter can be used with any of the other parameters except unique report names.
:user-dag-name "user-dag-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the records assigned to the *current user's Data Access Group* by using the literal value 'user-dag-name'. Note: This parameter will only work in a context where an authenticated user belongs to a project and has been assigned to a DAG in the project (this excludes survey pages and public project dashboards). This parameter can be used with any of the other parameters except unique report names.
:unique-dag-names Unique DAG Names - For Aggregate Functions, Charts, and Tables, filter the data being used to the records assigned to specific Data Access Groups by providing a DAG's unique group name (found on the Data Access Groups page). You may use one or more unique DAG names (comma-separated). Note: This parameter can be used with any of the other parameters except unique report names.
:bar-vertical "bar-vertical" - Display a bar chart with the bars going vertically instead of horizontally (the default) by using the literal value 'bar-vertical'. Note: This parameter can be used with any of the other parameters.
:bar-stacked "bar-stacked" - Only for bar charts using two fields, display the bar chart with the bars stacked on top of one another for each choice. Whereas the default view is that the bars of each field are displayed side by side to show the color grouping. To enable this, use the literal value 'bar-stacked'. Note: This parameter can be used with any of the other parameters.
:no-export-link "bar-stacked" - Only for bar charts using two fields, display the bar chart with the bars stacked on top of one another for each choice. Whereas the default view is that the bars of each field are displayed side by side to show the color grouping. To enable this, use the literal value 'bar-stacked'. Note: This parameter can be used with any of the other parameters.
Back to Top
Smart Charts / Tables / Functions (Usage Elsewhere In a Project) While project dashboards are an excellent place to use Smart Functions, Smart Tables, and Smart Charts, it is important to know that Smart Functions/Tables/Charts can actually be used *almost anywhere* in a project, such as on data entry forms, on survey pages, and in report instructions (to name a few). You can use Smart Functions/Tables/Charts anywhere that piping can be used. Click the green "Smart Variables" button on the Project Setup page to learn more about them. Note: The only place that Smart Charts cannot be used is inside the body of outgoing emails.
Back to Top
Smart Charts / Tables / Functions (Permissions) DAG permissions (i.e., filtering out records not assigned to the current user's DAG) are NOT applied by default to Smart Charts/Tables/Functions but are only applied when the Smart Chart/Table/Function utilizes a unique report name as a parameter (thus mimicking the natural DAG-filtering behavior of reports themselves) OR when the Smart Chart/Table/Function utilizes the "user-dag-name" parameter. This means that if a user is assigned to a DAG and views a project dashboard with the Smart Chart [-plot:weight], for example, the plot will display data for ALL records in the project and not just the user's DAG. To limit the plot to just data in the user's DAG, it could be changed to [-plot:weight:user-dag-name] in this case.
Smart Charts/Tables/Functions that utilize a unique report name as a parameter for data filtering purposes will still function and display normally even if the user does not have explicit access to view that specific report referenced as a parameter.
Back to Top
Alerts / Notifications (Import / Export) New feature: Import/export alerts via CSV file on Alerts & Notifications page - Users may export and import alerts to the same project or another project using a CSV file. If updating an existing alert, the unique alert ID must be included in the CSV file to identify the alert that the user wishes to modify. If the unique alert ID is left blank in the CSV file being uploaded, it is assumed that the user wishes to create a new alert
Back to Top
Alerts / Notifications (Reordering Alerts) New feature: Reorder alerts on Alerts & Notifications page - In the options menu for any given alert, a user can select an alert to be moved to another position on the Alerts & Notifications page. When this is done, it notifies the user that moving the alert will in most cases cause the alert numbers to be renumbered for many existing alerts (since they are numbered based on their order). However, their alert title and unique alert ID will not change during this process.
Back to Top
Data Quality Rules (Export Results) New feature: Export Data Quality rule results - After running a data quality rule, users may export the results/discrepancies of the rule as a CSV file. The CSV file will be structured exactly like a date export/import file, which should allow for faster and easier cleaning of data so that values can be fixed and then re-uploaded as a data import.
Back to Top
User Rights / Permissions (Import / Export) New feature: Ability to to import/export user rights via a CSV file on the User Rights page - Users can download a CSV file to view all the user privileges of the existing users in a project, including their instrument-level user rights. Users can upload a CSV file to grant new users access to the project and/or to modify the user privileges of existing users, including their instrument-level user rights.
NOTE: When using the Upload Users (CSV) option on the User Rights page, it now displays a checkbox option in the dialog to allow the user to optionally send an email notification to all new users being added to the project via this import process. In previous versions, no users would be notified via email if they were added to the project via the Upload Users (CSV) option but only if added using other methods.
Back to Top
Add New Field(s) From an Existing Field Bank New feature: Field Bank - When adding new fields via the Online Designer, users will see an "Import from Field Bank" button, which will allow them to search different standardized catalogs of commonly used fields, such as in the U.S. National Library of Medicine catalog. The Field Bank helps users add new fields quickly and easily to their data collection instruments. Over time, more standardized catalogs of fields will be added to the Field Bank.
Note the New 'Import from Field Bank' Button
Select Desired Field Bank @INLINE Action Tag (Display Uploaded Images) New feature: @INLINE action tag - Allows a PDF file or image file (JPG, JPEG, GIF, PNG, TIF, BMP) that is uploaded to a File Upload field to be displayed in an inline manner on the survey page or data entry form so that the PDF/image can be viewed by the user or survey participant without having to download it.
The PDF/image will be displayed inline on the page immediately above the download link for the field and will be displayed with 100% width by default (i.e., 100% width of the area in which it is contained). Images will be displayed with their native width:height ratio, although PDFs will be displayed with a 300 pixel height by default. If you wish to manually set the width and/or height of the image/PDF, you may put the width/height values inside parentheses after the action tag in the following manner: @INLINE(width) or @INLINE(width,height). The width/height can be a percentage value (e.g., 50%) or a number representing size in pixels (e.g., 400). Thus @INLINE(50%) will display an image at 50% size for the area in which it is contained on the page, and @INLINE(400,100) would display the image always at 400px tall and 100px wide. To make an inline PDF appear taller on the page, you might use @INLINE(100%,600) since 300px is the default height for inline PDFs. The @INLINE action tag also works if the File Upload field is embedded inside another field on the page. NOTE: This new feature does NOT automatically disable the "Image Viewer" external module if it is installed and enabled on any projects, nor will it conflict with the "Image Viewer" external module.
The @INLINE Action Tag Allows a PDF file or image file (JPG, JPEG, GIF, PNG, TIF, BMP) that is uploaded to a File Upload field to be displayed in an inline manner on the survey page or data entry form so that the PDF/image can be viewed by the user or survey participant without having to download it. The PDF/image will be displayed inline on the page immediately above the download link for the field and will be displayed with 100% width by default (i.e., 100% width of the area in which it is contained). Images will be displayed with their native width:height ratio, although PDFs will be displayed with a 300 pixel height by default. If you wish to manually set the width and/or height of the image/PDF, you may put the width/height values inside parentheses after the action tag in the following manner: @INLINE(width) or @INLINE(width,height). The width/height can be a percentage value (e.g., 50%) or a number representing size in pixels (e.g., 400). Thus @INLINE(50%) will display an image at 50% size for the area in which it is contained on the page, and @INLINE(400,100) would display the image always at 400px tall and 100px wide. To make an inline PDF appear taller on the page, you might use @INLINE(100%,600) since 300px is the default height for inline PDFs. Note: The @INLINE action tag also works if the File Upload field is embedded inside another field on the page.
Add a 'File Upload' field & add the @INLINE Action Tag When entering data, upload your image or PDF (NOTE: This works in survey mode AND standard REDCap data entry mode )
Pipe an Uploaded Image/PDF via the ':inline' piping tag New feature: New ":inline" piping option for File Upload fields
If piping using the ':inline' option for a File Upload field, such as [my_field:inline], in which the uploaded file is a PDF file or image file (JPG, JPEG, GIF, PNG, TIF, BMP), the file will be displayed in an inline manner so that it is viewable on the page. The ':inline' option DOES work inside emails, so you can pipe a field with ':inline' inside the email body, thus allowing you to display inline images inside survey invitations or Alerts & Notifications. The @INLINE action tag does not need to be used on a field in order to utilize the ":inline" piping option. Note: Inline images are not able to be displayed inside a downloaded PDF of a survey/instrument that contains data.
Configure a field to PIPE an uploaded IMAGE or PDF (NOTE: The source image can be from anywhere on the record (be sure to include event reference, if necessary)
Pipe a LINK to an Uploaded File via the ':link' piping tag New feature: New ':link' piping option for File Upload fields - If piping using the ':link option for a File Upload field, such as [_field:link], the file's filename will be displayed as a clickable hyperlink for downloading the file, which works on webpages and also inside the body of email text (i.e., survey invitations or Alerts & Notifications).
The new ':link' can also be used in survey invitations and alerts/notifications.
Note: When using the :inline piping option for File Upload files inside an email body (e.g., survey invitations, alerts), if the uploaded file is not an image file, it will still attach the file to the email but will display the file's filename in the email text as an alternative to displaying it as an inline image.
Pipe a 'Link' to an Uploaded File User Preference: CSV Export Delimeter New feature: CSV Delimiter as a user-level preference - The My Profile page now has a new user preference to allow a user to set their own preferred CSV delimiter (e.g., comma, semi-colon) that will be used as the delimiter character in all CSV file downloads throughout REDCap, such as data dictionary import/export, event import/export, user rights import/export, etc. This setting is not used by data imports and exports because those already have a way to specify the CSV delimiter manually. The system-level default value for this user preference can be set on the User Settings page in the Control Center, in which all new users created afterward will have their user-level preference set with this system-level default value. To modify all existing users preference after upgrading (if your users would not want a comma delimiter), it will require running an update query in the database, such as this: UPDATE redcap_user_information SET `csv_delimiter` = ';'.
Assign User to DAG When Adding to a Project Improvement: Assign a user to a DAG at the same time as adding the user to the project - Whenever a user is being added to a project via the User Rights page, if Data Access Groups are being utilized in the project, a new option will appear (whether if adding the user with custom rights or if assigning them to a user role) that allows you to assign the user to a DAG at the same time as adding them to the project. This helps prevent a common issue where a newly added user might temporarily have access to the records of *all* DAGs in the project prior to the user being assigned to a DAG immediately after getting added to a project. By making this two-step process a single step, it avoids possible data access issues for users who need to be assigned to a DAG.
Surveys: Custom Offline Messages New feature: Custom offline message for surveys in offline status - Users can provide custom text that is displayed to participants only when the survey is offline. This custom text will be displayed in place of the default offline text on the survey while the survey is in offline mode. This text can be set at the top of the Survey Settings page.
Surveys: New Stop Action Behavior Management and Messaging New feature: Survey-level Stop Action controls (new section on Survey Settings page)
Alternative survey completion text - Users can optionally set alternative survey completion text that is displayed in place of their standard survey completion text whenever a survey is ended via a Stop Action on any field. This is useful when it doesnt make sense for non-eligible participants to see the same survey completion text as those who completed the survey fully. Prevent survey responses from being saved if the survey ends via Stop Action - Users can optionally choose to prevent submitted responses from being saved as data in the project if the survey ends via Stop Action. This is useful if survey administrators do not wish to keep the data for ineligible participants, for example. This means that if a one-page public survey is started but ends via Stop Action, no data from that response will be saved into the project (i.e., no new record will be created), but it will log this event on the project Logging page (so that users are at least aware of this happening despite no data being saved). NOTE: If any data has been saved on the survey instrument for a given record prior to the Stop Action being triggered, that data will be deleted from that instrument. For example, if the survey is a multi-page survey in which data has been entered on previous pages prior to triggering the Stop Action, all data collected thus far in that survey will be deleted as if the survey was never taken. Additionally, if the record does not contain data in any other instruments, the entire record itself will be deleted during this process. If data does exist in other instruments, the record will not be deleted.
PRIVACY NOTE: If the option for Data Privacy/GDPR has been enabled in the project, in which it removes the contents of the log for a record that is deleted from the project, then if an entire record is deleted via this particular survey setting via a Stop Action, then all logged data values for the record will be removed from the log as per this project's data privacy setting.
Twilio: Participant Driven Email / SMS Preference (Twilio Requires JH REDCap Silver / Gold Tier and a Paid Twilio Account)
New feature: Field that maps to a participant's Twilio delivery preference - When using Twilio for surveys, users can control each participant's invitation preference automatically using a multiple choice field. If survey participants require using different methods (e.g., email, SMS w/ link, voice call survey) for receiving survey invitations and/or taking surveys, users can select a multiple choice field whose choices represent each survey invitation delivery method. After mapping the invitation preferences to a field, whenever the value of the field is added or modified, the participant's invitation preference will automatically be changed accordingly. IMPORTANT: The multiple choice codings for the selected field must be defined exactly as delineated below, although their corresponding choice labels can be modified to be whatever text the user desires. Also be aware that if the value of the field that is mapped is set to blank/null, then the invitation preference for the participant will revert to the project's default invitation preference (as defined in the Twilio configuration on Project Setup). Additionally, if a participant's invitation preference is modified via the Participant List, that change will also change the value of the mapping field selected above. Mapped field choice options:
EMAIL, Email invitation SMS_INVITE_WEB, SMS invitation (contains survey link) SMS_INITIATE, SMS invitation (take survey via SMS) VOICE_INITIATE, Voice call (participant receives voice call) SMS_INVITE_MAKE_CALL, SMS invitation (contains phone number to call) SMS_INVITE_RECEIVE_CALL, SMS invitation (reply via SMS to receive voice call) Slider Fields New / Improved: Custom ranges (min/max) for slider fields - Users may now set a custom minimum and/or custom maximum integer value for slider fields. The default min and max is still 0 and 100, respectively. If no value is entered for the min or max value, it will assume the default value. These can be set via the Edit Field popup in the Online Designer, and via the Text Validation Min and Text Validation Max columns in the Data Dictionary.
Changes to Events & Instrument Assignments In Production Mode New / Improved: Add Events and Instrument Assignments When In Production Mode - Projects will now be able to add new events and also to assign instruments to events while in production mode. Previously, these changes required a REDCap Administrator.
Note: Deleting / Renaming Events or Unassigning Instruments From Events still requires a REDCap administrator, as such changes can have devestating consequences. If you need to delete or rename an event or if you need to unassign an instrument from an event, please submit a Support Request Ticket by clicking HERE .
Other Miscellaneous Changes / Improvements Improvement: When viewing an instrument n the Online Designer, action tags are now displayed (in pink text) along the bottom edge of the field box (similar to how branching logic is displayed along the top of the field box). This makes it much easier to see which fields are utilizing action tags. Change: The size of displayed @CALCTEXT fields has been increased in order to display viewable text. Change: The @PREFILL action tag has been renamed to @SETVALUE , which more accurately captures how it behaves. Some confusion had occurred regarding this action tag's behavior simply because of its name. This change to the name is backward compatible so that projects already using @PREFILL will still work , but @SETVALUE will be the preferred action tag going forward. The description of the @SETVALUE action tag in the Action Tags documentation notes this name change. Change: Any fields using the @PREFILL/@SETVALUE action tag will no longer be read-only/disabled on survey pages and data entry forms but will be editable. If users wish to make the field read-only, it is recommended they simply add the @READONLY action tag as a means of maintaining the previous read-only behavior. Improvement: On the Calendar page when viewing the "View/Edit Calendar Event" popup for a calendar event that is attached to a record, the popup now displays a "View Record Home Page" link next to the record name to allow the user to easily navigate to the record. Change/improvement: The Logic Editor popup is now utilized when editing the "Action Tags/Field Annotation" text box in the Online Designer. Change: Due to concerns about sending identifying information from REDCap in outgoing emails, Survey Notification emails will no longer include the Participant Identifier in the email body (if a Participant Identifier was entered in the Participant List for a given participant). Change/improvement: The User Access Dashboard now displays "Last logged activity" for each project. Change: The alphanumeric hash that exists in all survey links has been increased in length from 10 to 16. Any new survey links created will have a 16 character length hash. Change/improvement: The "Phone (North America)" field validation now allows phone numbers that begin with "800" and 811. Change: Updates and new content for the Help & FAQ page. Improvement: Report description text now utilizes the rich text editor. Additionally, users may perform piping into a reports description, such as project-level Smart Variables, including Smart Charts, Smart Functions, and Smart Tables. Improvement: When exporting a PDF of all record data via the "Other Export Options" page, a copy of the downloaded PDF will now be archived and stored in the File Repository, similar to how other data exports (i.e., CSV, SPSS) are archived. This will help REDCap users keep better track of exactly what data was downloaded by someone when they export a PDF of all records in the project. Note: This does not apply to other PDF exports but only to the "all records" PDF export on the "Other Export Options" page. Change/improvement: When viewing the Survey Settings page for a repeating instrument, the "Location of the button on survey" option for the "Allow respondents to repeat the survey" setting now includes a new choice not to display the repeating survey button at all on the survey page. This is useful if users are utilizing the Survey Queue as the path for participants to enter new responses for the repeating responses instead of displaying the repeating survey button on the survey page itself. New feature: New API Export Logging method - This new API method allows users to export a projects logging via the API using very similar methods and filters as in the projects user interface. See the documentation for all filter parameters that are available. Significant Bug Fixes (v11.1.26)
Major bug fix: When using the Data Resolution Workflow in a project, any branching logic on the project's surveys or data entry forms mistakenly displays an error message and does not work. Additionally, clicking the Today/Now button for date or datetime fields would mistakenly display the "do you want to leave this page" browser popup. Major bug fix: When a field is embedded on a multi-page survey, in which the embedded field's parent field is used in branching logic on a later page, the embedded field's value might mistakenly get erased when a later survey page is submitted if the embedded field is set as a Required field. Major bug fix: When a repeating instrument has data entered on multiple repeating instances, and then afterward the instrument is made to no longer be repeatable, then any new data entered on that data entry form for fields that already have data on other instance might mistakenly get stored in the wrong repeating instance (i.e., get orphaned in the "redcap_data" database table) and thus would fail to be seen when reloading the form again. Major bug fix: If a project has randomization enabled and is using strata fields, if one or more strata fields exist on a survey instrument, and the survey containing the strata field(s) is opened after the record has been randomized, the strata fields would mistakenly not be disabled/read-only on the survey page but could be edited, which can cause major issues with a randomized project. It is expected that the strata fields should be disabled/readonly (whether on the data entry form or survey page) after the record has been randomized. Major bug fix: When using randomization in a longitudinal project in which randomization strata fields exist on a different event than the randomization field, if the values of the strata fields are added or modified during the randomization process, their values would mistakenly not get saved or logged in the correct event, thus orphaning those values. Major bug fix: When using an Adaptive or Auto-Scoring instrument downloaded from the REDCap Shared Library, in which that survey was set to use "Enhanced radios and checkboxes" via the Survey Settings page, the survey would not function and would not allow participants to submit their responses unless the survey was reverted to no longer using "Enhanced radios and checkboxes". Major bug fix: Alerts & Notifications that are set to be sent via SMS or Voice Call would mistakenly not get sent whenever the alert is triggered. Bug emerged in REDCap 10.6.18 LTS and 11.0.0 Standard.