Standard Rules

A Draft in a Standard Library Project may have associated Standard Rules. These rules define:

  • What should and should not appear in a Study Draft (e.g. is a Form allowed or denied in this Study)

  • The settings of object attributes and Custom Properties

These rules are associated with Project Custom Properties and are activated based on the values of those Custom Properties.

Some examples:

  1. A Standard Library defines a Vitals Form which has a question for the subject “Height”. In a neonatal study it may be more appropriate to measure the “Length” of the subject. A Standard Rule may be defined that when the Project Custom Property “Is Neonatal Study?” is set to “Yes” then the Question text for the Vitals HEIGHT question should be “Length”.

  2. A Standard Library defines a Pregnancy Test Form which is commonly used but it should never appear in studies with Male-only subjects enrolled. A Standard Rule may be defined that states when the Project Custom Property “Male Only Study?” is set to “Yes” then the Pregnancy Test Form should not appear in the study.

  3. A Standard Library defines a Pharmacokinetics (PK) Form and this should always be used in Phase I studies. A Standard Rule may be defined that states that when the Project Custom Property “Study Phase” is equal to “Phase I” then the PK Form must exist in the study.

Standard Rules in Standards Compliance

When comparing a Study Draft to a Library Draft, Standards Compliance is calculated for the Study Draft. For example this calculation can tell you if the design of a Form deviates from the Standard Library. However, in many cases we expect some deviation from the Library based up some attributes of the Project or study. Examples of Project attributes which might affect library usage are:

  • The Phase of the Study

  • The Therapeutic Area of the study

  • Whether the study has integrations such as IxRS or Rave Safety Gateway

  • The age range of the subjects

  • The countries or regions where the study will be carried out

  • Whether a study is a new or a roll-over study

These Project Attributes can be created as Custom Properties for the TrialGrid URL and then become available for all Projects in the TrialGrid URL.

Standard Rules can be used to vary the expected presence/absence of a Form, Field or other object from the Study Draft and the expected values of object attributes (such as question text) based on the Project Custom Property settings.

When a Draft is linked to a Library which has Standard Rules defined then the Rules in that library are evaluated against the Custom Property settings of the Project the Study Draft belongs to. i.e. If you create a Project and set its Custom Property for “Therapeutic Area” to “CNS” and then create a Draft in that Project and link it to a Library for standards comparison then the Rules in that library will be evaluated to determine which ones should be active where “Therapeutic Area” is equal to “CNS”. This will affect Standards Compliance calculations.

Logical Expressions

A Standard Rule has a logical expression. When that expression evaluates to True then the Rule is activated. Logical expressions will normally include references to Project Custom Properties. To refer to a Project Custom Property we use the format _p(“<property name>”)_

Examples of expressions:

Expression

Explanation

An empty expression always evaluates to False. This means the Rule will not be activated.

True

Always evaluates to True. This means the Rule will always be activated.

False

Always evaluates to False This means the Rule will never be activated.

p("Therapeutic Area") == "Oncology"

Evaluates True when the Project Custom Property named “Therapeutic Area” is set to the value “Oncology”

p("Therapeutic Area") != "Oncology"

Evaluates True when the Project Custom Property named “Therapeutic Area” is NOT set to the value “Oncology”

p("Therapeutic Area") in ["Oncology","CNS","Derm"]

Evaluates True when the Project Custom Property named “Therapeutic Area” is any one of the values “Oncology”,”CNS” or “Derm”

p("Early Phase Study")

Evaluates True when the Project Custom Property “Early Phase Study” equal to “True”

not p("Early Phase Study") == "True"

Evaluates True when the Project Custom Property “Early Phase Study” does not equal “True” (i.e. is equal to “False” or is empty/not se)

   p("Early Phase Study") == "True"
or p("Therapeutic area") == "CNS

Evaluates to True when the Project Custom Property “Early Phase Study” is equal to “True” or the Project Custom Property “Therapeutic Area” is equal to “CNS”

    p("Early Phase Study") == "True"
and p("Therapeutic area") == "CNS"

Evaluates to True when both the Project Custom Property “Early Phase Study” is equal to “True” AND the Project Custom Property “Therapeutic Area” is equal to “CNS”

not (
      p("Early Phase Study") == "True"
   or p("Therapeutic area") == "CNS"
)

Evaluates to True when the Project Custom Property “Early Phase Study” is not set to “True” or the Project Custom Property “Therapeutic Area” is not equal to “CNS”

to_integer(p("Max Subject Age")) < 18

Evaluates to True when the value of the Project Custom Property “Max Subject Age” converted to an integer number is less than 18.

to_integer(p("Min Subject Age")) >= 21

Evaluates to True when the value of the Project Custom Property “Min Subject Age” converted to an integer number is greater than or equal to 21.

Note

The keywords: True, False, or, and, not, p, to_integer, to_float and “in” are all case-sensitive.

1 Standard Rule Types ——————-

TrialGrid defines three types of Standard Rules:

  1. Must Exist : These Rules state that an object must exist in the Study when the condition is met.

  2. Must Not Exist : These Rules state that an object must not exist in the Study when the condition is met.

  3. Value Must Be : The Rules state that an Object attribute or Custom Property must have a certain value when the condition is met.

Standard Rule Identifiers

In order to identify the study objects that Rules act upon, the Rule Identifier for the object type must be used:

Object Type

Identifier Pattern

Example

Form

FORM_OID

DM

Field

FORM_OID.FIELD_OID

DM.DOB

Folder

FOLDER_OID

SCREEN

Matrix

MATRIX_OID

BASE

MatrixFolderForm

MATRIX_OID.FOLDER_OID.FORM_OID

BASE.SCREEN.DM

Data Dictionary

DATA_DICTIONARY_NAME

SEVERITY

Data Dictionary Entry

DATA_DICTIONARY_NAME.CODED_VALUE

SEVERITY.S

Unit Dictionary

UNIT_DICTIONARY_NAME

HEIGHT

Unit Dictionary Entry

UNIT_DICTIONARY_NAME.CODED_UNIT

HEIGHT.CM

Custom Function

CUSTOM_FUNCTION_NAME

*AlwaysTrue

Derivation

DERIVATION_NAME

CALC_AGE

Edit Check

EDIT_CHECK_NAME

CHK AE_001

Edit Check Action

EDIT_CHECK_NAME.ACTION_NAME (CQL) EDIT_CHECK_NAME.CustomFunction CFNAME (CQL) EDIT_CHECK_NAME.AddForm FORMOID (CQL)

CHK AE_001.OpenQuery (SCREEN.DM.DOB) CHK AE_001.CustomFunction *AlwaysTrue (:DOB) CHK AE_001.AddForm FORM001 (*.DM.DOB)

Note

Check Actions have two forms of identifier. For Custom Function and AddForm Actions the CustomFunction name or Form OID follows the action identifier. For all other action types (e.g. OpenQuery) the Action name only appears. In all cases the CQL value should match the CQL defined for the CheckAction in the TrialGrid Edit Check editor.

Generating a Draft from Library Rules

The Standard Rules in a Library define what objects should and should not exist in a Study Draft and what their attribute values should be given a set of Project-level settings.

From the Draft List page for a Project the “New Draft From Library” button allows a Draft to be generated from a Library and its Standard Rules based on the settings of the current Project.

For example, if a URL has a set of Custom Properties set for the Project attributes:

  • Therapeutic Area (CNS, HIV etc)

  • Study Phase (Phase I / Phase II / Phase III etc)

  • IxRS Integration (Yes/No)

Then the user setting up the Project will select the appropriate values for this Project.

A Library Draft containing standard objects (Forms, Custom Functions, Data Dictionaries etc) may have a set of Standard Rules which match the Project settings. e.g. A Standard Rule which says when a Project Study Phase is Phase I then the PK Form MUST EXIST in this Project.

When creating a Draft from a Library TrialGrid looks at the settings of Custom Properties on the Project the new Draft is being created in. These settings activate (or de-activate) Rules in the Library selected. For example, if the Project Study Phase is “Phase I” then the Rule described above would be activated and the PK Form would be copied into the new Draft because “PK Form MUST EXIST when Study Phase is Phase I”.

How Standard Rules are resolved on Draft Creation

When creating a Draft from a Library TrialGrid identifies all the Standard Rules which are activated by the current Project settings. This is a collection of Standard Rules which state that an object must or must not exist or that some attribute of the object should be changed (e.g. to activate or inactivate it, to change question or query text etc)

For each object targeted by a MUST EXIST rule TrialGrid determines if the set of rule activations should allow this object to be created in the Draft. The highest priority rule between the MUST EXIST and MUST NOT EXIST rules wins.

For example. There might be a set of Standard Rules in the Library Draft to copy from:

RULE A : When _True_ Form “DM” MUST EXIST in the Study (Priority 99)

RULE B : When _p(“Therapeutic Area”) == “HIV”_ Form “DM” MUST NOT EXIST in the Study (Priority 1)

RULE C : When _p(“Therapeutic Area”) == “HIV”_ Form “DM_HIV” MUST EXIST in the Study (Priority 1)

If the Project has Therapeutic Area set to “HIV” then TrialGrid will not create the DM Form but will create the DM_HIV Form.

Explanation:

RULE A states that the DM Form MUST EXIST for all Studies but RULE B is also activated because the Project has Therapeutic Area = “HIV”.

Rule B states that the Form DM MUST NOT exist so RULE A and RULE B are in conflict.

Since RULE B has a Priority of 1 (high priority) and RULE A has a Priority of 99 (lower priority) RULE B wins and the DM Form is not created.

RULE C ensures that the Form DM_HIV is created in the study.

Note

If two (or more) MUST EXIST/MUST NOT EXIST Rules conflict and have the same priority then the MUST EXIST Rule will be selected.

Once an Object is selected to be copied from the Library Draft TrialGrid looks for MUST HAVE ATTRIBUTE Standard Rules which may modify the attributes of that Object. For example, the Help Text of the Form might be changed depending on the Phase of the study.

Child-objects are also copied so when a Form is copied then each of the Fields within the Form is also copied unless there is a MUST NOT EXIST rule specifically targeting that Field. As each Field is copied, MUST HAVE ATTRIBUTE rules for each Field are also examined.

Related objects are also copied and change rules applied to them. If a Field is copied then any associated Data Dictionaries or Unit Dictionaries are also copied.

Must Exist rules on Child Objects

Generally MUST EXIST Rules should be provided for top-level objects such as Forms, Matrices, Data Dictionaries etc. Importing an object also ensures that its child objects are also imported (unless they have specific MUST NOT EXIST rules).

However, it is possible to state MUST EXIST rules for Child Objects such as the Fields in a Form. If a MUST EXIST Rule appears for a child object then this in turn will cause the import of the parent object. In this way the import system traverses from child to parent and then back down again through the children of that parent. For example, if FieldA in a Form1 has a MUST EXIST Rule then Form1 will be imported along with all the other Field children of Form1 (unless there is a Rule that explicitly states that a Field MUST NOT exist).

Important

If there is a MUST EXIST Rule on a Child Object and a MUST NOT EXIST Rule on the Parent Object then the import of the Child Object is cancelled. However, any related objects to the Child Object may still be imported. For example, FieldA has a MUST EXIST Rule. Its parent FORM1 has a MUST NOT EXIST Rule. FieldA will not be imported. However, if FieldA has a related DataDictionary then that Data Dictionary will be imported.