This feature is part of a paid plugin that is not part of enterprise or community edition. Email contact@krishagni.com for more details.

Introduction

Data validation is used to enter high-quality data. This ensures that while entering the data, the user does not violate any data entry rules. These rules can be defined either at the system level or at the CP level and the CP level take precedence over the system-level validations. They can be defined as below:

Data Validation is a series of constraints designed to check the validity of the input data.
Data Validation constraints can be made of variables of a single record or multiple records.
Data Validation is like database check constraints designed to ensure high-quality specimen data is collected.

For example

Participant age at the time of registration should be more than 18 years
Only male participant registrations are allowed
Frozen event timestamp should be later than the specimen creation time.

Defining Data Validation

Data validations can be defined using JSON. The ‘editChecks’ section of the code needs to be inserted after the ‘dictionary’ section in the workflows JSON.

Click here to view details for the configuration..

The code has three parts - records, forms and rules
1. records - Whenever any of these specified records are modified; the constraint rules should be evaluated/enforced. This refers to the data entry level at which the fields are present for which the edit check is to be applied. The value for records can be cpr, specimen, visit or a combination of these.
2. forms - Optional field. If present, specifies the list of forms whose data is used to enforce the constraints.
3. rules - List of integrity rules that should be satisfied by the records and forms.
A ‘rule’ is made up of three attributes when, expr, and description.
1. when: The attribute 'when' is optional and specifies when the rule is applicable. For example, the rule is applicable only for primary specimens
2. expr: The attribute 'expr' specifies the check constraint that should be satisfied.
3. description: The attribute 'description' describes the constraint in user-friendly language. This is also used in error messages when the rule is broken or not satisfied.
Aliases for rules are - “cpr, visit, primarySpecimen, specimen”, which are self-explanator.
Aliases for accessing the form records are cprForms, visitForms, primarySpecimenForms, specimenForms. These are maps that can be indexed by the form name to access the relevant form data. For example, specimenForms['SpecimenFrozenEvent'] can be used to access the latest frozen event. Similarly, specimenForms['SpecimenFrozenEvent$Array'] can be used to access the list of all the frozen events for the specimen in question.

Example: Visit date should be same or later than the registration date

For more examples, please refer to the wiki page Data Validation Examples

Click here to expand...

{
  "name" : "editChecks",
  "data" : {
    "constraints" : [ 
      {
        "records" : [ "cpr", "visit" ],
        "rules" : [
          {
            "expr" : "#cpr.registrationDate != null && #visit.visitDate != null && !#cpr.registrationDate.after(#visit.visitDate)",
            "description" : "Visit date should be same or later than the registration date!"
          } 
        ]
      }
    ]
  }
}

Adding Multiple Edit Checks in Same Workflow

In case there are many edit checks to be performed, here is a tip that could help in avoiding errors:

Check and test the data entry workflow after adding each edit check. This will allow you to identify if any edit check fails and will be useful in rectifying the failed one. In case all the edit checks are added together, it might be difficult to identify the edit check in case the above error ‘Cannot index into a null value’ occurs.

Data Validations (Edit Checks)

Introduction

Defining Data Validation

Example: Visit date should be same or later than the registration date

Adding Multiple Edit Checks in Same Workflow