Standard Validation Types

Comparison Validation

The Comparison Validation is used to compare a Model Data Attribute to another Data Attribute or a literal, using a particular comparison operator. This section describes its functionality.

Comparison Validation Property	Description
Source Field	The attribute whose value is to be compared. The Source Field can be a Data Attribute, Calculated Attribute or a Related Case Participant Attribute.
Comparison	The operator to use in the comparison; available operators and their meanings are detailed in the next section.
Target Field	The attribute whose value is to be compared. As a general rule the Target Field must be of the same Type (either Attribute Type or Attribute Data Type) in order to be comparable, and the Target Field list is filtered to only display attributes valid for comparison with the currently selected Source Field. The one exception to this rule is for Data Attributes with a data type of Integer, Money or Float; these numeric types are mutually comparable. Note: Note that Related Employment Attributes, Address Attributes and Comments Attributes are never available for use in Comparison Validations. Note: The Target Field must not point to the same Attribute as the Source Field.

The following table describes the valid combinations of operators and Data Types for Data Attributes and Calculated Attributes. A separate table for Related Case Participant Attributes is provided as their behavior is different.

Table 1. Supported Operators and Applicable Data/Calculated Attribute Data Types in Comparison Validations
Operator	Applicable Data Types	Description
==	Boolean, String, Integer, Float, Money, Codetable and Date.	The 'Equal To' operator checks that Source and Target Fields have exactly the same value (if they do not have the same value, the Validation will fail). See the note below for more information on use of this operator for 'Date' fields.
<>	Boolean, String, Integer, Float, Money, Codetable, Date and Date Time.	The 'Not Equal To' operator checks that Source and Destination Fields do not have exactly the same value (if they have the same value the Validation will fail). See the note below for more information on use of this operator for 'Date' fields
<	Integer, Float, Money, Date and Date Time.	The 'Less Than' operator checks that the Source Field value is less than the Destination Field value. If the Source Field value is greater than or equal to the Destination Field value, this Validation will fail.
<=	Integer, Float, Money, Date and Date Time.	The 'Less Than Or Equal To' operator checks that the Source Field value is less or equal to than the Destination Field value . If the Source Field value is greater than the Destination Field value, this Validation will fail.
>	Integer, Float, Money, Date and Date Time	The 'Greater Than' operator checks that the Source Field value is greater than the Destination Field value. If the Source Field value is less than or equal to the Destination Field value, this Validation will fail.
>=	Integer, Float, Money, Date and Date Time	The 'Greater Than Or Equal To' operator checks that the Source Field value is greater than or equal to the Destination Field value. If the Source Field value is less than the Destination Field value, this Validation will fail.
before	Date and Date Time.	The 'Before' operator checks that the Source Field value is before the Destination Field value. If the Source Field value is on on after the Destination Field value, this Validation will fail.
on or before	Date and Date Time.	The 'on or before' operator checks that the Source Field value is on or before to the Destination Field value. If the Source Field value is after the Destination Field value, this Validation will fail.
after	Date and Date Time	The 'after' operator checks that the Source Field value is after the Destination Field value. If the Source Field value is on or before to the Destination Field value, this Validation will fail.
on or after	Date and Date Time	The 'on or after' operator checks that the Source Field value is after or equal to the Destination Field value. If the Source Field value is before the Destination Field value, this Validation will fail.

Note: When the 'Source' Field is populated with a Data Attribute with a data type of 'Date', two additional attributes (which do not exist in the Dynamic Evidence Type Version meta data) are added to the 'Target' Field list:

evidenceReceivedDate
This attribute represents the Received Date which is stored on the Case Evidence Descriptor at runtime. Every create and modify page for Case Evidence in respect of a Dynamic Evidence Type Version will have this field added to it automatically by the Dynamic Evidence infrastructure, without the need to specify it in the Model. This Field represents that date upon which an agency received a piece of Evidence into the organization, and is a date which is frequently used in Evidence Comparison Validations.
evidenceEffectiveDateOfChange
This attribute represents the Effective Date of Change which is stored on the Case Evidence Descriptor at runtime. Every modify page for Case Evidence in respect of a Dynamic Evidence Type Version will have this field added to it automatically by the Dynamic Evidence infrastructure, without the need to specify it in the Model. This Field represents the Effective Date of Change for a Case Evidence record (see the Cúram Evidence Guide for more information on the meaning of this field), and is also a date which is frequently used in Evidence Comparison Validations.

The following table describes the operators which apply to Related Case Participant Attributes in Comparison Validations.

Table 2. Supported Operators for Related Case Participant Attributes in Comparison Validations
Operator	Description
==	The 'Equal To' operator checks that Source and Target Fields represent the same Participant; if they do not represent the same Participant, then the Validation will fail. An additional boolean attribute called ' shallow ' is provided for this Validation, but this is ignored by the Dynamic Evidence infrastructure when the operator is '==' (if the Related Case Participant ID is the same, then the underlying Concern Role ID must also be the same).
<>	The 'Not Equal To' operator checks that Source and Destination Fields do not have exactly the same value (if they have the same value the Validation will fail). An additional boolean attribute called ' shallow ' is provided for this Validation. If ' shallow ' is checked in the ' Create Validation ' dialog, then it is just the Related Case Participant IDs on the Evidence Record which are compared. If ' shallow ' is not checked in the ' Create Validation ' dialog, then the underlying Concern Role IDs are also checked for equality.

The following table describes some additional available options in Comparison Validation.

Table 3. Additional options in Comparison Validation
Options	Description
Literals	A source attribute (Data Attributes or Calculated Attributes) can be compared against literals. As a general rule, the literal value must of the same data type as that of the selected source attribute in order to be comparable. To compare a source attribute against a literal, select the "Use Literal" checkbox; the literal value can then be typed (or selected in the case of datatypes such as Codetable or Boolean or Date) into the Target field. Note: Literal value can only be specified for Data Attributes. Administrators may need to select a code table item as a literal value when the data type of the source attributes is "codetable". Where the data type of the first attribute or second attribute is 'Boolean', the values of 'true' and 'false' can be provided. In case where the data type is Date, date value can either be typed or can be selected through a Date Picker. Locale specific format can be typed for the literal value for the numeric data types such as Integer, Float and Money( Currency Symbol can also be typed along with the literal value in case of Money attribute.
Multiple Clauses	It is possible to provide multiple clauses in a Comparison Validation, each of which will need to pass for the overall Validation to pass. Multiple clauses can be provided by selecting the "Multiple Clause" checkbox on the Validation panel. Two buttons control the creation and deletion of Multiple Clauses: Add Clicking this button will add a clause to the current Validation, based on the currently selected source, target and operator fields. Delete Only enabled when a clause is selected in the Clause list, clicking this button removes the currently selected clause/comparison validation.
Message ID	To set a custom validation message, the administrator must set the "Message" property. To set this property, the search icon to the right of the "Message" property should be clicked: this brings up the "Add Validation Message" dialog. For more details on Custom Validation Message for Comparison Validations, see the "Custom Validation Message" section below. Note: Where there are Multiple Clauses, this property is Mandatory.

The following table describes the mandatory properties for Multiple Clauses in Comparison Validations.

Table 4. Multiple Clause Properties.
Multiple Clause Properties	Description
Conjunctions	Controls whether any clause or all the clauses in a group will be validated at run time. If the the "Any Clause" radio button is selected, then if any one of the clauses passes at runtime, the entire Validation will pass. If the "All Clauses" radio button is selected, then all clauses must pass in order for the entire Validation to pass.

Dependency Validation

The Dependency Validation is used to enforce a dependency of a particular type between two Attributes. This section describes its functionality. Note that the use of Calculated Attributes is not currently supported in Dependency Validations.

Dependency Validation Property	Description
First Attribute	The Data Attribute, Address Attribute, Related Case Participant Attribute or Comments Attribute on which 'Second Attribute' depends.
Second Attribute	The Data Attribute, Address Attribute, Related Case Participant Attribute or Comments Attribute which depends on 'First Attribute'.
Dependency	The nature of the dependency. This can be one of the following values: Must enter second attribute When this value is selected, if the case worker enters a value into the Field in respect of the Attribute pointed to by 'First Attribute', then they must also enter a value into the Field in respect of the Attribute pointed to by 'Second Attribute'. If something is entered in the first Field, but not in the second Field, this Validation will fail. Must not enter second attribute When this value is selected, if the case worker enters a value into the Field in respect of the Attribute pointed to by 'First Attribute', then they must not enter a value into the Field in respect of the Attribute pointed to by 'Second Attribute'. If something is entered in both Fields, this Validation will fail. At least one attribute When this value is selected, the case worker must enter a value into either or both Fields pointed to by 'First Attribute' and 'Second Attribute'; if both Fields are left blank, this Validation will fail. Only one attribute When this value is selected, the case worker must enter a value into one or other Fields pointed to by 'First Attribute' and 'Second Attribute'; if both Fields are entered, or neither Field is entered, this Validation will fail.
Bidirectional	Boolean property which applies to Dependency Validations with a Dependency of 'Must enter second attribute' and 'Must not enter second attribute' only (and is disabled when the other Dependency values are selected). Selecting the 'Bidirectional' property has the effect of adding the words '...And Vice Versa' to the descriptions under 'Dependency' above. For example, for the 'Must enter second attribute' Dependency, when this value is selected, if the case worker enters a value into the Field in respect of the Attribute pointed to by 'First Attribute', then they must also enter a value into the Field in respect of the Attribute pointed to by 'Second Attribute'; likewise, if the case worker enters a value into the Field in respect of the Attribute pointed to by 'Second Attribute', then they must also enter a value into the Field in respect of the Attribute pointed to by 'First Attribute'.

The following table describes some additional available options in Dependency Validation.

Table 5. Additional options in Dependency Validation
Options	Description
Literals	Literal value can be specified for both 'First Attribute' and 'Second Attribute'. As a general rule, the literal value must of the same data type as that of the selected first attribute or second attribute. To specify literals either to an First Attribute or Second Attribute,select the "Use Literal" checkbox; the literal value can then be typed (or selected where the the data type is Codetable or Boolean or Date) into the Source or Target Literal field. Note: Literal value can only be specified for Data Attributes. Administrators may need to select a code table item as a literal value when the data type of the source attributes is "codetable". Where the data type of the first attribute or second attribute is 'Boolean', the values of 'true' and 'false' can be provided. In case where the data type is Date, date value can either be typed or can be selected through a Date Picker. Locale specific format can be typed for the literal value for the numeric data types such as Integer, Float and Money( Currency Symbol can also be typed along with the literal value in case of Money attribute.
Message ID	To set a custom Validation message, the administrator must set the "Message" property. To set this property, the search icon to the right of the "Message" property should be clicked: this brings up the "Add Validation Message" dialog. For more details on Custom Validation Message for Dependency validation, see the "Custom Validation Message" section below.

Date of Birth Validation

The Date of Birth Validation is used to ensure that the date of birth of the Participant pointed to by a Related Case Participant Attribute in the Dynamic Evidence Type Version is before (or equal to) a specific date. This might sound like an overly restrictive validation, but it is in fact a frequently performed comparison in Case Evidence maintenance. This section describes its functionality. Note that the use of Calculated Attributes is not currently supported in Date of Birth Validations.

Date of Birth Validation Property	Description
Related Participant	The Related Case Participant to use in the Date of Birth comparison. The dropdown for this property will be populated with all Related Case Participant Attributes currently defined for the Dynamic Evidence Type Version. At runtime, the date of birth for the Person pointed to by the Related Case Participant will be compared against the date in 'Input Date' (Related Case Participant Date of Birth <= Input Date); if the Input Date is before the Date of Birth, the Validation will fail. Note that only Related Case Participants of type 'Person' are valid for use in such Comparisons, even though the Evidence Editor does not enforce this.
Input Date	The Data Attribute with a data type of 'Date' against which to compare. Note that, similar to the functionality provided in the Comparison Validation, both the evidenceReceivedDate and effectiveDateOfChange Evidence Descriptor attributes are available in this Validation for comparison against the Related Participant Date of Birth. See Standard Validation Types for more information. Note: Two additional attributes (which do not exist in the Dynamic Evidence Type Version meta data) are added to the 'Input Date' Field list: evidenceReceivedDate This attribute represents the Received Date which is stored on the Case Evidence Descriptor at runtime. Every create and modify page for Case Evidence in respect of a Dynamic Evidence Type Version will have this field added to it automatically by the Dynamic Evidence infrastructure, without the need to specify it in the Model. This Field represents that date upon which an agency received a piece of Evidence into the organization, and is a date which is frequently used in Evidence Date of Birth Validations. evidenceEffectiveDateOfChange This attribute represents the Effective Date of Change which is stored on the Case Evidence Descriptor at runtime. Every modify page for Case Evidence in respect of a Dynamic Evidence Type Version will have this field added to it automatically by the Dynamic Evidence infrastructure, without the need to specify it in the Model. This Field represents the Effective Date of Change for a Case Evidence record (see the Cúram Evidence Guide for more information on the meaning of this field), and is also a date which is frequently used in Evidence Date of Birth Validations.

Date of Birth Validation Property

Description

Related Participant

The Related Case Participant to use in the Date of Birth comparison. The dropdown for this property will be populated with all Related Case Participant Attributes currently defined for the Dynamic Evidence Type Version. At runtime, the date of birth for the Person pointed to by the Related Case Participant will be compared against the date in 'Input Date' (Related Case Participant Date of Birth <= Input Date); if the Input Date is before the Date of Birth, the Validation will fail. Note that only Related Case Participants of type 'Person' are valid for use in such Comparisons, even though the Evidence Editor does not enforce this.

Input Date

The Data Attribute with a data type of 'Date' against which to compare.

Note that, similar to the functionality provided in the Comparison Validation, both the evidenceReceivedDate and effectiveDateOfChange Evidence Descriptor attributes are available in this Validation for comparison against the Related Participant Date of Birth. See Standard Validation Types for more information.

Note: Two additional attributes (which do not exist in the Dynamic Evidence Type Version meta data) are added to the 'Input Date' Field list:

evidenceReceivedDate
This attribute represents the Received Date which is stored on the Case Evidence Descriptor at runtime. Every create and modify page for Case Evidence in respect of a Dynamic Evidence Type Version will have this field added to it automatically by the Dynamic Evidence infrastructure, without the need to specify it in the Model. This Field represents that date upon which an agency received a piece of Evidence into the organization, and is a date which is frequently used in Evidence Date of Birth Validations.
evidenceEffectiveDateOfChange
This attribute represents the Effective Date of Change which is stored on the Case Evidence Descriptor at runtime. Every modify page for Case Evidence in respect of a Dynamic Evidence Type Version will have this field added to it automatically by the Dynamic Evidence infrastructure, without the need to specify it in the Model. This Field represents the Effective Date of Change for a Case Evidence record (see the Cúram Evidence Guide for more information on the meaning of this field), and is also a date which is frequently used in Evidence Date of Birth Validations.

The following table describes some additional available options in Date of Birth Validation.

Table 6. Additional options in Date of Birth Validation
Options	Description
Message ID	To set a custom validation message, the administrator must set the "Message" property. To set this property, the search icon to the right of the "Message" property should be clicked: this brings up the "Add Validation Message" dialog. For more details on Custom Validation Messages for Date of Birth Validations, see the "Custom Validation Message" section below.

Duplicate Validation

The Duplicate Validation is used to prevent Case Evidence records which are considered 'duplicate' (according to specified criteria) from being recorded on the system.

Note that the operation of this Validation is slightly different in nature from that of other Validations, in that the selection set of records against which the Duplicate Validation is run can vary.

If the Dynamic Evidence Type Version has one or more Parent Dynamic Evidence Types, then at runtime the Duplicate Validation will only look at Child records of those Parents (i.e. Sibling records of the current record) to identify duplicates.

If however the Dynamic Evidence Type Version has no Parent relationships, then at runtime the Duplicate Validation will look at all Case Evidence records of the Dynamic Evidence Type for this Dynamic Evidence Type Version to identify duplicates.

This section further describes the functionality of the Duplicate Validation. Note also that the use of Calculated Attributes in Duplicate Validations is not currently supported.

Duplicate Validation Property	Description
Use Date Range, Start Date, End Date	When 'Use Date Range' is checked, two mandatory Duplicate Validation properties appear on the 'Create Validation' dialog: Start Date and End Date. These properties need to point to a Data Attributes with datatypes of 'Date'. At runtime, the Duplicate Validation will search for records in the selection set (see the overview above for details on how the selection set is identified) which have values in the Attributes pointed to by the Start and End Dates which overlap with the values provided in the create or modify Case Evidence screens. If such records are identified, the Validation will fail. For example, if the value provided in the Case Evidence screen Field for the Attribute pointed to by the Start Date property is before the value in the Field for the Attribute pointed to by the Start Date property in any of the records in the selection set, then the Validation will fail as a duplicate has been identified.
Other Attributes to Check	An optional list of Other Attributes to check (in tandem with any Date Range provided) for equality in order to identify duplicates. If records exist in the selection set which have Attribute values equal to the values for the Attributes in the 'Other Attributes to Check' list provided in the create or modify Case Evidence screens, then the Validation will fail. Note: If multiple attributes are provided in the list, they can be checked either individually or in combination for duplicates. To check the attributes individually select the radio button "Check each attributes individually". To check attributes in combination ( i.e. Checking that all the attributes are unique when taken together within the selection list), select the radio button "Check attributes together"

Duplicate Validation Property

Description

Use Date Range, Start Date, End Date

When 'Use Date Range' is checked, two mandatory Duplicate Validation properties appear on the 'Create Validation' dialog: Start Date and End Date. These properties need to point to a Data Attributes with datatypes of 'Date'.

At runtime, the Duplicate Validation will search for records in the selection set (see the overview above for details on how the selection set is identified) which have values in the Attributes pointed to by the Start and End Dates which overlap with the values provided in the create or modify Case Evidence screens. If such records are identified, the Validation will fail.

For example, if the value provided in the Case Evidence screen Field for the Attribute pointed to by the Start Date property is before the value in the Field for the Attribute pointed to by the Start Date property in any of the records in the selection set, then the Validation will fail as a duplicate has been identified.

Other Attributes to Check

An optional list of Other Attributes to check (in tandem with any Date Range provided) for equality in order to identify duplicates. If records exist in the selection set which have Attribute values equal to the values for the Attributes in the 'Other Attributes to Check' list provided in the create or modify Case Evidence screens, then the Validation will fail.

Note: If multiple attributes are provided in the list, they can be checked either individually or in combination for duplicates.

To check the attributes individually select the radio button "Check each attributes individually".
To check attributes in combination ( i.e. Checking that all the attributes are unique when taken together within the selection list), select the radio button "Check attributes together"

The following table describes some additional available options in Duplicate Validation.

Table 7. Additional options in Duplicate Validation
Options	Description
Message ID	The administrator can set a custom validation message for both Date Range attributes and for other attributes. To set a custom validation message either, the administrator must set the "Message" property. To set this property, the search icon to the right of the "Message" property should be clicked: this brings up the "Add Validation Message" dialog. For more details on Custom Validation Message for Duplicate validation, see the "Custom Validation Message" section below.

Custom Validation Message

To set a custom validation message for an validation type, the following properties must be specified

Table 8. Custom Validation Message Properties
Validation Message Mapping Properties	Description
Message	The text to use for the Validation Message. This message can be parameterized with Attribute Names, place holders for which are specified in the validation message with the following format: opening curly brace, parameter number, closing curly brace - e.g. {0}. At run time, whenever a validation fails, the parameter specified in the 'Message Parameters' list below will be substituted into the Message to construct the Validation Message to display. See the 'Message Parameters' property for more information on parameterization of messages.
Message ID	Mandatory string to be used as the key to the Message property value; can be any valid identifier (e.g. 'My EvidenceTypeVersion.ComparisonValidation.Message').
Message Parameters	An ordered list of Data Attributes/ Related Case Participant Attributes/ Address Attributes / Comments Attributes / Calculated Attributes to be used in the Message. For Comparison Validations or Date of Birth Validations, Two additional attributes (which do not exist in the Dynamic Evidence Type Version meta data) , namely 'evidenceReceivedDate' and 'evidenceEffectiveDateOfChange' are added to the list. For more information on these two additional attributes refer to the Comparison Validation section or the Date of Birth Validation section. As mentioned above, place holders are put in the Message to indicate that an Attribute value should be substituted into the Message at run time, and this should take the following format: {0}, {1}, etc. For example, say the 'Message' property is set to the following: {0} must not be equal to 'true' and {1} must not be equal to 'SX2', and the 'Message Parameters' are set the following: isPregnant, gender. At run time, when a user creates an evidence record and if the comparison validation fails, then the message displayed to the user will be displayed as something like the following: 'isPregnant' must be equal to 'true' and 'gender' must be equal to 'Female'.