Conditions

Like validations, dynamic logic conditions return a Boolean. The difference is that a condition has one or more objects as its input parameters, rather than a single value. Which object(s) are passed along as input parameters differs per signature. Oracle Health Insurance interprets the return value according to Groovy truth logic. That means that it interprets a returned null value as false.

Bulk Update Definition

A bulk update definition is evaluated during the bulk update of a policy.

The following signature applies:

In / Out	Name	Type	Description
In	bulkUpdateDefinition	BulkUpdateDefinition	The bulk update definition being evaluated (can be used to parametrize the dynamic logic)
In	policy	Policy	The policy that is being evaluated for bulk update
Out	n/a	Boolean	True when update on the policy should happen

This signature specifies the referenceDate on the bulk update definition as the default as-of date. If there is no referenceDate defined on the bulk update definition, then system date is set as the default as-of date.

Callout Rule

This type of dynamic logic can be attached to a callout rule to determine whether a callout should be executed during the processing of a policy. The following signature applies:

In / Out	Name	Type	Description
In	calloutRule	CalloutRule	The rule being evaluated (can be used to parametrize the dynamic logic)
In	policy	Policy	The policy that is being evaluated
Out	n/a	Boolean	True when the callout rule must be executed

This signature does not specify a default as-of date.

Country

It’s possible to specify a condition on a country. Only addresses that meet this condition are valid for that particular country. The following signature applies:

In / Out	Name	Type	Description
In	address	Address	The address to be checked
Out	n/a	Boolean	True when the address is allowed

This signature does not specify a default as-of date. This dynamic logic condition is executed when an address (in the specified country) is created or updated.

Dynamic Field Usage

A dynamic field usage extends a table with a dynamic field. A dynamic usage can specify two dynamic logic conditions: the first specifies when it is allowed to set the value for a dynamic field, the second specifies when it is required to set the value for a dynamic field. Both conditions have their own signature.

The following signature applies to dynamic field usage conditions that specify when a value is allowed:

In / Out	Name	Type	Description
In	Depends on the entity being extended	Depends on the entity being extended	The entity that is being extended
Out	n/a	Boolean	True when the dynamic check message must be attached

This signature does not specify a default as-of date. The condition is executed when a user or integration point request message tries to set the value of the dynamic field.

For example, if the dynamic field usage is on the REL_RELATIONS table, the object name in the dynamic logic is "relation", being of the type "Relation". Consider the following condition to clarify:

return relation.isPerson() && relation.gender=='F'

The following signature applies to dynamic field usage conditions that specify when a value is mandatory:

In / Out	Name	Type	Description
In	Depends on the entity being extended	Depends on the entity being extended	The entity that is being extended
Out	n/a	Boolean	True when the dynamic check message must be attached

This signature does not specify a default as-of date. The condition is executed a new record (in the extended table) is being created or an existing record is being updated.

Fee Definition

A fee definition is evaluated during the generation of a fee for a policy or a person/object on a policy. There are two signatures for fee definition conditions:

The following signature applies to fee definitions with level "Policy":

In / Out	Name	Type	Description
In	feeDefinition	FeeDefinition	The fee definition being evaluated (can be used to parametrize the dynamic logic)
In	policy	Policy	The policy that is being evaluated
Out	n/a	Boolean	True when a fee should be generated

This signature uses the effective date on the policy mutation as the default as-of date.

The following signature applies to fee definitions with level "Enrollment":

In / Out	Name	Type	Description
In	feeDefinition	FeeDefinition	The fee definition being evaluated (can be used to parametrize the dynamic logic)
In	policyEnrollment	Policy Enrollment	The policy enrollment that is being evaluated
Out	n/a	Boolean	True when a fee should be generated

This signature uses the effective date on the policy mutation as the default as-of date.

HTTP Link

This type of logic can be attached to a HTTP link definition which determines whether the link should be displayed in the "Links" drop down menu. The following signature applies:

In / Out	Name	Type	Description
In	Depends on the page	Depends on the page	The object that the page provides as input.
In	httpLink	HTTP Link	The http link that is being evaluated
Out	n/a	Boolean	True when link should be displayed

MDS (Condition)

OHI has a component that can evaluate a dynamic logic condition and return true or false. This outcome can then be used by an MDS developer, for example to conditionally show a field. The input object is the object on which MDS is being applied.

Output Definition

An output definition is evaluated during the generation of output for a policy or a person/object on a policy. There are two signatures for output definition conditions:

The following signature applies to output definitions with level "Policy":

In / Out	Name	Type	Description
In	outputDefinition	OutputDefinition	The output definition being evaluated (can be used to parametrize the dynamic logic)
In	policy	Policy	The policy that is being evaluated
Out	n/a	Boolean	True when output should be generated

This signature does not specify a default as-of date.

The following signature applies to output definitions with level "Enrollment":

In / Out	Name	Type	Description
In	outputDefinition	OutputDefinition	The output definition being evaluated (can be used to parametrize the dynamic logic)
In	policyEnrollment	Policy Enrollment	The policy enrollment that is being evaluated
Out	n/a	Boolean	True when output should be generated

This signature does not specify a default as-of date.

Parameter Value

This type of dynamic logic can be attached to a parameter domain value to determine whether a parameter domain value is valid for the policy enrollment product. The following signature applies:

In / Out	Name	Type	Description
In	policyEnrollmentProduct	PolicyEnrollmentProduct	The policy enrollment product being evaluated
In	parameterDomainValue	ParameterDomainValue	The parameter domain value that is being evaluated
Out	n/a	Boolean	True when the parameter domain value is available for the policy enrollment product / insurable entity

This signature does not specify a default as-of date.

Pend Rule

This type of dynamic logic can be attached to a pend rule rule to determine whether a policy should be pended during the processing of the policy. The following signature applies:

In / Out	Name	Type	Description
In	pendRule	PendRule	The rule being evaluated (can be used to parametrize the dynamic logic)
In	policy	Policy	The policy that is being evaluated
Out	n/a	Boolean	True when the policy must pend

This signature does not specify a default as-of date.

Policy Validation Rule

A policy validation rule is evaluated during the processing of a policy. There are three levels (signatures) for policy validations.

• Policy

• Policy Enrollment

• Policy Enrollment Product The following signature applies to policy validation rules with level "Policy":

In / Out	Name	Type	Description
In	policyValidationRule	PolicyValidationRule	The policy validation rule being evaluated (can be used to parametrize the dynamic logic)
In	policy	Policy	The policy that is being evaluated
Out	n/a	Boolean	True when the policy validation rule message should be attached and/or the policy validation rule function dynamic logic should be executed

This rule is triggered for each policy. This signature does not specify a default as-of date.

The following signature applies to policy validation rules with level "Policy Enrollment":

In / Out	Name	Type	Description
In	policyValidationRule	PolicyValidationRule	The policy validation rule being evaluated (can be used to parametrize the dynamic logic)
In	policyEnrollment	PolicyEnrollment	The policy enrollment that is being evaluated
Out	n/a	Boolean	True when the policy validation rule message should be attached and/or the policy validation rule function dynamic logic should be executed

This rule is triggered for each person or object on the policy. This signature does not specify a default as-of date.

The following signature applies to policy validation rules with level "Policy Enrollment Product":

In / Out	Name	Type	Description
In	policyValidationRule	PolicyValidationRule	The policy validation rule being evaluated (can be used to parametrize the dynamic logic)
In	policyEnrollmentProduct	PolicyEnrollmentProduct	The policy enrollment product that is being evaluated
Out	n/a	Boolean	True when the policy validation rule message should be attached and/or the policy validation rule function dynamic logic should be executed

This rule is triggered for each policy enrollment product on the policy. This signature’s as-of date defaults to the policy enrollment product start date.

Group Client Validation Rule

A group client validation rule is evaluated during the processing of a group client. There are two levels (signatures) for group client validations.

• Group Client

• Group Account

The following signature applies to policy validation rules with level "Group Client":

In / Out	Name	Type	Description
In	groupCientValidationRule	GroupCientValidationRule	The group client validation rule being evaluated (can be used to parametrize the dynamic logic)
In	groupClient	GroupClient	The group client that is being evaluated
Out	n/a	Boolean	True when the group client validation rule message should be attached and/or the group client validation rule function dynamic logic should be executed

This rule is triggered for each group client. This signature does not specify a default as-of date.

The following signature applies to policy validation rules with level "Group Account":

In / Out	Name	Type	Description
In	groupCientValidationRule	GroupCientValidationRule	The group client validation rule being evaluated (can be used to parametrize the dynamic logic)
In	groupAccount	GroupAccount	The group account that is being evaluated
Out	n/a	Boolean	True when the group client validation rule message should be attached and/or the group client validation rule function dynamic logic should be executed

This rule is triggered for each group account within the group client. This signature does not specify a default as-of date.

Schedule

This type of dynamic logic can be attached to a schedule definition to determine whether the premium schedule, adjustment or surcharge using that definition should be applied to a policy enrollment product during premium calculation. The following signature applies:

In / Out	Name	Type	Description
In	scheduleDefinition	ScheduleDefinition	The schedule definition that is being evaluated (can be used to parametrize the dynamic logic)
In	premiumSchedule	PremiumSchedule	The premium schedule that is being evaluated (can be used to parametrize the dynamic logic)
In	policyEnrollmentProduct	PolicyEnrollmentProduct	The policy enrollment product that is being evaluated
In	calculationPeriod	CalculationPeriod or PolicyCalculationPeriod	The system calculation period or policy calculation period that is being evaluated
In	referenceDate	Date	The date on which the condition needs to be evaluated
Out	n/a	Boolean	True when the premium schedule, adjustment or surcharge applies

Schedule Dimension Evaluation

There are four signatures for evaluation conditions:

Premium Schedule Line Evaluation

The following signature applies for the evaluation of the premium schedule lines for a premium schedule:

In / Out	Name	Type	Description
In	policyEnrollmentProduct	PolicyEnrollmentProduct	The policy enrollment product for which the premium is being evaluated
In	premiumScheduleLine	PremiumScheduleLine	The premium schedule line that is being evaluated
In	calculationPeriod	CalculationPeriod or PolicyCalculationPeriod	The system calculation period or policy calculation period that is being evaluated
In	referenceDate [1]	Date	The date on which the condition needs to be evaluated.
In/Out	dynamicFields	map [key, value]	The char, number, date or flex code type dynamic fields on the PCP can be set by creating a dynamicField map where the key is the field usage name and the value is data to be stored on the field.
Out	n/a	Boolean	True when the premium schedule line applies

This logic is executed during the evaluation of the premium schedule lines, to determine which premium schedule line applies.

Examples

Conditional evaluation of line based on some dimension 'state' on premiumScheduleLine.

return premiumScheduleLine.state == 'ALABAMA'

Alternatively, conditional evaluation of a line based on some dimension 'weight' on premiumScheduleLine with a value of type range.

 return premiumScheduleLine.weight.fromValue > 30  && premiumScheduleLine.weight.toValue < 40

Working with dynamicFields map

/ Date dynamic field
dynamicFields.put("someDateField", java.sql.Date.valueOf('2020-01-01'))
// Number dynamic field
dynamicFields.put("someNumberField", 123)
// Char dynamic field
dynamicFields.put("someCharField", "test")
// Flex code dynamic field (if schedule dimension is configured using dynamic field "tier")
dynamicFields.put("someFlexCodeField", premiumScheduleLine.tier)

Add-on Premium Schedule Line Evaluation

The following signature applies for the evaluation of the add-on premiumschedule lines for an add-on premium schedule:

In / Out	Name	Type	Description
In	policyEnrollmentProduct	PolicyEnrollmentProduct	The policy enrollment product for which the premium is being evaluated
In	addOnPremiumScheduleLine	PremiumScheduleLine	The premium schedule line that is being evaluated
In	calculationPeriod	CalculationPeriod or PolicyCalculationPeriod	The system calculation period or policy calculation period that is being evaluated
In	referenceDate**	Date	The date on which the condition needs to be evaluated
Out	n/a	Boolean	True when the premium schedule line applies

This logic is executed during the evaluation of the add-on premium schedule lines, to determine which add-on premium schedule line applies.

Adjustment Rule Evaluation

The following signature applies for the evaluation of the adjustment rules for a schedule definition of the type 'Adjustment', 'Surcharge' or 'Group Account Adjustment':

In / Out	Name	Type	Description
In	policyEnrollmentProduct	PolicyEnrollmentProduct	The policy enrollment product for which the adjustment/surcharge rule is being evaluated
In	adjustmentRule/surchargeRule	AdjustmentRule	The adjustment/surcharge rule that is being evaluated
In	calculationPeriod	CalculationPeriod or PolicyCalculationPeriod	The system calculation period or policy calculation period that is being evaluated
In	referenceDate**	Date	The date on which the condition needs to be evaluated.
Out	n/a	Boolean	True when the adjustment rule applies

This logic is executed during the evaluation of the adjustment rules, to determine which adjustment applies.

Another example: For Adjustments, a certain adjustment rule only applies if the collection frequency on the policy on the referenceDate matches with that on the frequency dimension on the adjustmentRule, the condition check could be as follows:

return adjustmentRule.frequency == policyEnrollmentProduct.policyEnrollment.policy.policyCollectionSettingList.asOf(referenceDate)[0].frequency

Fee Schedule Line Evaluation

The following signature applies for the evaluation of the fee schedule lines for a fee schedule.

In / Out	Name	Type	Description
In	policy	Policy	The policy for which a fee is being generated
In	policyEnrollment	PolicyEnrollment	The policy enrollment for which a fee is being generated (only for fees of level Enrollment)
In	feeDefinition	FeeDefinition	The fee definition that is being evaluated
In	feeScheduleLine	FeeScheduleLine	The fee schedule line line that is being evaluated
In	effectiveDate	Date	The date on which the condition needs to be evaluated (effective date of the policy mutation)
Out	n/a	Boolean	True when the fee schedule line applies

This logic is executed during the evaluation of the fee schedule lines, to determine which fee schedule line applies.

---

1. Reference Date - For policy calculation period this date is set to the date as referred by the value reference date setting on the schedule definition or premium schedule (as applicable) when such a setting is specified