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

OHI Product Definition 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.

Benefit Specification (Other)

This signature is used to determine whether the benefit specification applies to the claim line in OHI Claims Adjudication. 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	benefit Specification DynamicLogic	Benefit Specification 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. Logic of this signature is view only in OHI Product Definition.

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	Claim line primary 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 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	Null, not applicable for Product Definition
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 PAS_PRODUCTS table, the object name in the dynamic logic is "product", being of the type "Product". Consider the following condition to clarify:

return product.isTemplate() && product.indTemplate=='Y'

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	Null, not applicable for Product Definition
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.

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

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).

Product Filter

A product filter consists of predefined criteria for a query on products. Next to fixed dimensions like product line, product family and funding arrangement it is possible to have user defined conditions with the product filter dynamic logic condition.

In / Out	Name	Type	Description
In	product	Product	The product that is being evaluated
In	product Service Option	Product Service Option	The list of product service options contained in the product, null if none exist
In	product Service	Product Service	The list of product services contained in the product, null if none exist
In	product Filter	Product Filter	The product filter being evaluated. Can be used to parametrize the dynamic logic.
Out	n/a	Boolean	True when the product should be returned

This dynamic logic condition is executed in pages where multiple products are displayed. For example the View Products page can use a product filter as input for a product search. The filter will execute the condition to determine if a product needs to be returned as a search result.

Validation Check

This type of dynamic logic can be attached to a user defined validation check to determine whether a product passes the validation check. Which input parameters are passed along depends on the "level" field of the validation check. Each level uses the "Product" object as input, this object allows the logic to iterate over the product service options and product services contained in the validated product. This supports checks on missing product components.

There are four signatures for validation check conditions:

The following signature applies to validation checks with level "Product":

In / Out	Name	Type	Description
In	validation Check	Validation Check	The validation check being evaluated. Can be used to parametrize the dynamic logic.
In	product	Product	The product that is being evaluated
Out	n/a	Boolean	True when the product passes the validation

This signature triggers once per evaluated product.

The following signature applies to validation checks with level "Parameter Value":

In / Out	Name	Type	Description
In	validation Check	Validation Check	The validation check being evaluated. Can be used to parametrize the dynamic logic.
In	product	Product	The product that is being evaluated
In	parameter Value	Parameter Value	The parameter value that is being evaluated
Out	n/a	Boolean	True when the product passes the validation

This signature triggers once for each parameter value contained in the evaluated product.

The following signature applies to validation checks with level "Product Service Definition (Single)":

In / Out	Name	Type	Description
In	validation Check	Validation Check	The validation check being evaluated. Can be used to parametrize the dynamic logic.
In	product	Product	The product that is being evaluated
In	product Service Definition	Product Service Definition	The product service definition that is being evaluated
Out	n/a	Boolean	True when the product passes the validation

This signature triggers once for each product service definition contained in the evaluated product.

The following signature applies to validation checks with level "Product Service Definition (Combination)":

In / Out	Name	Type	Description
In	validationCheck	Validation Check	The validation check being evaluated. Can be used to parametrize the dynamic logic.
In	product	Product	The product that is being evaluated
In	product Service Definition1	Product Service Definition	The first product service definition that is being evaluated
In	product Service Definition2	Product Service Definition	The second product service definition that is being evaluated
Out	n/a	Boolean	True when the product passes the validation

This signature triggers once for each possible combination of product service definitions contained in the evaluated product.

Validation Check Examples

This check tells the user that he/she forgot to set a deductible accumulation option on the product service definition.

Level: Product Service Definition (Single) Message: USR-VAL-001 "The product service defintion {0} {1} {2} {3} starting on {4} has a deductible regime but no deductible accumulation options"

def check = 'DEDUCTIBLE'

for (i in productServiceDefinition.coverageRegime.coverageRegimeParameterList) {
  if (i.coverWithholdCategory.code = check){
    for (j in productServiceDefinition.selectedAccumulationOptionList){
      if (j.accumulationOption.coverWithholdCategory.code == check){
         -- both regime parameter and accumulation option found >> no message
         return true
      }
    }
    -- only regime parameter found, but no accumulation option >> throw message
    return false
  }
}
-- no regime parameter found >> no message
return true

Other examples of possible validation checks are the following:

• Verify the product service definitions where limits count towards "number of days" or "number of units". All the regimes attached to these product service definitions should start with PRD_BL%

• Verify that products that have (I)ndividual as contract type have only CONTINUEs on the family limits and vice versa

• If a Deductible, Penalty, Dollar Limit or Covered is present without a 100% value, raise an error message

• If a Penalty value is present on product service definition level and there is no penalty limit present, raise an error message

• If place of service usage (on service definition) is blank but place of service is populated, raise an error message

• If place of service (on service definition) is blank but place of service usage is populated, raise an error message