Premium Calculation Overview
This guide describes the steps and logic that the system applies to calculate premium. To determine the resulting premium amount, the activity evaluates settings on the premium schedules, surcharge and adjustment schedules, policies, group account and enrollment products. This guide explains how those settings affect the calculation by walking through each of the steps in the calculation flow, accompanied by a series of clarifying examples.
This first chapter briefly introduces the concepts that apply during the premium calculation. The subsequent chapters of this guide explain the concepts in greater detail.
Calculation Periods
Calculation periods represent the time demarcations over which a calculation applies.
System Calculation Periods and Policy Calculation Periods
OHI Enterprise Policy Administration supports two kinds of calculation periods, system calculation periods policy calculation periods.
System calculation periods are fixed periods of time that apply to every policy in the system. Although system calculation periods can be configured to span any length of time, they are typically set up as calendar months.
Policy Calculation Periods are periods that reflect the collection settings for a specific policy. The collection settings can be specified on multiple levels: policy, group account or group client. The system generates policy calculation periods based on the collection settings of the policy and automatically determines their effective time span. Changes on the collection settings may result in the need to re-generate the policy calculation periods.
The policy’s collection setting specifies if the premium calculation for a policy uses system calculation periods or policy calculation periods.
Effective Date
Calculating the appropriate premium for a policy requires the evaluation of many data elements. These could be attributes on the member record, the policy record, and the configuration settings. Each of these data elements has its own effective date span, and these spans will often not align with the calculation period. For example, the premium listed for persons younger than 18 could be different from the premium listed for persons of age 18 and older. So what happens if a person turns 18 halfway through the month of March - assuming the calculation periods equal calendar months?
To make sure a calculation always uses a consistent representation in time of these data elements, each calculation period has a single reference day. The calculation evaluates and applies all time-effective data for this date. A typical configuration specifies the reference day as the first day of the calculation period, that is in most cases the first day of the calendar month.
Previous and Future Calculation Periods
When the system calculates premium, it always does so for a specific calculation period, for example, the premium calculation for April 2015. This means the system will calculate all premium up to and including April 2015. It could mean the system also has to (re)calculate past calculation periods, e.g, for March, or even future calculation periods, because the policyholder chose to pre-pay the entire second quarter of the calendar year. Determining the appropriate periods to calculate is transparent to the user; the system simply does all the calculations for all the relevant periods to determine all the appropriate premiums.
Partial Enrollment
One of the most significant calculation scenarios is where a policyholder terminates the enrollment half-way through a calculation period. The system offers a number of settings for such partial enrollments:
- No Charge
-
The system ignores partial enrollment entirely, charging no premium at all,
- Full Period
-
The system treats partial enrollment as though the member enrolled for the full period,
- Per Day
-
The system calculates the premium only for the days the member actually enrolled,
- Enrolled Days Threshold
-
The system applies Full Period if the enrolled days threshold is met, and applies No Charge if the enrolled days threshold is not met.
Calculation Methods
The application supports four methods of calculation.
Based on Calculation Period
This method applies all premiums, adjustments and surcharges per calculation period. This means that all calculations for partial enrollment, rounding, and so on, are contained within the calculation period. For example, if a person terminates enrollment 10 days into the calculation period, then the calculated premium is multiplied by 10 and divided by the total number of days in the calculation period.
The Calculation Period based calculation method is only available for System Calculation Periods, not for Policy Calculation Periods [1].
See Calculation Period Based Calculations for more details.
Based on Contract Period
This method of calculation applies all premiums, adjustments and surcharges per contract period, possibly spanning multiple calculation periods.
This calculation method is significantly more complex because partial enrollment can have consequences for all the calculation periods in the contract period.
For example, consider a contract based policy where the contract follows the calendar year (1st of January - 31st of December). The calculation periods follow the calendar months.
The yearly premium is 1,200.00.
Within this contract a person enrolls from the 1st of January through the 28th of February in a non-leap year.
Now how should the calculation map the 1,200.00 to the two calculation periods?
Evenly or Daily Distribution
Should the calculation distribute the premium evenly over the days in the year or evenly over the calculation periods in the year?
Distributing the premium evenly over the days in the year results in a transparent calculation, but also results in a different premium amount each month, as the number of days per calendar month varies. In our example for January 1,200.00 / 365 days * 31 days = 101.92 and for February 1,200.00 / 365 days * 28 days = 92.06.
Distributing the premium evenly over the calculation periods in the year results in the same premium amount for all calculation periods. In our example that is a premium of 100.00 per calendar month. If a person stays enrolled the entire calendar year this also adds up to 1,200.00.
OHI Enterprise Policy Administration supports both kinds of distributions,'Daily' for an evenly ditribution per day, and 'Evenly' for an evenly distribution per calculation period. The system allows setting this amount distribution per enrollment product.
| Evenly distribution does not apply to partially enrolled calculation periods unless the partial period resolution is Full Period. |
Settling
The person was enrolled for two full months, so - according to the settings - the charged premium should be twice the monthly premium of 100.00, amounting to a total of 200.00. However, the person has only been enrolled for 59 days. Those 59 days, divided by the 365 days in the year, and multiplied by the year premium of 1,200.00, actually amount to a premium of 193.97.
The system will detect this scenario (assuming this is in fact desired and so configured) and recalculate to make sure only 193,97 is charged, instead of 200.00. This scenario is referred to as 'settling'. The last calculation in a contracted period always triggers the system to make sure the sum of the premiums charged in the (past) individual calculations is equal to the premium specified for the entire contracted period.
See Contract Period Based Calculations for more details.
Based on Calendar Year
This method of calculation applies all premiums, adjustments and surcharges per calendar year, also spanning multiple calculation periods. It is similar to the contract period based method, except that it does not perform settling.
See Calendar Year Based Calculations for more details.
Based on Days
The fourth method of calculation computes a daily premium based on the definition of the premium schedule. The system calculates the premium by multiplying the number of enrolled days in a calculation period by the daily premium amount. This method also does not perform settling.
See Day Based Calculations for more details.
Calculation Breakdown
The system uses parallel processing to calculate premium. When the user starts the premium calculation, the system will break that calculation down into smaller pieces that can be executed in parallel. First the system starts a separate calculation thread for each combination of brand and group account. Then, for each of these combinations, the system starts a separate calculation threads for each policy that belongs to that specific group account and brand.
A user can only start premium calculation at the highest level. Input parameters allow the user to filter the set of policies to calculate to, for example, the brand, the group client, or the group account of the policy. The Calculation Input Date parameter, restricts the premium calculation to only calculate the amounts that are relevant for that date.
In addition, the system checks every policy if it really needs calculation. Is the policy approved? Did somebody change the policy and does that change require a new calculation? Has something in the configuration data around the policy changed, for example the premium, that requires a new calculation?
See Calculate Premium for more details on the premium calculation.
Recalculation - Change Event Rules
Many of the data elements that the system evaluates in the premium calculation can be changed retroactively. Consider a person address change that is processed with a 3 month delay. Such a change could invalidate the results of past calculations and require the system to recalculate the results for those periods. But only if the person’s address is actually relevant in the premium calculation.
To ensure that the system handles retroactive changes appropriately, the user sets up change event rules. These change event rules tell the system which records and data elements to monitor, and, if their value should change, which periods should be recalculated. These could be rules both on operational data (policies, persons) or on configuration (premium schedules, adjustment rules).
For each of the change event rules the user needs to choose a setting for the effective date. This is the date that tells the system how far back it needs to recalculate. The appropriate setting depends on the specific change that the event rule is monitoring. For example, if a person retroactively terminates his or her enrollment, the termination date is the effective date. However, if the person updates a data element on the enrollment record, the start date of the enrollment is the effective date.
A retroactive change to a policy attribute only affects that particular policy. A retroactive change to a configuration setting can actually affect a large number of policies. The system takes care of this by tracing all policies that make use of that changed configuration setting and making sure they are all selected for recalculation.
See Change Event Rules for more details on change event rules
Calculation Results
The system stores the results of each calculation. These calculation result records specify all the relevant totals for the premium (premium, surcharge, adjustment), and they also contain a detailed breakdown of the intermediate results. This break-down shows which adjustment rules were applied, which surcharge rules were applied but also the amounts and / or percentages used to determine the intermediate result.
The calculation result details also show how the system dealt with partial enrollment and keeps copy of the relevant system settings that were used to come to the calculation result.