Home > CDX > Business Rules and DOH Tasks > Rule Components and Structure

Rule Components and Structure

Rules can be created to help ensure that a run report is complete, conflicting information is caught, inaccurate or improperly formatted entries are resolved before submission, and department standards are followed.

Rule Structure

Before you start creating a rule, it is a good idea to become comfortable with the basic structure of a flexible business rule. This structure is flexible to an extent, but each rule you construct will contain, in this order, the following components:

  • Rule – comprised of statements, requirement groups, requirements, and sub-conditions.

  • Statement – contains logical conditions that, when True/False, an actions is performed.

  • Requirement Group – set of logical conditions combined together with And/Or operators.

  • Requirement – a single logical condition (Field X, Operator, Comparison, Field Y/Value).

  • Sub Group/Sub Condition – group of logical conditions tied to a single requirement.

  • Action – single executable result; triggered when a statement’s conditions are True.

  • Data Field – A single data entry field.

Data Types

All Data Fields in FBR are tied to a Data Type, the following are the available data types.

  • Array – an array structure containing 0:M rows. Rows are complex objects.

  • Boolean – simple (true/false) data fields that are nullable. Values selected equate to a standard true, false, or null.

  • Date – simple date data fields. For Full Date/Time, a timestamp in milliseconds. For Date Only, a string representation of the chosen date (12-25-2014).

  • MultiSelect – similar to Pick Lists, can select more than one option. Structured as a basic array of values.

  • Number – simple numeric data fields that may also contain decimal places and are nullable.

  • PickList – fields represented by single-select drop-downs. Options in these lists are configured in CDX and are determined by either NEMSIS Code or ID (identifier for the picklist item).

  • String – basic text values.

  • UI Element – wraps groups of data fields or is used as a label. These fields do not contain data, are not introspectable, and can only have Actions performed on them.

  • Time – Time Only datafields, usually in conjunction with Date Only field. Typically only used with simple EXISTS rules.


Both Boolean and Arithmetic operators are used to define a flexible business rule, setting relational parameters so that a rule can appropriately trigger a warning or error message when specifications are not met. Arithmetic operators represent mathematical symbols used in all calculations and include MINUS, PLUS, and DIVIDED BY.  Boolean operators allow use of various conditional expressions, including EQUALS and GREATER THAN. Such expressions produce a true or false value when evaluated. For example, “5>3” is true.

The following Boolean and Arithmetic conditions can assist you in generating specific, tailored FBRs that are most appropriate for your department.

Boolean Operators

  • Equals – checks the equality between a field and a static value, a field and another field, or the result of an operation and a static value. 
    Applicable Data Types: All
    Example: Scene Address EQUALS Patient Address

  • Not Equal – opposite of EQUALS.
    Applicable Data Types: All

  • Greater Than – compares a field, or result of an operations, that has a numeric or date value; Field 1 > Field 2
    Applicable Data Types: Date, Number
    Example: GCS Total Score > 5

  • Less Than – compares a field, or result of an operation, that has a numeric or date value; Field 1 < Field 2
    Applicable Data Types: Date, Number

  • Equal or Greater Than – opposite of LESS THAN.
    Applicable Data Types: Date, Number

  • Equal or Less Than – opposite of GREATER THAN.
    Applicable Data Types: Date, Number

  • Contains – for arrays, given a sub-condition, requires at least one item in the array to meet that criteria.

  • Does Not Contain – opposite of CONTAINS.
    Applicable Data Types: Array, MultiSelect, String

  • RegEx (Regular Expression) – checks if the value of a field matches a specific pattern. PickList/MultiSelect comparisons will perform a REGEX on the specified property.
    Applicable Data Types: String, PickList, MultiSelect
    Example: check if a phone number field is in the “(123) 456-7890” field.

  • Not RegEx – opposite of REGEX.
    Applicable Data Types: String, PickList, MultiSelect

  • Exists – checks if a field’s value has been populated or a pick list item has been selected.
    Applicable Data Types: All

  • Does Not Exist – opposite of EXISTS.
    Applicable Data Types: All

Arithmetic Operators

  • Count – returns the number of items in the array or the number of values in the mulitselect.
    Applicable Data Types: Array, MultiSelect

  • Conditional Count – returns the number of items in an array which meet the defined condition. Sub-conditions defined as a collection of rule requirement groups joined together.
    Applicable Data Types: Array

Note: Only supported in TripTix Web/Windows 4.1.11+.

  • Minus – applies numeric subtraction (Number) or temporal subtraction (Date) between two applicable data fields.
    Temporal subtraction returns a Duration of time
    Applicable Data Types: Number, Date

  • Plus – applies numeric addition (Number) or string concatenation (string) between two applicable compassion fields.
    Applicable Data Types: Number, String

  • Times – applies numeric multiplication.
    Applicable Data Types: Number

  • Divided By – applies numeric division.
    Applicable Data Types: Number


Actions can be used with flexible business rules to perform specific actions on data fields whenever a particular rule is triggered. Rules can be limited to TripTix Web, Windows, and/or All Devices. If a rule is set only for Web, actions are only performed for this environment when the appropriate conditions are met. The same applies when a rule is set for only Windows. Due to some minor differences in the user interface between Web and Windows, you may consider setting a rule for just one of these environments when logical.

The following are common actions that can be used to display custom messages, hide data fields, mark required elements, and more. 

  • Display Message – displays a custom message to users in the Error Messages list; also specified in the UI by linking to a data field.

  • Hide – hides a data field. Data within the hidden item is removed.

  • Show – shows a data field that was previously hidden. If both Hide and Show are implemented on the same field, Show overrides its counterpart.

  • Required – marks a data field as Required. When required, an error is thrown if the field does not contain a valid value. 
    This rule is equivalent to: IF (dataField DOES NOT EXIST) THEN DISPLAY MESSAGE (error) “dataField is required.”

  • Disable – disables a data field, disallowing the entry of data by users. Any data contained in the disabled field will appear, but no new data can be entered.

  • Enable – enables a data field. Data fields are enabled by default. If both Disable and Enable are implemented on the same field, Enable overrides its counterpart.

  • Recommended – marks a data field as Recommended. Such marked fields may or may not be filled out and are not considered a warning.

  • Set Value (if empty) – updates the value of a data field with the provided value ONLY if the data field was not completed. 
    Applicable Data Types: All except Date/Time

Note: Only supported in TripTix Web/Windows 4.1.11+.

  • Overwrite Value – update the value of a data field with the provided value regardless of any existing data.
    Applicable Data Types: All except Date/Time.

Note: Only supported in TripTix Web/Windows 4.1.11+.

  • Add Array Row – adds a new row to the array with within the given parameters and values.
    Applicable Data Types: Array

Note: Only supported in TripTix Web/Windows 4.1.11+.

Action Severity

When applying an action to a rule, you must determine the severity of such action when it is triggered. There are two severity levels: Error and Warning. If defined as an Error in the Then section, the actions prevent the run from being finalized when the action is triggered. Runs saved with errors are considered Incomplete.

If Warning defines the set of actions in the Then section, the actions do not prevent the run record from being finalized when the rule conditions are not met. Runs saved with just warnings are considered Complete.

Editor Features

When it comes to FBRs, it is important to note that statements, requirement groups, requirements, and actions are all cloneable as applicable. Steps to clone these elements are included throughout this guide.

Additionally, the order of statements, groups, and requirements does not have a functional impact on the rule itself. The order of actions, however, can be significant, particularly when using Set Value, Overwrite, or Add Array Row actions. For example, with multi-selects, Set Value pushes values in whereas Overwrite clears a selection and enters one specific value. Thus, if you had Set Value ordered before Overwrite, the value from Overwrite would be the one to persist.

Requirement Groups

Requirements can be grouped together, meaning all or some of the requirements must apply in order for the rule to be triggered. If requirements are grouped and separated by the AND condition, all requirements in this group must apply before the rule is triggered. If requirements are grouped and separated by the OR condition, one or more of the requirements in the group must apply before any defined action is taken.

Note: If at any point you change the logical operator between REQUIREMENT1 and REQUIREMENT2 from an AND to an OR statement (or vice versa), the operator will change for all requirements.


Else-If conditional statements specify a new condition to test if the first condition is false.

AND versus OR

When writing rules, if AND is selected when creating requirement groups, both requirements must be met before the rule triggers the assigned action. If OR is selected, only one of the listed requirements must be met before the assigned action is triggered. 

For every requirement group added, you must determine whether AND or OR applies. Choosing the wrong designation may cause actions to be unnecessarily triggered and/or not enforced when applicable.

Last modified



This page has no classifications.