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 Preganncy 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 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 objects in Rules, the Rule Identifier for the object type must be used:

Object Type

Identifier Pattern

















Data Dictionary



Data Dictionary Entry



Unit Dictionary



Unit Dictionary Entry



Custom Function






Edit Check


CHK AE_001

Edit Check Action


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


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 Therapeutic Area = “*” (i.e. any value) Form “DM” MUST EXIST in the Study (Priority 99)

RULE B : When Therapeutic Area = “HIV” (i.e. any value) Form “DM” MUST NOT EXIST in the Study (Priority 1)

RULE C : When Therapeutic Area = “HIV” (i.e. any value) 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.

RULE A states that the DM Form MUST EXIST for all Studies (any Therapeutic Area value) 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 but RULE B has a Priority of 1 (high priority) and RULE A has a Priority of 99 (lower priority) so RULE B wins and the DM Form is not created. RULE C ensures that the Form DM_HIV is created in the study.


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).


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.