About data-entry rules

Creating

You create the following rules in the Rules tab:

• An intrinsic rule.
• A rule without a function.
• A rule using a function.

About

A data-entry rule is a rule that checks whether data is valid or that sets the value of an item based on a calculation. Different actions occur as a result of the evaluation of the rule expression. For example, an email can be sent or a query can be created.

A data-entry rule is part of a study object and not a separate component that is attached to the study object. Rules can be part of study designs, study elements, study events, forms, and items.

Because rules are part of study objects, when you reuse a study object from the library, you reuse the rules that are defined on that study object.

• When a rule is part of a study object template or type, the rule is automatically part of all study objects created from the template or type.
• When a rule is part of a study object and the study object is copied into another project, the rule is copied with the study object.
• For valid data-entry rules, if you modify the RefName of a study object referenced by the rule, the data-entry rule is automatically updated with the change.

  Note: Modifying the RefName of a study object from within the rule expression prevents the study object from being updated in rules that reference the study object.

Types

You can create the following types of rules.

• Intrinsic rules.
• Calculation rules.
• Constraint rules.

Depending on the rule, it might be better to use an intrinsic rule, an expression rule, or a function.

Structure

All data-entry rules consist of three parts.

• Precondition

  The event that causes a rule to execute, such as On Demand (Batch Mode) or Form Submission.

• Expression

  The expression that is evaluated.

• Action

  The action or actions to take depending on the result of evaluating the rule expression, such as create a query, store a value, or send an email message.

  Note: The action clause is similar to an If statement in C++, C#, or Java.

Scope

A rule that is part of a study object can refer only to:

• The study object and its children.
• Properties and values of the study object and its children.

This concept is called scope.

Running order

You cannot set the order in which data-entry rules are run.

Rule deployment

Rules created with two or more different actions are deployed to the InForm application as multiple rules. For example, a rule might call for:

• A query to be sent.
• An email message to be sent.
• A value to be set.

A different rule is created in the InForm application for each type of action. In the previous example, three rules are created:

• One rule sends a query.
• One rule sends an email message.
• One rule sets a value.

Deciding among hard-coded values, constants, and data mappings

Oracle recommends that you do not use hard-coded values or hard-coded constants in rules, as the rule might be less reusable. Consider using constants or data mappings instead. A data mapping is another name for an item that has been added to a data series and has a global scope for the purposes of rule creation.

If the value of an item is constant for every subject in a study, such as lab normal ranges, use constants. For example, if you expect blood pressure ranges to be uniform for all subjects in a study, you can use a constant for blood pressure.

If you want to capture dynamic values, such as gender, which varies from subject to subject, use data mappings. For example, acceptable hemoglobin ranges differ for men and women, so it makes more sense to use data mappings for these values in a rule.

Testing rules

You create test cases in the Rule Test Cases dialog box to test data-entry rules, workflow rules, and global conditions before deploying a study. Depending on the rule, you might create several or many test cases.

You can create test cases either after writing each rule or after all rules are finished.

To make sure that a rule is written correctly, consider writing and running a single test case for it, so you do not write many test cases for a rule that needs to be modified.

Naming conventions

You are not required to use a naming convention for rules, but conventions can help you distinguish one type of rule from another and avoid duplicate RefNames. If you want to adopt a naming convention, consider prefixing rules with the following:

• wr - workflow rule
• gc - global conditions
• rul - data-entry rules (for example, rulDMConsDtCompare)