Evaluate Regimes
In this step four regime types are applied; the first applies a waiting period, the second searches for authorizations, the third calculates cost sharing, and the fourth adjusts the results of the cost share calculation in context of coordination of benefits.
Authorization benefits specs are not selected for reservations and for claim lines that refer to a reservation line and therefore for these lines there is no authorization regime evaluation.
When applicable the four regimes are applied consecutively per claim line, per product. If the claim line has a fatal message after the regimes (from all products) have been evaluated, the covered amount is set to 0. The currency is set to the benefits input amount currency; if the benefits input amount is not specified, the currency is set to the default currency. The covered number of units is also set to 0.
When all lines have been considered, the total covered amount at the claim level is set (and the claim moves to the next step in the flow):
-
This field is set to the sum of the claimLine.coveredAmounts (only non-replaced claim lines) as long as all the currencies of the claim line covered amounts are equal; the currency for the total covered amount is set as well
-
If the currencies are not equal the field is not set; if it was already set, it is nullified (including the currency)
Claim lines on which the Locked and/or Keep Benefits indicator is checked, are ignored during this step.
Fatal Messages During Regime Execution
When a regime execution leads to a fatal message then all claim line messages that originated from regime evaluation (origin COVERAGE) are removed. The reason is that these messages clarify calculation results that have been removed, and can therefore be removed themselves.
All preliminary (regime, authorization and limit) consumptions are removed. The related regime counters are also removed if no consumptions exist under them. The related limit counter periods are also removed if no non-reversed consumptions remain under the periods (how consumptions count towards counter periods is described in the "Adjudication Limits" page of the Benefit Rules chapter of the Configuration Guide); the related limit counters are removed if no consumptions remain at all under those counters. The same applies to authorization consumptions, counter periods and counters (how authorization consumptions count towards counter periods is described in the Oracle Health Insurance Authorizations Developer Guide).
A fatal message at claim line level (product independent) or claim level results in NO claim line rule coverages and consumptions at all.
A product specific fatal claim line message results in the removal of claim line rule coverages and consumptions for that product only. If this happens while there are still eligible product benefit specifications for other (lower priority) products, the system moves on to the execution of regimes for the next product (still based on product priority).
For example, consider a member is enrolled on two products on the service date. Product A and product B. Product A has a higher priority and is therefore considered first. Unfortunately the member has not served the full waiting period that is configured for product A and so the evaluation of the waiting period regime leads to a product specific fatal message. The system then discards all the selected product benefit specification for product A and moves on to apply the product benefit specifications for product B. Since the waiting period for product B is fully served - nor are there any other fatal messages - the claim line is adjudicated under the benefit of product B.
Waiting Period Regimes
The first regime to be evaluated is the waiting period regime. Before this happens, the claim line is checked for product specific fatal messages that apply to the same product as the waiting period specification. If found, the waiting period regime evaluation stops. This prevents that claim lines with a fatal message for the same product are evaluated.
If the claim line specifies an overriding waiting period regime, the system uses the claim line product code to check on product specific fatal messages. If the claim line product code is empty, the system checks for fatal messages for the product with the highest priority in the list of policy products resulting from the Select Policy Products step. If found, the waiting period regime evaluation stops.
This regime determines the time period that has expired between the date that the waiting period started, and the claim line start date. If this period is equal or longer than the specified waiting period, the waiting period is served. If the period is shorter, the waiting period is not served. If the waiting period is not served, the leads to message specified on the regime is attached (origin BENEFITS) to the claim line. If the attached message is fatal, the claim line is denied, else the claim line is processed further.
The system derives the date that the waiting period started as follows:
-
If the waiting period input date is specified on the claim line, then that date is used.
-
If the claim line does not specify a waiting period input date, the system checks if any person covered service exists for the member in context. If that is the case it tries to find a matching person covered service and use its waiting period start date. If the system does not find a matching person covered service it raises fatal message CLA-FL-BENS-064.
-
If the system does not find any person covered service for the member the system uses the dynamic logic function on the waiting period regime to determine the waiting period start date.
-
If none of the previous is specified, then the system raises fatal message CLA-FL-BENS-064.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-064 |
Fatal |
The waiting period regime requires the waiting period input date to be specified |
As part of the evaluation, the system creates a claim line benefit specification with a reference to the waiting period specification, the product and the waiting period regime.
Waiting Periods from Previous Products
Enrollment on previous products sometimes entitles a person on cover even if the waiting period on the current benefit specification has not been served.
| The next section only applies if the claim line does not specify a waiting period start date. If the claim line specifies a waiting period start date, the waiting period evaluation does not consider the start date of any previous product. |
In general if a member has downgraded from a better product [1] to the current product, the waiting period of the current product is evaluated against the start date of the previous 'better' product.
If a member has upgraded from a lesser product to the current product, the waiting period of the current product is evaluated against the start date of the current product. If that waiting period is not served, the system evaluates if the waiting period of the previous, lesser product has been served. If that is the case the system accepts the current product as having served its waiting period. However, during evaluation of the coverage regimes the system applies the lesser coverage specifications (limits and parameters) from the current and the previous product. The system loops backward through the list of lesser policy products until it finds a product with a served waiting period. If it does not find such a product, it attaches the leads to message specified on the waiting period regime to the claim line (origin is BENEFITS). If the attached message is fatal, the claim line is denied, else the claim line is processed further.
If the waiting period on the previous product has been waived, the system considers the waiting period to be served. It adds a claim line message to the claim line explaining the waiver reason.
Person Covered Services
To determine which waiting period start date applies in case of previous products, the system uses person covered services.
Person covered services have their source in the enrollment system, for example Policies. The enrollment system holds the member’s enrollment data, and the reference data that determine if a service in one product provides a better, equal or lesser coverage than the same service in another product [2].
Combining enrollment information with product covered services (for example Policies) leads to a list of all services a member is entitled on per product, with the wait period start date for each, and a score representing the level of service.
The person data replication from Policies to Claims supports the replication of person covered services.
Person covered services can also be loaded in the system through the Relation Integration Point.
The person covered services holds possible combinations of the products the member is or was enrolled on, and the service option service codes[3] for those products.
If the product holds product parameters for Limits as well as for Cover withhold categories[4] there are separate person covered services for both types, meaning that the wait start date for the limits can be different from the wait start date for the parameters.
The image below displays enrollment data for member John Doe and the resulting person covered services. This example only specifies person covered services of service type Limit.
Waiting Period Evaluation for Upgrades or Downgrades
In the claims flow step Select Policy Products the system selected all policy products from the enrollment response that started on or before the claim line start date.
In the step Select Benefit Specifications the system selected the product benefit specifications belonging to these policy products.
Now the system selects the product benefit specification of the type waiting period for the product that is active on the claim line start date.
The system uses person covered services to decide if previous product enrollments can be used to serve the waiting period. If no person covered services exist for the member, the system does not check on previous products to determine the waiting period start date.
To find the waiting period start date from the person covered services the system selects the person covered services where
-
the product is the product in context
-
the service option service code is the service option service code on the product benefit specification
-
the claim line start date is between the start date and the end date of the person covered service.
The person covered service can be of two different types: Limit and Parameter. The wait period start date for the both can be different if one was upgraded, and the other downgraded when moving to a new product. For example, the new product has a higher cover limit, which is an upgrade, but also a higher copay, which is a downgrade. If this is the case, the system runs the following steps for both types separately.
- Waiting Period Waived?
-
If the Waived? indicator on the person covered service is set to Yes, the waiting period is considered to be served. The system adds the message that is specified on the waiver reason to the claim line messages (Origin is BENEFITS).
| If the claim line holds a waiting period input date, the system does not look for person covered services. The claim line wait period start date therefore overrules a waived waiting period in an applicable person covered service. |
- Waiting Period Not Waived
-
The system evaluates if the waiting period regime is served by checking that the number of days between the wait start date on the person covered service and the claim line start date is larger than the waiting period.
-
If the waiting period is served, the system continues with the next step of the claims flow with the benefit specifications for the current product. A second evaluation may still be required for a second covered service type.
-
If the waiting period is not served:
The system checks if the member has an applicable previous policy product that could serve the waiting period.
To apply, the policy product must have: a)an end date equal to the start date of the current product minus 1,
b) one or more person covered services for the current service option service code, and
c) one or more cover specifications for the current service option service code.If no policy product applies, the system attaches the leads to message from the waiting period regime to the claim line. Based on the severity of the message the system denies the claim line (Severity = Fatal) or continues with the flow (Severity = Informative).
If the previous policy product is a suspension period, the system immediately loops backward to the policy product previous to this suspension period. The suspension period itself does not cover any service, and it does not contribute to the waiting period already served. It does however bridge the gap between the current and the previous enrolled period. The enrolled number of days of the previous product do contribute to the waiting period already served.
This contribution of a previous enrollment must reflect in the waiting period start date on the person covered service to be used here in the claims flow. This means that it must be set when creating the person covered services.
If the system finds an applicable policy product, it adds the leads to continue message that is specified on the current waiting period regime to the claim line.
After that:-
If the Waived? indicator on the person covered service is set to Yes, the waiting period is considered to be served. The system adds the message that is specified on the waiver reason to the claim line messages (Origin is BENEFITS).
-
If the previous product has no waiting period specification, the system considers the waiting period of the current product as served.
It adds the cover specification of the previous product to the claim line benefit specifications and returns the product benefit specification parameter values to the main flow to be used during coverage calculation [5]. [6] See Applying Parameter Values. -
If the previous product has a waiting period specification, the system adds that specification to the claim line benefit specifications and checks if the waiting period is served based on the waiting period start date of the person covered service of the previous product, and the claim line service date.
If the waiting period is not served, the system again checks if the member has other applicable previous policy products that could serve the waiting period. This loop continues until the system finds a policy product that serves the waiting period or finds no more applicable policy products.
If the waiting period is served, the system adds the cover specification of the previous product to the claim line benefit specifications and returns the product benefit specification parameter values to the main flow to be used during coverage calculation.
If none of the previous products served the waiting period the system attaches the 'leads to' message from the waiting period regime of the current product to the claim line. If that message is fatal, the claim line is denied.
-
If the claim line specifies an overriding waiting period regime, this regime also applies when evaluating the waiting period for previous products.
If the claim line specifies an overriding waiting period regime, the resulting claim line benefit specification does not have a reference to a waiting period specification.
Authorization Regimes
Next evaluate the authorization regime. Before the evaluation, the claim line is checked for product specific fatal messages that apply to the same product as the authorization specification. If found, then the authorization regime evaluation stops. This prevents that claim lines with a fatal message for the same product are evaluated.
If the claim line specifies an overriding authorization regime, the system uses the claim line product code to check on product specific fatal messages. If the claim line product code is empty, the system checks for fatal messages for the product with the highest priority in the list of policy products resulting from the Select Policy Products step. If found, the authorization regime evaluation stops.
The benefits input amount is required for the evaluation, so if it’s not specified, (product independent) system message CLA-FL-BENS-010 is attached to the line. If a currency is specified on the authorization regime, it needs to match the benefits input amount currency. If the currencies do not match, (product dependent) system message CLA-FL-BENS-055 is attached to the line.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-010 |
Fatal |
The calculation of this line requires the benefits input amount to be specified |
CLA-FL-BENS-055 |
Fatal |
The currency of authorization regime {code} does not match the benefit currency |
If the claim line does not specify an overriding authorization regime but it specifies an authorization exception type and that type matches the type of the authorization regime, then the evaluation stops. The claim line is treated as though no authorization is required. If the claim line does specify an overriding authorization regime the evaluation is not stopped.
The appropriate authorization tranches is or are determined based on prior consumption on the regime by the same person or object. If the Authorization Needed? indicator is unchecked on the determined tranches, then the evaluation stops. The claim line is treated as though no authorization is required. It is possible to set up an authorization regime with a single tranche which does not require an authorization.
| This set up can be used to create an authorization requirement exception in the product configuration, that is, instead of leaving a gap where no authorization is needed, explicitly set up the exception. |
If the Authorization Needed? indicator is checked on the relevant tranche, an authorization is required and the Authorization Matching dynamic logic function starts its search for an authorization (see the "Dynamic Logic" chapter of the Developer Guide for more information). It is possible for a claim line to be divided over multiple tranches with different Authorization Needed? indicators. If this happens, the tranches with a checked Authorization Needed? indicator starts looking for authorizations, each in context of the amount, number of units or number of service days within the tranche. For example, it is possible to set up an authorization regime with two tranches, where the first tranche has an unchecked Authorization Needed? indicator and a maximum of 100 dollars and the second tranche has a checked Authorization Needed? indicator and no maximum. If a claim line is sent in with a benefits input amount of 150 dollars and there is no prior consumption on the regime by the person or object, the claim line is divided over the two tranches (100 dollars in the first tranche and 50 dollars in the second tranche) and the second tranche starts looking for an authorization.
The Authorization Matching dynamic logic function returns a list of eligible authorizations. Per authorization the Authorization Detail Matching dynamic logic function (if configured) returns a list of eligible authorization lines and authorization basket details (see the "Dynamic Logic" chapter in the Developer Guide for more information). If the Consume Auth? indicator on the benefit specification is checked, then the eligible authorizations (including their eligible authorization lines and authorization basket details) are consumed (if there is room left) starting with the oldest authorization. Authorizations that are matched using the overriding authorization regime are always consumed (the Consume Auth? indicator is overruled). An authorization is often specified in the provider’s currency which can differ from the benefit currency, so a conversion may be needed from the benefit currency into the authorization currency. The function dynamic logic with signature Currency Conversion (Authorization) is automatically applied when evaluating the first authorization in the list that is approved and that has an authorized amount specified on the authorization, authorization line and/or authorization basket detail level. The exchange rate that is returned by this logic is used to convert the amount for which an authorization is needed into the currency of the authorization. The authorization is consumed (if there is room left) in its own currency. The authorized amount is then converted back to the benefit currency using the reciprocal of the exchange rate.
If the authorized amounts applicable to the authorization have different currencies (on authorization, authorization line and basket levels), for example if the authorized amount on the authorization has a different currency than the currency of a basket that is attached to the authorization, fatal product dependent message CLA-FL-BENS-063 is attached to the claim line.
If the benefit and authorization currencies differ and there is no function dynamic logic with signature Currency Conversion (Authorization), fatal product dependent message CLA-FL-BENS-056 is attached to the claim line. If the function dynamic logic exists, but it does not find an exchange rate, technical error GEN-CURR-002 is thrown (see the "Dynamic Logic" chapter in the Developer Guide for more information).
It is possible that a claim line uses more than one authorization. The same exchange rate is used for all authorizations where it is applicable. If an approved authorization is evaluated that has a different currency than the currency of the previous authorization, fatal product dependent message CLA-FL-BENS-057 is attached to the claim line. This applies across products.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-056 |
Fatal |
There is no dynamic logic configured to convert the benefit currency into the authorization currency |
CLA-FL-BENS-057 |
Fatal |
The insurable entity’s authorizations have different currencies |
CLA-FL-BENS-063 |
Fatal |
All amounts on an authorization must be in the same currency |
If the Consume Auth? indicator is unchecked and the authorization is not matched using the overriding authorization regime then any limits specified on the authorization, its lines and its baskets are ignored:
-
The system does not create consumption within the context of the authorization.
-
The function dynamic logic with signature 'Currency Conversion (Authorization)' is not applied;
-
The situation where the maximum on an authorization has already been exceeded, is ignored.
In order to successfully authorize the claim line, the matched authorizations still needs to have the status Approved, even if the authorization regime is configured to ignore limits.
Authorizations can be restricted to a number of units. In this situation, the allowed number of units are counted towards the authorization. If the allowed number of units is not specified, it defaults to the charged number of units. Authorizations can also be restricted to a number of service days. In this situation a service day is counted towards the authorization.
Once the authorization period regime evaluation is complete, a claim line benefit specification is created with a reference to the authorization specification, the product and the authorization regime. This happens unless the evaluation led to a fatal system message. If the claim line specifies an overriding authorization regime, the resulting claim line benefit specification does not have a reference to an authorization specification.
Messages and Labels
The authorization regime specifies several messages. The applicable messages are attached to the claim line (with origin COVERAGE). The amounts in the messages are in the authorization currency. The different messages are explained in the "Authorization Regimes" page of the Benefit Rules chapter of the Configuration Guide.
If no messages have been configured for the No Benefit scenarios, the application defaults to a system message:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-033 |
Fatal |
The claimed service requires pre-authorization while none was found |
After attaching the messages, the system checks if it needs to apply claim line coverages. These coverage labels explain why a part of the benefits input amount is not covered, that is, when the authorization allows a smaller amount than the claim line benefits input amount.These claim line coverages are in the benefit currency. The different coverage labels are explained in the "Authorization Regimes" page of the Benefit Rules chapter of the Configuration Guide.
The authorization matching function is always executed, even when no authorizations have been found.
Coverage Regimes
Next up is the coverage regime. The benefits input amount is required for the evaluation of coverage regimes. Because there might not have been an authorization regime it is checked again. If no benefits input amount is specified, then the following product independent message is attached to the line.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-010 |
Fatal |
The calculation of this line requires the benefits input amount to be specified. |
Before the evaluation, the claim line is checked for product specific fatal messages that apply to the same product as the coverage specification. If found, then the coverage regime evaluation stops. This ensures that claim lines that have attained a fatal message for the same product, for example during the gathering of enrollment data (if the product does not belong to the brand or payer specified by the claim) or during the evaluation and application of authorizations or waiting periods, are not evaluated for coverage.
If the claim line specifies an overriding coverage regime, the system uses the claim line product code to check on product specific fatal messages. If the claim line product code is empty, the system checks for fatal messages for the product with the highest priority in the list of policy products resulting from the Select Policy Products step. If found, the coverage regime evaluation stops.
Coverage benefit specifications that apply when the authorization is missing only make sense in combination with an authorization specification and a second coverage specification that applies when an authorization is found. If the Authorization Missing specification is the only one that turned up in the benefit selection, the following message is attached to the line:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-034 |
Fatal |
Coverage for the claimed service assumes pre-authorization while the service does not require pre-authorization. |
This situation suggests a configuration error; it does not make sense to set up a coverage benefit specification that covers the situation where no authorization is found, while there is no authorization benefit specification in the first place.
If an authorization was required, found and applied, yet there was no coverage benefit specification with an unchecked Authorization Missing? indicator, the following message is attached to the claim line:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-038 |
Fatal |
Pre-authorization requirement applies while no coverage has been specified. |
This situation also suggests a configuration error; it does not make sense to set up an authorization benefit specification, while there is no coverage benefit specification in the first place.
If there is an authorization requirement, it is possible that the benefits input amount is split over two coverage regimes. This happens when there is not enough space on the authorizations to cover the claim line in full, or if an unsatisfied authorization requirement applies to only a part of the claim line due to authorization regime tranches.
The regime on the coverage specification with an unchecked Authorization Missing? indicator, covers that part of the benefits input amount that either does not require an authorization, or has a satisfied authorization requirement.
The regime on the coverage specification with a checked Authorization Missing? indicator, covers that part of the benefits input amount that has an unsatisfied authorization requirement. If the claim line specifies an Overriding Coverage Regime (No Auth) that regime is used for that purpose.
After the evaluation of each coverage regime, it is checked if the benefits input amount is fully covered.
-
If it is not fully covered, then the coverage regime of the next coverage specification is evaluated. If there are no more coverage specifications listed, then the evaluation of coverage specifications is complete.
-
If it is fully covered, then the coverage regime evaluation is considered complete; no more coverage regimes are evaluated.
Once the coverage regime evaluation is complete, any product specific claim line message, that applies to a product that is not part of the claim line coverage, is discarded. To clarify why, consider the following scenario:
When starting the evaluation of coverage regimes, two coverage specifications remain in the list of eligible specifications: one for the BASIC product and one for the EXTRA product. The BASIC product insures the service for 500 dollars. The EXTRA product re-insures the service for an additional 200 dollars. The claim line has a message that applies to the EXTRA product. Since the claim line only specifies a benefits input amount of 300 dollars, the regime specified by the EXTRA coverage specification is never applied. Consequently, any product specific messages that apply to the product EXTRA are discarded as well.
Evaluating a Single Coverage Regime
The following step is executed per claim line. This step describes the evaluation of the combination of a product and a coverage regime. The flow is schematically depicted by the following figure:
Retrieve Product and Coverage Regime
A claim line can hold an overriding value for the coverage benefit or for the coverage regime but not both.
If the claim line does not hold an overriding coverage regime or overriding coverage specification, the next combination of product and coverage regime is retrieved from the result set of the coverage specification selection. They are used to calculate the claim line coverage.
If the claim line holds an overriding coverage specification this specification is used to retrieve the coverage regime to calculate the claim line coverage.
If the claim line specifies an overriding coverage regime or when the coverage regime is based on an overriding coverage specification, three other pieces of information need to be retrieved in order to calculate the benefits. These are the family code, the product and the subscription date; these are necessary to process family level limits and limits based on subscription date. This information is available through the enrollment response, but it might also be specified on the claim line as an override. The claim line can specify the following combinations of overriding coverage fields:
-
Coverage regime, product, subscription date and family code
-
Coverage regime, product and subscription date
-
Coverage regime and family code
-
Coverage regime
If the claim line specifies an overriding coverage regime (or when the coverage regime is based on the overriding coverage specification) but no product and subscription date, then the policy product (and corresponding subscription date) with the highest priority, as available in the enrollment response, is used to evaluate the regime. If the claim line specifies an overriding regime but no family code, then the family code returned in the enrollment response is used to evaluate the regime.
If the claim line specifies an overriding coverage regime that uses a reference point Case, a fatal message is logged. The overriding coverage regime does not have an accompanying coverage specification and therefore no case definition.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-009 |
Fatal |
No case definition found for coverage regime {code} with reference Case |
If the claim line specifies an overriding coverage regime that uses any limits with a reference Case, a fatal message is logged. The overriding coverage regime does not have an accompanying coverage specification and therefore no case definition.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-011 |
Fatal |
No case definition found for limit {code} with reference Case |
These two messages can also occur if the claim line holds an overriding coverage specification referencing a coverage regime that uses a reference point Case or using any limits with a reference Case and this overriding coverage specification does not relate to a case definition. This situation can also occur for non-overriding values for the coverage specification and the coverage regime. It is discussed in the section #Case Definition[Case Definition] of this chapter.
If a currency is specified on the retrieved or overriding coverage regime, it needs to match the benefits input amount currency. If the currencies do not match, (product dependent) system message CLA-FL-BENS-058 is attached to the line.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-058 |
Fatal |
The currency of coverage regime {code} does not match the benefit currency |
Calculate Coverage and Consumption
First the appropriate coverage regime period is selected, based on the claim line start date and the reference (date) of the regime. Next, the appropriate coverage regime tranche is selected based on prior charges within the selected period.
Once the tranche is selected, the underlying cover withhold rules are evaluated. For details on the calculation model and relevant scenarios see the description of the "Coverage Regimes" page of the Benefit Rules chapter in the Configuration Guide. If a coverage label is used that has a dynamic logic function that defines the input value for the calculation of a cover withhold rule, the output amount of this dynamic logic has to be in the same currency as the benefits input amount. If there is a mismatch in currencies, the following product dependent fatal message is attached to the claim line:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-059 |
Fatal |
Coverage label {display_name} specified on cover withhold rule {sequence} in coverage regime {code} returns an amount in a different currency than the benefit currency |
Its possible for a claim line to be spread over more than one coverage regime tranche. This happens when the allowed amount or number of units exceeds the threshold set by the tranche that is initially selected. The allowed amount or units is broken down and applied across the tranches, each applying its own cover withhold rules to the allotted part of the allowed amount or units.
Coverage can never be less than 0 nor can the withheld or covered amount per unit be greater than the benefits input amount divided by the number of units. For example, if 30 dollars withhold per unit applies, but the benefits input amount is only 20 dollars for a single unit, then only 20 dollars is withheld. The second rule (output > input) does not apply for cover withhold rules that specify a percentage instead of an amount per unit.
Applying Parameter Values
A coverage regime is subject to parameter values. This means that the values specified on the regime are replaced by overriding values that have been specified in context of the claim line, product, product benefit specification or policy product. There are two kinds of parameters. The first one concerns the amount or percentage on the cover withhold rules; the second kind concerns the limits.
Amounts and Percentages
Each cover withhold rule can specify either an amount or a percentage. In addition, there are three other levels (claim line, product benefit specification and policy product) that can specify an amount or percentage:
| Level | Priority |
|---|---|
Claim Line Parameter |
1 |
Policy Product Parameter |
2 |
Product Benefit Specification Value |
3 |
Cover Withhold Rule |
4 |
The priority specifies the override order. For example, if both the Cover Withhold Rule and the Claim Line Parameter specify a percentage for the DEDUCTIBLE, the percentage on the claim line is applied. Consider the following example:
| Example 1 - CW Category "DEDUCTIBLE" | Percentage | Amount |
|---|---|---|
Claim Line Parameter |
0% |
|
Product Benefit Specification Value |
- |
- |
Cover Withhold Rule |
100% |
- |
Product benefit specification values are time valid, so only product benefit specification values that are valid on the claim line benefits input date are evaluated.
If product benefit specification parameters apply and during waiting period evaluation the waiting period was served by a previous product, the lower of the parameter values from the two product benefit specfications must be used.
For example:
| Product | Limit Parameter | Copay parameter |
|---|---|---|
Previous product A |
100 (= less) |
100 (= better) |
Current Product B |
200 (= better) |
200 (= less) |
If the waiting period was served based on product B, use Limit 200 and Copay 200 If the waiting period was served based on previous product A: use Limit 100 and Copay 200 (worst of both worlds).
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. Policy product parameters are only evaluated if the configuration of the product benefit specification values is valid (see checks below) and a product benefit specification value with an alias code is found. If a policy product parameter with a matching alias code is found, then the amount or percentage on the policy product parameter is applied (which value is applied, depends on the type of the value specified on the product benefit specification value) instead of the amount or percentage on the product benefit specification value.
Because Claims cannot, at configuration time, validate the consistency of a parameter with the configured cover withhold rule, the benefit configuration user is responsible for consistency. The following inconsistencies can occur during execution time:
The cover withhold parameter specifies a percentage, but the 1percentage of field in the cover withhold rule is not specified and the cover withhold rule doesn’t specify a reinsurance. In this situation Claims attaches the following fatal message (product dependent) to the claim line:
| Code | Sev | Message |
|---|---|---|
CLA-FL-BENS-013 |
Fatal |
Cover withhold rule {sequence} in coverage regime {code} expects an amount while the specified {product benefit specification parameter / claim line parameter} for product {code} and benefit specification {code} is a percentage |
The cover withhold parameter specifies an amount while the percentage of field in the cover withhold rule is specified. Even though Claims does have all the information it requires (it could simply ignore the percentage of field value) this situation does indicate that the configured cover withhold rule is not consistent with the way it is parameterized. Therefore, in this situation Claims attaches the following fatal message (product dependent) to the claim line:
| Code | Sev | Message |
|---|---|---|
CLA-FL-BENS-014 |
Fatal |
Cover withhold rule {sequence} in coverage regime {code} expects a percentage while the specified {product benefit specification parameter / claim line parameter} for product {code} and benefit specification {code} is an amount |
In case no parameter is found at all, the coverage regime cannot be executed, since the result of one cover withhold rule serves as the input for the subsequent. This can also occur in case the claim line is adjudicated based on an overriding coverage regime. In this situation Claims attaches the following fatal message (product dependent) to the claim line:
| Code | Sev | Message |
|---|---|---|
CLA-FL-BENS-015 |
Fatal |
No parameter value found for cover withhold rule {sequence} in coverage regime {code} for product {code} and benefit specification {code} |
The product benefit specification value specifies a percentage, but the matching policy product parameter has no percentage, or the product benefit specification value specifies an amount, but the matching policy product parameter has no amount. In this situation Claims attaches the following fatal message (product dependent) to the claim line:
| Code | Sev | Message |
|---|---|---|
CLA-FL-BENS-053 |
Fatal |
The policy product parameter {alias_code} does not have a value for {amount or percentage} |
The cover withhold parameter specifies an amount in a different currency than the benefits input amount currency. Therefore, in this situation Claims attaches the following fatal message (product dependent) to the claim line:
| Code | Sev | Message |
|---|---|---|
CLA-FL-BENS-060 |
Fatal |
Cover withhold rule {sequence} in coverage regime {code} expects an amount in the benefit currency while the specified {product benefit specification parameter/claim line parameter/policy product parameter} for product {code} and benefit specification {code} has a different currency |
Limits
The system applies a limit cover withhold rule if one of the following is true:
-
There is a Count Towards Limit record set up under the cover withhold rule
-
There is a Product Benefit Specification Limit with a matching Cover Withhold Category, that is valid on the benefits input date
-
There is a claim line limit with a matching cover withhold category
If any of these situations apply, the systems tries to find the applicable maximum and reached action. This information can be set in different places. Consider the following table:
| Level | Priority | Maximum | Reached Action? | Renewal + CO |
|---|---|---|---|---|
Claim Line Limit |
1 |
Required |
Optional |
N/a |
Policy Product Parameter |
2 |
Required |
N/a |
N/a |
Product Benefit Specification Limit |
3 |
Optional |
Optional |
N/a |
Product Limit |
4 |
Optional |
N/a |
Optional |
Count Towards Limit |
5 |
Optional |
Required |
N/a |
Limit |
6 |
N/a |
N/a |
Required |
The priority specifies the override order. For example, if both the Count Towards Limit and the Claim Line Limit specify an amount for an in-network deductible, the amount on the claim line is applied. Product limits and product benefit specification limits are time valid, so only product limits and product benefit specification limits that are valid on the claim line benefits input date are evaluated.
Claim line limits can have an aggregation level defined on it. If this is the case, the amounts and numbers defined on the limit are counted per aggregation level. The aggregation level that is stored on the limit counter period and the limit consumption depends on the configuration of the claim line limit and the limit itself. If the limit counter period has an aggregation level and the limit has no aggregation level dynamic logic function, the aggregation level on the claim line limit is copied to the limit counter period and limit consumption. If the limit has an aggregation level dynamic logic function defined, this dynamic logic function is executed and the result of this function is stored on the limit counter period and consumption. The aggregation level on the claim line limit may be used as input for the dynamic logic function.
Policy product parameters are only evaluated if the configuration of the product benefit specification limits is valid (see checks below) and a product benefit specification limit with an alias code is found. If a policy product parameter with a matching alias code is found, then the maximum on the policy product parameter is applied (which value is applied depends on the type of the limit) instead of the maximum on the product benefit specification limit.
When there aren’t any count toward limits configured, limits configured at claim line level are evaluated and only one is selected based on product and cover withhold rule category comparison as mentioned below:
-
Product must be mentioned at claim line limit
-
Product mentioned at claim line and claim line limit must be same
-
If cover withhold rule category isn’t null then category mentioned on claim line limit must be same as category mentioned in cover withhold rule
First claim line limit which satisfies the above comparison is returned. If there isn’t any matching claim line limit, the following check repeats on the list of configured claim line limits.
-
Product must not be mentioned at claim line limit
-
Cover withhold rule category mentioned at claim line limit must be same as category mentioned in cover withhold rule
First claim line limit which satisfies above comparison is returned.
If count towards limit is configured, then claim line limit overrides only the limit maximum for this. It does not evaluate other claim line limits that are configured.
The parameter values for the applied maximum, reached action and renewal do not have to be retrieved from the same level. If a limit applies, but none of the levels specify a maximum, then no consumption is counted towards the limit. Consider the two following examples:
| Example 1 | Maximum | Reached Action | Renewal |
|---|---|---|---|
Claim Line Limit |
|
- |
- |
Product Benefit Specification Limit |
2000 |
Continue |
- |
Count Towards Limit |
2500 |
Stop |
- |
Limit |
- |
- |
Calendar Year |
| Example 2 | Maximum | Reached Action | Renewal |
|---|---|---|---|
Product Benefit Specification Limit |
- |
Continue |
- |
Product Limit |
|
- |
Contract Year |
Limit |
- |
- |
Calendar Year |
If a limit has an aggregation level dynamic logic function defined, this function is executed to determine the aggregation level that is used to write consumption on the limit. If this dynamic logic function returns no value, a fatal error message is raised.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-067 |
Fatal |
Aggregation level could not be determined for limit {code} |
Once all limit values have been retrieved for a cover withhold rule, the system checks that the limits belong to the same limit type, that is, all limits must count to amounts, or all to units or all to service days. If the types are mixed, the following message (product dependent) is attached to the claim line. Only limits that have the same action as the cover withhold rule are retrieved. So a Cover Limit is not considered for a Cover Withhold Rule and vice versa.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-041 |
Fatal |
The limit values under product benefit specification ({product_code}, {benefit_specification_code}) conflict with the limit types under cover withhold rule {sequence} in coverage regime {code} |
Once the applicable maximum for a limit is determined, the system checks if the limit is prorated, that is, this is a configuration setting on the limit record. If so, the prorating function is called to determine the adjusted maximum value for the limit.
Once all limits have been retrieved and their maximums, reached actions and renewal information have been determined, the system checks if an authorization with a checked Override Cover Limits indicator has been applied[7] on the claim line. If that is the case all cover stop limits are treated as continue limits (meaning that the Reached Action for those limits is set to Continue).
For limits that are based on plan year or insurance, the system checks that the contract period (if specified in the enrollment response) covers the claim line start date. If not, the following fatal (product dependent) message is attached to the claim line:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-066 |
Fatal |
The contract period from {subscription start date} to {subscription end date} is not valid on service date {claim line start date} |
For limits that count per provider, the benefits provider has to be specified. If this is not the case, the following message (product dependent) is attached to the claim line:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-012 |
Fatal |
There must be at least one provider specified for limit {code} that does not count across providers |
If a policy product parameter is applied that does not specify a value that complies with the limit type, the following message (product dependent) is attached to the claim line:
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-053 |
Fatal |
The policy product parameter {alias code} does not have a value for {amount, number or service days} |
If a limit parameter is applied that specifies an amount in a different currency than the benefits input amount currency, the following message (product dependent) is attached to the claim line:
| Code | Sev | Message |
|---|---|---|
CLA-FL-BENS-061 |
Fatal |
Cover withhold rule {sequence} in coverage regime {code} expects a limit with an amount in the benefit currency while the specified {product benefit specification limit/claim line limit/policy product parameter} for product {code} and benefit specification {code} has a different currency |
It is possible for a counter period to have accumulated more consumption than its maximum. This can occur either because the counter period was incremented through the counter integration point or because a user has manually overridden the results of the benefits calculation.
Composite Limits
A limit may count consumption of other specified limits. Such a limit that considers consumption of other limits is called a composite limit. The limits which are considered by the composite limit are refereed to as sub-limits.
- Circular Reference
-
When evaluating a composite limit, it is possible that the set up may specify circular reference between limits acting as sub-limit and composite.
For example, a combined network deductible limit is composite of in network and out of network deductible limits. The in network deductible limit is composite of combined network deductible limit with provider group status set to in. In such a situation, when combined network deductible limit is evaluated, it considers the in or out of network deductible limits as the sub-limits. Similar, when in network limit is evaluated it considers combined network limit as a sublimit.
- Hierarchy
-
It is also possible to have a sub-limit which is composed of other limits, a hierarchical relationship. In such a case, only one level of relationship is considered. For example, suppose limit Flexi Advanced is composed of Dental Advanced limit (sub-limit). Dental Advanced ( as composite limit) has a sub-limit Dental Regular. In such a situation, when the Flexi Advance limit is evaluated, the consumptions that are physically linked to Dental Advanced are considered and those related to Dental Regular are not.
Messages
Adding to a counter period leads to one or more of the following product dependent claim line messages (if configured):
Limit Messages
- 'not met message'
-
Not met means that there is still room on the counter period after the consumption of the claim line in question.
- 'met message'
-
Met means that there was sufficient room on the counter period for the claim line in question, but after this consumption no room is left.
- 'met and exceeded message'
-
Met and exceeded means there was some room on the counter period for the claim line in question, but not enough.
- 'exceeded message'
-
Exceeded means there was no room at all on the counter period for the claim line in question.
In case of a claim line that refers to a reservation line, these messages are attached only when there is not enough room within the reserved consumption and the claim line is allowed to consume more that what is reserved for it. This is when the indicator ceiling on the reservation regime is set to No or is not applicable.
Reservation Regime Messages
- 'not met message'
-
The message that is attached to the actual claim line when a reservation line is used and the total reserved quantity (consumption) after processing the actual claim line still leaves room.
- 'met message'
-
The message that is attached to the actual claim line when a reservation line is used and the total reserved quantity (consumption) after processing the actual claim line exactly matches the reserved quantity.
- 'met and exceeded message'
-
The message that is attached to the actual claim line when a reservation line is used but its reserved quantity (consumption) was insufficient for the consumption of the actual claim line.
- 'exceeded message'
-
The message that is attached to the actual claim line when a reservation line is found, but cannot be used at all because the reserved quantity (consumption) is already used up fully.
Executing a cover withhold rule leads to a product dependent claim line message (if one is configured), on the condition that the covered (or withheld amount) is greater than 0. Claim line messages attached through limits, cover withhold rules and the dynamic function on coverage labels use the origin COVERAGE.
Storing Applied Parameters
The system stores the parameter values that were actually applied per claim line, with a reference to the product and benefit specification these values were retrieved from. The values may be based on previous products and benefit specifications in the case the waiting period was served by a previous product.
Storing Consumption
Because the system calculated consumption can be manually overruled later, it is marked as preliminary. Preliminary consumption is not written to the counter (yet). In other words, only the claim that wrote the preliminary consumption can actually see the consumption and uses it when calculating other lines; other claims ignore this preliminary consumption.
All consumption (authorization, tranche and limit) is initially stored as preliminary. Later, during the finalize step, the consumption is either removed or made final. Consider the following example:
| Step | Covered Amount | Consumption | Final? | Reverse? | Current Amount Within Claim | Current Amount Other Claims |
|---|---|---|---|---|---|---|
Benefits |
$ 100 |
$ 100 |
N |
N |
$ 100 |
$ 0 |
Finalize |
$ 100 |
$ 100 (t1) |
Y |
N |
$ 100 |
$ 100 |
Unfinalize |
$ 100 |
$ 100 |
Y |
Y |
$ 0 |
$ 100 |
Benefits |
$ 100 |
$ 100 |
Y |
Y |
$ 90 |
$ 100 |
$ 90 |
$ 90 |
N |
N |
|||
Finalize |
$ 90 (t2) |
Y |
N |
$ 90 |
$ 90 |
Because separate claims ignore each others results during the benefit calculation, there is always the risk that a counter exceeds the configured limit. This happens when the consumption of the individual claims remains under the limit, but the sum of both exceeds it.
To prevent two or more claims writing to the same counter without seeing each others consumption, the following mechanism applies. During the benefits step, when reading a counter, the version number of the counter is retrieved and stored. During the finalize step, before finalizing the claim, the version number of the counter is retrieved again and compared to the stored version number; if they match, the result is finalized and the version number of the counter is increased; if they don’t, the benefits step is repeated with the current version of the counters.
On every limit consumption, the display name is set to the display name of the product benefit specification limit that was used to calculate the consumption (this also applies when a policy product parameter was used to calculate the consumption). If the applied product benefit specification limit does not have a display name or the limit consumption was not calculated using a product benefit specification limit, the display name is set to the display name of the related limit.
Storing Coverages
At the claim line level, the claim line rule coverages are aggregated to claim line coverages and the covered amount is updated. At the claim level, the total covered amount is updated.
On every claim line rule coverage that matches the action of the related cover withhold rule, the display name is set to the display name of the product benefit specification value that was used to calculate the coverage (this also applies when a policy product parameter was used to calculate the coverage). If the applied product benefit specification value does not have a display name or the claim line rule coverage was not calculated using a product benefit specification value, the display name is set to the display name of the related coverage label. On every claim line rule coverage that does not match the action of the related cover withhold rule, the display name is set to the display name of the related coverage label.
On every claim line coverage, the display name is set to the display name of the related claim line rule coverages. If the related claim line rule coverages have different display names, the display name on the claim line coverage is set to the display name of the related coverage label.
Once the coverage regime evaluation is complete, a claim line benefit specification is created with a reference to the coverage specification, the product and the coverage regime. This happens unless the evaluation led to a fatal system message. For claim lines with an overriding coverage regime and/or an overriding product, the reference to the coverage specification remains empty (as none was applied).
Rounding
While calculating, numeric values stay as precise as technically possible and appropriate, but the end result of a calculation is always rounded to a precision as defined in the system property ohi.amount.scale. Within Claims, standard rounding happens based on the following principles:
-
underlying parts always add up to match the end result,
-
in the event of an even split beyond the precision of two digits behind the decimal point, rounding is biased towards that part of the amount that is covered, that is, at the expense of the part of the amount that is withheld, and
-
the last part calculated is always rounded such that principle (1) remains true.
For customized rounding methods, a dynamic logic of signature Benefits Rounding can be configured. If configured, that logic is then used for rounding the results of a cover withhold rule (see "Dynamic Logic" chapter in the Developer Guide for more information).
Consider the following example, where the benefits input amount is 100 dollars for 3 units. The benefit applies a benefit limit of 1 unit.
| Benefits Input Amount | Allowed Number of Units | Covered Amount | Covered Number of Units |
|---|---|---|---|
$ 100.00 |
3 |
$ 33.33 |
1 |
This results in the following coverages:
| Type | Label | Amount | Number of units |
|---|---|---|---|
Cover |
Coverage |
$ 33.33 |
1 |
Withhold |
Exceeds Limit |
$ 66.67 |
2 |
Consider the following example, where the benefits input amount is 0.11 dollars for a single unit. The benefit applies a 50% coinsurance.
| Benefits Input Amount | Allowed Number of Units | Covered Amount | Covered Number of Units |
|---|---|---|---|
$ 0.11 |
1 |
$ 0.06 |
1 |
This results in the following coverages:
| Type | Label | Amount | Number of Units |
|---|---|---|---|
Cover |
Coverage |
$ 0.06 |
1 |
Withhold |
Coinsurance |
$ 0.05 |
1 |
Consider the following example, where the benefits input amount is 100 dollars for 3 units. The person has two benefit plans; a base plan and a supplementary plan. The base plan applies a benefit limit of 1 unit and the supplementary plan applies a benefit limit for 1 (additional) unit.
| Benefits Input Amount | Allowed Number of Units | Covered Amount | Covered Number of Units |
|---|---|---|---|
$ 100.00 |
3 |
$ 66.67 |
2 |
This results in the following coverages:
| Type | Label | Amount | Number of Units |
|---|---|---|---|
Cover |
Coverage Base |
$ 33.33 |
1 |
Cover |
Coverage Supplementary |
$ 33.34 |
1 |
Withhold |
Exceeds limit |
$ 33.33 |
1 |
Consider the following example, where the benefits input amount is 100 dollars for 3 units. The person has three benefit plans; base plan A, supplementary plan B and supplementary plan C. Each plan applies a benefit limit of 1 (additional) unit.
| Benefits Input Amount | Allowed Number of Units | Covered Amount | Covered Number of Units |
|---|---|---|---|
$ 100.00 |
3 |
$ 100.00 |
3 |
This results in the following coverages:
| Type | Label | Amount | Number of Units |
|---|---|---|---|
Cover |
Coverage A |
$ 33.33 |
1 |
Cover |
Coverage B |
$ 33.34 |
1 |
Cover |
Coverage C |
$ 33.33 |
1 |
The calculation for plan B attempts to cover half of what remains after plan A (66,67 dollars) and then needs to round it. Plan C makes sure that all coverages add up to 100 dollars.
Case Definition
If a coverage regime uses a Case reference point, then the accompanying coverage specification needs to relate to a case definition; otherwise a fatal message (CLA-FL-BENS-009) is attached to that claim line for the appropriate product. The other way around is possible however: the coverage specification relates to a case definition, the claim line is attached to a case, but the coverage regime doesn’t use a Case reference point in any way. The same applies to any limits used in the coverage regime: if a limit uses a Case reference point, but no case definition is specified, product specific message CLA-FL-BENS-011 is attached to the claim line.
Evaluate Claim Time Limits
For every coverage providing product, the product claim time limit is evaluated. If a claim time limit is specified for the product, the start date of the claim line is compared to the receipt date of the claim. If the difference is more than the specified claim time limit, an informative message is attached to the claim line. Using external intervention rules, the claim may be pended for manual adjudication based on this message.
If the receipt date is empty, then no claim time limit evaluation is performed.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-008 |
Info |
This claimline was received after the claim time limit of \{product.claimTimeLimit} \{product.claimTimeLimitUOM}(s) expired |
Post Benefits Regimes
A post benefits regime is evaluated once the coverage regimes calculation is completed for a particular product. If the claim line specifies an overriding post benefits regime then only that regime is evaluated. The validate selection sub-step results in at most one post benefits regime, possibly with multiple post cover withhold rules. This regime is only evaluated if the claim line specifies no overriding post benefits regime.
Before the evaluation of the (single) post benefits regime, the claim line is checked for any product specific fatal messages that apply to the same product as the post benefits specification. If such a message exists, then the post benefits regime evaluation is considered complete. This makes sure that claim lines that have attained a fatal message for the same product, for example, during the gathering of enrollment data (if the product does not belong to the brand or payer specified by the claim) or during the evaluation and application of authorization, waiting period and coverage regimes, are not evaluated for post benefits.
If the claim line specifies an overriding post benefits regime, the system uses the claim line product code to check on product specific fatal messages. If the claim line product code is empty, the system checks for fatal messages for the product with the highest priority in the list of policy products resulting from the Select Policy Products step. If found, the post benefits regime evaluation stops.
Once the post benefits regime evaluation is complete, any product specific claim line message, that applies to a product that is not part of the claim line coverage, is discarded just as what would happen during the evaluation of a coverage regime.
Post Cover Withhold Rules
A post cover withhold rule can lead to a product dependent claim line message (if one is configured), on the condition that the covered (or withheld amount) is greater than 0; such a message uses the origin COVERAGE.
A post cover withhold rule applies its calculation to either the
-
remaining withheld (the sum amount of all withheld claim line rule coverages)
-
remaining covered (the sum amount of all covered claim line rule coverages)
-
specified label (the sum amount of all claim line rule coverages referring to the specific coverage label.
If the calculation applies to a label, but coverage label is unspecified, then the post cover withhold rule adds a new claim line rule coverage to the calculation rather than replacing other claim line rule coverages.
If a post cover withhold rule returns an amount in a currency that is not the same as the currency of the benefits input amount, then product dependent fatal message CLA-FL-BENS-062 is attached to the claim line.
If the post benefits regime does not specify any post cover withhold rules, then the product dependent fatal message CLA-FL-BENS-052 is attached to the claim line.
| Code | Sev | Text |
|---|---|---|
CLA-FL-BENS-052 |
Fatal |
Post benefits regime {code} cannot be applied, because it does not specify post cover withhold rules |
CLA-FL-BENS-062 |
Fatal |
Post cover withhold rule {sequence} in post benefits regime {code} returns an amount in a different currency than the benefit currency |
Applying Reserve Limits to Post Cover Withhold Rules
When the system applies a post cover withhold rule it checks the following:
-
Are there any claim line limits attached to the claim line
-
that refer to the same cover withhold category as the post cover withhold rule
-
that refer to a reserve action limit?
If such claim line limit exists, that limit applies as follows:
-
if the rule has action Withhold, then the system creates Positive Consumption for that limit up the calculated amount. There is no limit maximum.
-
if the rule has action Cover, then the system creates negative consumption for that limit up the calculated amount. To ensure that the current count never reaches below zero, the system automatically reduces the calculated amount and claim line rule coverages to prevent this from happening.
For reserve action limits, any positive preliminary consumption is not visible within the same claim. This ensures that any reserve consumption accrued by a claim, cannot be used within that same claim.
Storing Coverages
At the claim line level, the claim line rule coverages are aggregated to claim line coverages, the display name on the claim line rule and claim line coverages is set to the display name of the related coverage label, and the covered amount is updated. At the claim level, the total covered amount is updated.
Once the post benefits regime evaluation is complete, a claim line benefit specification is created with a reference to the post benefits specification, the product and the post benefits regime. This happens unless the evaluation led to a fatal system message. If the claim line specifies an overriding post benefits regime, the resulting claim line benefit specification does not have a reference to a post benefits specification.