Summary

This article covers the contents and the usage of the Dependencies - Definition worksheet.

Table of Contents

The Dependencies – Definition worksheet allows for the specification of predefined parameters for each question. For the question types specified on the Question Types – Definition worksheet, record the dependencies for each question. A dependency includes making sure data is within range, formatted properly, cannot be missing and other data validation checks.

Note: If a dependency was deployed, it should not be removed from the configuration. Rather, the dependency (with its ID and check if blank values unchanged) should be updated to an expression that always returns true; simply add 'OR 1==1' to the existing expression. This workflow will allow correct reconcile and close of eventually open, existing alerts.

questionTypeId

This attribute serves as the label for the question type, which is drawn from the Question Type – Definition worksheet. It defines a unique question in a dataset and can be repeated whenever necessary, but not on the same form. However, this dependency should be written once; e.g., a blood pressure questionType used on six forms only requires that the dependency be written once. If defined several times, it will need to be changed several times.

NOTE: It could become problematic when different ranges apply to the same question. This may be resolved by creating a second questionType and associating it with a second set of dependencies, but this should be avoided, if possible.

Use Alias to distinguish between instances of questionTypes within the dependency being written. For example, an Alias indicates: “On this form, have this behavior; on this other form, have this other behavior.” Use Alias when reasonable and avoid creating a second questionType. This way, you can allow for adjustments in the dependency.

dependencyId

This is a unique identifier per questionType. It is usually assigned sequentially and may contain numbers or letters. The dependencyId should not be changed after deployment of the trial.

Expression Type

This attribute allows the user to denote a custom dependency by entering “custom” in this field. However, you may leave this field blank (default) if the dependency is written in expression language.

NOTE: Use expression language if at all possible as this generally requires less time to test than custom dependencies.

Check If Blank

This attribute allows the user to specify whether a question should be evaluated when it is left blank, or when it has been answered, but not both. If the dependency is to be evaluated only when the data field is blank, enter ‘yes.’ This is useful for ensuring fields will not be left blank. When ‘no,’ the dependency will be processed only when the question is answered.

For the dependency in which Check if Blank equals ‘yes’, if the question is not answered, this dependency will be evaluated and an alert stating “An answer must be provided. Please verify.” will display. If the question Date of Birth is answered, the second dependency will evaluate to determine if the patient is at least 18 years of age and either display or not display the alert accordingly.

Note: The system is not designed to support changing the "Check If Blank" flag from yes to no and vice versa once data entry has begun. If the "Check If Blank" status must be changed in the case of a mistake or other reason it is best to remove the original dependency by turning it off, and add a new dependency then to run reconcile.

Correction Required

This setting determines whether the criteria of the dependency must be met prior to the form being saved. Enter ‘required’ if the user must modify the data to resolve the dependency before the data will be saved. This should be used sparingly to restrict field size (e.g., subject ID must be five digits) and to prevent duplicate ID. Enter ‘optional’ if the user is not required to correct the data and can proceed by saving the form. ‘optional’ (default) is typically used and will display an alert; e.g., out of range, cannot be blank, incorrectly completing the eCRF, etc.

Expression

This element may be evaluated as either a DataCollector Expression or a custom Java class defining evaluation criteria for the dependency. For custom dependencies, this value should define the name of the class. An expression is the desired value evaluated by relative or absolute addressing.

The implementation of cross form dependencies will not require that forms are completed within a specific sequence as the auto-reconciliation feature within the platform will automatically evaluate dependent forms/fields regardless of their placement within the subject’s casebook.

Data Values & Display Values

Question paths within expressions can be written to account for data values (the actual value stored in the database) or display values (the display label associated with a data value). To reference a data value, simply add .dataValue to the end of the question path. To reference a display value, simply add .displayValue to the end of the question path.

Example 1: Data Value
#studyTermination.visitDateTerm.dataValue
Example 2: Display Value
#studyTermination.visitDateTerm.displayValue

Note: Upon the evaluation of expressions containing a string, all spaces are removed from the value being evaluated. Therefore, all spaces should be removed from the string that is being compared to the value. For example, if the expression should check to see if a value is equal to 'Adverse Event', the expression should read: value == 'Adverse Event' .

Alert

This attribute defines the human-readable alert text to be displayed to the user, explaining what must be done, when a condition (dependency) is not met. This is written after writing the Expression. The alert text must be encoded to fit inside XML tags.

Need more help?

Please visit the Fountayn Contact Information page.