The Conditional Action type “Validation” allows users to validate a field’s value based on data or system variables. This is commonly known as an edit check and will cause an automatic query to be generated when the defined condition(s) are met. When the validation is triggered, a red error message is also displayed next to the field in the form as displayed in the following figure. The query message is truncated, but can be seen when the user hovers their mouse over it, or when they click on the query icon to view the details.



A typical conditional action on a number field is if a number value entered falls outside of a range of numbers.  Clinical Studio makes it very easy to evaluate if a value is outside of a range of numbers. The two examples below show how different error messages would result when Systolic Blood Pressure ranges are used; first, when a Validation using the min/max feature is entered, and; second, when a traditional Conditional Action statement has been placed on the field. 


Validation Using the Min/Max Feature 

Note: This method only works for whole integer values

The Min and Max fields represent the acceptable range values that can be entered into a field.  For example, if the Min is set at 50 the field will display an error message stating, “Value violates low range (50)” when the value entered is less than 50. To set a single set of ranges for the Systolic Blood Pressure:


In this case it is not necessary to write a conditional action. However, if the field is enabled and required based on another field’s answer or multiple validation conditional actions based on different range values, validations would need to be written for each of those messages.  Remember, these are only examples and the validation conditional action can be used for many different situations to make Users aware of an event. 



Validations Using a Traditional Conditional Action Statement

As stated above, it is not necessary to write a conditional action when using the Valid Range (min/max) feature. However, a form designer may choose to forgo use of the feature and instead create a traditional conditional action statement for any number of reasons. For example, maybe the valid range required is more specific down to the decimal, or there are other combined criteria/conditions in addition to the range itself. 

The example below explains how to create a conditional action statement that displays will display an error message if the range value is low for the systolic pressure (Hypotension).  For this example the Valid Range information was removed but the “Required” check box is left checked.  This ensures that if the user does not complete the field, when the form is saved, a red error message will display stating, “This Field is required” as shown in the figure below. The one exception to this rule is if the field is disabled or hidden, then the field is no longer required.



To create a traditional conditional action on the field indicating low systolic pressure perform the following steps:

Select the Systolic pressure field and click the conditional actions 0-View/Edit link as shown in the following figure. This will open the Conditional Action Builder.  In the Conditional Actions Builder click the type drop down and select Validation as shown below and follow the steps numbered in the image.




Another example of a Validation Conditional Action could be written to warn or alert the user that a date is to early or late based on either data collected on the same form or another form in the study (using an external variable). 

In the example below, separate validations were written for dates too early (shown in the image) and dates too late.

Constructing this validation would be similar to the one described above.



Edit checks can be written to handle highly advanced scenarios by utilizing "Blocks" within the conditions or performing computations within a condition itself, just to name a couple examples. 


Override Query Deployment

A unique function in TrialKit is the ability to override query distribution for every validation. By default, queries are deployed to specific roles as defined in the study configuration. However, each validation can be designed so when the edit check is triggered (e.g. A number is out of range), the resulting automatic query ignores the default query distribution.

In the example below, a validation (edit check) is set up on a field to only send a query to the Data Manager if the validation is triggered. This will override the normal query distribution which is set to go to all roles in the study.









Was this information helpful?YesNo