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 |
In |
parameters |
Map [key, value] |
List of name/value pairs that can be used in the dynamic logic |
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.
Business Event
This type of dynamic logic can be attached to a business event rule to determine whether a policy enrollment should be created.
The following signature applies:
In / Out | Name | Type | Description |
---|---|---|---|
In |
businessEventRule |
BusinessEventRule |
The business event rule being evaluated |
In |
policy |
Policy |
The policy that is being evaluated |
In |
policyEnrollment |
PolicyEnrollment |
The policy enrollment that is being evaluated |
In |
policyEnrollmentEventChangeSet |
PolicyEnrollmentEventChangeSet |
Change details that triggered the business event |
Out |
n/a |
Boolean |
True when a policy enrollment event must be created |
Please refer to the ObjectChangeLog Methods section for more information on the use of the PolicyEnrollmentEventChangeSet bind parameter.
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.
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.
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)
Oracle Health Insurance 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.
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 |
policyaddon |
PolicyAddOn |
The policy add-on that is being evaluated, applicable only in case of add-on premium |
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 |
policyaddon |
PolicyAddOn |
The policy add-on that is being evaluated, applicable only in case of add-on premium |
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)
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[1] |
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.