Conditions

Like validation, 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. The return value will be interpreted by Oracle Health Insurance according to Groovy truth logic, meaning that in case a NULL value is returned - this will be interpreted as false.

Claims knows a number of configurable rules and checks. The universal dimensions of these configurable rules and checks are captured in a meta data model. For example, a benefit specification always applies in the context of a procedure group. The primary use of dynamic logic conditions is to cover those dimensions that are not covered by the meta data model. For example, consider a benefit specification that applies only to persons that live in a specific country region. Such a condition cannot be configured using only the meta data model of benefit specifications; a dynamic logic condition should be used.

Ancillary Inclusion Rule

A case definition can contain a number of ancillary inclusion rules. Each of these rules represents a set of conditions. If a claim line meets the conditions of at least one rule and a case already exists, then that line is included as an ancillary line in that case. One of the conditions on an ancillary inclusion rule takes the form of a dynamic logic condition. The following signature applies. This signature’s as-of date defaults to the claim line start date:

Table 1. Ancillary Inclusion Rule
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed
In	ancillaryInclusionRule	AncillaryInclusionRule	The inclusion rule being evaluated. Can be used to parametrize the dynamic logic.
In	benefitSpecification	BenefitSpecification	The benefit specification related to the case definition being evaluated. Can be used to parametrize the dynamic logic.
In	product	Product	The product related to the case definition being evaluated (can be a family product or an overriding product specified on the claim line). Can be used to parametrize the dynamic logic.
In	adjudicationCase	Adjudication Case	The adjudication case being evaluated
In	primaryClaimLine	ClaimLine	The primary claim line of the adjudication case
Out	n/a	Boolean	True when the line must be appended to the existing case

This logic is executed during the evaluation of the ancillary inclusion rules. This is a step during the calculation of benefits.

Benefit Specification (Other)

This signature is used to determine whether the benefit specification applies to the claim line. The following signature applies:

Table 2. Benefit Specification (Other)
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	bill	Bill	The bill being processed, null if no bill exists
In	claimLine	ClaimLine	The claim line being processed
In	benefitSpecification DynamicLogic	BenefitSpecification DynamicLogic	The benefit specification condition being evaluated. Can be used to parametrize the dynamic logic.
In	product	Product	The product under which the benefit specification is evaluated
Out	n/a	Boolean	True when the benefit specification applies

This dynamic logic condition is executed during the selection of benefit specifications (run time). This signatures' default date is the claim line start date.

Case Definition

A case definition specifies the condition(s) that a claim line must meet in order to start a new case. If a line meets these conditions then a new case is opened and that line becomes its primary line. The following signature applies:

Table 3. Case Definition
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim being processed
In	caseDefinition	CaseDefinition	The case definition being evaluated. Can be used to parametrize the dynamic logic.
In	benefitSpecification	BenefitSpecification	The benefit specification related to the case definition being evaluated. Can be used to parametrize the dynamic logic.
In	product	Product	The product related to the case definition being evaluated (can be a family product or an overriding product specified on the claim line). Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the line must open a new case

This signature’s as-of date defaults to the claim line start date. This dynamic logic condition is executed during the evaluation of case definitions for the detection of a primary line. This is a step during the calculation of benefits.

Claim Callout Rule

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

Table 4. Claim Callout Rule
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	claimCalloutRule	ClaimCalloutRule	The rule being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the callout rule must be executed.

This signature’s as-of date defaults to the claim start date.

Claim Event Rule

This type of dynamic logic can be attached to a claim event rule to determine whether a claim event message should be sent. Which input parameters are passed along depends on the "level" field of the claim event rule. There are two signatures for claim event rule conditions:

The following signature applies to claim event rules with level "Claim":

Table 5. Claim Event Rule
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	claimEventRule	ClaimEventRule	The rule being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the event must be sent out.

This signature’s as-of date defaults to the claim start date. The following signature applies to claim event rules with level "Claim line" and "Claim with Lines":

Table 6. Claim Event Rules for "Claim line" and "Claim with Lines"
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	claimLine	ClaimLine	The claim line being processed
In	claimEventRule	ClaimEventRule	The rule being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the event must be sent out.

This signature’s as-of date defaults to the claim line start date. This dynamic logic is executed during the evaluation of claim event rules. Claim event rules are evaluated during claim status transitions.

Claim Transaction Event Rule (Claim)

This type of dynamic logic can be attached to a claim transaction event rule to determine whether a claim transaction event message should be sent.

Table 7. Claim Transaction Event Rule (Claim)
In or Out	Name	Type	Description
In	ctrClaim	ctrClaim	The ctr claim being evaluated.
In	claimTransactionEventRule	ClaimTransactionEventRule	The rule being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the event must be sent out.

Claim Transaction Event Rule (Claim Line)

This type of dynamic logic can be attached to a claim transaction event rule to determine whether a claim transaction event message should be sent.

Table 8. Claim Transaction Event Rule (Claim Line)
In or Out	Name	Type	Description
In	ctrClaimLine	ctrClaimLine	The ctr claim line being evaluated.
In	claimTransactionEventRule	ClaimTransactionEventRule	The rule being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the event must be sent out.

Classification Scheme

This type of dynamic logic is used in classification schemes.

The following signature applies to the classification scheme field "Claim Condition". Dynamic logic with this signature is used to determine whether the classification scheme applies to the claim. This signature’s as-of date defaults to the claim start date:

Table 9. Classification Scheme
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	classificationScheme	ClassificationScheme	The classification scheme being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the classification scheme applies to the claim

The following signature applies to the classification scheme field "Scheme Detail Condition". Dynamic logic with this signature is intended to define a mapping between claim line dynamic fields and classification scheme detail dynamic fields. I.e. to determine whether the scheme detail applies to the claim line. This signature’s as-of date defaults to the claim line price input date:

In or Out

Name

Type

Description

claimLine

ClaimLine

The claim line being processed.

classificationSchemeDetail

ClassificationSchemeDetail

The classification scheme detail being evaluated.

Out

n/a

Boolean

True when the classification scheme detail applies to the claim line

Classification Scheme Detail

This type of dynamic logic is used in classification scheme details.

The following signature applies to the classification scheme detail field "Claim Line Condition". Dynamic logic with this signature is used to determine whether the classification scheme detail applies to the claim line. This signature’s as-of date defaults to the claim line price input date:

Table 10. Classification Scheme Detail
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed.
In	classificationSchemeDetail	ClassificationSchemeDetail	The classification scheme detail being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the classification scheme detail applies to the claim line

The following signature applies to the classification scheme detail field "Authorization Condition". Dynamic logic with this signature is intended to determine whether the classification scheme detail applies to the claim line, based on the presence of an authorization. This signature’s as-of date defaults to the claim line price input date:

Table 11. Classification Scheme Detail Field "Authorization Condition"
In or Out	Name	Type	Description
In	authorization	Authorization	The authorization being evaluated..
In	claimLine	ClaimLine	The claim line being processed.
In	classificationSchemeDetail	ClassificationSchemeDetail	The classification scheme detail being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the classification scheme detail applies to the claim line

Combination Check (Condition)

A condition dynamic logic can be attached to a combination check to determine whether the combination check applies to the claim line. The following signature applies:

Table 12. Combination Check (Condition)
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed
In	combinationCheck	CombinationCheck	The check being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the combination check applies

Using the condition dynamic logic for combination checks, one can differentiate between messages one wants to give for similar duplicate checks, but in slightly different circumstances, e.g. to use different messages for an exact duplicate for a serviced person or object claim or for a provider claim.

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:

Table 13. Country
In or 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.

Diagnosis

Configuration components like a benefit specification and a pricing rule may be limited to specific diagnoses by a diagnosis condition.

Table 14. Diagnosis
In or Out	Name	Type	Description
In	diagnosis	Diagnosis	Claim line primary ^[1]] diagnosis 1. If a diagnosis type is specified on a benefit specification, the input for this condition is the claim line diagnosis of that specific type with the lowest sequence
Out	n/a	Boolean	True when the configuration component should be applied.

This dynamic logic condition is often executed during claims processing and has then as default date the claim line start date or pricing input date (based on the context of the rule).

Dynamic Check

A dynamic check condition is the primary component for the configuration of a dynamic check. Dynamic checks are non-benefit related checks that are used to cross-check values on a claim or claim line for validation purposes. Which input parameters are passed along depends on the "level" field of the dynamic check. There are two signatures:

The following signature applies to dynamic checks with level "Claim":

Table 15. Dynamic Check
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	dynamicCheck	DynamicCheck	The check being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	False when the dynamic check message must be attached

This signature’s as-of date defaults to the claim start date. The following signature applies to dynamic checks with level "Claim line":

Table 16. Dynamic Checks with Level "Claim Line"
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	claimLine	ClaimLine	The claim line being processed
In	product	Product	The product that provides the context of the dynamic check. Null for product independent checks.
In	dynamicCheck	DynamicCheck	The check being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	False when the dynamic check message must be attached

This signature’s as-of date defaults to the claim line start date. This dynamic logic is executed during the evaluation of dynamic checks.

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:

Table 17. Dynamic Field Usage
In or Out	Name	Type	Description
In	Depends on the entity being extended	Depends on the entity being extended	The entity that is being extended.
In	claim	Claim	The claim. Null if not applicable
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.

The first input parameter is the entity that is being extended. 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 second input parameter is the claim. This parameter is only passed along if the extended entity is in the following list: bill, claim line, claim diagnosis, claim line diagnosis, bill diagnosis or claim sub line. The purpose of this parameter is to make dynamic field usage conditions related to claims reusable. For example, regardless of whether the dynamic field is on the claim line or claim diagnosis, the following condition works for all entities in the mentioned list:

claim.claimForm.code == 'DENTAL'

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

Table 18. Dynamic Field Usage Conditions
In or Out	Name	Type	Description
In	Depends on the entity being extended	Depends on the entity being extended	The entity that is being extended.
In	claim	Claim	The claim. Null if not applicable
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.

Eligibility 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 an eligibility check. The following signature applies:

Table 19. Eligibility Callout Rule
In or Out	Name	Type	Description
In	eligibilityCheck	EligibilityCheck	The eligibility check that is being evaluated
In	calloutRule	CalloutRule	The rule being evaluated (can be used to parametrize the dynamic logic)
Out	n/a	Boolean	True when the callout rule must be executed

This signature’s as-of date defaults to the eligibility check request date.

Eligibility Validation Rule

A validation rule is evaluated during the processing of an eligibility check. \ The following signature applies to the validation rules:

Table 20. Eligibility Validation Rule
In or Out	Name	Type	Description
in	eligibilityCheck	EligibilityCheck	The eligibility check that is being evaluated
In	validationRule	ValidationRule	The validation rule being evaluated (can be used to parametrize the dynamic logic)
Out	n/a	Boolean	True when the validation rule message should be attached and/or the validation rule function dynamic logic should be executed

This signature’s as-of date defaults to the eligibility check request date.

Episode

A condition dynamic logic can be attached to an episode definition to make the episode definition more specific; it acts as a catchall to define when an episode definition is applicable, the only other dimension being the payer. This dynamic logic condition is executed during the episode of care detection substep at the start of pricing.

The following signature applies:

Table 21. Episode
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	episodeDefinition	EpisodeDefinition	The episode definition being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the episode definition is applicable to the claim.

This signature’s as-of date defaults to the claim start date.

Episode Criteria

A condition dynamic logic can be attached to an episode criteria to make the episode criteria more specific in addition to procedure groups and/or diagnosis group. This dynamic logic condition is executed during the episode of care detection substep at the start of pricing.

The following signature applies:

Table 22. Episode Criteria
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed
In	episodeCriteria	EpisodeCriteria	The episode criteria being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the episode criteria is applicable to the claim line.

This signature’s as-of date defaults to the claim line start date.

External Intervention Rule

A dynamic logic condition attached to an external intervention rule specifies a condition for a claim, bill or claim line. The claim pends if the condition is met. Which input parameters are passed along depends on the "level" field of the external intervention rule. There are three signatures for external intervention rule conditions:

The following signature applies to rules with level "Claim". This signature’s as-of date defaults to the claim start date:

Table 23. External Intervention Rule
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	externalInterventionRule	ExternalInterventionRule	The rule being evaluated. Can be used to parametrize the dynamic logic
Out	n/a	Boolean	True when the claim must pend

The following signature applies to rules with level "Claim Line". This signature’s as-of date defaults to the claim line start date:

Table 24. Rules with Level "Claim Line"
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed
In	externalInterventionRule	ExternalInterventionRule	The rule being evaluated. Can be used to parametrize the dynamic logic
Out	n/a	Boolean	True when the claim must pend

The following signature applies to rules with level "Bill". This signature’s as-of date defaults to the bill date:

Table 25. Rules with Level "Bill"
In or Out	Name	Type	Description
In	bill	Bill	The bill being processed
In	externalInterventionRule	ExternalInterventionRule	The rule being evaluated. Can be used to parametrize the dynamic logic
Out	n/a	Boolean	True when the claim must pend

The dynamic logic condition is executed when the external intervention rules are evaluated.

Fee Schedule

A condition dynamic logic can be attached to a fee schedule to determine how the dynamic fields on the fee schedule line are compared to the dynamic fields on the claim or claim line.

The following signature applies:

Table 26. Fee Schedule
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed
In	providerPricingClause	ProviderPricingClause	The provider pricing clause being evaluated
In	feeScheduleLine	FeeScheduleLine	The fee schedule line being evaluated
Out	n/a	Boolean	True when the fee schedule line applies

This dynamic logic condition is executed during the evaluation of fee schedule lines (run time). This signature’s as-of date defaults to the claim line pricing date.

Geographic Region

A geographic region is defined by one or more dynamic logic conditions. An address is in a geographic region if one of the geographic conditions evaluates as true.

The following signature applies:

Table 27. Geographic Region
In or Out	Name	Type	Description
In	address	Address	Address to be checked.
In	geographicCondition	GeographicCondition	The geographic condition being evaluated. Can be used to parametrize the dynamic logic
Out	n/a	Boolean	True when the address belongs to the geographic region

For example, the geographic region "NEWTON" consists of all addresses that have a zipcode between 02344 and 02349:

return address.postalCode >= "02344" && address.postalCode <= "02349"

This signature does not specify a default as-of date. This dynamic logic is executed when the pre-defined address method inGeographicRegion() is called.

Pricing Rule (Other)

This rule attaches a pricing rule to a dynamic logic condition to change the pricing rule. This condition executes when the application is setting a price on a claim line during runtime.

The following signature applies:

Table 28. Pricing Rule (Other)
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line
In	pricingRule	PricingRule	The pricing rule for adding parameters to dynamic logic.
In	userDefinedParameters[6]	userDefinedParameters	Variable to add a user-defined parameter with substitution value 6 in a condition. Applicable for message rules only.
In	userDefinedParameters[7]	userDefinedParameters	Variable to add a user-defined parameter with substitution value 7 in a condition. Applicable for message rules only.
Out	not applicable	Boolean	True when the pricing rule applies to the claim line

This signature’s as-of date defaults to the claim line pricing date.

Procedure

Configuration components like a benefit specification and a pricing rule may be limited to specific procedures by a procedure condition. A procedure condition can also be specified as a parameter in a claim reprocessing request.

Table 29. Procedure
In or Out	Name	Type	Description
In	procedure	Procedure	Claim line procedure(s).
Out	n/a	Boolean	True when the configuration component should be applied.

This dynamic logic condition is often executed during claims processing and has then as default date the claim line start date or price input date (based on the context of the rule).

Process Field Derivation Rule

A dynamic logic condition attached to a process field derivation rule specifies a condition for a claim or claim line. The value of the process field is set if the condition is met. Which input parameters are passed along depends on the "level" field of the process field of the process field derivation rule. There are two signatures for process field derivation rule conditions:

The following signature applies to rules with process field level "Claim". This signature’s as-of date defaults to the claim start date:

Table 30. Process Field Derivation Rule
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	processFieldDerivationRule	ProcessFieldDerivationRule	The rule being evaluated. Can be used to parametrize the dynamic logic
Out	n/a	Boolean	True when the value of the process field must be set

The following signature applies to rules with process field level "Claim Line". This signature’s as-of date defaults to the claim line start date or price input date (based on the context of the rule):

Table 31. Signature for Level "Claim Line".
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed
In	processFieldDerivationRule	ProcessFieldDerivationRule	The rule being evaluated. Can be used to parametrize the dynamic logic
Out	n/a	Boolean	True when the value of the process field must be set

The dynamic logic condition is executed when the process field deriv ationrules are evaluated.

Product Category

A condition dynamic logic can be attached to a product category to determine whether the product category applies to a product. The following signature applies:

Table 32. Product Category
In or Out	Name	Type	Description
In	productList	List <Product>	A list with the product(s) of the concerned serviced person or object. This list is empty, if the claim line specifies an overriding funding arrangement, product line and/or product family (regardless of whether or not the enrollment callout has been executed).
In	claimLine	ClaimLine	The claim line being processed.
In	productCategoryConditionDynamicLogic	ProductCategoryConditionDynamicLogic	The product category condition being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the product category applies

This dynamic logic condition is executed during the selection of provider pricing clauses (run time). Provider pricing clauses can be particularized to a product category. This signature’s as-of date defaults to the claim line price input date.

Provider Category

A condition dynamic logic can be attached to a provider category to determine whether the provider category applies to a provider. The following signature applies:

Table 33. Provider Category
In or Out	Name	Type	Description
In	claimLine	ClaimLine	The claim line being processed.
In	providerCategoryConditionDynamicLogic	ProviderCategoryDynamicLogic	The provider category condition being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the provider category applies

This dynamic logic condition is executed during the selection of provider pricing clauses (run time). Provider pricing clauses can be particularized to a provider category. This signature’s as-of date defaults to the claim line price input date.

Provider Pricing Clause

Dynamic logic is used to determine whether the provider pricing clause applies to the claim line.

The following signature applies:

Table 34. Provider Pricing Clause
In or Out	Name	Type	Description
In	claim	Claim	The claim being processed
In	bill	Bill	The bill being processed, null if no bill exists
In	claimLine	ClaimLine	The claim line being processed
In	providerPricingClauseDynamicLogic	ProviderPricingClauseDynamicLogic	The provider pricing clause condition being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the provider pricing clause applies

This dynamic logic condition is executed during the selection of provider pricing clauses (run time). This signatures' default date is the price input date.