Adjudication Limits
Adjudication limits keep track of the quantity of coverage for a single person (or object) or a single policy with the purpose of limiting (or starting) coverage as soon as the specified maximum has been reached. The configuration of a limit includes settings for the behavior of the limit, such as whether it is a cover limit (e.g. benefit limit) or a withhold limit (for example deductible) and whether it applies per person or per family. Each limit keeps separate counters.
Limit
A limit has the following fields:
| Field | Description |
|---|---|
Code |
The unique code of the limit. |
Description |
The description of the limit. |
Display Name |
The display name of the limit. |
Service Option Service Code |
The service option service code of the limit. This optional field is used as a reference in the Product Service Consumption IP. |
Limit Level |
This controls whether the limit counts per single insurable entity (for example a person) or counts for all insurable entities on the same policy (for example a counter per family). |
Type |
Sets the unit of measurement: amounts, units or service days. |
Action |
Is this a limit on the Withhold or a limit on the Coverage? |
Reference |
Specifies the as-of date that is used to determine which period applies. The following as-of dates can be specified:
Person: The first period starts at the date of birth of the person. Object: The first period starts at the object date of the object.
So forth, periods are set out until the last period that ranges from the service date unto and including (the service date plus the limit period) minus one day. However, if at any point the end date surpasses the system date, the setting out of periods stops right there. This limit actually has no fixed period and therefore the counter period for such a limit doesn’t refer to a time period: it just acts as a placeholder for all consumption. Example: Service date is August 10th 2008 and the length of the limit period is a month. Periods are then set out, the first being July 11th 2008 up to and including August 10th 2008, the last being August 10th 2008 up to and including September 9th 2008. Example: Service date is August 10th 2009, the length of the limit period is a month and today is August 17th 2009. Periods are then set out, the first being July 11th 2009 up to and including August 10th 2009, the last being July 18th 2009 up to and including August 17th 2009.
See the Scenarios section for detailed examples of how counter periods are set out. |
Renewal Period |
The length of the renewal period. |
Renewal Period Unit of Measure |
The unit of measure for the renewal period length. |
Carry Over Period |
The length of the carry over period. The consumption during the carry over period is also counted for the next period. If the limit counts per product aggregation level, only the consumption of the same (or unspecified) product aggregation level is counted; if the limit counts across product aggregation levels all consumption is counted, regardless of the product aggregation level. E.g. when a period of 1 calendar year is defined with an carry over of 3 months this means that claim lines in the last 3 months of 2009 are also counted towards 2010. This is only applicable for limits with reference calendar year, plan year or annual. |
Carry Over Period Unit of Measure |
The unit of measure for the same product carry over period length. |
Other Products Carry Over Period |
The length of the other products carry over period. Consumption of other (or unspecified) product aggregation levels during the carry over period is also counted for the next period of the new product aggregation level; consumption of the same product aggregation level is not counted. This is only applicable for limits that count per product aggregation level with reference calendar year, plan year and annual. |
Other Products Carry Over Period Unit of Measure |
The unit of measure for the other products carry over period length. |
Across Products |
Is the limit counted across the product aggregation level? Yes: the limit is counted across all products. No: the limit is counted per product aggregation level. |
Across Providers |
Is the limit counted across providers? Yes: the limit is counted over all providers. No: the limit is counted per provider. |
Prorate |
Dynamic logic function with signature 'Prorate' |
Follow Limit |
The limit that this limit follows for plotting counter periods. This is only applicable for limits with reference first claim irregular. |
Limit Not Met Message |
The message that is attached to the claim line when the limit has not been exceeded. |
Limit Met Message |
The message that is attached to the claim line when the limit has been met. |
Limit Met and Exceeded Message |
The message that is attached to the claim line when the limit has been met and exceeded. |
Limit Exceeded Message |
The message that is attached to the claim line when the limit has already been exceeded. |
Annual Limit Start Month |
The limit with the reference Annual starts on 1st of the month. This is only applicable for the limits with reference Annual. |
Aggregation Level |
Dynamic logic function with signature 'Aggregation Level' |
A limit can count for all providers, or on a _per-provider_basis. If a limit is counted per provider, then the code of the provider is stored on the limit counter period and limit consumption. A limit that counts per provider can be used to, e.g., configure a copayment per provider per day.
The same flexibility applies to products. A limit can keep track of the count across all products, or on a per-product basis. If a limit counts per product, the limit counter period and limit consumption keep track of the product aggregation level, rather than the product code. This allows a limit to keep track of the count per group of products rather than per individual product. Products that have the same aggregation level share all limits. Products that have different aggregation levels share only those limits that count across products.
Keeping track of a limit per product, that is, per product aggregation level, can be applied to ensure that (1) a base product and a supplementary product that belong to the same product line (that is, have the same aggregation level) both count towards the same distinct out-of-pocket-cost limit, while products that belong to other product lines keep track of their own distinct out-of-pocket-cost limit and that (2) when an insured transfers from product A to product B mid-year plan year, the limit count resets (if the products have different aggregation levels) or is retained (if the products have the same aggregation level).
A third option to keep track of a limit is by configuring a dynamic logic function that determines an aggregation level (that is, limits count per enrollment product). If such a dynamic logic is defined, the limit counter period and limit consumption keep track of the aggregation level that is the outcome of this dynamic logic function. If no dynamic function is defined on the limit, no aggregation level is stamped on the limit counter period and limit consumption. This allows a limit to keep track of the count per configured aggregation level. Note that this option cannot be used in combination with product aggregation level.
The limit allows a user to configure a number of messages. One of these messages can be attached to a claim line if the conditions are met. The text fields of a message may contain placeholders for values which are only available at run time. These placeholders are represented in the text fields by an integer enclosed by curly brackets, for example, {3}. When the message is displayed in the user interface, the placeholders are replaced by actual values.
The meaning of a placeholder value depends on where in the configuration the message is set up. The following table specifies the placeholder values for messages that are attached to limits:
-
0. The amount, number or service days counted under the limit (if an amount, then postfixed by a space and the currency display code of the amount)
-
1. The amount, number or service days of the limit (if an amount, then postfixed by a space and the currency display code of the amount)
-
2. The code of the limit
-
3. The start date of the limit counter period
-
4. The end date of the limit counter period
-
5. The current count on the limit counter period, including consumption of the current claim line (if an amount, then postfixed by a space and the currency display code of the amount)
-
6. The limit minus the current count, including consumption of the current claim line (if an amount, then postfixed by a space and the currency display code of the amount)
-
Only populated for 'not met' messages.
-
-
7. The amount, number or service days on the claim line with which the limit is exceeded (if an amount, then postfixed by a space and the currency display code of the amount)
-
Only populated for 'met and exceeded' and 'exceeded' messages.
-
-
8. The description of the limit
To get a clear understanding of how placeholders are populated, consider the following examples:
The limit has a maximum amount of $1000. The set up message text of the "Limit not met" message reads: "An amount of {0} has been counted towards the limit of {1} for the period of {3} to {4}. Currently {5} of this limit has been used and {6} is remaining." The message attached to a claim line, that counts towards (but does not exceed) the limit, reads:
"An amount of 125.00 $ has been counted towards the limit of 1000.00 $ for the period of 2009-01-01 to 2009-12-31. Currently 650.00 $ of this limit has been used and 350.00 $ is remaining"
The limit has a maximum of 10 units. The set up message text of the "Limit not met" message reads: "The number of {0} units have been counted towards the {2} limit of {1} units for the period of {3} to {4}. Currently {5} units of this limit has been used and {6} are remaining." The message attached to a claim line, that counts towards (but does not exceed) the limit, reads:
"The number of 3 units have been counted towards the OFFICE VISIT limit of 10 units for the period 2009-04-15 to 2009-06-13. Currently 7 units have been used and 3 units are remaining"
Limits are building blocks for creating coverage regimes. A coverage regime can configure a limit without specifying the actual maximum. The limit maximum is then specified on a higher level, that is, in context of a certain product or benefit. Note that the actual limit can also be specified on the claim line; however, this is intended for ad hoc overrides. Because the regime simply acts as a template its usability is significantly increased.
A limit with reference Calendar Year, Plan Year or Annual may specify sub limits. When a limit specifies sub limits, the limit is referred to as a 'composite limit'.
Sub Limit
| Field | Description |
|---|---|
Composite Limit |
The limit for which this sub limit is defined |
Sub Limit |
The limit that acts as a sub limit. Only the limits with reference calendar year, plan year or annual can be specified as sub limits |
Provider Group Status |
When specified the consumption with a specific provider group status (In or Out) are considered by the composite limit |
Across Products |
Is the sub limit counted across the product aggregation level? Yes: the limit is counted across all products. No: the limit is counted per product aggregation level. For a sub limit configured to count per products all consumptions with no aggregation level or the aggregation level that matches the counter periods of the composite limit, are considered for calculating the current values on the counter periods of the composite. For a sub limit configured to count across products all consumptions (regardless of the aggregation level) are considered for calculating the current values on the counter periods of the composite. This setting is applicable only when the composite counts per product. Note that the sub limit counts across product, if the composite limit counts across product. |
Limit Counter
A limit counter acts as an umbrella for all of the consumption on a limit as well as the periods of time for a limit. A limit counter has the following fields:
| Field | Description |
|---|---|
Limit |
The limit for which this counter is used. |
Insurable Entity |
The relation (person) or object to which this counter applies. This field is only populated for insurable entity level limits. |
Family Code |
The code of the the family to which this counter applies. This field is only populated for family level limits. |
Adjudication Case Id |
The identification of the adjudication case to which this counter applies. This field is only populated for limits with reference case. |
Claim |
The claim to which this counter applies. This field is only populated for limits with reference single claim |
Version |
The version of the counter (to detect concurrent use). The version is incremented when:
|
Limit Counter Period
A limit counter period shows the periods of time that are set out for a limit counter. A limit (except with references 'First Claim', 'First Claim Irregular' and 'Single Claim') will always result in periods that can be set out just by looking at the configuration and are in that way fixed. The start date and end date for such a limit counter period are determined based on the limit period length, unit of measure and reference (date). Consider a limit, based on the calendar year. When a claim line counts towards such a limit, a period can be set out from January 1st up to and including December 31st of the year of the service date. When a claim line comes in with a service date in another calendar year, another period is created (see scenarios A to J in the Scenarios section for detailed examples). However changing the limit settings might have impact on existing counter periods (see scenario K for a detailed example). A limit with reference 'First Claim' will lead to periods that might change when more claims come in and are in that way not fixed (see scenario L for a detailed example). The same applies to limits with reference 'First Claim Irregular', with the difference that the periods are irregular (see scenario M for a detailed example). In case of a limit with reference 'Single Claim', the claim lines within a single claim needs to be counted towards a limit which applies only once per claim, hence a period without a start and end date is set out. When another claim comes in, a new counter period (including a counter) is created to accommodate the consumptions of its claim lines (see scenario T for a detailed example). A limit counter period has the following fields:
| Field | Description |
|---|---|
Limit Counter |
The limit counter for which this period is set out. |
Provider |
The link to the benefits provider to which the count applies. |
Aggregation Level |
The aggregation level code of the product or the outcome of the dynamic logic function to which the count applies. |
Start Date |
The start date of the period. |
End Date |
The end date of the period. |
Carry Over Start Date |
The onset date from which consumption of preceding counter periods also counts towards this counter period. This date is only set if a carry over period is configured and the limit has reference calendar year, plan year or annual. |
Other Products Carry Over Start Date |
The onset date from which consumption of other product aggregation levels of preceding counter periods also counts towards this counter period. This date is only set if an other products carry over period is configured and the limit has reference calendar year, plan year or annual. |
Current Amount |
The current counted amount. This equals the sum of all (finalized and non expired) consumption amounts for this counter period. |
Current Amount Currency |
The currency of the current amount. |
Maximum Amount |
The maximum amount against which was counted on the last (sorted first on service date then on transaction date-time) internal finalized consumption that counts towards this counter period. |
Maximum Amount Currency |
The currency of the maximum amount. |
Current Number |
The current counted number of units. This equals the sum of all (finalized and non expired) consumption numbers for this counter period. |
Maximum Number |
The maximum number of units against which was counted on the last (sorted first on service date then on transaction date-time) internal finalized consumption that counts towards this counter period. |
Current Service Days |
The current counted number of service days. This equals the sum of all (finalized and non expired) distinct consumption service days for this counter period. |
Maximum Service Days |
The maximum number of distinct service days against which was counted on the last (sorted first on service date then on transaction date-time) internal finalized consumption that counts towards this counter period. |
Limit Consumptions
Limit counter periods keep track of the amount, number of units or number of service days used on a limit. A limit consumption represents a single increment to that counter period. Consumption can originate from an adjudicated claim, it can be sent in by an external component through the counters integration point or it can be entered in the 'Adjudication Limit Counters' page. Consumption taken by a processed claim line is referred to as internal consumption. Consumption that has been written through the integration point or directly through the user interface is referred to as external consumption.
A limit consumption can represent a negative number of units or amount. External consumption can be negative. The internal consumptions that are created to offset the reserved consumption are also negative.
If an approved and paid claim is reprocessed and denied, the consumption that originated from the initial adjudication is reversed, that is, the reversal date-time is set.
A limit consumption under a service day counter specifies a single date. Service day counters are different this way because they accumulate only the distinct consumption. For example, if the counter should have two consumptions for the service date 02/04/2012, it still only counts as a single service day. It is impossible to send in a negative date, so in order to decrement a service day counter through the counter integration point or through the 'Adjudication Limit Counters' UI page, a limit consumption has an indicator specifically for this purpose. If the withdrawn indicator is checked, the consumption represents a decrement of the number of service days (provided that the specified date was counted in the first place).
A limit consumption belongs to a single limit counter and is never removed; consumption can be reversed or offset by a negative counter part, but never removed. In the event that a claim line counts towards more than one limit, for example, a claim line that counts towards both a insurable entity deductible and family deductible, a separate consumption is created for each limit. Both consumptions will have the same claim line as its source.
The consumption that is registered by a reservation claim line will have indicator reserved set to Y(es) and expiration date is set to the expiration date of the reservation. The claim that refers to this reservation line will register 1) consumption that it needs to register and 2) an offset negative consumption. For the offset consumption, the indicator reserved is set to Y(es) and expiration date is set to the expiration date of the reservation. If the consumption that originated from initial adjudication is reversed, then the offset consumption is also reversed.
The absolute value of the offset consumption (for amount and units) depends on the available reserved room. It is possible that the claim line takes more consumption than what is reserved for it. This is possible, for example, for a cover limit when the ceiling indicator is set to N(o) and the limit maximum has not been reached. In this case the absolute value of the offset will be less (but equal to the reserved room present) than the consumption taken by the claim line. The offset value also depends on the indicator release (on the reservation regime). If it is set to Y(es); then the offset consumption offsets the entire reserved value. In this case it is possible that the absolute value of the offset is more than the consumption taken by the claim line. For the limit in service days the offset consumption is created with the service date as on the reserved consumption and the withdrawn indicator set to Y(es). When the withdrawn indicator is checked, the consumption represents a decrement of the number of service days (provided that the specified date was counted for earlier).
Note that when the released indicator is configured to Y(es) the excess reserved consumption is only released from the counter period where the actual consumption is being registered.
For a cover limit, the maximum consumption (available room) that can be registered by a claim line that refers to a reservation line is governed by the setting of the ceiling indicator for amount and on the ceiling indicator for the number of units on the reservation regime:
Ceiling set to Y(es):
The sum of the non expired consumption reserved by the reservation line and non expired offset consumption(s) (negative consumption) taken by the claim lines (referring the same reservation line) under the counter period gives the available room. A consumption is considered as 'expired' for the claim line when the receipt date of the claim is after the expiration date on the consumption; if no receipt date is specified, the entry date of the claim is considered. It is always guaranteed to have access to the reserved consumption even if the maximum on the limit has been reached.
Ceiling set to N(o)
The available room is the sum of: 1) available room within the counter period (unconsumed amount or number of units). This is the difference between the finalized and non expired consumptions (current) of the counter period (if existing) and the maximum on the limit. 2) available room on the reservation. This is the sum of the non expired consumption reserved by the reservation line and non expired offset consumption (negative consumption) taken by the claim lines referring the same reservation line under the counter period.
The reservation regime holds no setting for the ceiling for the number of service days. For the number of service days the reservation is always considered to be the ceiling.
For a withhold limit the available room is the sum of: 1) available room within the counter period (unconsumed amount, number of units or number of service days): This is the difference of the finalized and non expired consumptions (current) under the counter period (if existing) and the maximum on the limit. 2) available room on the reservation. This is the sum of the non expired consumption reserved by the reservation line and non expired offset consumption (negative consumption) taken by the claim lines referring the same reservation line under the counter period.
When a claim line does not refer to a reservation line the available room is the available room within the counter period (unconsumed amount, number of units or number of service days): This is the difference of the finalized and non expired consumptions (current) under the counter period (if existing) and the maximum on the limit.
The claim line is always guaranteed to have access to the reserved consumptions that are not yet taken even if the maximum on the limit has reached.
A limit consumption has the following fields:
| Field | Description |
|---|---|
Limit Counter |
The limit counter towards which this consumption counts. |
Counter Version |
The version of the counter at the time of writing this consumption. |
Claim Line |
The line that generated this consumption. |
Claim |
The claim that the claim line that generated this consumption belongs to. |
Insurable Entity |
The serviced person or object. |
Provider |
The benefits provider. Always filled if the information is available when the consumption is created (so also for limits that count across providers). |
Aggregation Level |
The aggregation level code of the product or the outcome of the aggregation level dynamic logic function to which the consumption applies. Always filled if the information is available when the consumption is created (so also for limits that count across products). If the consumption is the aggregated consumption of processing multiple products for a limit that counts across products, the field is only set if all products have the same aggregation level. |
Amount |
The amount by which this consumption increments the counter. |
Amount Currency |
The currency of the amount. |
Maximum Amount |
The maximum amount (limit) against which was counted upon creation of this consumption. |
Maximum Amount Currency |
The currency of the maximum amount. |
Number of Units |
The number of units by which this consumption increments the counter. |
Maximum Number of Units |
The max number of units (limit) against which was counted upon creation of this consumption. |
Service Date |
The service date for which this consumption is registered. |
Maximum Service Days |
The max number of service days (limit) against which was counted upon creation of this consumption. |
Reversal Date-time |
The date and time on which this consumption was logically deleted (due to reprocessing) |
Transaction Date-time |
The date and time on which this consumption became finalized. |
External Id |
The unique identifier of the consumption. Used in case this consumption is created through the counter integration point or through the 'Adjudication Limit Counters' UI page, instead of internal claims processing. |
Description |
The description of the consumption. Used in case this consumption is created through the counter integration point or through the 'Adjudication Limit Counters' UI page, instead of internal claims processing. |
Display Name |
The display name of the consumption. |
Provider Group Status |
The provider group status (In or Out) of the consumption. For internal consumption the status is set based on the provider group status related values on the Claim Line Benefit Specification (where Benefit Specification Type is Cover) that resulted in the consumption:
|
Withdrawn Indicator |
If checked, this consumption decrements a service day based counter. |
Preliminary Indicator |
Is this consumption linked to a non-finalized claim line? |
Marked For Reversal Indicator |
Is this consumption marked for reversal (through unfinalize)? |
Reversed Indicator |
Is this consumption reversed? |
Exclude From Carry Over Indicator |
Is this consumption excluded from counting towards a carry over if a carry over period is configured and the consumption falls within that period? If checked, this consumption does not count towards a carry over. Note that this indicator can only be checked for external consumption; for internal consumption it is always unchecked. The indicator also applies to the other products carry over period. |
Expiration Date |
The date after which the consumption expires. The claim receipt date is used as the as-of date. If the receipt date is not specified then the entry date of the claim is used as the as-of date. |
Reserved Indicator |
Is the consumption reserved? |
Transaction Source |
The transaction source of the consumption. |
Reference |
The reference of the consumption. |
Evaluation of Counters and Counter Periods
When a new claim line is evaluated, the system first checks if the applicable counter exists based on the limit settings and the information related to the claim line:
-
Limit: level and reference
-
Claim line [4]: person or object (if the limit is of level insurable entity), family code (if the limit is of level family), adjudication case (if the limit has reference case) and claim (if the limit has reference single claim)
[4]
The applicable counter has the same person or object as the person or object in context (if the limit is of level insurable entity), it has the same family code as the family code of the person or object in context (if the limit is of level family), it has the same adjudication case as the adjudication case in context (if the limit has reference case) and it has the same claim as the claim to which the claim line in context belongs (if the limit has reference single claim).
If it does not exist, the counter is created using the information as specified above. If the applicable counter already exists, the system evaluates the existing counter periods (if any) to decide what needs to happen: create consumption, create new counter period(s) and/or remove existing counter period(s). The behavior is different for the different limit references (see sections below).
Note that the following behavior regarding the evaluation of consumption is generic:
-
Consumption with an unspecified provider counts towards counter periods of all providers
-
Consumption with a specified provider also counts towards counter periods with an unspecified provider (for limits that count across providers)
-
Consumption with an unspecified aggregation level counts towards counter periods of all aggregation levels
-
Note that if both a carry over period and an other products carry over period are specified and the consumption falls in both periods, it still only counts once towards the counter period
-
-
Consumption with a specified aggregation level also counts towards counter periods with an unspecified aggregation level (for limits that count across products)
-
Consumption only counts towards counter periods with the same currency (consumption currency matches counter period current amount currency)
-
External consumptions are not taken into account when plotting counter periods; they are only taken into account when setting the current values of counter periods that are plotted for internal consumptions
-
Consumptions with an expiration date before the receipt date of the claim (if receipt date is not specified then entry date is taken as as-of date) are considered as expired and are not taken into account for the evaluation.
Composite Limit
If the limit is a composite limit, then the consumptions of its sub limits are also selected when:
-
they are not for the same claim line as the composite limit consumption
-
If the composite limit and the sub limit(s) apply simultaneously for the same claim line, then only the composite limit consumption of that claim line are considered during evaluations. This is done to ensure there is no double counting of the consumption.
-
-
and have the same provider group status as specified in the sub limit setup
-
for a sub limit configured to count per products all consumptions with no aggregation level or the aggregation level that matches the counter periods of the composite limit, are considered for calculating the current values on the counter periods of the composite.
-
for a sub limit configured to count across products all consumptions (regardless of the aggregation level) are considered for calculating the current values on the counter periods of the composite
Evaluation
The generic consumption evaluation rules mentioned above are applicable for the sub limit consumption.
Note that when a limit acts as sub limit, it is the sub limit setup that determines if it counts per product or across product, within the context of the composite.
Insurance, Insurable Entity, Case, First Claim and Around Treatment
New Counter
After creating the new counter, the applicable counter period is created based on the limit settings and the information related to the claim line:
-
Limit: reference, renewal period and across products/providers indicators
-
Claim line: person’s date of birth or object’s object date (if the limit has reference insurable entity), adjudication case start date (if the limit has reference case), subscription date (if the limit has reference insurance), claim line start date (referred to as service date in the sections below), benefits input amount currency (if the limit is of type amount), benefits provider (if the limit counts per provider) and (product) aggregation level (if the limit counts per product aggregation level or an aggregation level dynamic logic function is defined on the limit)
The start and end dates [5] on the counter period are set based on the service date, the reference date (person’s date of birth, object’s object date, adjudication case start date, subscription date [6] or first service date [7]) and the renewal period. If the limit counts per provider, the benefits provider is set on the counter period. If the limit counts per product aggregation level, the aggregation level of the product in context is set on the counter period, if the limit has an aggregation level dynamic logic function, the result of this function is set on the counter period. The current count on the counter period is set to 0 (for amounts the currency is set to the benefits input amount currency).
After creating the counter period, a preliminary consumption (based on the limit maximum and reached action [8] on the service date) is created for the new counter. When this consumption is finalized (in the Finalize step of the claims flow), the counter period is updated: the current count and the maximum [9] are set based on the consumption. Note that it is possible that the preliminary consumption is deleted before the claim finalizes, because a fatal message is attached to the claim line (for example a fatal Limit Met and Exceeded message or a fatal Manual Adjudication message). In that scenario the counter and counter period are also deleted if the deleted preliminary consumption was the only consumption.
[5]
[6]
[7]
[8]
[9]
Existing Counter
The system checks if the applicable counter period exists, based on the limit settings and the information related to the claim line (same as in the New Counter mechanism). The applicable counter period has correct start and end dates [10] based on the service date, the reference date (person’s date of birth, object’s object date, adjudication case start date, subscription date [11] or first service date [12]) and the renewal period, it has the same provider as the benefits provider if the limit counts per provider (unspecified if the limit counts across providers), it has the same aggregation level as the aggregation level of the product in context if the limit counts per product aggregation level (unspecified if the limit counts across product aggregation levels) or it has the same aggregation level as returned by the dynamic logic function on the limit and it has the same current amount currency as the benefits input amount currency if the limit is of type amount.
[10]
[11]
[12]
Existing Counter Period
If the applicable counter period exists, the system checks if there is room left on the counter period based on the current count of the counter period (including the preliminary consumptions of other claim lines within the same claim that count towards the counter period) and the limit maximum (including reached action) on the service date [13]. If there is room left on the counter period, a preliminary consumption is created for the existing counter. When this consumption is finalized (in the Finalize step of the claims flow), the counter period is updated (same as in the New Counter mechanism).
[13]
New Counter Period
If the applicable counter period does not exist, it is created with the correct start date, end date, provider and aggregation level (same as in the New Counter mechanism). Afterwards, the system checks if there are any existing final (non-reversed and not marked for reversal) consumptions that fall within the new counter period and count towards it. The current count and maximum on the new counter period are set based on those consumptions (for amounts the currency is set to the benefits input amount currency, so only consumptions with the same currency are taken into account). If there is room left on the counter period (same check as for an existing counter period), a preliminary consumption is created for the existing counter. When this consumption is finalized (in the Finalize step of the claims flow), the counter period is updated (same as in the New Counter mechanism).
Different Currency
If the limit is of type amount and counter periods exist for the same combination of provider and aggregation level as the new counter period, but with a current amount currency that differs from the benefits input amount currency, those counter periods are deleted.
Updating Across Providers Indicator
If the limit counts across providers and counter periods exist for specific providers (this means that the across providers indicator on the limit has been updated), those counter periods are deleted.
For limits with reference insurance, insurable entity, case or first claim, the system also checks if any final (non-reversed and not marked for reversal) consumptions exist (for amounts only consumptions with the same currency as the benefits input amount currency are taken into account) outside the new counter period. If that is the case, new counter periods are created based on those consumptions and the current limit settings.
If the limit counts per provider and counter periods exist without a specified provider (this means that the across providers indicator on the limit has been updated), those counter periods are deleted. The system also checks if any final (non-reversed and not marked for reversal) consumptions exist for providers other than the claim line’s benefits provider. If that is the case, new counter periods are created for those providers based on those consumptions (note that consumptions with an unspecified provider are also taken into account) and the current limit settings. The current count and maximum on the new counter period(s) are set based on those consumptions (for amounts the currency is set to the currency of the most recent consumption based on the service date, so only consumptions matching that currency are taken into account).
For limits with reference insurance, insurable entity, case or first claim, the system also checks if any final (non-reversed and not marked for reversal) consumptions exist for the benefits provider (for amounts only consumptions with the same currency as the benefits input amount currency are taken into account) outside the new counter period (note that consumptions with an unspecified provider are also taken into account). If that is the case, new counter periods are created based on those consumptions and the current limit settings.
Updating Across Products Indicator
When the across products indicator has been updated, the same mechanism applies as specified in the Updating Across Providers Indicator section.
Updating Reference Date and/or Renewal Period
For limits with reference insurance, insurable entity, case or first claim, if counter periods exist for the same combination of provider, aggregation level and current amount currency as the new counter period, those counter periods are checked to verify if they are still valid (correct start and end dates) based on the current limit settings [14] (it is possible that the reference date and/or the renewal period have/has been updated). Note that this means that if a limit counts per provider and/or aggregation level, only the counter periods for the applicable combination of provider and aggregation level are checked; counter periods for other providers and/or aggregation levels are not taken into account, even if there are changes in the renewal period and/or the reference date.
If the checked counter periods are not valid, they are deleted and new counter periods are created based on the existing final (non-reversed and not marked for reversal) consumptions (for amounts only consumptions with the same currency as the benefits input amount currency are taken into account) and the current limit settings. See scenario L for a detailed example. Note that if a limit counts per aggregation level and only consumptions exist without an aggregation level, the counter periods are still created for the specific aggregation level, because consumption without an aggregation level counts towards specific aggregation level counter periods. The same applies if the limit counts per provider; consumption without a provider counts towards specific provider counter periods.
[14]
First Claim Irregular
New Counter
After creating the new counter, the applicable counter period is created based on the limit settings and the information related to the claim line:
-
Limit: reference, renewal period, across products/providers indicators and follow limit
-
Claim line: claim line start date (referred to as service date in the sections below), benefits input amount currency (if the limit is of type amount), benefits provider (if the limit counts per provider) and product aggregation level (if the limit counts per product aggregation level) or the outcome of the aggregation level dynamic logic function on the limit
If the limit counts per provider, the benefits provider is set on the counter period. If the limit counts per product aggregation level, the aggregation level of the product in context is set on the counter period, if the limit counts per configured aggregation level, the result of the dynamic logic function on the limit is set on the counter period. The current count on the counter period is set to 0 (for amounts the currency is set to the benefits input amount currency).
If the limit does not specify a follow limit, the start and end dates on the counter period are set based on the service date, the reference date and the renewal period (see scenario M for a detailed example). The reference date used to set out the periods is the first service date. For a new counter that does not follow another counter, the first service date is the claim line start date.
If the limit specifies a follow limit with the same reference and the same across providers/products settings, then the system checks if an applicable 'follow' counter exists for the follow limit:
-
If both the limit and the follow limit have level insurable entity, then the 'follow' counter is for the same insurable entity
-
If both the limit and the follow limit have level family, then the 'follow' counter is for the same family
-
If the limit has level insurable entity and the follow limit has level family, then the 'follow' counter is for the family of the insurable entity
-
If the limit has level family and the follow limit has level insurable entity, then the follow limit is ignored
Note that if the limit specifies a follow limit, but the limits do not adhere to the rule that they both must have the same reference and the same across providers/products settings, then the follow limit is ignored as well. When the follow limit is ignored, the start and end dates on the new counter period are set as usual (based on the service date, reference date and renewal period).
If the applicable 'follow' counter does not exist, the start and end dates on the new counter period are set as usual (as specified above).
If the applicable 'follow' counter exists, the system checks if the applicable counter period exists for the 'follow' counter. The applicable 'follow' counter period has the same provider and aggregation level (note that they can also be unspecified) as the new counter period and it includes the service date of the claim line. If the applicable 'follow' counter period exists, the start and end dates of that counter period are set on the new (following) counter period as well (see scenario N for a detailed example).
If the applicable 'follow' counter period does not exist, the start and end dates on the new counter period are set as usual (as specified above). However, if the end date of the new counter period is on or after the start date of the first succeeding counter period (with the same provider and aggregation level) of the 'follow' counter, then the end date is set to one day prior to the start date of that counter period.
After creating the counter period, a preliminary consumption (based on the limit maximum and reached action on the service date) is created for the new counter. When this consumption is finalized (in the Finalize step of the claims flow), the counter period is updated (same as for the other limit references).
Existing Counter
If the applicable counter already exists, the system evaluates the existing counter periods (if any) to decide what needs to happen: create consumption, create new counter period(s) and/or remove existing counter period(s). The behavior is different for the scenarios where a follow limit applies.
Without Follow Limit
The system first checks if the existing counter periods (if any) are still valid based on the renewal period, the across providers/products settings and the currency. If they are not valid they are deleted and in some cases new counter periods are created. The next step is to find or create the applicable counter period for the claim line service date and create a consumption for it (if applicable). In some cases this includes the deletion of existing succeeding counter periods and the creation of new counter periods (see scenario M for a detailed example).
Cleanup
If the limit is of type amount and counter periods exist for the provider and aggregation level in context (based on the across providers/products settings, benefits provider and aggregation level), but with a current amount currency that differs from the benefits input amount currency, those counter periods are deleted.
If the limit counts across providers and counter periods exist for specific providers (this means that the across providers indicator on the limit has been updated), those counter periods are deleted. If the limit counts per provider and counter periods exist without a specified provider (this also means that the across providers indicator on the limit has been updated), those counter periods are deleted. The same applies when the across products indicator has been updated.
If counter periods exist for the provider and aggregation level in context (and the correct currency if applicable), but with a period length that differs from the renewal period specified on the limit, those counter periods are deleted.
Applicable Counter Period
In this step the system first checks if any counter periods exist for the provider and aggregation level in context (based on the across providers/products indicators, benefits provider and aggregation level); note that they can also be unspecified. It is possible that the counter periods have been deleted in the cleanup step or there has been no consumption yet for the provider and aggregation level in context.
If no counter periods exist for the provider and aggregation level in context, the system creates the counter period(s) based on the renewal period, the final (non-reversed and not marked for reversal) consumptions (if any), the claim line service date and the reference date. The reference date used to set out the periods is the first service date; the first service date is determined based on the existing consumptions and the claim line service date. Note that for limits with reference first claim irregular, the periods are irregular, meaning that the next period starts on the first service date that occurs after the end date of the previous period [15]. Note that the length of the periods is always the same (based on the renewal period). Afterwards the system checks if there is room left on the newly created applicable (that includes the claim line service date) counter period and creates a consumption for it (same as for the first claim reference).
If counter periods exist for the provider and aggregation level in context, the system checks if the applicable counter period (that includes the claim line service date) exists. If the applicable counter period exists, the system checks if there is room left on the counter period and creates a consumption (same as specified above).
If the applicable counter period does not exist, it is created based on the service date (which becomes the start date), the renewal period and the existing consumptions (same as for the first claim reference). Afterwards the system checks if there is room left on the newly created counter period and creates a consumption (same as specified above). It is possible that the newly created counter period overlaps with a succeeding counter period. If that is the case, the succeeding counter period is deleted and the system checks if a new counter period needs to be created based on the existing 'orphaned' consumptions (if any). If needed, a new counter period is created and the system again checks if there is overlap with a succeeding counter period (same as above). The system keeps on doing this until no new counter period needs to be created or there is no overlap with the succeeding counter period. Note that it is not possible to simply delete all succeeding counter periods and recreate them based on the consumptions, because there will not always be consumption on the first service date of a period (for example when the limit was already exceeded).
[15]
Orphaned Consumptions
It is possible that because counter periods have been deleted in the cleanup step, consumptions exist that no longer belong to a counter period; the so called orphaned consumptions. This applies when the across providers indicator and/or the across product indicator have/has been updated (from checked to unchecked) and for example consumptions exist for providers other than the claim line’s benefits provider. The system creates the counter period(s) for every applicable combination of provider and aggregation level based on the renewal period, the final (non-reversed and not marked for reversal) consumptions (if any) and the reference date. This is the same as creating counter periods for the provider and aggregation level in context (as specified above).
With Follow Limit
The mechanism specified below applies when an applicable 'follow' counter has been found. In the scenarios where a follow limit is specified, but is ignored (see New Counter mechanism), the evaluation is the same as if no follow limit is specified (see previous section). The same applies if no applicable 'follow' counter exists.
The system first checks if the existing counter periods (if any) of the 'following' (for the limit that is being evaluated) counter are still valid based on their start and end dates, the across providers/products settings and the currency. If they are not valid, they are deleted. The next step is to find or create the applicable counter period for the claim line service date and create (if applicable) a consumption for it. In the last step the system creates counter periods for orphaned consumptions (if any).
Cleanup
The checks (including cleanup) regarding the currency and the across providers/products settings are the same as if no follow limit applies (specified in the previous section).
If counter periods exist for the provider and aggregation level in context (and the correct currency if applicable), every counter period is checked individually to see if it is still valid:
-
Counter periods that match (same start and end dates) with counter periods (for the provider and aggregation level in context) of the 'follow' counter are kept
-
Counter periods that do not match (different start and end dates) with counter periods (for the provider and aggregation level in context) of the 'follow' counter, but that have time overlap with them are deleted
-
Counter periods that do not match with counter periods of the 'follow' counter (same as above) and do not have time overlap with them are checked based on the renewal period of the 'following' limit:
-
If the length of the counter period matches the renewal period, the counter period is kept
-
If the length of the counter period does not match the renewal period, the system checks if the end date of the counter period is one day prior to the start date of a counter period (for the provider and aggregation level in context) of the 'follow' counter; if that is the case the counter period is kept else it is deleted
-
Applicable Counter Period
The next step is to check if the applicable counter period (that includes the claim line start date) exists. This is done based on the 'follow' counter. The system checks if a counter period (for the provider and aggregation level in context) for the 'follow' counter exists that includes the service date of the claim line.
If the applicable 'follow' counter period exists, the system checks if the same (with the same provider, aggregation level, start date and end date) counter period exists for the 'following' (for the limit that is being evaluated) counter. If the applicable 'following' counter period exists, the system checks if there is room left on the counter period and (if applicable) creates a consumption (same as for the other limit references). If the applicable 'following' counter period does not exist, it is created (with the same start date and end date as the 'follow' counter period). Afterwards, the system checks if there are any existing consumptions that fall within the new counter period and count towards it; the current count is set based on those consumptions (same as for the other limit references). If there is room left on the counter period a consumption is created (same as above).
If the applicable 'follow' counter period does not exist, the 'following' counter period is created with the start and end dates set as usual (based on the service date, reference date and renewal period). However, if the end date of the new counter period is on or after the start date of the first succeeding counter period (with the same provider and aggregation level) of the 'follow' counter, then the end date is set to one day prior to the start date of that counter period. Afterwards, the system checks if there are any existing consumptions that fall within the new counter period and count towards it; the current count is set based on those consumptions (same as above). If there is room left on the counter period a consumption is created (same as above). It is possible that the newly created counter period overlaps with an existing counter period; in that case the existing counter period is deleted.
Orphaned Consumptions
It is possible that because counter periods have been deleted in the previous steps, consumptions exist that no longer belong to a counter period; the so called orphaned consumptions. The system evaluates the internal orphaned consumptions one by one starting with the earliest service date. For every orphaned consumption, the system checks if there is a counter period (for the provider and aggregation level in context) for the 'follow' counter that includes the service date of the consumption. If it exists, a counter period for the 'following' counter is created with the same start and end dates and the succeeding applicable consumptions (internal and external) that also fall within that period are counted towards it. If the 'follow' counter period does not exist, the 'following' counter period is created with the start and end dates set as usual (based on the service date and the renewal period). However, if the end date of the new counter period is on or after the start date of the first succeeding counter period (with the same provider and aggregation level) of the 'follow' counter, then the end date is set to one day prior to the start date of that counter period. The succeeding applicable consumptions that fall within that period are counted towards it (same as above). Note that the above also applies for counter periods of other providers and aggregation levels than the provider and aggregation level in context (if applicable).
Calendar Year and Plan Year
New Counter
After creating the new counter, the applicable counter periods (multiple counter periods might be needed if a carry over period applies) are created based on the limit settings and the information related to the claim line:
-
Limit: reference, renewal period, carry over period, other products carry over period and across products/providers indicators
-
Overriding reference, renewal period, carry over period and other products carry over period can be specified on the product limit level for specific time periods
-
-
Claim line: subscription date (if the limit has reference plan year), claim line start date (referred to as service date in the sections below), benefits input amount currency (if the limit is of type amount), benefits provider (if the limit counts per provider) and product aggregation level (if the limit counts per product aggregation level) or the result of the aggregation level dynamic logic function on the limit (if the limit counts per configured aggregation level)
The system fetches the settings specified on the limit and the settings specified on all (if any) product limits [16] (for the limit and product in context) that specify a reference. Based on that information, the system knows which settings apply across time. Note that if a product limit does not exist for a certain time period, the settings specified on the limit apply to that time period. See scenario K for a detailed example.
First a counter period is created for the service date. The start and end dates on the counter period are set based on the reference date (calendar year start date or subscription date [17]) and the renewal period that are valid on the service date, if the start and end dates fall within the same limit settings time period as the service date. If the start date falls outside the limit settings time period of the service date, the system checks if the reference and renewal period settings on the start date are the same as on the service date; if that is the case the start date is set normally (see scenarios A, B, C, D and F for detailed examples on how counter periods are set out). If that is not the case, the system looks for the earliest date after the start date on which the reference and renewal period settings are the same as on the service date and sets that date as the start date of the counter period.
If the end date falls outside the limit settings time period of the service date, the system checks if the reference and renewal period settings on the end date are the same as on the service date; if that is the case the end date is set normally. If that is not the case, the system looks for the latest date before the end date on which the reference and renewal period settings are the same as on the service date and sets that date as the end date of the counter period.
The carry over start date is set based on the carry over period setting (if specified) that is valid on the counter period start date. The same applies to the other products carry over start date.
If the limit counts per provider, the benefits provider is set on the counter period. If the limit counts per product aggregation level, the aggregation level of the product in context is set on the counter period. If the limit counts per configured aggregation level, the result of the dynamic logic function on the limit is set on the counter period. The current count on the counter period is set to 0 (for amounts the currency is set to the benefits input amount currency).
The next step is to check if the service date falls within the carry over period of succeeding counter periods. The system fetches the carry over period setting that is valid on the first day after the end date of the applicable counter period. If based on that setting the service date falls within the carry over period, a new counter period is created (using the same mechanism as specified above). The system keeps on checking and creating succeeding counter periods, until the service date does not fall within a carry over period.
After creating the counter period(s), a preliminary consumption (based on the limit maximum and reached action on the service date) is created for the new counter. When this consumption is finalized (in the Finalize step of the claims flow), the counter period(s) is/are updated (same as in the New Counter mechanism of the other limit references).
When a limit being evaluated is configured as a sub limit to some other limit(s), then the applicable counter periods## (when exists) of the other such limit(s) (not present simultaneously on the claim line), are also included and their current is updated. No counter periods for the composite limit are created if they do not exist. When the counter periods of the composite limit is updated, then its counter is also updated by 1.
[16]
[17]
Existing Counter
The system fetches the settings specified on the limit and the settings specified on all (if any) product limits (for the limit and product in context) that specify a renewal reference. Based on that information, the system knows which settings apply across time (same as in the New Counter mechanism). The next step is to check if the existing counter periods (if any) are still valid based on the fetched limit settings; invalid counter periods are deleted and new valid counter periods are created. After that the system identifies the applicable counter periods, creates them if they don’t exist and creates the consumption. See scenario K for a detailed example.
Existing Counter Periods
The first step of checking the existing counter periods, is to detect if the across products/providers indicators have been updated. If they have been updated, all counter periods are replaced. If the indicators have not been updated, the counter periods are checked individually.
Updating Across Products/Providers Indicator(s)
If the limit counts across product aggregation levels and counter periods exist for specific aggregation levels or if the limit counts per product aggregation level and counter periods exist without a specified aggregation level, it means that the across products indicator on the limit has been updated. The same check is performed for the across providers indicator. If at least one of the indicators has been updated, all existing counter periods are deleted. New counter periods are created based on the existing final (non-reversed and not marked for reversal) consumptions and the fetched limit settings (see New Counter mechanism for more information). The current count and maximum on the new counter period(s) are set based on those consumptions.
If the limit counts per product aggregation level, counter periods are only created for the aggregation level of the product in context. Note that consumptions with an unspecified aggregation level are also taken into account. For amounts only consumptions with the same currency as the benefits input amount currency are taken into account.
If the limit counts per provider, first counter periods are created for the benefits provider. Note that consumptions with an unspecified provider are also taken into account. For amounts only consumptions with the same currency as the benefits input amount currency are taken into account.
If consumptions also exist for other providers, counter periods are also created for those providers, also taking into account consumptions with an unspecified provider. For amounts only consumptions with the same currency as the currency of the most recent consumption (based on the service date) are taken into account.
Individual Counter Periods
If the across products/providers indicators have not been updated, the system checks all existing counter periods for the applicable combination of provider and aggregation level individually. If the limit is of type amount the system first checks if counter periods (for the applicable combination of provider and aggregation level) exist with a current amount currency that differs from the benefits input amount currency; those counter periods are deleted. Afterwards the dates (start date, end date, carry over start date and other product carry over start date) on the existing counter periods (for the applicable combination of provider and aggregation level) are checked. The counter periods with wrong dates are deleted and new counter periods are created based on the existing final (non-reversed and not marked for reversal) consumptions and the fetched limit settings [18] (see New Counter mechanism for more information).
[18]
Applicable Counter Periods
After the existing counter periods have been checked, the system checks if the applicable counter period for the service date exists, based on the fetched limit settings and the information related to the claim line (same as in the New Counter mechanism). The applicable counter period has correct dates (start date, end date, carry over start date and other products carry over start date) based on the limit settings and their time validity, it has the same provider as the benefits provider if the limit counts per provider (unspecified if the limit counts across providers), it has the same aggregation level as the aggregation level of the product in context if the limit counts per product aggregation level (unspecified if the limit counts across product aggregation levels) and it has the same current amount currency as the benefits input amount currency if the limit is of type amount.
If the applicable counter period exists, the system checks if there is room left on the counter period based on the current count of the counter period (including the preliminary consumptions of other claim lines within the same claim that count towards the counter period) and the limit maximum (including reached action) on the service date. If there is no room left, the evaluation stops.
If the applicable counter period does not exist, it is created with the correct start date, end date, carry over start date, other products carry over start date, provider and aggregation level (same as in the New Counter mechanism). Afterwards, the system checks if there are any existing final (non-reversed and not marked for reversal) consumptions that fall within the new counter period and count towards it (note that this also includes carry over consumption). The current count and maximum on the new counter period are set based on those consumptions (for amounts the currency is set to the benefits input amount currency, so only consumptions with the same currency are taken into account).
If there is room left on the applicable (existing or new) counter period, the next step is to check if the service date falls within the carry over period of succeeding counter periods. The system fetches the carry over period setting that is valid on the first day after the end date of the applicable counter period. If based on that setting the service date falls within the carry over period, the system checks if the applicable carry over counter period exists; if it does not exist it is created. Afterwards, the system checks if there is any existing final (non-reversed and not marked for reversal) consumption that counts towards the new counter period (including carry over consumption). The current count and maximum on the new counter period are set based on those consumptions (for amounts the currency is set to the benefits input amount currency, so only consumptions with the same currency are taken into account). The system keeps on checking and creating succeeding counter periods, until the service date does not fall within a carry over period.
A preliminary consumption (based on the limit maximum and reached action on the service date) is created for the counter. When this consumption is finalized (in the Finalize step of the claims flow), the applicable counter period(s) is/are updated (same as in the New Counter mechanism of the other limit references). Note that this also includes counter periods of other aggregation levels (if the limit counts per product aggregation level) that have an other products carry over start date that is the same as or earlier than the service date of the consumption.
When a limit being evaluated is a sub limit, then the applicable counter periods [19] (when exists) of the composite limits, which are not present simultaneously on the claim line, are also included and updated as explained above. No counter periods for the composite limit are created if they do not exist.
[19]
Annual
A limit with the reference 'Annual' works exactly the same as a limit with the reference 'Calendar Year', except that:
-
The start and end dates of the counter period are set based on the reference date, which is 1st of the month as specified by the annual limit start month
-
A limit with the reference 'Annual' cannot have an overriding reference, renewal period, carry over period and other products carry over period on the product limit level, and therefore additional checks on the time validity of the settings for plotting of counter period, carryover period and other products carry over period are not applicable.
Single Claim
New Counter
After creating the new counter, a counter period is created based on the limit settings and the information related to the claim line:
-
Limit: reference and across products/providers indicators
-
Claim line: benefits input amount currency (if the limit is of type amount), benefits provider (if the limit counts per provider) and product aggregation level (if the limit counts per product aggregation level) or the outcome of the aggregation level dynamic logic function on the limit
The start and end dates on the counter period do not have any values specified on them. If the limit counts per provider, the benefits provider is set on the counter period. If the limit counts per product aggregation level, the aggregation level of the product in context is set on the counter period. If the limit counts per configured aggregation level, the result of the dynamic logic function on the limit is set on the counter period. The current count on the counter period is set to 0 (for amounts the currency is set to the benefits input amount currency).
After creating the counter period, a preliminary consumption is created (based on the limit maximum and reached action on the service date) for the new counter. When this consumption is finalized (in the Finalize step of the claims flow), the counter period is updated (same as in the New Counter mechanism of the other limit references).
Existing Counter
The system checks if the applicable counter period exists, based on the limit settings and the information related to the claim line (same as in the New Counter mechanism). The applicable counter period has the same provider as the benefits provider if the limit counts per provider (unspecified if the limit counts across providers), it has the same aggregation level as the aggregation level of the product in context if the limit counts per product aggregation level (unspecified if the limit counts across product aggregation levels) and it has the same current amount currency as the benefits input amount currency if the limit is of type amount.
Existing Counter Period
Same mechanism applies as in the 'Existing Counter Period' sub-section under limits with reference insurance, insurable entity, case, first claim and around treatment section.
New Counter Period
If the applicable counter period does not exist, it is created with the correct provider and aggregation level (same as in the New Counter mechanism). The current count and the maximum of the counter period are set using the same mechanism as in the 'New Counter Period' sub-section under limits with reference insurance, insurable entity, case, first claim and around treatment section. This includes the follow situations as well:
-
Different currency
-
Updating Across Providers Indicator
-
Updating Across Products Indicator
Note that although consumption for a reservation claim line is created normally but the during the creation of consumption for an actual claim line, the system never checks for the presence of consumption created by a reservation claim line (which includes ignoring all the information that is configured on the reservation regime).
Scenarios
To get a clear understanding of how limit counters and counter periods are set out, consider the following scenarios. Note that multiple limit counters for the same limit run concurrently, since each limit counter is specifically for a person or object or family. To prevent cluttering, this is not evident in the images that visualize the scenarios.
Scenario A through D illustrate how different period lengths are set out in combination with a reoccurring reference date. The scenarios assume a reference date of January 1st (start-of-calendar-year). Scenario E and F illustrate the difference between the start-of-insurance-date reference and the plan year reference. Scenario G illustrates how limit counter periods based on a case reference are set out.
Scenario H illustrates how the counter periods of a limit with a configured carry over period are set out. Scenario I and J illustrate how limit consumptions are created and how they lead to the creation of new counter periods.
Scenario K illustrates the impact on counter periods when the reference date of a limit is changed.
Scenarios L and M illustrate the workings of a limit with reference 'First Claim' and 'First Claim Irregular'. Scenario N illustrates the workings of a follow limit.
Scenarios O to R and W illustrate the workings of a limit for a claim line that refers to a reservation line. Scenario O illustrates the working of a cover limit when the indicator amount ceiling is configured on the reservation regime as Y(es). Scenario P illustrates the working of a cover limit when the amount ceiling is configured on the reservation regime as N(o). Scenario Q illustrates the working of a cover limit when the indicator release set to Y(es). Scenario R illustrates the working of a withhold limit for a claim line that refers to a reservation line. Scenario W see below.
Scenario U (a, b and c) illustrates the working of a composite limit.
Scenario V illustrates the working of a limit with an aggregation level dynamic logic function.
Scenario W illustrates the working of a cover limit when the indicator amount ceiling is configured on the reservation regime as N(o) and the indicator number of units ceiling is configured as Y(es).
Scenario A (CY - 1Y)
Limit with a 1 year period and a start-of-calendar-year reference:
Note that the first limit counter period is (possibly) set out before the person’s subscription date. This does not, in any way, influence whether or not a person is covered.
Scenario B (CY - 3M)
Limit with a 3 month period and a start-of-calendar-year reference:
Scenario C (CY - 8M)
Limit with a 8 month period and a start-of-calendar-year reference:
Note that two counter periods are set out for each calendar year. The first counter period spans the specified 8 months. The second counter period is cut short at 4 months, ending one day prior to the re-occurrence of the reference date. For calendar year based limits, the reference date is January 1st.
Scenario D (CY - 18M)
Limit with a 18 month period and a start-of-calendar-year reference:
The unusual aspect of this scenario is that the specified period length (18 months) is longer than the time span between two occurrences of the reference date (12 months). This is handled as follows: the first counter period is always set out for the full length of the specified period, even if the reference date reoccurs during this period. The subsequent counter period will end one day prior to the next occurrence of the reference date.
For this scenario that means that, for every two years, an 18 month counter period is set out, followed by a 6 month counter period.
Scenario E (Insurance - 5M)
Limit with a 5 month period and a start-of-insurance based reference. The subscription date is May 1st 2008:
Starting from the subscription date, consecutive 5 month counter periods are set out. This pattern repeats without end.
Scenario F (PY- 5M)
Limit with a 5 month period and a plan year based reference. The subscription date is May 1st 2008:
Starting from the subscription date, consecutive 5 month counter periods are set out. However, a counter period is cut short in the event that the subscription date reoccurs. Starting from the re-occurrence of the subscription date consecutive 5 month counter periods are set out. This pattern repeats.
Scenario G (Case - 5M)
Limit with a 5 month period and a case reference. The case start date is May 1st 2008:
Starting from the case start date, consecutive 5 month counters periods are set out. This pattern repeats without end.
Scenario H (CY - 1Y - 2M CO)
Limit that counts across products, with a 1 year period and calendar year reference. The carry over period is configured to be 2 months:
Counter periods are set out as normal, but each counter period starts 2 months prior to the reference date, i.e., the first of January. This creates an overlap of counter periods. The effect is that any claim line that counts towards this limit, and has a start date between Nov 1st and Dec 31st, is counted in two counter periods: the counter period for the current and next year.
Scenario I (Consumptions)
To clarify the purpose of limit consumptions, consider the following scenario. Person A is subscribed to a product A on the 1st of Jan 2007. Product A has a yearly insurable entity deductible of $1000. The limit is configured as follows:
-
Code: MEM_DED
-
Description: Member Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar Year
-
Renewal Period: 1 year
The first claim line processed for person A has a claim line start date on the 2nd of Feb 2007. The claim line uses $300 of the insurable entity deductible. Because no existing limit counter period covers the specified date, a new limit counter period (including a limit counter) is created, starting on the 1st of Jan 2007, ending on the 31st of Dec 2007:
After the limit counter period and consumption have been created, the counter period for 1-Jan-2007 through 31-Dec-2007 has a current amount of $300. The second claim line processed for person A has a claim line start date on the 13th of Aug 2007. The service date is in a period with an existing counter period, so the consumption is recorded under that counter period:
Once the consumption has been created, the counter period for 1-Jan-2007 through 31-Dec-2007 is updated so that it has a current amount of $800. The third line processed for person A has a claim line start date on the 25th of Mar 2009. No counter period exists for that that yet, so a new limit counter period is created starting on the 1st of Jan 2009, ending on the 31st of Dec 2009:
After the limit counter period and consumption have been created, the counter period for 1-Jan-09 through 31-Dec-09 has a current amount of $400. Now let us assume that the person sends in an appeal. The appeal results in the third line being reprocessed. After reprocessing, the line only counts $200 towards the deductible, rather than the initially calculated $400.
Consumptions that have been recorded as the result of an approved claim line are never removed, not even if the claim line is altered and reprocessed at a later point in time. Instead OHI Claims marks the initial consumption as being reversed (which means that it no longer actually increments the counter) and a new positive consumption of $200 to store the new result. As a result, there are two separate consumptions on 25-Mar-09:
The counter period for 1-Jan-09 through 31-Dec-2009 is updated so that it has a current amount of $200.
Scenario J (Service Days)
To clarify the workings of a service days based limit consider the following scenario. The limit enforces that a person visits his or her physical therapist (PT) no more than 10 times per calendar year. In this context, the term 'visits' translates into distinct service days, rather than the allowed number of units. In other words, 3 claim lines that charge a PT visit, all of which are on the same service date, still count as a single visit within the context of this limit. The limit is configured as follows:
-
Code: PT_VISIT_LIMIT
-
Description: Physical Therapy Visit Limit
-
Action: Cover
-
Level: Insurable Entity
-
Type: Service Days
-
Reference: Calendar Year
-
Renewal Period: 1 year
The first line processed for person A has a start date on March 30th, 2008. There is no counter period that covers the service date, so a new limit counter period is created starting on the 1st of Jan 2008, ending on the 31st of Dec 2008. The line increments the current count by 1 day:
The second claim line has start date on August 28th, 2008. Since that date is within the existing counter period, a new consumption is created for the existing limit counter period. The current count is updated to 2 days:
The third claim line has start date, again, on March 30th, 2008. Since that date is within the existing counter period, a new consumption is created for the existing limit counter period. Because the type of the limit is 'service days', the current count is based on distinct service dates. Since there was already a consumption on March 30th, the current count remains 2 days, even though there are three consumptions:
The fourth claim line has start date on December 29th, 2008, and an end date on January 3rd, 2009. The line charges 5 units.
Limits of the type 'service days' count distinct claim line start dates; the number of allowed units and the claim line end date are not relevant for the counter. So the result of the fourth claim line is a single consumption with service date December 29th, 2008. The current count is incremented to 3:
The second line (service date on August 28th) is reprocessed and denied. As a result, the consumption is reversed. Within the context of a service date based limit, a reversed consumption negates exactly 1 incremental consumption. The effect is that August 28th is no longer considered to count towards the limit, and the current count is decremented to 2 days:
Note that reversing the consumption on March 30th (e.g. as a result of reprocessing) would have no impact on the current count since there is still an incremental consumption on that date. The net outcome is that March 30th would still count towards the limit.
Scenario K (CY → PY)
To clarify the impact of changing the reference date (from Calendar Year to Plan Year) of a limit on counter periods, consider the following scenario. The limit is configured as follows:
-
Code: MEM_OOPM
-
Description: Member out-of-pocket maximum
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar Year
-
Renewal Period: 1 year
-
Maximum (specified on the Product Benefit Specification Limit): $2000
The following product limit is configured on product BASIC:
-
Limit: MEM_OOPM
-
Reference: Calendar Year
-
Renewal Period: 1 year
-
Start Date: 01/01/2013
-
End Date: -
Multiple claims are processed for person A subscribed to product BASIC on the 1st of Jul 2013 (subscription date) having claim lines with service dates in 2013 (second half year) and 2014 (first half year). A counter and two counter periods (calendar year 2013 and calendar year 2014) are created including the limit consumptions that count towards them.
Let’s consider the scenario that on the 1st of Jul 2014 the reference of the limit is changed to Plan Year on product BASIC. This means that the existing product limit is end dated (end date set to 06/30/2014) and a new product limit is created:
-
Limit: MEM_OOPM
-
Reference: Plan Year
-
Renewal Period: 1 year
-
Start Date: 07/01/2014
-
End Date: -
A new claim for person A with a claim line with a start date (service date) on the 2nd of Aug 2014 is processed. The claim line has a benefits input amount of $100. The system first checks if the existing counter periods are still valid based on the limit settings. The counter period for calendar year 2013 is still valid, so it is kept. The counter period for calendar year 2014 is no longer valid because the end date of the counter period no longer complies with the new settings. The counter period is replaced by a new valid counter period starting on the 1st of Jan 2014 and ending on the 30th of Jun 2014; the current count of the counter period is set based on the existing consumptions. Afterwards, the system checks if a valid counter period exists for the new service date; it does not exist so it is created starting on the 1st of Jul 2014 and ending on the 30th of Jun 2015. A consumption of $100 is created and the current count of the new counter period is set to $100.
Let’s consider the scenario that instead of changing the reference of the limit to Plan Year on the 1st of Jul 2014, the reference of the limit is changed on the 1st of Jan 2015. This means that the existing product limit is end dated (end date set to 31/12/2014) and a new product limit is created:
-
Limit: MEM_OOPM
-
Reference: Plan Year
-
Renewal Period: 1 year
-
Start Date: 01/01/2015
-
End Date: -
A new claim for person A with a claim line with a start date (service date) on the 22nd of Mar 2015 is processed. The claim line has a benefits input amount of $100. The system first checks if the existing counter periods are still valid based on the limit settings. The counter periods for the calendar year 2013 and calendar year 2014 are both still valid, so they are kept. Afterwards, the system checks if a valid counter period exists for the new service date; it does not exist so it is created starting on the 1st of Jan 2015 and ending on the 30th of Jun 2015. A consumption of $100 is created and the current count of the new counter period is set to $100.
Scenario L (First Claim)
To clarify the workings of a limit with reference 'First Claim', consider the following scenario. The limit enforces that a person spends no more than $250 per 2 years on glasses and contact lenses. The limit is configured as follows:
-
Code: VISION_LIMIT
-
Description: Vision Limit
-
Action: Cover
-
Level: Insurable Entity
-
Type: Amount
-
Reference: First Claim
-
Renewal Period: 2 years
-
Maximum (specified on the Product Benefit Specification Limit): $250
The first claim processed for person A has a claim line with a start date (service date) on the 2nd of Jun 2016. The claim line has a benefits input amount of $100. Because no counter exists yet for person A for this limit, it is created including a counter period that covers the service date, starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2018. A consumption of $100 is created and the current count of the new counter period is set to $100.
The second claim processed for person A has a claim line with a start date (service date) on the 21st of Mar 2017. The claim line has a benefits input amount of $100. Because the counter period that was created when the first claim was processed, covers the service date, no new counter period is created. A consumption of $100 is created and the current count of the existing counter period is set to $200.
The third claim processed for person A has a claim line with a start date (service date) on the 10th of Jul 2018. The claim line has a benefits input amount of $100. Because no existing counter period covers the service date, a new counter period is created based on the start date of the first counter period (used as the reference date) and the renewal period of the limit, so starting on the 2nd of Jun 2018 and ending on the 1st of Jun 2020. A consumption of $100 is created and the current count of the new counter period is set to $100.
Note that if the first claim is reprocessed and denied, the counter periods and the results of the second and third claim will not be automatically updated. The second and third claim will need to be reprocessed as well.
Now let’s consider a couple of different scenarios for processing a fourth claim:
-
The fourth claim processed for person A has a claim line with a start date on the 3rd of Jan 2016. The claim line has a benefits input amount of $50. Because no existing counter period covers the specified date (which lies before the first counter period), a new counter period is created, starting on the 3rd of Jan 2016 and ending on the 2nd of Jan 2018. The existing consumptions from the first two claims both fall within the new counter period and count towards it, so the current count (that will be used to evaluate the claim line of the fourth claim) is set to $200. A consumption of $50 is created and the current count of the new counter period is set to $250.
The existing counter periods are no longer valid (reference date is changed) so they are deleted. A new counter period is created, starting on the 3rd of Jan 2018 and ending on the 2nd of Jan 2020 for the existing consumption of the third claim and the current count of the new counter period is set to $100.
-
The fourth claim processed for person A is the same as specified above, but the maximum of the limit has been updated to $200. The behavior of creating the new counter periods and deleting the existing counter periods is exactly the same as specified above. However, no consumption is created because the limit is exceeded. So even if no consumption is created, the first counter period will start at the first service date.
-
The renewal period of the limit is updated to 1 year. The fourth claim processed for person A has a claim line with a start date on the 8th of Aug 2016. The claim line has a benefits input amount of $50. The counter period created for the first claim, starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2018, covers the service date, but the end date is not correct based on the current renewal period. A new counter period is created, starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2017. The existing consumptions from the first two claims both fall within the new counter period and count towards it, so the current count (that will be used to evaluate the claim line of the fourth claim) is set to $200. A consumption of $50 is created and the current count of the new counter period is set to $250.
The existing counter periods are no longer valid (renewal period is changed), so they are deleted. A new counter period is created, starting on the 2nd of Jun 2018 and ending on the 1st of Jun 2019 for the existing consumption of the third claim and the current count of the new counter period is set to $100. Note that there is no counter period created starting on the 2nd of Jun 2017 and ending on the 1st of Jun 2018, because there is no consumption in this period.
Scenario M (First Claim Irregular Periods)
To clarify the workings of a limit with reference 'First Claim Irregular', consider the following scenario. The limit is configured as follows:
-
Code: MEM_DED
-
Description: Member deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: First Claim Irregular
-
Renewal Period: 1 year
-
Maximum (specified on the Product Benefit Specification Limit): $250
The first claim processed for person A has a claim line with a start date (service date) on the 2nd of Jun 2016. The claim line has a benefits input amount of $100. Because no counter exists yet for person A for this limit, it is created including a counter period that covers the service date, starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2017. A consumption of $100 is created and the current count of the new counter period is set to $100.
The second claim processed for person A has a claim line with a start date (service date) on the 21st of Jan 2017. The claim line has a benefits input amount of $100. Because the counter period that was created when the first claim was processed, covers the service date, no new counter period is created. A consumption of $100 is created and the current count of the existing counter period is set to $200.
The third claim processed for person A has a claim line with a start date (service date) on the 10th of Jul 2017. The claim line has a benefits input amount of $100. Because no existing counter period covers the service date, a new counter period is created based on the service date, so starting on the 10th of Jul 2017 and ending on the 9th of Jul 2018. A consumption of $100 is created and the current count of the new counter period is set to $100.
Note that if the first claim is reprocessed and denied, the counter periods and the results of the second and third claim will not be automatically updated. The second and third claim will need to be reprocessed as well.
Now let’s consider a couple of different scenarios for processing a fourth claim:
-
The fourth claim processed for person A has a claim line with a start date on the 3rd of Jan 2016. The claim line has a benefits input amount of $50. Because no existing counter period covers the specified date (which lies before the first counter period), a new counter period is created, starting on the 3rd of Jan 2016 and ending on the 2nd of Jan 2017. The existing consumption from the first claim falls within the new counter period and count towards it, so the current count (that will be used to evaluate the claim line of the fourth claim) is set to $100. A consumption of $50 is created and the current count of the new counter period is set to $150.
The existing counter periods are no longer valid, so they are deleted. A new counter period is created, starting on the 21st of Jan 2017 and ending on the 20th of Jan 2018 for the existing consumptions of the second and third claim and the current count of the new counter period is set to $200.
-
The fourth claim processed for person A has a claim line with a start date on the 3rd of May 2016. The claim line has a benefits input amount of $50. Because no existing counter period covers the specified date (which lies before the first counter period), a new counter period is created, starting on the 3rd of May 2016 and ending on the 2nd of May 2017. The existing consumptions from the first two claims fall within the new counter period and count towards it, so the current count (that will be used to evaluate the claim line of the fourth claim) is set to $200. A consumption of $50 is created and the current count of the new counter period is set to $250.
The existing counter period starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2017 is no longer valid, so it is deleted. The existing counter period starting on the 10th of Jul 2017 and ending on the 9th of Jun 2018 is still valid, so it is kept.
-
The fourth claim processed for person A has a claim line with a start date on the 10th of Jun 2017. The claim line has a benefits input amount of $50. Because no existing counter period covers the specified date (which lies in between the first and the second counter period), a new counter period is created, starting on the 10th of Jun 2017 and ending on the 9th of Jun 2018. The existing consumption from the third claim falls within the new counter period and counts towards it, so the current count (that will be used to evaluate the claim line of the fourth claim) is set to $100. A consumption of $50 is created and the current count of the new counter period is set to $150.
The existing counter period starting on the 10th of Jul 2017 and ending on the 9th of Jun 2018 is no longer valid, so it is deleted. The existing counter period starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2017 is still valid, so it is kept.
Scenario N (Follow Limit)
To clarify the workings of a follow limit, consider the following scenario. The limit is configured as follows:
-
Code: MEM_DED
-
Description: Member deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: First Claim Irregular
-
Renewal Period: 1 year
-
Maximum (specified on the Product Benefit Specification Limit): $75,000 (Chilean Peso)
-
Follow Limit: FAM_DED
The follow limit is configured as follows:
-
Code: FAM_DED
-
Description: Family deductible
-
Action: Withhold
-
Level: Family
-
Type: Amount
-
Reference: First Claim Irregular
-
Renewal Period: 1 year
-
Maximum (specified on the Product Benefit Specification Limit): $200,000 (Chilean Peso)
The Martinez family has three family members: Pablo, Ana and Juan.
The first claim processed is for Pablo and it has a claim line with a start date (service date) on the 2nd of Jun 2016. The claim line has a benefits input amount of $50,000. Because no counter exists yet for the Martinez family (family deductible limit), it is created including a counter period that covers the service date, starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2017. A consumption of $50,000 is created and the current count of the new counter period is set to $50,000. A counter (including counter period and consumption) for Pablo (member deductible limit) is created as well (same as the family counter).
The second claim processed is for Ana and it has a claim line with a start date (service date) on the 3rd of Apr 2017. The claim line has a benefits input amount of $75,000. The counter for the Martinez family (family deductible limit) already exists with a counter period that includes the service date of the new claim line. A consumption of $75,000 is created and the current count of the counter period is set to $125,000. A counter for Ana (member deductible limit) does not yet exist, so it is created. The counter period is created based on the follow limit (family deductible limit), meaning that it starts on the 2nd of Jun 2016 and ends on the 1st of Jun 2017 (instead of starting on the 3rd of Apr 2017 and ending on the 2nd of Apr 2018). A consumption of $75,000 is created and the current count of the new counter period is set to $75,000.
Now let’s consider a couple of different scenarios for processing the third claim:
-
The third claim processed is for Juan and it has a claim line with a start date (service date) on the 1st of May 2017. The claim line has a benefits input amount of $50,000. The counter for the Martinez family (family deductible limit) already exists with a counter period that includes the service date of the new claim line. A consumption of $50,000 is created and the current count of the counter period is set to $175,000. A counter for Juan (member deductible limit) does not yet exist, so it is created. The counter period is created based on the follow limit (family deductible limit), meaning that it starts on the 2nd of Jun 2016 and ends on the 1st of Jun 2017 (instead of starting on the 1st of May 2017 and ending on the 30th of Apr 2018). A consumption of $50,000 is created and the current count of the new counter period is set to $50,000.
-
The third claim processed is for Juan and it has a claim line with a start date (service date) on the 20th of Sep 2017. The claim line has a benefits input amount of $25,000. The counter for the Martinez family (family deductible limit) already exists, but without a counter period that includes the service date of the new claim line. A new counter period is created, starting on the 20th of Sep 2017 and ending on the 19th of Sep 2018. A consumption of $25,000 is created and the current count of the new counter period is set to $25,000. The existing counter period starting on the 2nd of Jun 2016 and ending on the 1st of Jun 2017 is still valid, so it is kept. A counter for Juan (member deductible limit) does not yet exist, so it is created. The counter period is created based on the follow limit (family deductible limit), meaning that it starts on the 20th of Sep 2017 and ends on the 19th of Sep 2018. A consumption of $25,000 is created and the current count of the new counter period is set to $25,000.
-
The third claim processed is for Juan and it has a claim line with a start date (service date) on the 5th of Mar 2016. The claim line has a benefits input amount of $20,000. The counter for the Martinez family (family deductible limit) already exists, but because no existing counter period covers the specified date (which lies before the first counter period), a new counter period is created, starting on the 5th of Mar 2016 and ending on the 4th of Mar 2017. The existing consumption from the first claim falls within the new counter period and counts towards it, so the current count (that will be used to evaluate the claim line of the third claim) is set to $50,000. A consumption of $20,000 is created and the current count of the new counter period is set to $70,000. A new counter period is created, starting on the 3rd of Apr 2017 and ending on the 2nd of Apr 2018 for the existing consumption of the second claim and the current count of the new counter period is set to $75.000. The existing counter period for the family deductible limit is no longer valid (reference date is changed) so it is deleted. A counter (including counter period and consumption) for Juan (member deductible limit) is created as well (counter period starting on the 5th of Mar 2016 and ending on the 4th of Mar 2017 with a current count of $20,000). Note that the existing counters and counter periods for Pablo and Ana (member deductible limit) are not automatically updated; they will be updated accordingly when the first and second claim are reprocessed.
Scenario O (cover limit - indicator ceiling set to Y(es))
The cover limit is defined as:
-
Code: HOSPITALIZATION_LIMIT
-
Description: Hospitalization Limit
-
Action: Cover
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Start-of-calendar-year
-
Renewal Period: 1 years
-
Maximum (specified on the Product Benefit Specification Limit): $50000
The reservation regime is configured as :
-
Code: REV001
-
Indicator Amount Ceiling: Y
-
Exceed Label: Reservation withheld
The following claim lines are processed :
| Processing Seq . | Process Type | Res. Regime and Reservation Line | Claim Line Code | Receipt Date | Service Date | Expiration Date | Serviced Person | Benefits input amount |
|---|---|---|---|---|---|---|---|---|
1 |
Reservation |
- |
RES001 |
03-10-2017 |
03-03-2017 |
06-30-2017 |
MEM_001 |
$25000 |
2 |
Claim |
REV001/RES001 |
CL001 |
03-23-2017 |
03-03-2017 |
- |
MEM_001 |
$15000 |
3 |
Claim |
REV001/RES001 |
CL002 |
05-03-2017 |
04-14-2017 |
- |
MEM_001 |
$5000 |
4 |
Claim |
REV001/RES001 |
CL003 |
06-06-2017 |
06-05-2017 |
- |
MEM_001 |
$15000 |
When the reservation line RES001 is processed, it creates a counter period that covers the service date starting at 01-01-2017 and ending at 12-31-2017. The current amount on the counter period is set to $25000 and the following consumption is created:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$25000 |
$50000 |
06-30-2017 |
Y |
The limit message - 'limit not met' is attached to the reservation line.
The claim line CL001 refers to the reservation regime REV001 and reservation line RES001. The available room on the counter period for this claim line is $25000 ($25000 minus 0; as there are no consumptions using the reserved consumption) plus 0 (as the reservation regime is configured to be a ceiling). The following consumptions are created:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$15000 |
$50000 |
- |
- |
-$15000 |
$50000 |
06-30-2017 |
Y |
The current amount on the counter period does not change and is $25000 (i.e. the sum of the all non expired consumption: $25000+$15000-$15000). The reservation regime message - 'limit not met' is attached.
When CL002 is processed the available room on the counter period is $10000 ($25000 - $15000). This line registers a consumption of $5000 and offset consumption of -$5000. The reservation regime message - 'limit not met' is attached.
When CL003 is processed the available room on the counter period is $5000 ($25000 - $15000 -$5000). The claim line can register a consumption only up to the reserved amount. This is because the indicator amount ceiling is set to Y(es) on the reservation regime. The remaining $10000 is withheld under the 'Exceeded' coverage label configured on the reservation regime. The reservation regime message - 'limit met and exceeded' is attached. The following consumptions are created:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$5000 |
$50000 |
- |
- |
-$5000 |
$50000 |
06-30-2017 |
Y |
Note that in this scenario the limit messages are not attached.
Scenario P (cover limit - indicator ceiling set to N(0))
The cover limit is defined as:
-
Code: HOSPITALIZATION_LIMIT
-
Description: Hospitalization Limit
-
Action: Cover
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Start-of-calendar-year
-
Renewal Period: 1 years
-
Maximum (specified on the Product Benefit Specification Limit): $50000
The reservation regime is configured as:
-
Code REV002
-
Indicator Amount Ceiling: N(o)
-
Exceed Label: Reservation withheld
The following claim lines are processed:
| Processing Seq. | Process Type | Res. Regime and Reservation Line | Claim Line Code | Receipt Date | Service Date | Expiration Date | Serviced Person | Benefits input amount |
|---|---|---|---|---|---|---|---|---|
1 |
Reservation |
- |
RES002 |
03-10-2017 |
03-03-2017 |
06-30-2017 |
MEM_001 |
$25000 |
2 |
Claim |
REV002/RES002 |
CL001 |
03-23-2017 |
03-03-2017 |
- |
MEM_001 |
$15000 |
3 |
Claim |
REV002/RES002 |
CL002 |
05-03-2017 |
04-14-2017 |
- |
MEM_001 |
$5000 |
4 |
Claim |
REV002/RES002 |
CL003 |
06-06-2017 |
06-05-2017 |
- |
MEM_001 |
$35000 |
RES002, CL001, and CL002 are processed as in the scenario O.
When CL003 is processed the available room on the counter period is $30000, that is, the available room on the limit ($25000) + the available room on the reservation ($5000). The claim line can register a consumption up to $30000. The remaining $5000 is withheld under the withhold label of the cover withhold category of the cover withhold rule. The reservation regime message - 'limit met and exceeded' and the limit message - 'limit met and exceed' are attached. Note that the limit message is attached as the claim line utilizes the available room on the limit.
The following consumptions are created:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$30000 |
$50000 |
- |
- |
-$5000 |
$50000 |
06-30-2017 |
Y |
Scenario Q (cover limit - indicator release set to Y(es))
The cover limit is defined as:
-
Code: HOSPITALIZATION_LIMIT
-
Description: Hospitalization Limit
-
Action: Cover
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Start-of-calendar-year
-
Renewal Period: 1 years
-
Maximum (specified on the Product Benefit Specification Limit): $50000
The reservation regime is configured as:
-
Code: REV003
-
Indicator Release: Y(es)
-
Indicator Amount Ceiling: Y(es)
-
Exceed Label: Reservation withheld
The following claim lines are processed:
| Processing Seq . | Process Type | Res. Regime and Reservation Line | Claim Line Code | Receipt Date | Service Date | Expiration Date | Serviced Person | Benefits input amount |
|---|---|---|---|---|---|---|---|---|
1 |
Reservation |
- |
RES003 |
03-10-2017 |
03-03-2017 |
06-30-2017 |
MEM_001 |
$25000 |
2 |
Claim |
REV003/RES003 |
CL001 |
03-23-2017 |
03-03-2017 |
- |
MEM_001 |
$15000 |
3 |
Claim |
REV003/RES003 |
CL002 |
05-03-2017 |
04-14-2017 |
- |
MEM_001 |
$5000 |
When the reservation line RES003 is processed, it creates a counter period that covers the service date starting at 01-01-2017 and ending at 12-31-2017. The current amount on the counter period is set to $25000 and the following consumption is created:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$25000 |
$50000 |
06-30-2017 |
Y |
The limit message - 'limit not met' is attached to the reservation line.
The claim line CL001 refers to the reservation regime REV003 and reservation line RES003. The available room on the counter period for this claim line is $25000 ($25000 minus 0; as there are no consumptions using the reserved consumption) plus 0 (as the reservation regime is configured to be ceiling for the amount). Because the indicator release on the regime is configured as Y(es), the offset is created such that it offsets the complete reserved value. The following consumptions are created:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$15000 |
$50000 |
- |
- |
-$25000 |
$50000 |
06-30-2017 |
Y |
The reservation regime message - 'limit not met' is attached.
When the claim line CL002 is processed, the available room on the counter period is 0 (as the reservation is fully consumed by CL001). This line, therefore, cannot register any consumption. The reservation regime message - 'limit exceeded' is attached. The entire $5000 is withheld under the 'Exceeded' label that is configured on the reservation regime.
Alternatively, if the indicator amount ceiling was configured to N(o) then the available room on the counter period will be $25000, that is the available room on the limit ($25000) + the available room on the reservation (0). The reservation regime message - 'limit exceeded' and limit message - 'limit not met' is attached. The limit message is attached because the claim line consumes the room available on the limit.
The following consumption is created:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$5000 |
$50000 |
- |
- |
Scenario R (withhold limit)
The limit is configured as follows:
-
Code: MEM_DED
-
Description: Member Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar Year
-
Renewal Period: 1 year
-
Yearly insurable entity deductible of $1000
The reservation regime is configured as:
-
Code: REV004
-
Indicator Release: Y(es)
-
Indicator Amount Ceiling: Not Applicable
-
Exceed Label: Not Applicable
The following claim lines are processed:
| Processing Seq . | Process Type | Res. Regime and Reservation Line | Claim Line Code | Receipt Date | Service Date | Expiration Date | Serviced Person | Benefits input amount |
|---|---|---|---|---|---|---|---|---|
1 |
Reservation |
- |
RES004 |
03-10-2017 |
03-03-2017 |
06-30-2017 |
MEM_001 |
$200 |
2 |
Claim |
REV004/RES004 |
CL001 |
03-23-2017 |
03-03-2017 |
- |
MEM_001 |
$100 |
3 |
Claim |
REV004/RES004 |
CL002 |
05-03-2017 |
04-14-2017 |
- |
MEM_001 |
$100 |
4 |
Claim |
REV004/RES004 |
CL003 |
07-09-2017 |
07-09-2017 |
- |
MEM_001 |
$800 |
5 |
Claim |
REV004/RES004 |
CL004 |
07-09-2017 |
07-09-2017 |
- |
MEM_001 |
$200 |
When the reservation line RES004 is processed it reserves a consumption of $200. Then CL001 is processed, it registers the consumptions of $100 and -$200 as the release indicator is set to Y(es). The reservation regime message - 'limit not met' is attached.
When CL002 is processed, the available room on the counter period is $900 (the available room on the limit ($1000 - ($200 +$100 -$200)) + 0 (available room on the reservation). CL002 registers the following consumption:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$100 |
$1000 |
- |
- |
The reservation regime message - 'limit exceeded' and limit message - 'limit not met' are attached.
For CL003, the available room on the counter period is $800, that is because this claim line is processed after the reservation has expired. It only sees a positive consumption of $100 by claim line CL001 and $100 by claim line CL002. Since the claim line CL003 refers to a reservation line, the reservation regime message - 'limit exceeded' is attached. Limit message - 'limit met' is also attached.
CL003 registers the following consumption:
| Amount | Maximum amount | Expiration Date | Indicator Reserved |
|---|---|---|---|
$800 |
$1000 |
- |
- |
When CL004 is processed, there is no room on the counter period and therefore, no consumptions are created. The reservation regime message - 'limit exceeded' and the limit message - 'limit exceeded' are attached.
Scenario S (PY - with subscription end date)
Limit with a 3 month period and a plan year based reference. The subscription date is May 1st 2008 and subscription end date is September 30th 2008:
Since the limit reference is plan year and the subscription end date is available, the counter period is set out using the subscription date and subscription end date i.e., 5/1/08 to 9/30/08 instead of the usual 3 month renewal period.
Scenario T (Single Claim)
To clarify the working of a limit with reference 'Single Claim', consider the following scenario. A limit enforces that a provider is liable to bear a penalty of maximum $500 per unauthorized claim. This is ensured by having an withhold limit. The limit is configured as follows:
-
Code: PENALTY_LIMIT
-
Description: Unauthorized Claim Penalty
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Single Claim
The first claim processed is for Person A and it has a single claim line with a start date (service date) on the 13th of Mar 2016. There is no existing counter period since it is the first claim line, hence a new limit counter period (including a limit counter with reference to the claim to which the claim line belongs) is created. The claim line has a benefits input amount of $350. A new consumption is created and the current amount of the new counter period is updated to $350.
Another claim comes in with two claim lines. The first claim line processed for person A has the claim line start date 21th of Jul 2016 and with benefits input amount of $400 which is used from the withhold limit. The system finds that no counter exists for the combination of limit and claim, so a new counter period (including a counter) is created. Then a new consumption is recorded and the current amount on the limit counter period is updated.
The second claim line processed for the same person has the claim line start date 6th of Aug 2017 and benefits input amount of $300. A counter and a counter period exists, so the new consumption is created for the existing limit counter period. The current amount is updated to $500.
Scenario Ua (Composite Limit)
To clarify the workings of a composite limit when a member switches to a product that counts towards combined network deductible from a product that counts towards IN and OON deductible separately.
The in network deductible limit is configured as:
-
Code: MEM_IN_DED
-
Description: Member In Network Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts per product
-
Maximum (specified on the Product Benefit Specification Limit): $1,000
The out of network deductible limit is configured as:
-
Code: MEM_OON_DED
-
Description: Member Out of Network Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts per product
-
Maximum (specified on the Product Benefit Specification Limit): $2,000
The combined network deductible limit is configured as:
-
Code: MEM_CN_DED
-
Description: Member Combined Network Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts per product
-
Maximum (specified on the Product Benefit Specification Limit): $2000
-
Carry Over Period : 2 Months
-
Sub limits
-
MEM_IN_DED counts across products
-
MEM_OON_DED counts across products
-
A member switches from Plan A (having a product with aggregation level PLAN_A and counting towards IN/OON limits separately) switches to Plan B (having a product with aggregation level PLAN_B and counting towards combined network limit) as of 1st January 2019 .
Suppose the following consumption are present on the IN/OON limits:
| Limit | Service Date | Amount | Aggregation Level |
|---|---|---|---|
MEM_IN_DED |
12-28-2018 |
$100 |
PLAN_A |
MEM_IN_DED |
11-05-2018 |
$350 |
PLAN_A |
MEM_OON_DED |
11-06-2018 |
$200 |
PLAN_A |
Now, suppose a claim is received for the member with a service date of 01-16-2019. This claims gets adjudicated against PLAN B, the limit combined network deductible MEM_CN_DED gets applied. Limit MEM_CN_DED is composite of MEM_IN_DED and MEM_OON_DED and therefore it considers the consumption of these limits for the same member.
Here, limit MEM_CN_DED counts per product, but the sub limits are configured to count across products. Also a carry over period of two months is configured on MEM_CN_DED and therefore MEM_CN_DED sees a total consumption of $650 as of 01-16-2019 (as the consumptions on MEM_IN_DED and MEM_OON_DED fall in the carry over period for MEM_CN_DED). The remaining on the limit MEM_CN_DED as of 01-16-2019 is $1350, against which the claim gets adjudicated.
Alternately, if the sub limits were configured to count per product, then MEM_CN_DED will see the total consumption of $0 as of 01-16-2019 as consumptions of MEM_IN_DED and MEM_OON_DED have a different product aggregation level and no other product carry over is configured.
Scenario Ub (Composite Limit)
To clarify the workings of a composite limit when a member switches to a product that counts towards in and out network deductible separately from a product that counts towards combined network deductible.
The in network deductible limit is configured as:
-
Code: MEM_IN_DED
-
Description: Member In Network Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts per product
-
Maximum (specified on the Product Benefit Specification Limit): $1,000
-
Sub limits
-
MEM_CN_DED counts across products, product provider group status IN
-
The out of network deductible limit is configured as:
-
Code: MEM_OON_DED
-
Description: Member Out of Network Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts per product
-
Maximum (specified on the Product Benefit Specification Limit): $2,000
-
Sub limits
-
MEM_CN_DED counts across products, product provider group status OUT
-
The combined network deductible limit is configured as:
-
Code: MEM_CN_DED
-
Description: Member Combined Network Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts per product
-
Maximum (specified on the Product Benefit Specification Limit): $2000
-
Sub limits
-
MEM_IN_DED counts across products
-
MEM_OON_DED counts across products
-
A member switches from Plan B (having a product with aggregation level PLAN_B and counting towards combined limit) switches to Plan A (having a product with aggregation level PLAN_A and counting towards IN/OON separately limit) as of 1st August 2019 .
Suppose the following consumption are present on the combined limits:
| Limit | Service Date | Amount | Aggregation Level | Provider Group Status |
|---|---|---|---|---|
MEM_CN_DED |
03-18-2019 |
$150 |
PLAN_B |
IN |
MEM_CN_DED |
05-20-2019 |
$250 |
PLAN_B |
IN |
MEM_CN_DED |
06-10-2019 |
$200 |
PLAN_B |
OUT |
Now, suppose first claim is received for the member after the switch with a service date of 09-10-2019. This claims gets adjudicated against PLAN A.
Suppose, if the provider group status gets evaluated to IN, and therefore the MEM_IN_DED gets applied.
Limit MEM_IN_DED is a composite of MEM_CN_DED and it considers the consumption of the sub limit for the same member. Here, MEM_IN_DED is configured to consider the consumptions of MEM_CN_DED with provider group status set to 'IN' and therefore MEM_IN_DED counts a total consumption of $400 as of 09-10-2019.
The remaining on the limit MEM_IN_DED as of 09-10-2019 is $600, against which the claim gets adjudicated.
Scenario Uc (Composite Limit)
To clarify the workings of a composite limit when a member switches from a product that counts towards a service option based limit e.g dental, orthopedic, physiotherapy separately to a product that counts towards a combined limit as a stop limit and service option based limits as continue
The dental cover limit is configured as:
-
Code: MEM_DENTAL_COV
-
Description: Member Dental Cover
-
Action: Cover
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts Across Product
The combined cover limit is configured as:
-
Code: MEM_FLEXI_COVER
-
Description: Member Flexi Cover
-
Action: Cover
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar year
-
Renewal Period: 1 year
-
Counts Across product
-
Sub limits
-
MEM_DENTAL_COV, counts across product
-
The products are configured as:
Product Dental
-
Counts towards MEM_DENTAL_COV, $1500, stop
Product Flexi
-
Counts towards MEM_DENTAL_COV, continue
-
Counts towards MEM_FLEXI_COVER, $4000, stop
A member switches from Plan A (having Dental product) to Plan B (having Flexi product) as of 1st August 2019 .
Suppose the following consumption are present on the dental limits:
| Limit | Service Date | Amount |
|---|---|---|
MEM_DENTAL_COV |
03-18-2019 |
$150 |
MEM_DENTAL_COV |
05-20-2019 |
$250 |
MEM_DENTAL_COV |
06-10-2019 |
$200 |
Suppose the very first claim is received for the member after the switch with a service date of 09-10-2019. This claim gets adjudicated against Plan B.
Limit MEM_FLEXI_COVER is a composite of MEM_DENTAL_COV and it considers the consumption of the sub limit MEM_DENTAL_COV for the same member. The limit MEM_FLEXI_COVER counts a total consumption of $600 as of 09-10-2019. The composite limit will not consider the consumptions of the sub limit(s) that are for the same claim line (i.e. when they count simultaneously) and therefore it ignores a consumption of the MEM_DENTAL_COV for the same claim line when identifying the total consumption.
The remaining on the limit MEM_FLEXI_COVER as of 09-10-2019 is $3400, against which the claim gets adjudicated.
Assuming the claim is for benefits input amount $210 and 100% coverage applies, then the following consumptions are created:
| Limit | Service Date | Amount | Claim Line |
|---|---|---|---|
MEM_DENTAL_COV |
09-10-2019 |
$210 |
Line 1 |
MEM_FLEXI_COVER |
09-10-2019 |
$210 |
Line 1 |
Suppose another claim is received for the member with a service date of 10-01-2019. The limit MEM_FLEXI_COVER will consider all the consumptions of MEM_DENTAL_COV, except the ones which have a reference to the same claim line as its own consumptions. The limit MEM_FLEXI_COVER count a total consumption of $810 as of 10-01-2019. The remaining on the limit MEM_FLEXI_COVER as of 10-01-2019 is $3190, against which the claim gets adjudicated.
Scenario V (Aggregation Level Dynamic Logic Function)
To clarify the purpose of limit consumptions in combination with an aggregation level, consider the following scenario. Person A is subscribed to a product A on the 1st of Jan 2007. Product A deductible of $1500 per person, per year, per diagnosis. The limit is configured as follows:
-
Code: MEM_DED
-
Description: Member Deductible
-
Action: Withhold
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Calendar Year
-
Renewal Period: 1 year
-
Across Products: Yes
-
Aggregation Level Dynamic Logic: DIAG_CODE
The DIAG_CODE dynamic logic function returns the first 3 characters of the primary diagnosis code on the claim line.
The first claim line processed for person A has a claim line with diagnosis code 320.02 and start date on the 2nd of Feb 2007. The claim line uses $300 of the insurable entity deductible. Because no existing limit counter period covers the specified date and aggregation level (320), a new limit counter period (including a limit counter) is created, starting on the 1st of Jan 2007, ending on the 31st of Dec 2007:
After the limit counter period and consumption have been created, the counter period for 1-Jan-2007 through 31-Dec-2007 has a current amount of $300. The second claim line processed for person A has a claim line has diagnosis code 320.09 and start date on the 13th of Aug 2007. The service date is in a period with an existing counter period with the same aggregation level (320), so the consumption is recorded under that counter period:
Once the consumption has been created, the counter period for 1-Jan-2007 through 31-Dec-2007 is updated so that it has a current amount of $800. The third line processed for person A has a claim line start date on the 25th of Oct 2007 and diagnosis code 340.01. Although a counter period exists for 1-Jan-2007 through 31-Dec-2007, a new limit counter period is created starting on the 1st of Jan 2007, ending on the 31st of Dec 2007 because the aggregation level is not the same (340).
Scenario Wa (two cover limits - Amount and Number of Units; Res regime with ind. amount ceiling set to N(o) - ind. number of units ceiling set to Y(es))
| If both a Number of Units cover limit and an Amount cover limit are defined, best practice is to configure the Number of Units limit as first and the Amount limit as second. |
The first cover limit is defined as:
-
Code: HOSPITALIZATION_LIMIT_UNITS
-
Description: Hospitalization Limit Number of Units
-
Action: Cover
-
Level: Insurable Entity
-
Type: Number of Units
-
Reference: Start-of-calendar-year
-
Renewal Period: 1 years
-
Maximum (specified on the Product Benefit Specification Limit): 10
The second cover limit is defined as:
-
Code: HOSPITALIZATION_LIMIT_AMOUNT
-
Description: Hospitalization Limit Amount
-
Action: Cover
-
Level: Insurable Entity
-
Type: Amount
-
Reference: Start-of-calendar-year
-
Renewal Period: 1 years
-
Maximum (specified on the Product Benefit Specification Limit): $50,000
The reservation regime is configured as :
-
Code: REV001
-
Indicator Amount Ceiling: N
-
Indicator Number of Units Ceiling: Y
-
Exceed Label: Reservation withheld
The following claim lines are processed :
| Processing Seq . | Process Type | Res. Regime and Reservation Line | Claim Line Code | Receipt Date | Service Date | Expiration Date | Serviced Person | Benefits input amount | Benefits input number of units |
|---|---|---|---|---|---|---|---|---|---|
1 |
Reservation |
- |
RES001 |
03-10-2017 |
03-03-2017 |
06-30-2017 |
MEM_001 |
$5,000 |
1 |
2 |
Claim |
REV001/RES001 |
CL001 |
03-23-2017 |
03-03-2017 |
- |
MEM_001 |
$8,000 |
1 |
When the reservation line RES001 is processed, it creates two counter periods that covers the service date starting at 01-01-2017 and ending at 12-31-2017. One counter period for the number of units, one for the amount.
First the current number of units on the counter period is set to 1 and the following consumption is created for the number of units limit:
| Amount | Number of Units | Maximum Number | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
0 |
1 |
10 |
06-30-2017 |
Y |
The limit message - 'limit not met' is attached to the reservation line.
Second the current amount on the counter period is set to $5,000 and the following consumption is created for the amount limit:
| Amount | Number of Units | Maximum Amount | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
$5,000 |
0 |
$50,000 |
06-30-2017 |
Y |
The limit message - 'limit not met' is attached to the reservation line.
When CL001 is processed the available room on the Number of Units counter period is 10, that is, the available room on the limit (9) + the available room on the reservation (1). The claim line can register a consumption up to 1 on the reservation. The reservation regime message - 'limit met' and the limit message - 'limit not met' are attached.
| Amount | Number of Units | Maximum Number | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
0 |
1 |
10 |
||
0 |
-1 |
10 |
06-30-2017 |
Y |
The current amount on the Number of Units counter period is set to 1. The available room is 9.
Still processing CL001, the available room on the Amount counter period is $50,000, that is, the available room on the limit ($45,000) + the available room on the reservation ($5,000). The claim line can register a consumption up to $5,000 on the reservation. The reservation regime Amount Ceiling is No and there is availabe room on the counter period so the remaining $3,000 is still covered. The reservation regime message - 'limit met and exceeded' and the limit message - 'limit not met' are attached.
| Amount | Number of Units | Maximum Amount | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
$8,000 |
0 |
$50,000 |
||
-$5,000 |
0 |
$50,000 |
06-30-2017 |
Y |
The current amount on the Amount counter period is set to $8,000. The available room is $42,000.
Scenario Wb (two cover limit - Amount and Number of Units; Res regime with ind. amount ceiling set to N(o) - ind. number of units ceiling set to Y(es))
Same situation as for scenario Wa but the benefits input number of units on the claim line is 2. Note that the benefits input amount has doubled, the price per unit is still $8,000.
The following claim lines are processed :
| Processing Seq . | Process Type | Res. Regime and Reservation Line | Claim Line Code | Receipt Date | Service Date | Expiration Date | Serviced Person | Benefits input amount | Benefits input number of units |
|---|---|---|---|---|---|---|---|---|---|
1 |
Reservation |
- |
RES001 |
03-10-2017 |
03-03-2017 |
06-30-2017 |
MEM_001 |
$9,000 |
1 |
2 |
Claim |
REV001/RES001 |
CL001 |
03-23-2017 |
03-03-2017 |
- |
MEM_001 |
$16,000 |
2 |
When the reservation line RES001 is processed, it creates two counter periods that cover the service date starting at 01-01-2017 and ending at 12-31-2017. One counter period for the number of units, one for the amount.
First the current number of units on the counter period is set to 1 (reservation) and the following consumption is created for the number of units limit:
| Amount | Number of Units | Maximum Number | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
0 |
1 |
10 |
06-30-2017 |
Y |
The limit message - 'limit not met' is attached to the reservation line.
Second the current amount on the counter period is set to $9,000 (reservation) and the following consumption is created for the amount limit:
| Amount | Number of Units | Maximum Amount | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
$9,000 |
0 |
$50,000 |
06-30-2017 |
Y |
The limit message - 'limit not met' is attached to the reservation line.
When CL001 is processed the available room on the Number of Units counter period is 10, that is, the available room on the limit (9) + the available room on the reservation (1). The claim line wants to register a consumption of 2 but can only register a consumption up to 1 due to the ceiled reservation.
The reservation regime message - 'limit met and exceeded' and the limit message - 'limit not met' are attached.
| Amount | Number of Units | Maximum Number | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
0 |
1 |
10 |
||
0 |
-1 |
10 |
06-30-2017 |
Y |
The current amount on the Number of Units counter period is set to 1. The available room is 9. There is no reservation number of units left.
As the system covers only half of the units (1 instead of 2), it will withold also half of the amount ($8,000) and try to cover the other half.
Still processing CL001, the available room on the Amount counter period is $50,000, that is, the available room on the limit ($41,000) + the available room on the reservation ($9,000). The claim line can register a consumption of $8,000 on the $9,000 reservation; the amount for the 1 unit is covered. The reservation regime message - 'limit not met' and the limit message - 'limit not met' are attached.
| Amount | Number of Units | Maximum Amount | Expiration Date | Indicator Reserved |
|---|---|---|---|---|
$8,000 |
0 |
$50,000 |
||
-$8,000 |
0 |
$50,000 |
06-30-2017 |
Y |
The current amount on the Amount counter period is set to $8,000. The available room is $42,000.
Note that there still is an amount reservation of $1,000 and the cover limit still allows $42,000 consumption and the amount reservation has no ceiling. However the system will not use these amounts because the number of units has reached its (reservation) maximum.