Products and Product Benefit Specifications
Benefit plans come in many variations, where part of the plan is common across plans, and part is specific to the account for which the plan is designed. In Oracle Health Insurance Claims Adjudication a benefit plan for which all options have been defined is called a product. In other words, a product is the complete package of configuration needed to adjudicate claims, including all benefit options and cost-share settings.
The OHI Claims Adjudication product data model can be characterized as fairly flat; it is a four level structure where the top level is the product and the bottom level is the coverage regime.
Product
A product uniquely identifies a set of benefits. A product has the following fields:
Product
Field |
Description |
Code |
The unique code of the product. |
Description |
The description of the product. |
Aggregation Level |
A label that drives whether or not a limit is shared across products.* |
Priority |
In the event that a person or object is subscribed to multiple products, the priority (number) determines in which order the products are evaluated. Products are evaluated starting with the smallest priority number value, e.g, a product with priority 1 is evaluated before a product with priority 2. |
Brand |
The brand to which the product belongs. |
Product Line |
The product line to which the product belongs (e.g. HMO, PPO, POS). |
Product Family |
The product family to which the product belongs. |
Funding Arrangement |
The funding arrangement of the product (e.g. self insured, fully insured, partially self insured). |
Claim Time Limit |
The length of the period allowed between the service date and the receipt date of a claim, for claims covered by this product. |
Claim Time Limit UoM |
The unit of measurement in which the period is expressed: Days, Months or Years. |
Currency |
The currency for amount fields in product limits, product benefit specification values and product benefit specification limits. |
Build Number |
Integer that is incremented by 1 for each successful build |
[1]
Constraints:
-
Claim time limit and claim time limit UoM must both be specified or both be left blank
Underwriters
An underwriter is an organization that carries the financial risk for a product. Configuring underwrites is optional; there is no hard coded logic in the application that requires underwriters to be set up for a product. The purpose of storing underwriters is to support the scenario where the application enriches claim transactions with underwriter information to be leveraged downstream.
A product can have no, one or multiple underwriters associated with it. An underwriter has the following fields:
Underwriter
Field |
Description |
Organization |
The organization that carries the risk for the specified product. |
Product |
The product for which the risk is carried. |
Percentage |
The percentage of the risk carried. |
Start Date |
The first day of the period in which the relation acts as an underwriter for the product. |
End Date |
The last day of the period in which the relation acts as an underwriter for the product. |
Constraints:
-
It is not allowed to specify multiple underwriters for the same organization that overlap in time
-
At any given point in time, a product has no underwriters OR the total of underwriter percentages for one product is 100
-
The end date of the underwriter should not lie past the end date of the organization
Underwriters have no functional impact on calculating a claim’s benefits.
Financial Holds
Financial holds prevent financial transactions that include products to which the hold applies from being included in financial messages (and therefore paid).
A product can have no, one or multiple financial holds associated with it. A financial hold has the following fields:
Financial Hold
Field |
Description |
Hold Type |
The hold type that is applied to the product. Hold types are user defined and can be picked from a list of values. |
Product |
The product to which the hold applies. |
Status |
Active, Released or Expired. |
Held By |
The user that applied the financial hold to the product. |
Hold Datetime |
The date and time the financial hold was recorded in the system. |
Released By |
The user that (manually) released the financial hold from the product. |
Release Datetime |
The date and time the financial hold was released. |
Expiration Datetime |
The date and time the financial hold expires automatically |
Hold comment |
A comment on why the financial hold was recorded on the product |
Release comment |
A comment on why the financial hold was released |
Constraints:
-
Financial hold attributes can only be updated when the status of the hold is Active
-
Only expiration datetime, hold comment and release comment are updateable (as long as the status is Active)
-
Financial holds cannot be deleted
-
The expiration datetime of the financial hold should not lie in the past
Financial holds have no functional impact on calculating a claim’s benefits or the claims finalization process.
Financial holds on product level apply to all financial transactions with at least one financial transaction detail with a Product Code of a product that is on hold. As a consequence, customers that wish to use product financial holds need to make sure that the product code on financial transaction detail is propagated through dynamic logic (from claim line transaction coverage).
Product Provider Groups
Product provider groups represent the network of providers associated with a product. A product can be associated with no, one or multiple product provider groups. A product provider group has the following fields:
Product Provider Group
Field |
Description |
Product |
The unique code of the product for which the product provider groups are defined. |
Provider Group |
The provider group that represents the list of providers that are affiliated with the specified product. |
Assignment Label |
The qualifying label for the assignment of the provider group. If specified the system will use the policy product provider group(s) with a matching assignment label when determining network status in the claims flow. |
Start Date |
The start date as of when the providers in - the provider group (on this record) - or the provider groups that match the assignment label during claims proccessing are 'in network' for the product. |
End Date |
The end date of the product provider group. |
Constraints:
-
It is not allowed to specify multiple product provider groups for the same provider group and assignment label that overlap in time
-
At least one of provider group and assignment label must be specified
Product provider groups work in conjunction with the benefit specification field "product provider group scope". To clarify, consider a scenario where a user configures two benefit specifications. Both have different benefits. The first applies only to claim lines for which the benefits provider is IN scope of at least one of the product provider groups, the second applies only when the benefits provider is OUT of scope for all of the product provider groups.
The start and end date are evaluated during claims processing, based on the claim line start date.
Product Limits
A product limit allows a user to set a value for a limit. This applies in the situation where the coverage regime(s) specify a limit (such as a deductible) without specifying the actual height. The product limit sets the height of that limit in context of the product, e.g., for product ABC the height of the deductible is set to 1500 dollars. In other words, the coverage regime acts as a template; the actual value is specified on the product limit. The merit of such a configuration setup is that the coverage regime(s) can be reused across all products. A product limit has the following fields:
Product Limit
Field |
Description |
Product |
The unique code of the product for which the product limits are defined. |
Limit |
The limit that will be used by all regimes with cover withhold rules that count towards the limit. |
Maximum Amount |
The height against which the limit should adjudicate. |
Maximum Amount Currency |
The currency of the maximum amount; it is automatically set to the currency that is specified on the product. |
Maximum Number of Units |
The height against which the limit should adjudicate. |
Maximum Service Days |
The height against which the limit should adjudicate. |
(Renewal) Reference |
The way the renewal date is defined: 1st day of calendar year © or of plan year (P) or 1st of annual year start month (A) |
Renewal Period |
The length of the renewal period. |
Renewal Period UoM |
The unit of measure for the renewal period: Days, Months or Years. |
Carry Over Period |
The length of the carry over period. |
Carry Over Period UoM |
The unit of measure for the carry over period: Days, Months or Years. |
Other Products Carry Over Period |
The length of the other products carry over period. |
Other Products Carry Over Period UoM |
The unit of measure for the other products carry over period: Days, Months or Years. |
Annual Year Start Month |
The limit with the reference Annual starts on 1st of the month. This is only applicable for the limits with reference Annual. |
Start Date |
The start date of the period for which the limit will be applied. Evaluated against the claim line service date. |
End Date |
The end date of the period for which the limit will be applied. Evaluated against the claim line service date. |
To clarify this concept, consider the following scenario. A payer offers a selection of three products; product A, B and C. These products are identical except for the fact that the height of the insurable entity deductible is different:
-
Product A has a $1000 insurable entity deductible;
-
Product B has a $1500 insurable entity deductible;
-
Product C has a $2000 insurable entity deductible.
Constraints:
-
It is not allowed to specify multiple product limits for the same limit that overlap in time
-
The product limit must specify a maximum that complies with the limit type
-
The product limit must either specify:
-
reference, renewal period and renewal period unit of measure
-
reference, renewal period, renewal period unit of measure, carry over period and carry over period unit of measure
-
reference, renewal period, renewal period unit of measure, other products carry over period and other products carry over period unit of measure
-
renewal reference, renewal period, renewal period unit of measure, carry over period, carry over period unit of measure, other products carry over period and other products carry over period unit of measure
-
none of the above* It is not allowed to specify a reference on the product limit level for limits that are not calendar year or plan year based
Product Benefit Specifications
A benefit specification can be linked to one or more products in a time valid way through product benefit specifications. A product benefit specification has the following fields:
Product Benefit Specification
Field |
Description |
Product |
The unique code of the product for which the product benefit specification is defined. |
Benefit Specification |
The unique code of the benefit specification for which the product benefit specification is defined. |
Start Date |
The start date of the period for which the regime will be applied. Evaluated against the claim line service date. |
End Date |
The end date of the period for which the regime will be applied. Evaluated against the claim line service date. |
Enabled? |
If unchecked, then this benefit specification will not be evaluated when determining the benefits for a claim being processed. |
It is not allowed to specify multiple enabled product benefit specifications for the same benefit specification that overlap in time
A product benefit specification can have parameter values. These reflect the actual dollar amounts and percentages that are used by the calculation, which allows the coverage regime (which specifies the calculation) to be reused across many different benefits.
A product benefit specification parameter is stored as a detail of a product benefit specification. There are three types of parameters; the first applies to cover withhold categories (product benefit specification values), the second to limits (product benefit specification limits) and the third to a reinsurance percentage (product benefit specification reinsurance). A product benefit specification value has the following fields:
Product Benefit Specification Value
Field |
Description |
Product Benefit Specification |
The product benefit specification to which the parameter applies. |
Cover Withhold Category |
Cover withhold rules of this category are parameterized by the specified amount or percentage. |
Alias Code |
The alias code of the parameter. |
Display Name |
The display name of the parameter. |
Amount |
The amount per unit to be used by cover withhold rules of the specified cover withhold category. |
Amount Currency |
The currency of the amount per unit; it is automatically set to the currency that is specified on the product. |
Percentage |
The percentage to be used by cover withhold rules of the specified cover withhold category. |
Start Date |
The start date of the period for which the parameter will be applied (evaluated against the claim line service date). |
End Date |
The end date of the period for which the parameter will be applied (evaluated against the claim line service date). |
Constraints:
-
A product benefit specification value can only reference a product benefit specification that refers to a coverage benefit specification
-
It is not allowed to specify multiple product benefit specification values for the same product benefit specification and cover withhold category that overlap in time
-
Either the amount or percentage must be filled, but not both
-
The time validity of a product benefit specification value must be within the time validity of the product benefit specification
A product benefit specification limit has the following fields:
Product Benefit Specification Limit
Field |
Description |
Product Benefit Specification |
The product benefit specification to which the parameter applies. |
Limit |
The limit to be used when a cover withhold rule counts towards the specified limit. |
Alias Code |
The alias code of the parameter. |
Display Name |
The display name of the parameter. |
Maximum Amount |
The height against which the limit should adjudicate. |
Maximum Amount Currency |
The currency of the maximum amount; it is automatically set to the currency that is specified on the product. |
Maximum Number of Units |
The height against which the limit should adjudicate. |
Maximum Service Days |
The height against which the limit should adjudicate. |
Cover Withhold Category |
The cover withhold rule category to which this limit counts. |
Reached Action |
Specifies what should happen when the limit is reached: stop or continue applying the rule. |
Start Date |
The start date of the period for which the limit will be applied (evaluated against the claim line service date). |
End Date |
The end date of the period for which the limit will be applied (evaluated against the claim line service date). |
Constraints:
-
A product benefit specification limit can only reference a product benefit specification that refers to a coverage benefit specification
-
It is not allowed to specify multiple product benefit specification limits for the same product benefit specification, limit and cover withhold category that overlap in time
-
It is not allowed to specify multiple product benefit specification limits for the same product benefit specification and limit that overlap in time without specifying the cover withhold category
-
All product benefit specification limits for the same cover withhold category must count either units, days or amounts
-
The product benefit specification limit must specify a maximum that complies with the limit type
-
Both the cover withhold category and reached action have to be set or both have to be unspecified
-
The time validity of a product benefit specification limit must be within the time validity of the product benefit specification
A product benefit specification reinsurance has the following fields:
Product Benefit Specification Reinsurance
Field |
Description |
Product Benefit Specification |
The product benefit specification to which the parameter applies. |
Alias Code |
The alias code of the reinsurance parameter. |
Display Name |
The display name of the parameter. |
Start Date |
The start date of the period for which the parameter will be applied (evaluated against the claim line service date). |
End Date |
The end date of the period for which the parameter will be applied (evaluated against the claim line service date). |
Note that this parameter does not specify a value. The applicable reinsurance percentage is derived while a claim line is processed and therefore not stored as configuration.
Constraints:
-
A product benefit specification reinsurance can only reference a product benefit specification that refers to a coverage benefit specification
-
The time validity of a product benefit specification reinsurance must be within the time validity of the product benefit specification
-
It is not allowed to specify multiple product benefit specification reinsurance records for the same product benefit specification and alias code that overlap in time
-
A product benefit specification reinsurance must specify an alias code
How Limit Parameter Values are applied
Information which limit to apply and how to apply it can be stored on different levels within the product. Consider the following table:
Level |
Prio |
Can specify Limit + Height? |
Can specify Apply + Reached Action? |
Claim Line Limit |
1 |
Yes |
No |
Policy Product Parameter |
2 |
Yes |
No |
Product Benefit Specification Limit |
3 |
Yes |
Yes |
Product Limit |
4 |
Yes |
No |
Cover Withhold Rule (Count Towards Limit) |
5 |
Yes |
Yes |
The priority indicates how the different levels interact in case more than one level specifies a height. For example, both the coverage regime and the claim line limit specify a dollar amount for an in-network deductible, the dollar amount on the claim line is applied.
Only the product benefit specification limit and the cover withhold rule can control whether or not a limit actually applies. The cover withhold rule does this via a count-towards-limit record, the product benefit specification limit does this via the cover withhold category of the cover withhold rule to which it applies. Claim line limits and product limits can specify a limit height, but rely on the coverage regime or product benefit specification to see if that limit actually applies. Policy product parameters can specify a limit height, but rely on the product benefit specification to see if that limit actually applies (if there is a product benefit specification limit with a matching alias code).
Once the limit is selected, it is checked whether the limit is subject to prorating. This is the case when a prorating dynamic logic function is defined on the limit. The dynamic logic function is then executed and the result of this function is the height of the limit that is applied. If no dynamic logic function is defined on the limit, no prorating is done.
The applied height and reached action are not necessarily specified on the same level. Consider the following example where both a claim line limit, a product benefit specification limit and a product limit apply:
Level |
Height |
Reached Action |
Claim Line Limit |
1500 |
- |
Product Benefit Specification Limit |
2000 |
Continue |
Cover Withhold Rule (Count Towards Limit) |
2500 |
Stop |
Applied |
1500 |
Continue |
Applied after prorating |
750 |
Continue |
In the event that a cover withhold rule counts towards a limit but none of the levels specify a limit and height, then the cover withhold rule behaves as though it does not count towards that limit at all.
How Cover Withhold Parameter Values are applied
During the evaluation of a coverage regime, whenever a cover withhold rule is applied, the system looks for an applicable parameter value. This value can be specified on different levels. The level on which the parameter is set also determines the override sequence (prio) in the event that multiple values are retrieved:
Level |
Prio |
Claim Line Parameter |
1 |
Policy Product Parameter |
2 |
Product Benefit Specification Value |
3 |
Cover Withhold Rule |
4 |
A claim line parameter can specify a product. If a product is specified, then it can only be used within the context of a product benefit specification that references the same product; if no product is specified, then it can be used within the context of any product benefit specification. An applicable claim line parameter thus meets two conditions; (1) it specifies the same cover withhold category as the cover withhold rule and (2) its product - if specified - must match the product of the product benefit specification.
An applicable product benefit specification parameter value specifies (1) the same cover withhold category as the cover withhold rule and (2) is attached to the product benefit specification that invoked the coverage regime. If a policy product parameter matches the alias code of the applicable product benefit specification value, it is applied instead of the product benefit specification value.
In the event that an applicable parameter value is found, the amount or percentage is applied as if it was specified on the cover withhold rule itself.
How Reinsurance Parameters are applied
Once a claim is finalized, the application determines for each claim line whether it should generate financial transaction details that represent a receivable from the reinsurance carrier, for a percentage of the claim line covered amount. This happens only if the claim line was adjudicated based on a product benefit specification that has one or more product benefit specification reinsurance records, AND the enrollment response included a reinsurance percentage for one or more alias codes on those product benefit specification reinsurance records.