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:
In / 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:
In / 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:
In / 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:
In / 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":
In / 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":
In / 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.
In / 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.
In / 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:
In / 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 / Out | Name | Type | Description |
---|---|---|---|
In |
claimLine |
ClaimLine |
The claim line being processed. |
In |
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:
In / 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:
In / 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:
In / 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:
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.
Diagnosis
Configuration components like a benefit specification and a pricing rule may be limited to specific diagnoses by a diagnosis condition.
In / Out | Name | Type | Description |
---|---|---|---|
In |
diagnosis |
Diagnosis |
|
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":
In / 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":
In / 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:
In / 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:
In / 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:
In / 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:
In / 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:
In / 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:
In / 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:
In / 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:
In / 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:
In / 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:
In / 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:
In / 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.
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.
Pricing Rule (Other)
A condition dynamic logic can be attached to a pricing rule to make the pricing rule more specific. This dynamic logic condition is executed during the selection of pricing rules (run time) applicable to the pricing of a claim line.
The following signature applies:
In / Out | Name | Type | Description |
---|---|---|---|
In |
claimLine |
ClaimLine |
The claim line that is being priced |
In |
pricingRule |
PricingRule |
The pricing rule being evaluated. Can be used to parametrize the dynamic logic. |
Out |
n/a |
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.
In / 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:
In / 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):
In / 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:
In / 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:
In / 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:
In / 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.