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)

• What may be allowed to appear in a Study Draft (to control what Standards Managers have to review)

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

Rules are created and changed one at a time in the Standard Rule editor. They can also be edited in bulk in a Standard Rule Property Sheet, if one has been defined for your Role.

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.

4. A study build will use a Standard Library but the standards manager does not want to review Custom Functions which are created specific for this study. A Standard Rule may be defined that states that a Custom Function with any name (or a name matching a specific pattern) may exist. Custom Functions created in the study which match this rule are then listed as "allowed changes" from the library and do not require approval. Note that it is also possible to switch off standards compliance reporting for object types at the URL level see Configuring Standards Compliance configuration at URL level.

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 on 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") == "True"	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 set)
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"
int(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.
int(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, int, float and in are all case-sensitive.

Note

int() and float() need the Project Custom Property to hold a number. If the value is blank or is not a number, for example "TBC", the Rule does not apply to that Project.

Standard Rule Types

TrialGrid defines four 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. May Exist : These Rules state than an object may exist in the Study when the condition is met.

4. Must Have Attribute : The Rules state that an Object attribute or Custom Property must match a certain value when the condition is met.

Must Exist Rules

When you want to ensure that a study design contains a particular object (e.g. a Form or Custom Function) a MUST EXIST rule can be defined in the library which ensures that this object exists in any study linked to the library. This is useful when you have standard forms which are used in all studies or when studies with IxRS integrations require a specific set of Forms, Fields, Custom Functions and Edit Checks. The librarian can create a set of rules in the Library which state that when the Project is an IxRS study then these objects MUST exist in a study built from or linked to this library.

Must Not Exist Rules

The opposite of Must Exist rules. Sometimes Forms or other study design objects exist in the library but there are situations where they should not be used. For example, IxRS related Forms, Custom Functions etc may not be desired in studies which do not have IxRS integration. If they are included in the study build they may match the library but they are not valid in the context of that study. In this case a set of MUST NOT EXIST rules can be created by the librarian to ensure that these objects are not used in a study built from or linked to this library.

May Exist Rules

When a study draft is linked to a library draft, compliance between the study draft and the library is calculated. If an object in the study draft is not found in the library draft then this is a deviation and it must be explained by the study builder. However, it is common to have study-specific objects such as Edit Checks, Forms and Custom Functions and some organizations may not wish to have standards managers review every object not found in the library. A set of May Exist rules can be created by the librarian to allow objects not found in the library to be automatically approved for the purposes of compliance checking. Wildcard identifiers (see below) are especially useful for May Exist rules because they allow rules to be written that match objects with any name or with a name that matches a certain pattern (e.g. object name starts, contains or ends with some set of characters).

May Exist rules are also useful for copying optional objects from a Library when creating a Draft from a library using Rules. Objects identified by May Exist rules will be copied from the library to the new Draft but they can then be deleted from the created Draft without triggering any standards compliance issues.

Must Have Attribute Rules

Although a library may contain a standard Form (or other object) some variation of the attributes of that object are expected in some circumstances. For example, some question labels may vary based on whether the study is observational vs having an active medication or for different patient populations. If MUST/MAY/MUST NOT rules determine whether an object should exist, Value Must Match rules determine what it should look like.

Standard Object 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)

Important

[*] Some objects in Medidata Rave are allowed to contain period (.) characters. This can confuse identifiers. For example a Data Dictionary Entry coded value of "UNIT.1" in a Data Dictionary called "WEIGHTS.UNIT" might have a rule identifier like "WEIGHTS.UNIT.UNIT.1" The system cannot know if this is referring to a Data Dictionary called "WEIGHTS.UNIT.UNIT" with a Coded Value of "1" or some other combination. In this situation periods should be identified with the \ character. It would be "WEIGHTS\.UNIT.UNIT\.1".

Note

Check Actions have two forms of identifier. For:

• CustomFunction

• AddForm

• MergeMatrix

• AddMatrix

• OldMergeMatrix

Actions a name/OID (of a Custom Function, Form or Matrix) 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.

Important

When two objects exist with the same identifier only the first will be imported. For example, if a Data Dictionary had two Coded values of "F" "(F/Female and F/Female (Reported)" for example then only one of these (the first in ordinal order) would be imported.

Wildcard Object Identifiers

An Object Identifier can be set as a Wildcard identifier. In this case the Object Identifier is treated as a regular expression which may match many object names, rather than a single name.

A good introduction and tutorial for learning more about regular expressions is here: https://regexone.com/ and you can test the regular expressions used by TrialGrid with the https://regex101.com/ or https://pythex.org/ websites.

Wildcard object identifier examples:

Pattern	Meaning
.*	Match any character (.) repeated zero or more times (*) so applies to all names.
DEMOG	Match the sequence of letters "DEMOG" anywhere in the object name. This pattern would match "ABC_DEMOG_1" and "DEMOG2" as well as "DEMOG"
^DEMOG\d$	Match identifiers that start (^) with DEMOG followed by a single digit (\d) and the end of the identifier ($). This pattern would match "DEMOG1" but not "DEMOG123"
^DEMOG\d*$	Match identifiers that start (^) with DEMOG followed by any number of digits (\d*) and then the end of the identifier ($). This pattern would match "DEMOG1" or "DEMOG123"
^DEMOG(RAPHY)?$	Match identifiers that start (^) with DEMOG followed by RAPHY repeated zero or 1 (?) times. The braces () around RAPHY group these characters together so they can be operated on by the ? This pattern would match "DEMOG" or "DEMOGRAPHY"
^DEMOG(1|2)$	Match identifiers that start (^) with DEMOG followed either (|) by number 1 or 2. and then the end of the identifier ($).
^DM\..*DAT$	Match identifiers that start (^) with DM followed by a period (\.). The period normally means "any character" but we want to match an actual period so the \ "escapes" this period. Then we want any number of characters (.*) ending with DAT and then the end of the identifier ($). This pattern would match "DM.BDAT", "DM.BIRTHDAT" or "DM.VISITDAT" but not "DM.BDATE" since it does not end "DAT"

Wildcard Identifiers are useful when you want to use an object naming convention like "ends with 'DAT'" or "contains 'HIV'" to identify a set of objects and apply a rule to them without having to create a rule for every possible identifier.

Important

Wildcard checks against object identifiers are Case Insensitive. So "demog" will match "DEMOG".

Must Have Attribute rules and Wildcard Values

Must Have Attribute rules are useful when you want to ensure that an object attribute is set to some value. One of our examples was:

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

This rule checks that an attribute of a Field with OID "HEIGHT in the form with OID "VITALS" is always set to "Length". If the conditions of this Rule are met then standards compliance calculations will flag the VITALS Form as non-compliant if its HEIGHT question pretext is not set to "Length".

However, sometimes you may not wish to be so strict. It may be enough that the question text contains the word "Length" and we don't care if the text is "Length:", "Measured Length" or "Enter Length of Subject". Wildcards can be used in this situation also. Using the same patterns as described above for Wildcard Object Identifiers we can enter a pattern of "Length" (meaning match any string containing the characters "Length") and check the "wildcard" checkbox for the attribute.

Important

Wildcard checks against attribute values are Case Sensitive. So Length will not match "length".

Rule Priorities

Each standard Rule has a priority associated with it. The lower the number, the higher the priority of the Rule. A Rule with priority 1 will be applied in preference to a rule with priority 99.

For example, imagine two rules:

RULE A : When p("Uses IxRS") == "True" Form "IXRS" MUST EXIST in the Study (Priority 2)

RULE B : When p("Study Phase") == "I" Form "IXRS" MUST NOT EXIST in the Study (Priority 1)

In the case where the Project custom property "Uses IxRS" is set to "True" and the Project custom property "Study Phase" is set to "I" then these rules are in conflict, Rule A says that IXRS form must exist and rule B says it must not. In this case RULE B wins because it has a priority of 1 which makes it more important than RULE A. If both rules had the same priority then the MUST EXIST (Rule A) rule would win because the system chooses the MUST EXIST rule when MIST EXIST and MUST NOT EXIST rules have the same importance.

Note

When two or more Must Have Attribute Rules for the same attribute of the same object apply to a Study and have the same priority:

• If they all require the same value, that value is applied. View Restrictions, Entry Restrictions and Review Groups are compared as lists of roles or groups, so their order does not matter. Yes/No attributes are compared as true or false, so False and FALSE are the same value, and number attributes as numbers, so 5 and 05 are the same value.

• If any of them requires a different value, none of them is applied, and the attribute is compared with the value in the Library as if there were no Rule.

• When checking standards compliance, a wildcard Rule only agrees with another wildcard Rule with exactly the same pattern, never with a Rule that requires a fixed value.

Rule Health

The Rule Health tab of the Standard Rules page lists the active Rules of a Library Draft that can never take effect, or that duplicate or contradict another Rule, with the reason for each. It is worked out each time the tab is opened, so it reflects the Rules as they are now. The filter button beside the search box shows buttons giving how many findings each check found, which filter the list to one check.

Identifier matches nothing. A Must Have Attribute Rule acts only on an object that is also in the Library, so it is listed when no object of its type in the Library Draft has its identifier (compared ignoring case), or when its wildcard matches no object. Must Exist, May Exist and Must Not Exist Rules are not listed for this, because they also apply to objects a Study adds that are not in the Library. A wildcard that is not a valid regular expression never matches anything, so it is listed whatever the type of Rule.

Attribute name never compared. A Must Have Attribute Rule is listed when its attribute name is not one that standards compliance compares for that type of object: one of the object's attributes, or a Custom Property defined for that type of object in the URL. The name must match exactly, including its case. The nearest valid name is suggested.

Duplicate rules. Rules with the same object, Rule type, attribute, priority, expression and value are listed together. They do no harm, because Rules that agree are applied (see Rule Priorities), but only one of them is needed. Values are compared as described there, and the case of an exact identifier is ignored. Expressions are compared ignoring their layout, such as spacing and whether quotes are single or double, but not the text inside quotes, so "Phase II" and "Phase  II" are different. Expressions joining the same comparisons with and in a different order are the same. A wildcard is compared exactly.

A Rule is also listed as a duplicate of another with the same object, Rule type, attribute and value when the other has the same or a higher priority and is selected by every Study that selects it, so the Rule never changes the result. For example, a Rule with the expression p("EP") == "Yes" is listed under a Rule with the expression True, under the same Rule at a higher priority, and under a Rule with the expression p("EP") != "No". Rule Health works this out from comparisons of a Project Property with fixed values using ==, !=, in or not in, joined with and and or: p("TA") in ["ONC", "HIV"] is true whenever p("TA") == "ONC" is, and so is p("TA") == "ONC" or p("TA") == "HIV". Any other part of an expression is only taken to be true when the other expression contains it written the same way. An expression evaluated as part of an or stops the whole expression when it cannot be evaluated, for example int(p("Age")) for a Study with no Age, so a later alternative is only used when every alternative before it is a comparison of a Project Property with fixed values, which can be evaluated for a Study on the Library's URL. A Study on another URL that does not define the Property is not considered. A Rule whose own expression Rule Health lists under Condition covers no other Rule. Of two Rules at the same priority whose expressions are written differently but always agree, such as p("TA") == "ONC" and p("TA") in ["ONC"], the one whose Rule ID sorts first is listed with the other under it.

A Must Exist or May Exist Rule is only listed under one with a higher priority, not the same priority. A Study selecting several of these Rules at the same priority applies the one whose Rule ID sorts first, whatever their expressions, so removing one of them can change which applies. For the same reason, of a set of identical Must Exist or May Exist Rules the one whose Rule ID sorts first is listed first, and it is the one to keep.

Same-priority disagreement. Two Rules with the same priority that apply to at least one of the same objects in the Library are listed together when they disagree:

• Must Have Attribute Rules for the same attribute that require different values, because a Study selecting both applies neither.

• A Must Not Exist Rule and a Must Exist or May Exist Rule, because a Study selecting both keeps the object.

• A Must Exist Rule and a May Exist Rule, because a Study selecting both applies whichever Rule's ID sorts first, which is named.

They are not listed when their expressions cannot both be true: when each requires something of the same Project Property, in an expression that is a single comparison or comparisons joined with and, using ==, !=, in or not in against fixed values, and no value meets both. Any other expression is assumed to allow both, so a pair may be listed that no Study in fact selects together.

Condition. A Rule is listed when no Study can select it, because it has no expression or its expression cannot be evaluated, for example because it names a Project Property the URL does not define. It is also listed when it compares a Choice Project Property with a value that is not one of the property's choices. An inactive choice is not listed, because Projects already set to it still select the Rule. A comparison of fixed values only, such as "TA" in ["ONC"], is listed because it is the same for every Study; where one of the values is the name of a Project Property, p("TA") is suggested.

Role or Review Group not in the URL. A Must Have Attribute Rule for the ViewRestrictions or EntryRestrictions of a Form or Field is listed when it names a role that is not one of the URL's EDC Roles, and one for the ReviewGroups of a Field when it names a Review Group the URL does not have. Names are compared ignoring their case. A Rule naming an inactive EDC Role or Review Group is also listed, because the form editor does not offer it and Diagnostics report a Study object that names one. Where an unknown name has the same words as an active one of the URL's in another order, or is spelled like one, that one is suggested. A Rule whose value is a wildcard is not checked.

A user whose role can edit objects in the Draft can select findings in the list and choose an action from the Actions menu. The Draft must not be locked.

• Delete… and Inactivate… apply to the Rules of selected Identifier matches nothing and Condition findings. They show the Rules affected and ask for confirmation. Any other selected finding is left out and named, because fixing it means choosing which Rule to keep.

• Fix… steps through the selected findings: one step for each set of duplicates, one for each Rule's own problems, and one for each disagreeing pair. Each step suggests a fix where there is one, and every step can leave things unchanged.

  • An identifier can be changed, and Test shows what it would match. The nearest identifier in the Library is suggested. A Rule with no near identifier is deleted unless another choice is made.

  • An attribute name is chosen from the attributes standards compliance compares for that type of object. The nearest one is selected.

  • An expression can be edited, and the choices of the Project Properties it uses are shown. A Rule that no Study can select is deleted unless another choice is made, except one that compares fixed values where a value names a Project Property: "TA" in ["ONC"] is rewritten as p("TA") in ["ONC"], and the Rule is fixed that way unless the rewritten expression still has a problem, when it is left unchanged.

  • The roles or Review Groups a Rule requires can be edited, and the URL's active ones are shown. A name the URL does not have is replaced with an active one with the same words in another order. A name that is only spelled like one of the URL's is not replaced, since it may be a different role. A Rule with a name that is not replaced, or that is inactive, is left unchanged unless another choice is made.

  • For a set of duplicates, one Rule is kept and the others are deleted. Where one Rule covers the others, only it can be kept, or all of them, since keeping a covered Rule would delete the Rule that applies to the Studies it does not. Of identical Must Exist or May Exist Rules, only the one whose Rule ID sorts first can be kept.

  • For a disagreeing pair, the priorities of both Rules can be changed, or left as they are. The Rule with the lower number applies.

  A change that would still be listed is refused at its step. Choosing to delete a Rule skips the later steps for it.

Nothing is saved until the changes are confirmed, on the last step of Fix… or in the window Delete… and Inactivate… open, which lists every change and the number of Drafts each Rule is active in. The changes are then saved together: if any of them cannot be saved, for example because the Rule was deleted meanwhile, none is, and the reasons are shown. The Drafts that use the Rules are then recalculated once for all the changes, and the Rule Health list is shown again.

Clicking a Rule in the list opens it in a window over the list, so the selection and filters are still there when it is closed. The list is not worked out again when the window closes. A selected finding that is no longer reported, because a Rule was changed or deleted since the list was shown, is named on the last step and left alone.

A finding that has been looked at and is to stay as it is can be dismissed. Select it and choose Dismiss… from the Actions menu; a reason is required, and it is recorded in the history of each Rule in the finding. Dismissing applies to the whole finding, so a set of duplicates or a disagreeing pair is dismissed together, and one Rule's other findings are still listed. A finding is its check and its Rules: if a set of dismissed duplicates gains another Rule, the larger set is a new finding and is listed, and if that Rule is later removed, the set that was dismissed is hidden again.

A dismissed finding is hidden from the list, and left out of the counts, until one of its Rules changes in a way that affects what Rule Health finds: its type, object type, object identifier, attribute, value, priority, expression or whether it is active. Editing a Rule's Identifier, description, labels or Custom Properties does not bring the finding back. A Condition finding also comes back when it gains a reason it did not have when it was dismissed, for example when a choice its expression uses is removed from the Project Property. This is checked each time the Rule Health list is shown. When a finding comes back, its dismissal ends, and this is recorded in the history of each Rule in the finding. Changing the Rule or the Project Property back afterwards does not hide the finding again. A change that is undone before the list is next shown leaves the dismissal in place. On a locked Draft, a dismissal that no longer holds is not applied, so its finding is listed, but it only ends when the list is shown after the Draft is unlocked.

The filter buttons can show dismissed findings, each with who dismissed it, when and why. Withdraw dismissal… lists a dismissed finding again. When a Library Draft is copied, its dismissals are copied with its Rules.

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 defined as Custom Properties.

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 Projects custom properties.

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.

Note

Wildcard Must Have Attribute rules are ignored when creating a Draft from a Library in this way because these rules are used to check values, not to set them. For example, if the Wildcard rule says the Attribute must match a pattern of 3 letters followed by a number, the system can't know what actual value to enter.

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, 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 particular 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.

Steps in the Import Process

When creating a Draft from a Library via Standard rules the system follows this process:

1. Identify all the rules in the Library Draft that evaluate True for the current Project settings.

2. Expand all the Wildcard Object identifier rules into individual rules by finding all objects in the Library draft which match the rules. For example a Rule "Forms with OID ^VITALS(1|2|3)$ MUST NOT EXIST" will search the library for all forms which match this pattern. If forms VITALS1, VITALS2, VITALS3 and VITALS4 exist then this will match for VITALS1, VITALS2 and VITALS3 and the wildcard rule will be turned into 3 fixed rules:

   • "Forms with OID VITALS1 MUST NOT EXIST"

   • "Forms with OID VITALS2 MUST NOT EXIST"

   • "Forms with OID VITALS3 MUST NOT EXIST"

   In this way a single wildcard rule can be expanded into several fixed rules before processing.

3. Process the active Must Exist rules in the following order, omitting elements with Must Not Exist rules and applying changes to attributes defined by Must Have Attribute rules

   1. Data Dictionaries

   2. Data Dictionary Entries

   3. Unit Dictionaries

   4. Unit Dictionary Entries

   5. Folders

   6. Custom Functions

   7. Forms

   8. Fields

   9. Matrices

   10. Derivations

   11. Derivation Steps

   12. Checks

   13. Check Steps

   14. Check Actions

   15. Matrix Folder/Forms

   16. Custom Properties of Objects

At the end of this step of the process the new draft will be populated with Forms, Fields, Folders and other objects but to avoid the need to create Must Exist rules for every object the system then tries to find objects in the library which are related to what has already been populated but which have not themselves been copied over.

It performs two further steps:

1. Examine all Matrices in the Library Draft. Any which contain a Folder/Form combination which are already in the new Draft are copied over along with those combinations. For example, if FORM1 and FOLDER1 have been copied to the new Draft via Must Exist rules but Matrix MATRIX1 has not been copied over. MATRIX1 contains two folder/form combinations FORM1/FOLDER2 and FORM1/FOLDER1. In this case FORM1 and FOLDER1 exist in the new Draft and so MATRIX1 will be copied over with the FORM1/FOLDER1 combination. The MATRIX1 copy in the Draft will not include the FORM1/FOLDER2 combination because FOLDER2 was not found in the new Draft.

2. Examine all Edit Checks in the Library Draft. If the Edit Check steps and actions ALL reference Folders/Forms/Fields which exist in the new Draft then the Edit Check will be copied over to the new Draft. Note that this does not include Edit Checks with AddForm, AddMatrix and MergeMatrix actions where the target of the action does not already exist in the new Draft because including these would require copying in the related Form or Matrix which would require further analysis for their related Edit Checks etc.

3. Examine all Derivations in the Library Draft. If the Derivation target and steps ALL reference Folders/Forms/Fields which exist in the new Draft then the Derivation will be copied over to the new Draft.

These steps exist to reduce the number of Must Exist rules that would otherwise have to be written to ensure every Matrix, Edit Check and Derivation is copied over.

At the end of this process, all selected objects are copied to the new Draft.

Generating Documents

If your URL has Document Templates defined for Standard Rules, a "Documents" entry appears in the "Actions" menu above the list. The generated document receives the Standard Rules you have selected with the row checkboxes, and those matching whatever search and filters are active, so a report can cover just the part of the list you are looking at.