Neue Features in REDCap - idea-labs/documentation GitHub Wiki

Wir listen hier auf, was seit dem letzten Update neu in REDCap ist und was es an zukünftigen Neuerungen gibt. Die Auswahl ist eher selektiv und danach gerichtet, was uns interessant erscheint. Es kann also gut sein, dass Ihr Neuerungen entdeckt, die hier nicht aufgelistet sind. Aber vielleicht ist auch in dieser Liste für Euch etwas dabei. Probiert es aus!

New feature: Download all files on a report - When viewing a report (including public reports) that contains one or more File Upload fields or Signature fields, a “Download Files (zip)” button will appear on the page to allow users to easily download all the report’s uploaded files into a single zip file for those fields for the records in the report.

Improvement: On the Survey Settings page, the setting “For Required fields, display the red 'must provide value' text on the survey page?” now has a new option: "Display only the red asterisk". This provides an additional option rather than having to choose between the binary options to hide or not hide the text.
Improvement: New survey setting allows users to set a custom width of the survey displayed on the page between 50% and 100%. The default value for the setting is “Fixed width (default)”.
Improvement: New survey setting allows users to show or hide the Submit buttons displayed at the bottom of every survey page (including the 'Next Page' and 'Previous Page' buttons).
Improvement: New survey setting allows users to provide alternative text for the 'Submit', 'Next Page', and 'Previous Page' buttons displayed at the bottom of every survey page.

New feature: Survey Start Time and related Smart Variables
REDCap now collects when participants begin a survey (i.e., the initial time the survey page is opened). Going forward, any responses collected (partial or completed) will have their start time displayed at the top of the data entry form when viewing the response.

New Smart Variables for Survey Start Date/Time: Users can access the start time via piping by using the new Smart Variables [survey-time-started:instrument] and [survey-date-started:instrument], which can be used inside the @DEFAULT or @CALCTEXT action tags, among other places. If users wish to have them return the raw value, which will be in 'YYYY-MM-DD HH:MM:SS' format and would be more appropriate for conditional logic or calculated fields, simply append ':value' after the unique instrument name - e.g., [survey-date-started:instrument:value].

New Smart Variables for Survey Duration: Users can obtain the total amount of time that has elapsed since the survey was started (in seconds, minutes, etc.) by using [survey-duration:instrument:units] and [survey-duration-completed:instrument:units]. The Smart Variable [survey-duration] represents the difference between the survey's start time and either its 1) completion time (if completed) or 2) the current time (if not completed), whereas [survey-duration-completed] represents the difference between the survey's start time and completion time, in which a blank value will be returned if the survey has not been completed. Options for 'units': 'y' (years, 1 year = 365.2425 days), 'M' (months, 1 month = 30.44 days), 'd' (days), 'h' (hours), 'm' (minutes), 's' (seconds).

New feature: Conditional logic for Survey Auto-Continue: When enabling Survey Auto-Continue on the Survey Settings page for a survey, users may now optionally specify conditional logic to determine whether or not the auto-continue should be applied. As such, REDCap will auto-continue to the next survey only if the conditional logic is TRUE or if the logic textbox has been left blank. This new option can be used as a simpler alternative to the Survey Queue, which can require more complex instrument-event level configurations for longitudinal projects.

New feature: Multi-Language Management
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.

Usage: When entering data on a data entry form or survey, users and participants will be able to choose their language from a drop-down list or buttons on the page to easily switch to their preferred language for the text displayed on the page. This feature allows users to translate all text related to the data entry process, both for surveys and for data entry forms. Even various survey settings and email text can be translated. For users on data entry forms, if a language is selected, that selection is stored in the user’s user account settings internally (in the REDCap backend database), whereas a survey participant’s selected language will be stored in a cookie in their web browser as a way to remember their language preference if they return in the future (and also to maintain their selected language from page to page). The language can be pre-selected for a participant, if desired, using the “Language preference field” setting on the MLM page in the project or via the @LANGUAGE-FORCE action tags (seen below).

New feature: Form Display Logic
Form Display Logic is an advanced feature that provides a way to use conditional logic to disable specific data entry forms that are displayed on the Record Status Dashboard, Record Home Page, or the form list on the left-hand menu. You might think of it as 'form-level branching logic'. Form Display Logic can be very useful if you wish to prevent users from entering data on a specific form or event until certain conditions have been met. The forms will still be displayed on the page, but they will be disabled in order to prevent users from accessing them. Below you may define as many conditions as you want. A form may be selected in multiple conditions, but if so, please note that the form will be enabled if at least one of the conditions is met. The Form Display Logic does not impact data imports but only operates in the data entry user interface to enable/disable forms. Additionally, Form Display Logic is not utilized by the Survey Queue at all but can affect the behavior of the Survey Auto-Continue feature if the checkbox for it is enabled in the setup dialog. The Form Display Logic setup can be found by clicking the “Form Display Logic” button at the top of the instrument list in the Online Designer.

Change/improvement: A button to open the Codebook page as a floating popup window was added inside the Logic Editor popup to allow users to easily find and reference fields they want to use in their logic while in the editor.

New action tag: @IF - Allows various action tags to be set based on conditional logic provided inside an @IF() function - e.g., @IF(CONDITION, ACTION TAGS if condition is TRUE, ACTION TAGS if condition is FALSE). Simply provide a condition using normal logic syntax (similar to branching logic), and it will implement one set of action tags or another based on whether that condition is true or false. For example, you can have @IF([yes_no] = '1', @HIDDEN, @HIDE-CHOICE='3' @READ-ONLY), in which it will implement @HIDDEN if the 'yes_no' field's value is '1', otherwise, it will implement the two action tags @HIDE-CHOICE='3' and @READ-ONLY. If you wish not to output any action tags for a certain condition, set it with a pair of apostrophes/quotes as a placeholder - e.g., @IF([my_radio]='1', @READONLY, ''). 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.

New action tag: @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. Formatierung lässt sich nicht exportieren

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

Change: If new instruments are created in a project while in production status, all users and user roles will no longer automatically get full "View & Edit" rights to that instrument for their Data Viewing Rights but instead will receive "No Access (Hidden)" rights by default for new instruments. When in development status, the instrument-level rights still defaults to "View & Edit" for new instruments. This change helps improve security when a project is in production to ensure that users do not accidentally gain access to data that they should not see if new instruments are still being added to the project.

Improvement: On the External Modules page in a project, users with appropriate privileges may now import and export the configuration settings for any module that is enabled in the project. This feature functions as a convenience by allowing users to easily migrate the configuration settings of one or more modules to another project that has the same module(s) enabled.
Change/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: Reports A and B now have built-in Live Filters: 1) the record ID field, 2) a list of all events (if the project is longitudinal), and 3) a list of all Data Access Groups (if the project contains DAGs and the current user is not assigned to a DAG).

New feature: Project Dashboards
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. 🔗 Example dashboard

Setting project dashboards as “public”: If enabled at the system-level, 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. Users can opt to create a custom/short url for any project dashboard that is enabled as “public”.

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 with its legacy counterpart (i.e., @PREFILL and @SETVALUE will work equivalently), but @SETVALUE will be the preferred name 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. Some users had complained of the read-only attribute as being too restrictive and inflexible, thus preventing some valid use cases. 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.

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.

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 doesn’t 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.

Improvement: 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.

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.

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.

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.

Improvement: In the Online Designer, any fields that have action tags will have those action tags listed immediately below the field in the table on that page. This makes it easier to know if a field has a certain action tag without having to open the Edit Field dialog for the field.

New feature: Auto-numbering of repeating instances for data imports When using repeating events or repeating instruments, it may be difficult when performing dynamic imports of data for these because it is not easily known how many repeating instances already exist in a project for a given repeating event/instrument, thus often forcing users to invent clever ways to determine this, such as performing data exports beforehand and then dynamically determining what the next repeating instance number should be. However, that is no longer necessary. When performing a data import now for a repeating event/instrument, users may use the literal value “new” as the value for the “redcap_repeat_instance” field in their data import. By doing so, REDCap will perform the instance auto-numbering on its own to increment the repeating instances properly based on the highest numbered instance that already exists in the saved data in the project.

New feature: New survey option “Save a PDF of completed survey response to a File Upload field” - On the Survey Settings page in the Online Designer, users may select a File Upload field in the project where a static PDF file of a participant’s survey response will be stored immediately after they complete the survey. For longitudinal projects, if the target field exists on multiple events, users may set this feature so that it stores the PDF in the selected field in the current event (default) or else in a specific event in the project. Thanks to Philip Chase and his team at University of Florida for their inspiration for this feature, in which it was based on their “Save Survey PDF to Field” external module. NOTE: Upgrading to REDCap 10.6.0 will not automatically disable the “Save Survey PDF to Field” module if it is installed and enabled on any projects, nor will it transfer the saved settings of that module into this new feature in REDCap.

Improvement: File Upload fields and Signature fields may now be used in piping. If you are piping from a File Upload field or Signature field, the field's numerical value will be piped by default, but you may pipe the original filename of the uploaded file by appending the ':label' option, such as [my_field:label].

New action tag: @PREFILL - Sets a field's value to static text or dynamic/piped text whenever a data entry form or survey page is loaded, in which it will always overwrite an existing value of the field. The format must follow the pattern @PREFILL="????", in which the desired value should be inside single or double quotes. A field with @PREFILL will always be read-only, thus its value cannot be modified manually on the data entry form or survey page. For text fields, you may pipe and concatenate values from other fields in the project - e.g., @PREFILL='Name: [first_name] [last_name], DOB: [dob]'. For checkbox fields, simply separate multiple checkbox values with commas - e.g., @PREFILL='1,3,[other_field:value]'.
NOTE: The piped value does not get applied during any data imports (via API or Data Import Tool) but only operates when viewing survey pages and data entry forms.
NOTE: A field with @PREFILL will have its value updated ONLY when the page loads, which means that its value will not be updated in real-time if you modify other fields on the same page that are piped into the @PREFILL tag.
NOTE: If being used on a date or datetime field, the date value inside the quotes must be in Y-M-D format - e.g., @PREFILL='2007-12-25' - regardless of the field's set date format.
NOTE: The only difference between @PREFILL and @DEFAULT is that @DEFAULT is only applied when an instrument has no data yet, whereas @PREFILL will always be applied on an instrument, meaning that @PREFILL will ALWAYS overwrite the value if a field value already exists. TIP: To pipe the value of one multiple choice field into another multiple choice field, make sure you append ':value' to the variable being piped - e.g., @PREFILL='[my_dropdown:value]'.

New special functions: left(), right(), mid(), length(), find(), trim(), upper(), lower(), and concat(). These nine new functions can be specifically used when dealing with text values and may be especially useful when using them in conjunction with the @CALCTEXT action tag. To learn more and to see some practical examples of their usage, click the blue 'Special Functions' button in the Online Designer in any project.

• left(text, number of characters)- Returns the leftmost characters from a text value. For example, left([last_name], 3) would return 'Tay' if the value of [last_name] is 'Taylor'.
• right(text, number of characters)- Returns the rightmost characters from a text value. For example, right([last_name], 4) would return 'ylor' if the value of [last_name] is 'Taylor'.
• length(text)- Returns the number of characters in a text string. For example, length([last_name]) would return '6' if the value of [last_name] is 'Taylor'.
• find(needle, haystack)- Finds one text value within another. Is case insensitive. The "needle" may be one or more characters long. For example, find('y', [last_name']) would return '3' if the value of [last_name] is 'Taylor'. The value '0' will be returned if "needle" is not found within "haystack".
• mid(text, start position, number of characters)- Returns a specific number of characters from a text string starting at the position you specify. The second parameter denotes the starting position, in which the beginning of the text value would be '1'. The third parameter represents how many characters to return. For example, mid([last_name], 2, 3) would return 'AYL' if the value of [last_name] is 'TAYLOR'.
• concat(text,text,...)- Combines/concatenates the text from multiple text strings into a single text value. For example, concat([first_name], ' ', [last_name]) would return something like 'Rob Taylor'. Each item inside the function must be separated by commas. Each item might be static text (wrapped in single quotes or double quotes), a field variable, or a Smart Variable.
• upper(text)- Converts text to uppercase. For example, upper('John Doe') will return 'JOHN DOE'.
• lower(text)- Converts text to lowercase. For example, lower('John Doe') will return 'john doe'.
• trim(text)- Removes any spaces from both the beginning and end of a text value. For example, trim(' Sentence with spaces on end. ') will return 'Sentence with spaces on end.'.

New action tag: @CALCDATE - Performs a date calculation by adding or subtracting a specified amount of time from a specified date or datetime field and then provides the result as a date or datetime value - e.g., @CALCDATE([visit_date], 7, 'd'). The first parameter inside the @CALCDATE() function should be a text field with date, datetime, or datetime_seconds validation, in which you may specify (if needed) the event and repeating instance - e.g., @CALCDATE([baseline_event][visit_date], 7, 'd'). The second parameter represents the offset number amount that should be added or subtracted. It can be a decimal number or integer. Tip: To subtract (i.e., go backwards in time), use a negative number. The third parameter represents the units of the offset amount, which will be represented by the following options: 'y' (years, 1 year = 365.2425 days), 'M' (months, 1 month = 30.44 days), 'd' (days), 'h' (hours), 'm' (minutes), 's' (seconds). The unit option must be wrapped in quotes or apostrophes. NOTE: Both the source field and the result field must be a text field with date, datetime, or datetime_seconds validation. It is important to realize that a field with @CALCDATE will not be editable on the survey page or data entry form, and the field will function almost exactly like a normal calculated field, in which its value may get updated via a data import, when running Data Quality rule H, or in real-time during normal data entry on a form or survey.

New action tag: @CALCTEXT - Evaluates logic that is provided inside a @CALCTEXT() function and outputs the result as text, typically performed with an if(x,y,z) function - e.g., @CALCTEXT(if([gender]='1', 'male', 'female')). NOTE: It is important to realize that a field with @CALCTEXT will not be editable on the survey page or data entry form, and the field will function almost exactly like a normal calculated field, in which its value may get updated via a data import, when running Data Quality rule H, or in real-time during normal data entry on a form or survey. If desired, it is possible to return the value as a number - e.g., @CALCTEXT(if([age] >= 18, 'adult', 5*[other_field])).

New ”Keep the Survey Queue hidden from participants?” setting in the “Set up Survey Queue” dialog on the Online Designer : This setting will keep the Survey Queue table hidden from participants, and will force Auto Start to be enabled for all queue-activated surveys. This is useful if users wish to use the Survey Queue to automatically guide survey participants to the next survey without displaying the queue of surveys.

New feature: Select and modify multiple fields together on the Online Designer - Users may select multiple fields on the Online Designer by holding the Ctrl, Shift, or Cmd key on their keyboard while clicking on the field in the table, which will reveal the options to Move, Copy, or Delete all the selected fields. To make users aware of this feature, a floating note now appears near the right side of the page in the Online Designer with instructions on how to use this.

Improvement: In REDCap 10.0.2, a new feature was added to the Online Designer’s “Add/Edit Branching Logic” dialog to help users modify branching logic for many fields at once if they had the exact same branching logic. Now this has been improved further so that if users do not want to keep seeing this prompt when editing branching logic, a new checkbox in the dialog that says “Do not show this message again” can be checked, which will prevent the prompt from being displayed in that project for that user during the remainder of their REDCap session.

• Link to Online Designer: Adds links to the Online Designer page of projects in the Fields column.
• Link to Record Status Dashboard: Adds links to the Record Status Dashboard in the Records column.
• Collapse All: Adds a Collapse All button next to the Organize button that collapses all project folders.
• Organize Projects filtering: Adds a filter in the Organize Projects pop-up.

New feature: Field Embedding Field Embedding is the ultimate way to customize surveys and data collection instruments to make them look exactly how you want. Field Embedding is a Shazam-like feature that allows you to reposition field elements on a survey page or data entry form so that they get embedded in a new location on that same page. Embedding fields gives users greater control over the look and feel of your instrument. Users may place fields in a grid/table for a more compact user-friendly page, or they can position fields close together in a group.

• To use Field Embedding, users simply need to place the REDCap variable name of a field inside braces/curly brackets - e.g., {date_of_birth} - and place it in the Field Label, Field Note, Section Header, or Choice Label of any other field on that same instrument. Field embedding will not work across instruments but only on the current instrument/survey being viewed. If on a multi-page survey, then the embedded field must be on the same survey page as its host field.
• No action tags or custom HTML is required to use Field Embedding. Users can simply use the rich text editor in the Online Designer to design their layout and then place the field variables inside that layout. The layout does not have to be a table/grid (although tables are common for this), and fields can be embedded inside any field type (not just Descriptive fields).

Calculated Fields

• Change: In previous versions, calculated fields could only utilize either numeric fields or date/datetime fields in the calculation. Now non-numeric fields may be used, most notably inside IF statements. For example, if ([field1] = “A”, 0, 99).
• Change: In previous versions, using > or < in branching logic would not always work as expected. For example, [a] > [b] would have to be formatted as [a]**1 > [b]**1 to work correctly 100% of the time, which is not intuitive. This is no longer required, in which [a] > [b] will work as one would expect in branching logic. Note: This does not apply to calc fields, which have never had this problem.
• Change/improvement: **The datediff() **function used in branching logic and calc fields no longer requires the date format parameter (“ymd”, “mdy”, “dmy”). This was required for datediff() in calc fields and branching logic but was not required elsewhere, such as in report filters, DQ rule logic, ASI/Alert conditions, etc. The $returnSignedValue parameter (if provided) can now be provided as the fourth parameter - e.g., datediff([dob], “today”, “y”, true). NOTE: Both of the date/datetime fields used in the datediff function must still be in the same date format (“mdy”, “dmy”, or “ymd”), so that is still a requirement.

Improvement: New PDF customization to hide the Record ID from the PDF header. In the "PDF Customizations" section of the "Additional Customizations" dialog on the Project Setup page, users may set this option to display or hide the record name in the top header of every PDF page when downloading a PDF with data for a record. This is a project-level setting, so setting it applies to all PDFs generated for records in the project.

Improvement/change: The sending of a survey confirmation email now gets logged on the project Logging page when a confirmation email has been set to send to a survey participant after having completed a survey, in which the logged event will note the record name, the To address, the From address, the email subject, and whether or not the email contained attachments (including the PDF of the participant's survey responses).