Validate Product

Product validation is used to check if a single product complies to a number of fixed and user configurable checks and will create product messages if any checks fail. To make product configuration more user friendly and faster the user can decide when the checks are triggered instead of having them executed automatically when saving a product. For example; each product service definition is required to have a reference to a regime to be successfully converted into a benefit specification, but this reference is implemented as optional and therefore not checked. When the user is ready with configuring a product, the validate product function will check for the presence of a regime in all the product service definitions contained in the product and will report the results back to the user.

The validation can be triggered in two ways:

• Directly through the "Validate Product" function.

• Indirectly through the "Build Product" function, this function will start validation followed by build.

Both functions are called from the Setup Products page. The "Build Product" function can also be called from the View Products page.

The function will execute all the checks in this document for the product that is in focus in the Setup Products page or for all the products that are in focus in the View Products page.

If a check fails the corresponding message is logged as a product message and processing continues until all checks are executed or until a processing error occurs.

Remove all existing Product Messages

Prior to the execution of the checks all preexisting product messages are deleted for the product.

Complete Parameter Alias Usages

Prior to the execution of the checks all parameter alias usages created in context of the product (that is, for a product service definition contained in the product) are evaluated and, if possible, completed with the following algorithm:

• Determine the parameter alias usages that (1) reference a limit and (2) do not reference a parameter alias

• For each resulting parameter alias usage determine the list of possible parameter aliases for the referenced limit

• Determine if one of those parameter aliases has a parameter alias usage that (1) references the same product service definition and (2) references a cover withhold category

If a matching parameter alias usage is found; update the parameter alias usage of the limit so that it references the same parameter alias as the parameter alias usage of the cover withhold category.

If no matching parameter alias usage is found; do not update the parameter alias usage of the limit. This parameter alias usage will fail the parameter completeness check further on in the process, requiring changes in the configuration of the product.

Execute Validation Checks

Cleanup not used Parameter Values

This step of the process will clean up any parameter values that are not used in any of the product service definitions of the validated product.

Check for each parameter value defined in context of the product if the corresponding parameter alias has at least one parameter alias usage for a product service definition contained in the product. If no parameter alias usages exist delete the parameter value.

Check Product: Plan versus Calendar

A product will in real life never have a combination of Calendar Year based limits and Plan Year based limits in the same time period. If a product is configured that has at least one Calendar Year based limit and at least one Plan Year based limit in the same time period, message PRD-VL-PROD-001 message will be logged.

Duplicate Product Service Definitions Check

For each product service definition contained in the product, the combination of all of the following fields is checked and must be unique.

• Service Definition

• Gender

• Indicator Authorization Missing

• Network Status (Product Provider Group Usage)

• Specific Networks (Specific Provider Group Usage)

• The List of Specific Provider Groups

• Age From

• Age To

• Person Country Region Usage

• Person Country Region

• Person Country Region Group

• Provider Country Region Usage

• Provider Country Region

• Provider Country Region Group

• Employer Country Region Usage

• Employer Country Region

• Employer Country Region Group

• Condition

• Start Date

• All dynamic fields that are defined on the product service definition and that are also defined on the benefit specification. This means that dynamic fields that are only defined on the product service definitions are ignored by the duplicate check.

For each set of non unique product service definitions that is encountered a single PRD-VL-PROD-002 message is logged. A set is interpreted as two or more duplicate product service definitions.

Service Inclusion Completeness Checks

For each product service option and product service a check is done to determine if at least one underlying component is included in the product. For each product service definition a check is done if the parent service of the service definition is also included in the product.

• For each service option contained in the product, determine if there is at least one service under that service option that is included in the product through a product service. For each included service option without underlying details log a single PRD-VL-PROD-003 message.

• For each service contained in the product, determine if there is at least one service definition under that service that is included in the product through a product service definition. For each included service without underlying details log a single PRD-VL-PROD-004 message.

• For each service definition contained in the product, determine if a product service exists for the service under which the service definition is grouped. If no included service exists for the included service definition log a single PRD-VL-PROD-013.

Accumulation Option Completeness Checks

For each parameter alias usage based on a cover withhold category:

• That references a parameter alias, that has one or more parameter alias limits

• There must be a selected accumulation option on the same product service definition that references one of the parameter alias limits

• For each combination of product service definition and parameter alias that lacks an accumulation option, message PRD-VL-PROD-005 is logged.

Parameter Completeness Checks

Whenever a regime is added to a product service definition that contains a cover withhold category that has its type set to not <null> or an accumulation option is added that references a limit with multiple parameter aliases defined for it, the system will create a "placeholder" parameter alias usage for the product service definition. This parameter alias usage references the product service definition and the limit or cover withhold category for which the user needs to select the appropriate alias. By selecting the parameter alias the parameter alias usage will get a foreign key to that parameter alias.

This check will validate if all parameter alias usages for all product service definitions contained in the product have a foreign key to a parameter alias. For each parameter alias usage that does not have a foreign key to a parameter alias log a single PRD-VL-PROD-006 message.

There can be three reasons why a parameter alias usage does not have a foreign key to a parameter alias:

1. The user did not select a parameter alias during the configuration of a product service definition; the user needs to select the appropriate alias for the cover withhold category or limit.

2. The user was not able to select a parameter alias because none was configured for the limit or the cover withhold category. The user needs to define at least one parameter alias for the limit or the cover withhold category. For a cover withhold category; the user can now select a parameter alias. For a limit; the user needs to remove the accumulation option containing the limit and re-include it in the product service definition.

3. The complete parameter alias usages step was not able to create the foreign key to a parameter alias for the parameter alias usage.

A second check will validate if a parameter value is defined (in context of the product) for all parameter aliases that have a parameter alias usage for at least one product service definition contained in the product. For each parameter alias, that does not have a value defined at the parameter alias level (for amounts this means a value in the currency of the product) and that does not have a parameter value in context of the product log a single PRD-VL-PROD-007 message.

Mandatory Field Checks

To be able to convert a combined product service definition and service definition into a benefit specification the minimum required number of fields that need to be present on a benefit specification must be present. The presence of the following fields is validated for each product service definition contained in the product.

• Each product service definition must have a reference to an authorization regime, a coverage regime, a reservation regime, a waiting period regime or a post benefits regime. For each product service definition that does not have a reference to one of these regimes log a single PRD-VL-PROD-008 message.

• Each product service definition must have a network status defined indicating the scope of the product provider group(s). For each product service definition that does not have a defined scope log a single PRD-VL-PROD-009 message.

Non-existent Provider Group Code Check

When the user configures product service definition provider groups in the specific networks column of a product service definition, it is possible to enter non-existing provider group codes because this detail is not stored as a foreign key but as a code attribute. This allows the user to continue with product configuration even if a certain provider group does not exist yet. For export purposes all provider group codes defined for a product service definition must exist in the system. A non existent provider group will cause the import for a benefit specification to fail.

This check will validate if the codes that exist in the "product service def provider group" entity for each of the product service definitions in the product have a matching code in the "provider group" entity. For each product service definition provider group code that does not have a matching provider group code log a single PRD-VL-PROD-010 message.

If a nonexistent provider group code is encountered and this is not due to an incorrectly entered code (e.g. a typo), then several steps need to be taken to solve this error situation. First the user needs to determine if the provider group exists in the claims adjudication engine that is used as the source for the building blocks that are imported into OHI Product Definition. If the provider group does not exist it needs to be created. When the provider group is present in the claims adjudication engine it needs to be exported and placed in a location that can be accessed by Oracle Health Insurance Product Definition (OHI provides for this with the product building blocks data set definition in the "Outbound Data Sets" page of OHI Claims Adjudication and Pricing). The file can then be imported using the "Inbound Data Sets" page in Oracle Health Insurance Product Definition. As a result the provider group is now available in the application.

Accumulation Option and Limit Renewal Alignment Checks

A product contains selected accumulation options and product limit renewal periods. Both entities contain a reference to a limit. Some limits require a product limit renewal period to be configured if they are included in the product. This is determined by the Set Renewal? indicator on the limit. The following validations are used to prevent misalignment of these entities.

For each distinct limit that is included in the product through a selected accumulation option determine:

• If the Set Renewal? indicator on the limit is set to yes

• If a product limit renewal period exists for that limit and product combination

For each limit that has its indicator set to yes and does not have a product limit renewal period defined for the product, log a single PRD-VL-PROD-011 message.

For each distinct limit that is included in the product through a product limit renewal period determine:

• If a selected accumulation option exists for the product, for an accumulation option that references the limit

For each limit that does not have at least a single selected accumulation option defined for the product, log a single PRD-VL-PROD-012 message.

Reinsurance Configuration Checks

If the application properties for reinsurance are configured, then the application checks that the specified dynamic field usage name matches

• a dynamic field on the product, set up as a single non time valid field, based on a flex code definition

• a dynamic field on the service definition, set up as a multi value non time valid field, based on the same flex code definition

If this not true, then the application logs message PRD-VL-PROD-014.

The application checks that the list of parameter alias codes includes only character strings

• that are no longer than 30 characters

• that are uppercase

• that are not duplicate entries

If this not true, then the application logs message PRD-VL-PROD-015.

If only one of both properties is set, the application also logs PRD-VL-PROD-015.

User Defined Validation Checks

In addition to the fixed checks it is possible to define validation checks using dynamic logic. These checks are configured in the Validation Checks page that is located in the menu under Configuration/Products/Validation. All checks that are configured in this page are executed for each product. Consult the Conditions chapter of the implementation guide for more information on the used dynamic logic signatures.

Failing a check will attach the message that is configured for the check as a product validation result. It is possible to attach informative and fatal messages.

Validation Messages

In addition to business rule violation messages, the following validation messages can be raised.

Code	Severity	Message
PRD-VL-PROD-001	Fatal	The product is configured with both calendar year and plan year based limits in the same time period.
PRD-VL-PROD-002	Fatal	Duplicate definitions exist for {0}, {1}.
PRD-VL-PROD-003	Fatal	{0} is included but no underlying services are included.
PRD-VL-PROD-004	Fatal	{0}, {1} is included but no underlying definitions are included.
PRD-VL-PROD-005	Fatal	{0}, {1} contains one or more definitions that require the selection of an accumulation option for {2}.
PRD-VL-PROD-006	Fatal	{0}, {1} contains one or more definitions that require the selection of a cost share option.
PRD-VL-PROD-007	Fatal	{0} is used for cost sharing of the {1}, but no value is defined for it.
PRD-VL-PROD-008	Fatal	{0}, {1} contains one or more definitions that do not specify a regime.
PRD-VL-PROD-009	Fatal	{0}, {1} contains one or more definitions that do not specify a network status.
PRD-VL-PROD-010	Fatal	{0}, {1} contains one or more definitions that specify an unknown provider group: {2).
PRD-VL-PROD-011	Fatal	{0} is included as an accumulation option, but no renewal is defined for the limit.
PRD-VL-PROD-012	Fatal	{0} has renewal defined, but is not included as an accumulation option.
PRD-VL-PROD-013	Fatal	The product includes definitions for {0}, {1}, but that service is not included.
PRD-VL-PROD-014	Fatal	The reinsurance dynamic fields are not configured correctly
PRD-VL-PROD-015	Fatal	The reinsurance parameter alias code list is not specified correctly