Build Product
The build product function takes the configured product that consists of product service definitions, and creates the functional equivalent of that product consisting of product benefit specifications. A product benefit specification is a denormalized equivalent of a product service definition.
The user triggers this function through clicking on the "Build" button on the Setup Product page or the "Rebuild Selected Products" button on the Products page.
The build product function execute three different steps in sequence. These steps are: (1) Trigger the validate product function to verify that no fatal messages are attached to the product and that would prevent a successful build. (2) Find the matching benefit specification to build the product, or create them if they can’t be found. (3) Generate the product details by creating product benefit specifications and assigning parameters to them. If the build is successful, that is, all three steps are completed successfully, the Build Number on the product is incremented by 1.
Validate Product
The first step of building a product executes the validation function. The validation function is executed even for those products that have already been validated directly prior to building (the validation function can be invoked separately as well). The checks executed are described in the validate product description.
If the result of the validate product function is zero (0) fatal messages the generate product function continues to the generate benefit specifications step. If one or more fatal product messages are logged the process stops at this point.
Generate Benefit Specifications
The second step of the generate product function is to generate benefit specifications unless a matching benefit specification already exists. This is the only function that creates new benefit specifications within Oracle Health Insurance Product Definition. This feature can only create benefit specifications, it never updates an existing benefit specification. Updates to service definitions are propagated to any benefit specification that is based upon that service definition. This propagation mechanism is described in the setup service definitions page. Benefit specifications are removed with a purging mechanism that can be triggered benefit specifications page.
Whenever the build product function is invoked, the generate benefit specifications step processes each product service definition contained in the product and only one of two possible outcomes can occur for each product service definition:
-
If no matching benefit specification exists for a combination of elements found on the product service definition a new benefit specification is created and processing continues with the next product service definition.
-
If a matching benefit specification exists, no new benefit specification is created, deleted or updated and processing continues with the next product service definition.
The following steps are executed sequentially for each product service definition in the product
Try to find a matching Benefit Specification
For each product service definition in the list, compare the elements present on the product service definition with all preexisting benefit specifications and match the following attributes, references or details:
-
Service Definition
-
Coverage Regime
-
Waiting Period Regime
-
Authorization Regime
-
Reservation Regime
-
Post Benefits Regime
-
Indicator Authorization Missing
-
Network Status (Product Provider Group Usage)
-
Specific Networks (Specific Provider Group Usage)
-
The List of Specific Provider Groups
-
Gender
-
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 (the product service definition condition is present as a benefit specification condition)
-
Priority (the second half of the priority of the benefit specification must match the priority of the service definition that is referenced by the product service definition)
-
If dynamic fields are defined on the product service definition, for each field it is determined:
If there is an exact match with a benefit specification continue to the next product service definition. If there is no exact match with a benefit specification, create a new benefit specification and then continue to the next product service definition.
Create a new Benefit Specification
If no exact match was found a new benefit specification is created with all the elements found on both the product service definition and the service definition:
-
Code (a concatenation of the short codes of the service option, service and service definition, a regime type indicator ("C", "A", "R", "W" or "P") and a five digit sequence number)
-
Service Option Service Code (a concatenation of the short codes of the service option and service)
-
Description (a concatenation of the descriptions of the service option, service and service definition)
-
The type of the benefit specification is determined by the service definition type (authorization specification, coverage specification, reservation specification, waiting period specification or post benefit specification)
-
Service Definition (a reference to the service definition on which the benefit specification is based)
-
Procedure Group Usage
-
Procedure Group
-
Procedure Group 2 Usage
-
Procedure Group 2
-
Procedure Group 3 Usage
-
Procedure Group 3
-
Procedure Condition Usage
-
Procedure Condition
-
Diagnosis Usage
-
Diagnosis Group
-
Diagnosis Condition
-
Diagnosis Type
-
Product Provider Group Scope
-
Specific Provider Group Scope
-
Benefit Specification Provider Group (multiple)
-
Regime
-
Indicator Authorization Missing
-
Indicator Consume Authorization
-
Case Definition
-
Claim Form Type
-
Modifier Usage
-
Benefit Specification Modifier (multiple)
-
Specialty Usage
-
Benefit Specification Specialty (multiple)
-
Location Type Usage
-
Benefit Specification Location Type (multiple)
-
Benefit Specification Conditions (a single one from the product service definition and multiple from the service definition)
-
Employer Country Region Usage
-
Employer Country Region Group
-
Employer Country Region
-
Person Country Region Usage
-
Person Country Region Group
-
Person Country Region
-
Provider Country Region Usage
-
Provider Country Region Group
-
Provider Country Region
-
Gender
-
Age From
-
Age To
-
Gender
-
Priority (the benefit priority that is the combination of the service definition and product service definition priorities)
-
Active Indicator (set to Yes)
-
For each dynamic field defined for the service definition that is not null it is determined if a dynamic field with an identical name exists for the benefit specification. If a match is found the value is copied from the service definition dynamic field to the benefit specification dynamic field with the same name
-
For each dynamic field defined for the product service definition that is not null it is determined if a dynamic field with an identical name exists for the benefit specification. If a match is found the value is copied from the product service definition dynamic field to the benefit specification dynamic field with the same name
| It is possible to configure a dynamic field usage of the same name on both the product service definition and the service definition. In this case the dynamic field value copied from the product service definition overwrites the value copied from the service definition on the benefit specification. |
Generate Product Details
The generate product details step creates the intersections between the products and the benefit specifications by way of product benefit specifications and assign the correct parameter values to them for the cover withhold categories and limits that are used in context of this product and benefit specification combination. The product record under which the (product) benefit specifications are generated is the same record as the product under which the (product) services are configured. Any product provider groups are left untouched.
The following steps are executed in the described order for each invocation of the generate product details:
1 Clear Previous Details
Remove all the preexisting:
-
Product Benefit Specifications
-
Product Benefit Specification Values
-
Product Benefit Specification Limits
-
Product Benefit Specification Reinsurances
-
Product Limits
for the product that is being built. The product details are rebuilt each time from scratch.
2 Product Limits
For each product limit renewal period defined for the product, create an equivalent product limit. These entities are nearly identical. Product limits do not have maximums (max amount, units and days); these are set for each individual product benefit specification limit.
Each product limit can have the following attributes set:
-
Reference
-
Renewal Period
-
Renewal Period Unit of Measure
-
Carry Over Period
-
Carry Over Period Unit of Measure
-
Other Products Carry Over Period
-
Other Products Carry Over Period Unit of Measure
-
Start Date
-
End Date
Steps 3 through 6 are executed sequentially for each product service definition in the product.
3 Find the benefit specification
Determine the matching benefit specification for the product service definition. All benefit specifications that are required by the product were already created during the generate benefit specifications step of this function, so a matching benefit specification is always. Finding a benefit specification is done using the same method to determine if a matching benefit specification exists (see: Try to find a matching Benefit Specification).
4 Create the product benefit specification
A new product benefit specification is created, connecting the product and the found benefit specification. The start and end date are copied from the product service definition. For each dynamic field defined for the product service definition that is not null it is determined if a dynamic field with an identical name exists for the product benefit specification. If a match is found the value is copied from the product service definition dynamic field to the product benefit specification dynamic field with the same name
5 Determine the cover withhold category parameters
This step determines the correct value to apply for each product benefit specification value by determining the parameter value defined for the parameter alias used in the product service definition. The number of product benefit specification value details that need to be created is dependent on the number of parameter alias usages that exist for the product benefit specification.
For each dynamic field defined for the parameter alias and the parameter value that is not null it is determined if a dynamic field with an identical name exists for the product benefit specification value. If a match is found the value is copied from the parameter alias or parameter value dynamic field to the product benefit specification value dynamic field with the same name. If both the parameter alias and the parameter value have a dynamic field with the same name, the value that was defined for the parameter value takes precedence. Unless a parameter alias value (for example, a state mandate value) is defined for the parameter alias. In that situation the dynamic field value on the parameter alias takes precedence over the parameter value.
6 Determine the limit parameters
This step determines the correct value to apply for each product benefit specification limit by determining the parameter value defined for the parameter alias used in the product service definition. The number of product benefit specification limit details that need to be created is dependent on the number of selected accumulation options that exist for the product benefit specification.
For each dynamic field defined for the parameter alias and the parameter value that is not null it is determined if a dynamic field with an identical name exists for the product benefit specification limit. If a match is found the value is copied from the parameter alias or parameter value dynamic field to the product benefit specification limit dynamic field with the same name. If both the parameter alias and the parameter value have a dynamic field with the same name, the value that was defined for the parameter value takes precedence. Unless a parameter alias value (for example a state mandate value) is defined for the parameter alias. In that situation the dynamic field value on the parameter alias takes precedence over the parameter value.
7 Determine the reinsurance parameters
This step determines which product benefit specification reinsurances apply. This is controlled through dynamic fields and two application properties:
-
A dynamic field usage name
-
A list of parameter alias codes
For every created product benefit specification:
-
If both (property 1) and (property 2) are specified
-
and both the applicable product and the applicable service definition have a dynamic field with a usage name equal to (property 1)
-
and both fields are based on a flex code definition (this can be any flex code definition, as long as it is the same one)
-
and both fields refer to the same flex code value
-
then the generation process attaches one product benefit specification reinsurance record for each alias code in (property 2)
-
for each product benefit specification reinsurance created in this way
-
the start and end date are the same as on the product benefit specification
-
the display name is copied from the parameter alias with the same alias code, if one exists.
Note that it is not required to set up parameter alias records for the alias codes that are specified in (property 2). Setting up corresponding parameter alias records allows the user to control the display name for the reinsurance parameters that end up in the generated product.
Note that if there is no dynamic field that matches (property 1) on either the product or the service definition, then no reinsurance parameters are generated. There is no error message.
For example,
-
suppose (property 1) specifies usage name 'reinsuranceCategory'
-
suppose (property 2) specifies character string 'REIN'
-
suppose there is a flex code definition 'RCAT' that specifies two flex codes: A, B
-
suppose both the product and the service definition have been extended by a dynamic field
-
with usageName: reinsuranceCategory
-
based on the flex code definition: RCAT
-
under the product, the dynamic field is set up as single value
-
under the service definition, the dynamic field is set up as multi value
-
The following image shows the possible combinations and indicates when the system generates reinsurance parameter values:
There are three products and four service definitions. All three products include all four service definitions:
-
Under product P1 service definitions S2 and S4 are subject to reinsurance. The corresponding product benefit specifications will have a product benefit specification reinsurance with the alias code "REIN"
-
Under product P2 service definitions S3 and S4 are subject to reinsurance
-
Under product P3, no service definitions are subject to reinsurance