Conditional Actions - Hide

Prev Next

Hiding and Unhiding a Form or Data Field During Data Entry

Fields can be hidden based on data entered (or not entered) either on the current form or other forms (via external variables). This is also known as “Skip Logic”, used to focus data entry only on what is needed so the data entry user is not sifting through irrelevant content.

Hiding a Field

There are three ways a field can be hidden:

  • Conditional hiding - Prevents users from entering data on irrelevant fields. This method is covered in this article.

  • The 'Hidden' field property - Hides a field at all times for all users, but can still compute or populate data behind the scenes

  • Field Blinding - Hides the field only for specific users, but can still contain data

Conditional hiding of a field will, by default, cause the data to be cleared if data exists in the field before it becomes hidden. In the example below, if data is saved in the 'Specify' field, that data will be removed if the field later gets hidden by the user changing their answer.

Conditionally hidden forms will not clear data.

 

Make the field's label follow what the field is doing

It's important to consider the field's label too. If a field is hidden or blinded, and that field has a  text label along with it, you most likely want the label to also do what the field is doing. 

To accomplish this, each label has a "field" property where the label can be attributed to the field it's part of.

Building a Hide Condition

For a Hide condition, a common example is to collect further details based on a prior response. That prior response is often in the same form, but does not need to be (read more about external variables).

In the example shown above, the conditional action is set up on the Specify field. The operator is set as “Not Equal” because the field where the action is being written needs to be hidden at all times until the Race field has “Other” selected during data entry.

Hiding a Field Based on Choices Made in a Multi-select Field

The operators in a multi-select field work differently because there is no exact value to use as a trigger. A user could select one, some, or all choices. For this reason, the operators in a multi-select field are “in” and “not in” - meaning “includes” and “does not include”.

In this example, a ‘Specify’ field only needs to be displayed if the user selects the choices Mexico or Other, or both. So the condition should be to Hide if the multi-select field does NOT include the value 4 or 9 (coded values for the choices Mexico and Other):

Hiding a normalized table

Normalized tables can be conditionally hidden as well, the process of setting it up is just like that of any field. Select the table and then the conditional action builder.


Special Note About Tables

Fields within tables should not be set up with hide conditions. Instead use a Disable. This lets the user see what exists in a given table cell since table cells are always visible. If a field in a table gets disabled after data has been entered, be sure to also populate/clear the field with another condition.

Hiding Tabs/Pages On a Form

Hidden Tabs are often used when a form contains multiple tabs, but some tabs aren’t applicable and don’t need to be accessible for data entry.

To hide a tab, define a Hide CA on any field (usually the first one) within the tab that needs to be hidden. Second, name the conditional action starting with this syntax: {Tab

Here's an example:

Hiding based on another (external) repeating form

Note

This can apply to other dynamic conditional actions like populate or disable as well

One advanced scenario may be where a user needs to dynamically hide content on a form based on a value that comes from another log/repeating form. The natural obstacle here is that the Builder cannot anticipate what the data will be, so the system needs to be set up to dynamically go look for specific data. That’s where the external type of Any Form Date comes in.

Here’s an example where an indication field on the Medications form only needs to be collected if the Severity of the related Adverse Event is marked as “Severe”

Most systems would not have a way to go get the Severity of all the adverse events and then dynamically know which one to use. Luckily TrialKit does!

Step 1) Declared the target reference field the Adverse Event form:

Step 2) On the Medications form, define which date field will need to be used to find the correct Adverse Event record. This is done in the form properties.

Step 3) Now build the condtion(s) needed to hide (or disable) any fields necessary:

Since the external value above is being used in the condition, the system will get the list of all Severity values from the Adverse Event logs, and then use the one that matches the date that the user filled in on the Medications form.

Hiding Forms and Visits

Both forms and entire visits can be conditionally hidden. This is helpful for only collecting the forms that are relevant to the current subject. A common example is a Pregnancy Test form being hidden for any subject that is not female.

To hide a form, the condition must be an external variable collected on some other form or visit. In this example "Gender" is an external variable from the Demographics form at a specified visit. The conditional action is written at the Form level, rather than field level.

Additionally, if an entire visit needs to be hidden, apply the same Hide condition to all forms within the visit. This can be done by copying and pasting to the other forms. For visit-based hiding, the condition needs to include criteria for the visit as part of the condition.

Be cognizant of how much form hiding is being done within the study. Having a large number of forms hiding based on all kinds of various conditions will start to impact the speed of the system when Clinicians open subject casebooks. This is because the system needs to process through all the hiding logic to determine which forms to display.