# Configure Custom Validation Criteria Learn how to configure _Validation Criteria_ for Agencies not already supported by Veeva Safety. ## About Custom Validation Criteria As standard, Safety provides _Validation Criteria_ for the ICH, EMA, FDA, FDA VAERS, PMDA, NMPA, and MFDS health authorities. If you need to add custom _Validation Criteria_ to enforce data quality requirements for _Submissions_ or _Distributions_ other than the ones already included in Safety, you can configure your Vault by adding custom _Validation Criteria_. This custom criteria then runs as part of _Case_ and _Submission_ Validation.
The next section describes how you can add custom _Validation Criteria_ to your Vault. ## Create Custom Validation Criteria {#create-custom-validation-criteria} Complete the following steps to create and configure custom _Validation Criteria_: 1. Navigate to **Business Admin > Objects > Validation Criteria**. 2. Select **Create**. 3. Complete the applicable fields. 4. Select **Save**. Repeat the above steps for each custom _Validation Criteria_ required. ### Validation Criteria Fields {#fields}
Field Description
Name Enter the name of the custom Validation Criteria.
Source Select Custom.
Always Evaluate

Select this option if Vault should evaluate this Validation Criteria for all global and regional destinations regardless of the Case having a reporting obligation.

If the Always Evaluate option is selected for a Validation Criteria, leave the Agency and File Format fields blank.
Agency

Select the Agency to which the Validation Criteria applies.

Leave this field blank if the custom rule is a global validation.

If this validation is regional and only applies to a specific agency, then select the appropriate Agency.

If you are using a File Format validation, Vault will evaluate the rule only when validations are run for one of the specified File Format and Agency pairings.

Conformance Enter the description of the Validation Criteria.
Data Element Specify the E2B element ID that the custom rule will validate.
Data Element Name Specify the E2B element ID name that the custom rule will validate.
File Format

Select which standard E2B file formats the Validation Criteria applies to.

If you are using Case Data or Case Data - Expression, you can leave this field blank unless you are configuring the Validation Criteria for a specific agency or agencies.

If you are using File Format, or are configuring a Validation Criteria to run for a specific agency or agencies only, select the standard E2B file formats to which the Validation Criteria applies. This field works with the Agency field and must be aligned accordingly. For example, if you select EMA for the Agency, you must select an EMA File Format. Vault will evaluate the rule only when validations are run for one of the specified File Format and Agency pairings.

Evaluation Level

Select the levels at which Vault evaluates the Validation Criteria record.

For example, select Case if the rule is intended to be evaluated when validations are run from the Case level only.

Result Status Type

Select whether Vault should treat a rule violation as a Warning, Fail, or Hard Fail.

This field is directly tied to the Validation Status field of the associated Validation Result object.

  • Either a Fail or Hard Fail result will prevent an auto-submission to a gateway.
  • Only a Hard Fail result will prevent you from triggering the Submit to Gateway action.
Vault Object Enter the API name of the relevant object for the validated E2B field. When validation results are generated, they will contain a link to the specified object. For example, case_drug_history__v.
Vault Field Enter the API name of the relevant field for the validated E2B field. When validation results are generated, they will contain a link to the specified object. For example, mpid_version__v.
Rule Version Enter the version number of the Validation Criteria.
Rule Formula Format

Select whether to use File Format, Case Data, or Case Data - Expression for formula execution:

  • File Format: A JSON schema validation based on Case data that is specific to an E2B format
  • Case Data: A JSON schema validation based on Case data that is not specific to an E2B format
  • Case Data - Expression: A Vault Expression Language-based validation based on Case data that is not specific to an E2B format

If left blank, Vault defaults to File Format.

Validation Query Builder Enter the formula used to validate against the specified E2B files.
Supersedes If this Validation Criteria supersedes an existing Validation Criteria, select the name of the superseded rule in this field.

If this rule and the superseded rule are both due to be evaluated, Vault evaluates this rule instead of the superseded rule.

API Name Enter a unique __c API name for this Validation Criteria.
## Write Custom Validation Criteria Rule Formulas {#validation-expression-language} When writing the [Validation Query][1] for a custom _Validation Criteria_ with a _Rule Formula Format_ of _Case Data - Expression_, use either of the following methods: 1. `VS_LET(var, path_to_validating_records, expression)`: Using this method, you can select any Safety object as the beginning of the path to the validating records (the top-level object). 2. `expression`: With this method, the top-level object is either a _Case_ or a _Transmission_. ### Path to Validating Records {#path-to-validating-records} The `path_to_validating_records` tells the Safety Reporting Rule Engine where to find the set of records to evaluate relative to the top-level object. The Rule Engine performs the `expression` defined in the _Rule Formula_ field on each record to obtain a set of pass and fail results. Vault stores these results in the _Validation Results_ and _Validation Results Summary_ for the _Case_. It is important to use the correct object relationship names when specifying this path. To obtain the relationship names for an object, navigate to **Admin > Configuration > Objects > [object] > Relationships**. Example: `case_version__v.case_products_case_version__vr` returns all of the _Case Products_ associated with the _Case_. You can also specify _Case Documents_ (`case_documents__v`) as the top-level object to validate attachment descriptions (**Case > Source > Attachments**) and literature references (**Case > Source > Literature**). Example: `VS_LET(cd, case_documents__v, IF(cd.classification__v = "Literature", not(isblank(cd.reference_text__v)), true))` validates that any _Case Document_ classified as _Literature_ does not have a blank _Reference_ field. ### Rule Formula Expression When writing the [Validation Query][1] for your custom _Validation Criteria_ (either as a standalone `expression` or as a `VS_LET` statement), you can use any of the operators and functions in the Vault Formula Reference Guide and the Safety-specific functions detailed in Create Formula Expressions. See [Appendix: Example Expressions][0] for examples of how you can build expressions to use in your rule formulas.
## Troubleshoot Validation Criteria If Vault encounters any validation errors when running the **Evaluate Regulatory Conformance** action for an _Inbox item_, a _Case_, or a _Submission_, the _Validation Status_ field of the _Validation Results Summary_ record changes to _Error_.
Common _Validation Criteria_ errors include the following: * A missing or incorrect Vault object * A missing or incorrect Vault field * An incorrect Rule Formula (including invalid references and null pointer exceptions) * An invalid JSON schema To help diagnose the error, Vault provides Validation Error logs in CSV format for individual [_Cases_ and _Submissions_][2], and for individual _Validation Criteria_. Once you have diagnosed and fixed all validation errors, run the **Evaluate Regulatory Conformance** action on the object to clear the _Error_. ### Validation Error Logs for Cases and Submissions {#cases-and-submissions-logs} The Validation Error Log for a _Case_ or _Submission_ lists all the _Validation Criteria_ that failed for that record. You can obtain the Validation Error Log for a _Case_ or _Submission_ by navigating to the **Validations Results (Failures & Warnings)** section and selecting the **Validation Results Summary** record. The _Validation Status_ field of this record shows _Error_. From the **Validation Results Summary** record, select the **Download Validation Error Log** action from the **All Actions** menu.
### Validation Error Logs for Validation Criteria The Validation Error Log for a _Validation Criteria_ record lists all _Case_ or _Submission_ records where the _Validation Criteria_ failed. _Validation Criteria_ records that caused an error are in the _Error_ lifecycle state. You can obtain the Validation Error Log for a _Validation Criteria_ record by navigating to **Business Admin > Objects > Validation Criteria** and selecting the **Validation Criteria** record. From the **Validation Criteria** record, select the **Download Validation Error Log** action from the **All Actions** menu. ## Appendix: Example Expressions {#example-expressions} The following table contains example expressions that illustrate how to use the `VS_LET` and `VS_ANYOF` functions to test _Case_ data.
Example Expression Description
VS_ANYOF(case_version__v.case_assessments_case_version__vr.rank__v, LAMBDA(element, element = 1))

These examples illustrate how to specify the path_to_validating_records in an expression.

The first expression performs this using a single VS_ANYOF function that specifies the path_to_validating_records, and the operation to perform on those records (LAMBDA).

The second expression uses the VS_LET function to set ca as an alias for case_version__v. The following VS_ANYOF function uses this alias as the starting point of its path_to_validating_records.

Both of these expressions return true if any Case Assessment on the Case has a Rank value of 1.

The VS_LET function is useful if the subsequent logic uses multiple functions that refer to the same path_to_validating_records.

VS_LET(ca, case_version__v, VS_ANYOF(ca.case_assessments_case_version__vr.rank__v, LAMBDA(element, element = 1)))
VS_ANYOF(case_version__v.case_assessments_case_version__vr, LAMBDA(element, element.rank__v = 1))

These examples illustrate that you can specify the path_to_validating_records partially in the VS_LET or VS_ANYOF function and partially in the LAMBDA function.

These expressions perform the same operation on the same set of records as the expression above, but the full path_to_validating_records is specified partially by the VS_ANYOF or VS_LET function and partially by the LAMBDA function.

This technique is useful if the expression has multiple functions that operate on different sets of records which are based on a common path_to_validating_records.

VS_LET(ca, case_version__v, VS_ANYOF(ca.case_assessments_case_version__vr, LAMBDA(element, element.rank__v = 1)))
VS_LET(ca, case_version__v, VS_ANYOF(ca.case_products_case_version__vr, LAMBDA(element, element.mpid__v = "mpid1"))) This example returns true if any of the Case Products on the Case has a Medicinal Product Identifier value of mpid1.
VS_LET(cv, case_version__v, NOT(VS_ANYOF(cv.transmissions_case_version__vr, LAMBDA(t, t.object_type__vr.api_name__v = 'inbound_transmission__v' && t.origin__vr.api_name__v = 'ema__v')))) This example illustrates how to reference an Inbound Transmission in an expression. The expression returns false if the Inbound Transmission on the Case originated from the EMA.
VS_LET(ca, case_version__v, VS_ANYOF(ca.case_assessments_case_version__vr, LAMBDA(element, element.rank__v = 1)) || ca.patient_first_name__v = " any_name__v 123 ")

This example demonstrates using multiple operations within a VS_LET function.

The expression uses the logical OR (||) operator and returns true if either of the following conditions is true:

  • Any Case Assessment on the Case has a Rank value of 1.
  • The Patient First Name field on the Case matches the specified string.
VS_LET(ca, case_version__v, VS_ANYOF(ca.case_adverse_events_case_version__vr, LAMBDA(element, element.days_hospitalized__v = 2)))

These examples demonstrate using multiple operations inside of the LAMBDA function.

The first expression returns true if any Case Adverse Event on the Case has a Days Hospitalized value of 2.

The second expression returns true if any Case Adverse Event on the Case has a Days Hospitalized value of 2 OR (||) is blank.

The third expression returns true if any Case Adverse Event on the Case has a Days Hospitalized value of 2 AND (&&) the Days Hospitalized value is greater than the Minimum Days Hospitalized value of the Organization associated with the Case. In this example, Minimum Days Hospitalized is a custom field on the Organization object.

VS_LET(ca, case_version__v, VS_ANYOF(ca.case_adverse_events_case_version__vr, LAMBDA(element, element.days_hospitalized__v = 2 || ISBLANK(element.days_hospitalized__v) )))
VS_LET(ca, case_version__v, VS_ANYOF(ca.case_adverse_events_case_version__vr, LAMBDA(element, element.days_hospitalized__v = 2 && element.days_hospitalized__v >= ca.organization__vr.min_days_hospitalized__c )))
## Appendix: Custom Validation Criteria Using JSON {#json-method} If required, you can use JSON instead of the Vault Expression Language to create custom _Validation Criteria_. However, we recommend using the Vault Expression Language described above as it is considerably quicker and easier to configure than the JSON method. The JSON method will continue to be supported but will not be enhanced in future releases. The JSON method is similar to that described in Create Custom Validation Criteria above, except that the code you enter in the Rule Formula field must be valid JSON. When E2B files are generated for standard (non-custom) file formats, all of the relevant E2B data is exposed in structured JSON for validation purposes. The following files are examples of the structured JSON for the standard formats that can be used for reference: * E2B(R2): sample-full-e2br2-json.json * FDA E2B(R2): sample-full-fda-e2br2-json.json * HC E2B(R2): sample-full-hc-e2br2-json.json * E2B(R3): sample-full-e2br3-json.json * EMA E2B(R3): sample-full-ema-e2br3-json.json * FDA VAERS E2B(R3): sample-full-fda-e2br3-json.json * PMDA E2B(R3): sample-full-pmda-e2br3-json.json * Case Data: sample-full-case.json You can find validation criteria types, including syntax and limitations, on the JSON Schema website.
### Custom Validation Criteria Examples Consider the following examples of custom _Validation Criteria_ configured in Safety and the JSON syntax for each: #### Example 1: Simple Rule * **File Format**: HC E2B(R2) * **Agency**: Health Canada * **Data Element**: A.2.1.2f * **Data Element Name**: Reporter's Postcode * **Conformance**: "This field is required." * **Vault Object**: `case_contact__v` * **Vault Field**: `postalcode_value__v` * **Rule Formula**: simple-rule-formula.json #### Example 2: Complex Rule * **File Format**: FDA VAERS E2B(R3) * **Agency**: FDA * **Data Element**: D.2.1 * **Data Element Name**: Date of Birth * **Conformance**: "FDA requires that at least one of the data elements in the Age Information section (Date of Birth (D.2.1), Age at Time of Vaccination (FDA.D.2.1a/b), Age at time of Onset of Reaction (D.2.2a/b), Gestation Period When Reaction / Event Was Observed in the Foetus (D.2.2.1a/b), and Patient Age Group (D.2.3)) be populated, preferably Date of Birth and Age at the Time of Vaccination. If Local Criteria Report Type = Malfunction Only (No AE), then all age fields are optional." * **Vault Object**: `case_version__v` * **Vault Field**: `dob_idate__v` * **Rule Formula**: complex-rule-formula.json #### Example 3: Detailed JSON Structure Example * **File Format**: FDA VAERS E2B(R3) * **Agency**: FDA * **Data Element**: D.10.8.r.2a * **Data Element Name**: MPID Version Date / Number * **Conformance**: "This field is required when Medicinal Product Identifier (MPID) (D.10.8.r.2b) is populated." * **Vault Object**: `case_drug_history__v` * **Vault Field**: `mpid_version__v` * **Rule Formula**: 
 1 {
 2  "$schema": "http://json-schema.org/draft-07/schema#",
 3  "type": "object",
 4  "description": "#/sectionD/d_10_patientParent/d_10_8_r_parentDrugHistory",
 5  "definitions": {
 6    "d_10_8_r_2b_POPULATED": {
 7      "properties": {
 8        "_2b_MPID": {
 9          "type": "string",
10          "minLength": 1
11        }
12      },
13      "required": ["_2b_MPID"]
14    },
15    "d_10_8_r_2a_EXISTS": {
16      "properties": {
17        "_2a_MPIDVersionDataNumber": {
18          "type": "string",
19          "minLength": 1
20        }
21      },
22      "required": ["_2a_MPIDVersionDataNumber"]
23    }
24  },
25  "properties": {
26    "sectionD": {
27      "type": "object",
28      "properties": {
29        "d_10_patientParent": {
30          "type": "object",
31          "properties": {
32            "d_10_8_r_parentDrugHistory": {
33              "type": "array",
34              "items": {
35                "type": "object",
36                "if": {
37                  "$ref": "#/definitions/d_10_8_r_2b_POPULATED"
38                },
39                "then": {
40                  "$ref": "#/definitions/d_10_8_r_2a_EXISTS"
41                }
42              }
43            }
44          }
45        }
46      }
47    }
48  }
49 }
Line #2: "$schema" key Specifies the URI for the desired JSON schema version. We recommend using `"http://json-schema.org/draft-07/schema#"`. Line #3: "type" key Specifies the data type for a schema. The top-level JSON element in the structured JSON is always type `"object"`. Line #4: "description" key Specifies the JSON path to the validated JSON element. In this case, the validated JSON element `"_2a_MPIDVersionDataNumber"` is located in `"sectionD → d_10_patientParent → d_10_8_r_parentDrugHistory"`. Lines #5-24: "definitions" Specifies a map of JSON schemas. Each of the schemas defined in this map can be referenced and evaluated by using the `"$ref"` keyword. While not required, definitions can help increase readability when there are multiple schemas (to help describe what each one is validating) and/or for defining a schema that will be used multiple times. Line #6-14: "d_10_8_r_2b_POPULATED" schema Specifies the schema for ensuring that D.10.8.r.2b (`"_2b_MPID"`) is populated. This schema is referenced later using the `"$ref"` keyword, within the schema for `"d_10_8_r_parentDrugHistory"`. * `"type": "string"` → Enforces a string value * `"minlength": "1"` → Enforces a non-blank value * `"required" : ["_2b_MPID"]` → Enforces the element's existence Line #15-24: "d_10_8_r_2a_EXISTS" schema Specifies the schema for ensuring that D.10.8.r.2a (`"_2a_MPIDVersionDataNumber"`) is populated. This schema is referenced later using the `"$ref"` keyword, within the schema for `"d_10_8_r_parentDrugHistory"`. * `"type": "string"` → Enforces a string value * `"minlength": "1"` → Enforces a non-blank value * `"required" : ["_2a_MPIDVersionDataNumber"]` → Enforces the element's existence Lines #25-48: "properties" (top-level) Specifies the properties of the top-level JSON object. The value of the `"properties"` is an object where each key is the name of a property or element and each value is a schema used to validate that element. Lines #26-47: "sectionD" schema Specifies the JSON schema for the `"sectionD"` object. Line #27: "type": "object" Specifies the type of `"sectionD"`, which is an object containing key-value pairs (properties). Line #28: "properties" (sectionD) Specifies the properties of the `"sectionD"` JSON object. It contains key-value pairs where each key is the name of a property/element under `"sectionD"` and the value is a schema used to validate that property. Lines #29-45: "d_10_patientParent" schema Specifies the JSON schema for the `"d_10_patientParent"` property. Line #30: "type": "object" Specifies the type of `"d_10_patientParent"`, which is an object containing key-value pairs (properties). Line #31: "properties" (d_10_patientParent) Specifies the properties of the `"d_10_patientParent"` JSON object. It contains key-value pairs where each key is the name of a property/element under `"d_10_patientParent"` and the value is a schema used to validate that property. Lines #32-43: "d_10_8_r_parentDrugHistory" schema Specifies the JSON schema for the `"d_10_8_r_parentDrugHistory"` property: Line #33: "type": "array" Specifies the type of `"d_10_8_r_parentDrugHistory"`, which is an array containing ordered elements. Lines #34-42: "items" (d_10_8_r_parentDrugHistory) Specifies a single schema that will be used to validate against all items in the `"d_10_8_r_parentDrugHistory"` array. Lines #36-41: "if" → "then" Specifies that the evaluation of a schema (`"then"`) is dependent on the outcome of the evaluation of another schema (`"if"`). In this case, the E2B field D.10.8.r.2a is required (then) only when the E2B field D.10.8.r.2b is populated (if). Line #36-38: "if" schema Specifies the `"if"` schema. In this case, the schema is `"#/definitions/d_10_8_r_2b_POPULATED"`, which was defined earlier and is being referenced using the `"$ref"` keyword. Line #39-41: "then" schema Specifies the `"then"` schema. In this case, the schema is `"#/definitions/d_10_8_r_2a_EXISTS"` which was defined earlier and is being referenced using the `"$ref"` keyword. #### Example 4: Case Data JSON Structure Examples * **File Format**: N/A * sample-global-case-data-json-schema.json * sample-global-case-and-reason-omitted.json * sample-global-case-child-data-json-schema.json * sample-global-case-grandchild-data-json-schema.json * sample-global-localized-case-child-data-json-schema.json * sample-global-localized-case-grandchild-data-json-schema.json * sample-global-transmission-json-schema.json [0]: #example-expressions [1]: #validation-query [2]: #cases-and-submissions-logs