|
Insurance Abstract
A data processing system for accurately calculating a discount in
a medical insurance plan comprises a premiums module adapted to
access data regarding the amount of premiums paid by a policyholder
of the medical insurance plan for a predetermined period. A claims
module is adapted to access data regarding the amount of claims
paid by the medical insurance plan to the policyholder for the predetermined
period, the claims module being further adapted to access data to
determine if there have been any claims submitted by a policyholder
which have not yet been paid, and if so to apply a set of rules
to each submitted claim which has not been paid to determine if
it is likely to be paid, and if the claim is likely to be paid then
adding the amount of the claim to the amount of claims already paid
for the predetermined period. Finally, a discount module adapted
to receive data from the premiums module and the claims module and
to use the data to calculate a discount amount.
Insurance Claims
1. A data processing system for accurately calculating a discount
in a medical insurance plan, the system comprising: a premiums module
adapted to access data regarding the amount of premiums paid by
a policyholder of the medical insurance plan for a predetermined
period, a claims module adapted to access data regarding the amount
of claims paid by the medical insurance plan to the policyholder
for the predetermined period, the claims module being further adapted
to access data to determine if there have been any claims submitted
by a policyholder which have not yet been paid, and if so to apply
a set of rules to each submitted claim which has not been paid to
determine if it is likely to be paid, and if the claim is likely
to be paid then adding the amount of the claim to the amount of
claims already paid for the predetermined period; and a discount
module adapted to receive data from the premiums module and the
claims module and to use the data to calculate a discount amount.
2. A system according to claim 1 further comprising an incentive
scheme module adapted to access data regarding the level of the
policyholder in an incentive scheme and to use this data to calculate
the discount amount.
3. A system according to claim 1 wherein the discount module is
adapted to check the data received from the premiums module and
the claims module.
4. A system according to claim 1 wherein the claims module is further
adapted to determine if there have been any claims authorised for
a policyholder which have not yet been claimed, and if so to apply
a set of rules to determine the likely amount of the authorised
claim and then add the likely amount of the claim to the amount
of claims already paid for the predetermined period.
5. A system according to claim 1 wherein the premiums module is
adapted to determine if the amount of premiums paid by the policyholder
of the medical insurance plan for the predetermined period was a
discounted amount, and if so to calculate a notional amount being
the amount the policyholder would have paid if they were not awarded
a discount, wherein the notional amount is used to calculate the
discount amount.
6. A system according to claim 1 wherein the claims module is adapted
to compare the number of claims submitted by a policyholder to the
number of claims submitted by a policyholder in a previous time
period as a further error check.
7. A system according to claim 1 wherein the premium module is
adapted to use the calculated discount to calculate a premium for
the policyholder for the coming year.
8. A machine-readable medium comprising instructions, which when
executed by a machine, cause the machine to perform a method of
calculating a discount in a medical insurance plan, the method comprising:
accessing premiums data regarding the amount of premiums paid by
a policyholder of the medical insurance plan for a predetermined
period, accessing claims data regarding the amount of claims paid
by the medical insurance plan to the policyholder for the predetermined
period; accessing further claims data to determine if there have
been any claims submitted by a policyholder which have not yet been
paid, and if so to apply a set of rules to each submitted claim
which has not been paid to determine if it is likely to be paid,
and if the claim is likely to be paid then adding the amount of
the claim to the amount of claims already paid for the predetermined
period; and using the data accessed to calculate a discount amount.
9. A machine-readable medium according to claim 8 comprising instructions,
which when executed by a machine, cause the machine to perform a
method of calculating a discount in a medical insurance plan, the
method further comprising accessing data regarding the level of
the policyholder in an incentive scheme and using this data to calculate
the discount amount.
10. A machine-readable medium according to claim 8 comprising instructions,
which when executed by a machine, cause the machine to perform a
method of calculating a discount in a medical insurance plan, the
method further comprising checking the data received from the premiums
module and the claims module.
11. A machine-readable medium according to claim 8 comprising instructions,
which when executed by a machine, cause the machine to perform a
method of calculating a discount in a medical insurance plan, the
method further comprising determining if there have been any claims
authorised for a policyholder which have not yet been claimed, and
if so to apply a set of rules to determine the likely amount of
the authorised claim and then adding the likely amount of the claim
to the amount of claims already paid for the predetermined period.
12. A machine-readable medium according to claim 8 comprising instructions,
which when executed by a machine, cause the machine to perform a
method of calculating a discount in a medical insurance plan, the
method further comprising determining if the amount of premiums
paid by the policyholder of the medical insurance plan for the predetermined
period was a discounted amount, and if so to calculate a notional
amount being the amount the policyholder would have paid if they
were not awarded a discount, wherein the notional amount is used
to calculate the discount amount.
13. A machine-readable medium according to claim 8 comprising instructions,
which when executed by a machine, cause the machine to perform a
method of calculating a discount in a medical insurance plan, the
method further comprising comparing the number of claims submitted
by a policyholder to the number of claims submitted by a policyholder
in a previous time period as a further error check.
14. A method of calculating a discount in a medical insurance plan,
the method comprising: accessing premiums data regarding the amount
of premiums paid by a policyholder of the medical insurance plan
for a predetermined period, accessing claims data regarding the
amount of claims paid by the medical insurance plan to the policyholder
for the predetermined period; accessing further claims data to determine
if there have been any claims submitted by a policyholder which
have not yet been paid, and if so to apply a set of rules to each
submitted claim which has not been paid to determine if it is likely
to be paid, and if the claim is likely to be paid then adding the
amount of the claim to the amount of claims already paid for the
predetermined period; and using the data accessed to calculate a
discount amount.
15. A method according to claim 14 further comprising accessing
data regarding the level of the policyholder in an incentive scheme
and using this data to calculate the discount amount.
16. A method according to claim 14 further comprising checking
the data received from the premiums module and the claims module.
17. A method according to claim 14 further comprising determining
if there have been any claims authorised for a policyholder which
have not yet been claimed, and if so to apply a set of rules to
determine the likely amount of the authorised claim and then adding
the likely amount of the claim to the amount of claims already paid
for the predetermined period.
18. A method according to claim 14 further comprising determining
if the amount of premiums paid by the policyholder of the medical
insurance plan for the predetermined period was a discounted amount,
and if so to calculate a notional amount being the amount the policyholder
would have paid if they were not awarded a discount, wherein the
notional amount is used to calculate the discount amount.
19. A method according to claim 14 further comprising comparing
the number of claims submitted by a policyholder to the number of
claims submitted by a policyholder in a previous time period as
a further error check.
Insurance Description
BACKGROUND OF THE INVENTION
[0001] This invention relates to a data processing system for accurately
calculating a policyholder's discount in a medical insurance plan
and to a method therefor.
[0002] Good management of a medical insurance plan, typically a
private medical insurance plan, is obviously important to the plan
managers to ensure the ongoing financial viability of the plan.
However, in recent years, in some countries, there has been a change
in the management of a medical insurance plan to focus on the policyholders
of the plan and to encourage the policyholders of the plan to stay
healthy. To date, this has not been a discernible trend in the United
Kingdom.
[0003] Examples of the developments in this area are described
in South African patents numbers 99/1746 and 2001/3936, the contents
of which are incorporated herein by reference.
[0004] Another method of managing a medical insurance plan that
is focused on encouraging the policyholders of the plan to manage
their claims is to offer the policyholders a discount based on the
mount of premiums paid to the medical insurance plan, the amount
of claims made from the medical insurance plan and possibly the
level of the policyholder in an incentive scheme associated with
the insurance plan. This approach addresses two latent problems
inhering in insurance in general, namely moral hazard, whereby policyholders
may be incentivised to claim and adverse selection, whereby high-risk
individuals are attracted to purchase the insurance plan. In addition,
the approach mitigates the tendency in private medical insurance
to reward sickness.
[0005] However, the practical implementation of such a method poses
technical difficulties as it is not simple to determine the amount
of premiums paid to the medical insurance plan and the amount of
claims made from the medical insurance plan. This is because the
amount of premiums paid can change suddenly if a policyholder changes
their plan options, for example. Also, the amount of claims made
can vary if there are claims which have been submitted but have
not yet been processed or if there are claims which are under dispute,
for example. Simply to take a snapshot of how much premiums has
been paid in a given period and how many claims have been paid out
to the policyholder would not give accurate amounts for use in determining
an appropriate discount.
[0006] The present invention provides a data and rules processing
system for accurately calculating a policyholder's discount in a
medical insurance plan and to a method therefor.
SUMMARY OF THE INVENTION
[0007] According to one embodiment of the invention there is provided
a data processing system for accurately calculating a discount in
a medical insurance plan, the system comprising: [0008] a premiums
module adapted to access data regarding the amount of premiums paid
by a policyholder of the medical insurance plan for a predetermined
period, [0009] a claims module adapted to access data regarding
the amount of claims paid by the medical insurance plan to the policyholder
for the predetermined period, the claims module being further adapted
to access data to determine if there have been any claims submitted
by a policyholder which have not yet been paid, and if so to apply
a set of rules to each submitted claim which has not been paid to
determine if it is likely to be paid, and if the claim is likely
to be paid then adding the amount of the claim to the amount of
claims already paid for the predetermined period; and [0010] a discount
module adapted to receive data from the premiums module and the
claims module and to use the data to calculate a discount amount.
[0011] In another embodiment a machine-readable medium comprising
instructions, which when executed by a machine, cause the machine
to perform a method of calculating a discount in a medical insurance
plan, the method comprising: [0012] accessing premiums data regarding
the amount of premiums paid by a policyholder of the medical insurance
plan for a predetermined period, [0013] accessing claims data regarding
the amount of claims paid by the medical insurance plan to the policyholder
for the predetermined period; [0014] accessing further claims data
to determine if there have been any claims submitted by a policyholder
which have not yet been paid, and if so to apply a set of rules
to each submitted claim which has not been paid to determine if
it is likely to be paid, and if the claim is likely to be paid then
adding the amount of the claim to the amount of claims already paid
for the predetermined period; and [0015] using the data accessed
to calculate a discount amount.
[0016] In a further embodiment a method of calculating a discount
in a medical insurance plan, the method comprising: [0017] accessing
premiums data regarding the amount of premiums paid by a policyholder
of the medical insurance plan for a predetermined period, [0018]
accessing claims data regarding the amount of claims paid by the
medical insurance plan to the policyholder for the predetermined
period; [0019] accessing further claims data to determine if there
have been any claims submitted by a policyholder which have not
yet been paid, and if so to apply a set of rules to each submitted
claim which has not been paid to determine if it is likely to be
paid, and if the claim is likely to be paid then adding the amount
of the claim to the amount of claims already paid for the predetermined
period; and [0020] using the data accessed to calculate a discount
amount.
BRIEF DESCRIPTION OF THE DRAWINGS
[0021] FIG. 1 is a schematic representation of a discount methodology
in a medical insurance scheme;
[0022] FIG. 2 is a schematic representation of a system according
to the present invention used to implement the discount methodology
illustrated in FIG. 1;
[0023] FIG. 3 is a schematic representation of an incentive system
used together with a medical insurance scheme; and
[0024] FIG. 4 is a schematic representation of the actions taken
by a discount calculation program to obtain data from various sources
required to perform the calculation.
DESCRIPTION OF PREFERRED EMBODIMENTS
[0025] Referring to South African patents numbers 99/1746 and 2001/3936,
the contents of which are incorporated herein by reference, these
documents describe a method of managing a medical insurance plan
wherein a plurality of health-related facilities and or services
are offered to policyholders of the medical insurance plan. The
patents list a number of health-related facilities and/or services,
examples of which are an approved health club or gymnasium, a weight-loss
programme or a smoke ender programme. Use of the facilities and/or
services by policyholders is monitored and points are awarded to
a policyholder for using the facilities and/or services. The following
table summarises examples of points-earning activities: TABLE-US-00001
Detailed Points Category category/activity Eligibility awarded Frequency
Fitness Gym workout Any 5 per workout Fitness assessment Any 75
per assessment Organised fitness Any 20 per event event Healthy
Being a non-smoker Any 250 per year choices declaration made If
a smoker, joining Any 150 per event a smoke-ender program Reading
self help Any 10 per article articles Online risk Any 25 per assessment
assessment Completing a first Any 30 points earned aid course in
each of the two years Passing an online Any 40 per event health
information quiz Stress centre Any 25 per assessment Preventative
Regular checkups <12 250 per event measures for child, baby years
Completed <24 200 per event vaccinations months Mammogram women
> 250 per event 45 years Glaucoma testing >40 250 points in
each years of the two years Glucose testing >40 250 points in
each years of the two years Dental checkups Any 150 per event Pap
smears women > 250 per event 16 years Cholesterol men >35,
250 points in each screening women > of the five 45 years Prostate
screening men >50 250 per event Use Any 20 per event online/telephone
GP Flu vaccination Any 150 per event Nutrition Online nutrition
Any 10 per article articles Creating healthy Any 30 per event meal
plan online Results Maintaining fitness Any 30 per level rating
maintained Improving fitness Any 50 per level rating improved Maintaining
target Any 30 per level BMI band maintained Improving target Any
50 per level BMI band improved Maintaining body Any 30 per level
fat target maintained Improving body fat Any 50 per level target
improved Maintaining blood Any 30 per level pressure maintained
Improving blood Any 50 per level pressure improved No sick days
off Any 200 per year work bonus achieved Carryovers Total points
end of second year . . . third 10% . . . fourth 15% . . . fifth+
20%
[0026] Further, as described in these patents, a plurality of status
levels in an incentive scheme are defined which are described in
these patents as blue, bronze, silver and gold. Depending on the
number of points a policyholder is awarded, one of these status
levels are allocated to the policyholder so that the policyholder's
status level is essentially according to the use of the facilities
and or services.
[0027] Finally, a reward is allocated to the policyholders depending
on their status level. However, the rewards contemplated in these
patents do not always motivate policyholders.
[0028] Premiums for most medical insurance plans rise each year
to keep pace with inflation and this is irrespective of whether
or not the policyholder claims from the medical insurance plan.
Thus, another method of motivating policyholders would be to provide
the policyholder's with a discount which either takes the form of
a cash-back bonus or of a decrease in the premiums payable for the
medical insurance plan for a future period of time.
[0029] According to the present invention, the amount of claims
from the medical insurance plan that a policyholder makes, together
with the policyholder's status level in the incentive scheme are
used to determine the policyholder's premium payable in the coming
year.
[0030] For example, referring to FIG. 1, a married man aged 36
living in London covering his spouse and two children could expect
to pay about .English Pound.80 per month. That's p=.English Pound.960
in a full year. If we assume he claims .English Pound.428 during
the year for private consultations, that means the amount potentially
available as a discount off next year's premium, is .English Pound.532
(.English Pound.672-.English Pound.428).
[0031] If the incentive scheme is also used then the actual percentage
of the .English Pound.532 that is applied as a discount from the
following year's premium depends on how actively the policyholder
looked after their health. From a minimum of 25% right up to the
full .English Pound.532. Thus a full 100% of the amount could be
applied to reduce the subsequent year's premium. Alternatively,
the policyholder can take 50% of the discount in cash.
[0032] In this scenario, whether its nearer the 25% or the 100%
discount level depends entirely on the policyholder's status. Everyone
starts as a Bronze policyholder and even if they do not do anything
further to improve their health they will always be entitled to
the Bronze policyholder discount rate of 25%. So in the example
above a policyholder would always qualify for .English Pound.133
off the following year's premium. But with a little effort a policyholder
could enjoy Gold or Platinum status with discounts of up to 100%
as can be seen from the exemplary table below: TABLE-US-00002 Discount
rate (%) Points required Bronze 35 Nil Silver 50 1500 Gold 75 2500
Platinum 100 3200
[0033] In essence, the method of managing a medical insurance plan
described above is focused on the policyholder and incentivises
the policyholder to look after their health.
[0034] In order to implement the abovementioned method, it is necessary
to provide a data processing system which is able to calculate the
discount.
[0035] However, the practical implementation of such a method poses
technical difficulties as it is difficult to determine the amount
of premiums paid to the medical insurance plan and the amount of
claims made from the medical insurance plan. This is because the
amount of premiums paid can change suddenly if a policyholder changes
their plan options, for example. Also, the amount of claims made
can vary if there are claims which have been submitted but have
not yet been processed or if there are claims which are under dispute,
for example. Simply to take a snapshot of how much premiums have
been paid in a given period and how many claims have been paid out
to the policyholder would not give accurate amounts for use in determining
an appropriate discount.
[0036] The present invention is implemented in a machine in the
exemplary form of a computer system within which a set of instructions,
for causing the machine to perform the methodology of the present
invention. In alternative embodiments, the machine operates as a
standalone device or may be connected (e.g., networked) to other
machines. In a networked deployment, the machine may operate in
the capacity of a server or a client machine in server-client network
environment, or as a peer machine in a peer-to-peer (or distributed)
network environment. The machine may be a server computer or any
machine capable of executing a set of instructions (sequential or
otherwise) that specify actions to be taken by that machine. Further,
while only a single machine may be referred to below, the term "machine"
shall also be taken to include any collection of machines that individually
or jointly execute a set (or multiple sets) of instructions to perform
any one or more of the methodologies discussed herein.
[0037] The exemplary computer system will typically includes a
processor (e.g. a central processing unit (CPU) a graphics processing
unit (GPU) or both), a main memory and a static memory, which communicate
with each other via a bus. The computer system may further include
a video display unit (e.g. a liquid crystal display (LCD) or a cathode
ray tube (CRT)). The computer system also includes an alphanumeric
input device (e.g., a keyboard), a cursor control device (e.g. a
mouse), a disk drive unit, a signal generation device (e.g. a speaker)
and a network interface device.
[0038] The disk drive unit includes a machine-readable medium on
which is stored one or more sets of instructions (e.g. software)
embodying any one or more of the methodologies or functions described
herein. The software may also reside, completely or at least partially,
within the main memory and/or within the processor during execution
thereof by the computer system, the main memory and the processor
also constituting machine-readable media.
[0039] The software may further be transmitted or received over
a network via the network interface device.
[0040] While the machine-readable medium is shown in an exemplary
embodiment to be a single medium, the term "machine-readable
medium" should be taken to include a single medium or multiple
media (e.g., a centralized or distributed database, and/or associated
caches and servers) that store the one or more sets of instructions.
The term "machine-readable medium" shall also be taken
to include any medium that is capable of storing, encoding or carrying
a set of instructions for execution by the machine and that cause
the machine to perform any one or more of the methodologies of the
present invention. The term "machine-readable medium"
shall accordingly be taken to include, but not be limited to, solid-state
memories, optical and magnetic media, and carrier wave signals.
[0041] Referring to FIG. 2, the machine implemented present invention
includes a premiums module 10, a claims module 12 and possibly an
incentive module 14. All of these are operatively connected to a
discount module 16 which calculates the calculated discount 18.
[0042] Furthermore, the abovementioned modules may form part of
a larger system which implements the medical insurance plan.
[0043] Referring first to the premiums module, it will be appreciated
that the premiums paid could be calculated for any predetermined
period, for example monthly, quarterly, biannually or annually.
It is envisaged that in a preferred embodiment, the premiums payable
will be calculated annually. In this case, the prior predetermined
period will be the previous year.
[0044] The premium on a policy is calculated when it is first created.
Additionally, a recalculation occurs for certain subsequent changes
to the policy. The premium calculation will generate a change in
the premium based on the effective date of the administration change.
[0045] Additional complexities arise in the context of insurance
plans sold to a group of individuals through their employer. Such
plans differ in premiums and applicable benefits compared plans
sold to an individual. A key feature of administration in these
cases is to provide employers with an option of covering only a
portion of a policyholder's insurance contribution, also known as
"split" or "flexible" billing. This is essentially
a means of splitting the premium for each policyholder between employer
and employee as a fixed percentage, or some other mathematical function.
The split may also be based on the policyholder's dependants, with
the employer opting to cover a percentage of the relevant premium/s.
Additionally, employers may pay for cover under a certain plan,
leaving the employee to upgrade if they desire, and to pay the difference.
Either way, premiums paid by the employee are deducted from salary
by the employer where the employer may receive a discretionary discount
as a result of performing this collection function. All records
of such transactions are accounted for within the calculation system.
[0046] The premiums module 16 is designed to "split"
the overall premium into portions for the various paying parties,
such as the policyholder portion, employer portion etc. This calculation
is based on a combination of data and rules in accordance with the
above description. These rules are summarized below: [0047] 1) The
calculation ascertains the billing category and benefit plan being
referenced from policyholder data. An additional rule determines
the subsequent action sequence based on possible permutations of
this data [0048] 2) Each step is then processed in the order paying
party, premium component, split sequence [0049] 3) The step is applied
to each premium amount of the same component, applied to premium
amounts of the same type for each dependent [0050] 4) The split
amount is calculated according to the rule definition as set up
for the specific employer. This could simply be a user specified
amount, or a percentage of this premium amount or more complex types
like table look ups, carried over values etc. [0051] 5) Based on
the hierarchy defined for each component, the dependant amount types
for the same component and party are calculated. Their split amount
for this party is calculated in the same ratio as in the as for
the principal policyholder [0052] 6) For the "parents"
of premium sub-components, each amount calculated is added to a
running total, so that the rule that the parents amount equals the
sum of the child amounts for the same party is enforced. Generic
Definition of Premium Components
[0053] The core of the premium calculation function rests within
data and systems, and is designed to furnish real-time individual
and cumulative premium contributions for a given period. Rates tables
are stored and referenced to determine the applicable rate for the
policyholder for whom the calculation has been invoked. These premium
rates are determined according to various policyholder choices,
including: [0054] 1) Plan choice [0055] 2) Age of the policyholder
[0056] 3) Status of the policyholder [0057] 4) Smoker/non-smoker
status [0058] 5) Hospital accommodation grade [0059] 6) Location
of hospital (inside/outside London)
[0060] A risk factor is then incorporated to this premium rate
based once again on policyholder choice such as excess level, grade
of hospital accommodation etc. The calculation of this risk factor
may result in a risk loading onto the premium rates determined above.
The newly adjusted premium amount is then also subject to additional
premium loadings such as insurance premium tax. Each of these loadings
will be stored as their own separate components in the premium breakdown,
so that they can be disclosed separately where needed. All of the
above is stored and calculated automatically based on choices made
by the policyholder as an input into the new business application
process. Changes to any of the above components can be done effective
any day of the month and thus premiums can change based on an `any-date`
basis.
[0061] The flexibility of the design extends to a means of specifying
generic types of premium component such as "risk premium",
"administration fee", "expense allowance". Sub-components
may be generated according to the templates for each parent type.
The Low claims Bonus is configured to either include or exclude
various component types from its premium calculations.
[0062] Referring now to the calculation of the claims amount, since
there are many steps in processing claims from receipt through to
resolution, the system of the medical insurance plan is predicated
on obtaining identification of a claim as soon as it has been received.
The tasks of capturing the claims is thus split into "header
capture" phase and "line capture" phase with the
former allowing tracking of claims processing to proceed even though
not all data has been electronically captured.
[0063] The medical insurance system also contains modules to render
claims into a standard captured format. This enables claims to be
identified as soon as possible regardless of receipt method. A claim
may be received through mail, email. Fax, hand-delivery or electronically.
[0064] The system has been designed to automatically insert the
image of a claim into a workflow pipeline. In order to do this,
a context for the claim must first be derived. Since all claims
require pre-authorisation, the goal of this step is to find the
corresponding authorisation data, and to perform a series of automated
data comparisons. At authorisation time the following data will
have been obtained from a notifying party: identification of policyholder,
identification of clinical consultant or hospital, set of clinical
codes representing the clinical criteria against which authorisation
is granted, and the expected dates and times of clinical treatments.
(In complex cases this data may be modified subsequent to authorisation
as a function of case management and other communications).
[0065] The contextualisation of the claim is then a means of matching
data on that claim with a pre-existing data set. In many cases,
this match will not be exact, and a series of rules is required
to automatically perform the association. These rules are based
on the following set of criteria: [0066] A clinical code does not
match the expected set of codes, but may still be valid for a number
of reasons (the code could be clinically similar, or may be coded
in diagnosis--rather than procedure-format) [0067] The service provider
may in some way be affiliated to the expected provider: e.g. same
hospital group, or doctors who work both individually and in partnership
[0068] Identifiers of policyholders and doctors could be incorrect
or incomplete
[0069] Cases like these may be automatically or partially resolved
based on the firing of a series of rules within the rule base.
[0070] In other cases, a separate set of rules may be applied instead:
for example, the clinical codes may be missing, but the claim may
be on a case basis only. The system will perform this and other
checks in order to determine if the case claim can proceed despite
missing data. In all cases there is a defined minimal data set without
which the claim cannot be contextualised.
[0071] If none of the rules are able to perform the association
categorically, the system can route the claim to a party capable
of performing this association.
[0072] Immediate adjudication on a captured claim is subject to
a wide number of rules incorporated into the system's data and algorithms.
The schematic below shows the adjudication rules within the context
of the overall claims pipeline.
[0073] A formatted text version of the invoice is captured from
an image of the original invoice. Details captured include the provider,
policyholder, service dates, procedures and claimed amounts.
The following is then checked for:
[0074] 1. Provider is registered, active and has not been marked
for fraud. [0075] 2. Membership and dependant exists, is not suspended.
[0076] 3. Procedure codes exist and are appropriate for the billing
provider
[0077] If the service date falls within the admission and discharge
dates of an approved hospitalisation for a particular dependent,
the invoice is linked to the event.
[0078] The maximum tariff and the agreed/standard tariff are determined
per line of the invoice. Rules concerning how much to pay are always
with reference to these maxima and tariff rates. The tariff calculation
is influenced by factors such as the procedure done, the provider
and his network agreements.
[0079] The system checks that the invoice has not been paid previously,
before funding the current invoice. The criteria for deciding that
a line of the invoice is a true duplicate of a previously paid line
currently varies per medical specialty. For example, the procedure
code, provider, policyholder, dependant and service date must all
match across two GP invoice lines before they are considered to
be true duplicates, but for pathology invoices, the dependant number
is not relevant. True duplicates are rejected automatically.
[0080] Invoice lines are rejected if clinical billing rules are
violated within an invoice. For example there may be two pathology
procedure codes. One procedure code is for a set of tests, while
the second procedure code is for a particular test that is included
in the set of tests under the first procedure code. It is incorrect
for the provider to bill both procedures on an invoice.
[0081] When a policyholder joins, an underwriting process may determine
that cover is excluded for certain conditions for a certain period
of time. For example, a general policyholder-specific underwriting
exclusion can exclude all cover for two years. If a policyholder
has a pre-existing condition such as diabetes, a condition-specific
exclusion can be applied for a period of time. All invoices relating
to an underwritten condition are not paid. In such cases, the routing
algorithm will decide on whether to ensure human verification is
obtained. Alternatively, "moratorium" underwriting may
be used whereby no investigation is performed up-front, but deferred
until such time as the policyholder presents with a clinical condition.
The normal underwriting process will then ensue at the later time.
[0082] There are rules for non payment of invoices, that are proprietary
to the product. These rules can be clinical decisions or benefit
decisions from the business or risk management owners of the product.
For example, day to day dentistry and infertility treatment are
not covered. The rules are defined in terms of plans, procedure
codes or categories, medicine codes, providers, practice types,
age ranges etc. These rules are all ultimately an intrinsic part
of the system. Where there are product rules coded in terms of clinical
codes, the system will add a warning reason code to an invoice line
for an excluded procedure. The system will not reject the invoice
line as a product exclusion unless the decision is endorsed by an
assessor.
[0083] The amount paid on an invoice line can be constrained by
limits. The applicable limit towards which an invoice line will
accumulate, will be identified by the procedure code, practice type
or event admission category.
[0084] If the policyholder selected an annual excess, then the
system will not pay invoices to the value of the excess amount per
dependant. Accumulation to the excess amount will be according to
the order in which the invoices are received. This rule is may be
automatically overwritten in certain circumstances. The amount which
would have paid will be accumulated towards the excess i.e. not
necessarily the full claimed amount, and not invoices that would
never have been covered by the plan.
[0085] If the policyholder has selected a plan that has deductibles
for specific in-hospital procedures, then the deductible amount
will not be paid on the hospital invoice corresponding to the event
approved for the specific procedure.
[0086] Policyholders or employers can have payment of their invoices
suspended for reasons such as non payment of premiums or fraud.
The status of the claim within the pipeline will be automatically
updated.
[0087] An invoice that is received more than 3 months after the
treatment took place is considered to have been submitted too late
for payment.
[0088] A list of hospitals that are considered to be "In Network"
will be published. The In-Network hospitals will include a selection
of hospitals both inside and outside of London. When a policyholder
takes out the policy, he or she can choose whether or not to include
London hospitals in their list of In-Network hospitals. If a policyholder
is admitted to an Out of Network hospital (either a London hospital
when this option was not selected, or a hospital that is not on
the Prudential Health list), there will be a co-payment applicable
to the hospital account. .English Pound.400 per day at an Out of
Network hospital will be paid. Other co-payment options include:
a 30% co-payment, a deductible on the event or payment of the equivalent
of the cost of the hospitalisation had it taken place In Network.
These rules are coded in the rule base.
[0089] The policyholder can select from several accommodation grade.
Essential grade is a standard private hospital bed. Premier refers
to more up market hospitals or better rooms in standard hospitals.
Not all hospitals offer both accommodation grades, so a policyholder's
choice of In Network hospital can be limited by their accommodation
grade choice. A policyholder will have a per day rate paid in accordance
with their accommodation grade choice, irrespective of which accommodation
grade was actually used.
[0090] If the policyholder chooses to have treatment in a non-private
NHS facility and the treatment would have been covered by their
plan, then the policyholder is entitled to an NHS cash benefit.
The NHS discharge form will be treated as a submitted invoice and
a per day rate will be paid to the policyholder.
[0091] An approved hospital authorisation is a guarantee of payment.
A set of meta-rules is embedded in the rules logic to resolve conflicts
for claims that are guaranteed, but that violate other criteria.
[0092] The service provider or hospital is always paid, unless
there is an indication on the invoice that the policyholder has
already paid, in which case the policyholder is refunded.
[0093] The claims Adjudication system will check whether it is
appropriate to route an invoice for Manual Assessment. Meta-rules
determine if a previous rule application may be taken as binding,
or if a warning alone should be applied and the claim routed for
manual assessment. The workflow system will move claims to the Manual
Assessment pool where appropriate.
[0094] FIG. 3 illustrates the interconnecting aspects of software
modules that combine to perform tasks associated with points and
status allocations in an incentive programme. The programme will
herein after be referred to as the Vitality.TM. programme.
[0095] Vitality partners may be split into those providing a health-related
service (yielding points) or benefit partners providing goods or
services to a Vitality policyholder at preferential rates. A given
partner may fall into both categories.
[0096] Benefits-only partners normally communicate with administration
systems at the financial level only, and have no bearing on Vitality
points. The Vitality (section of the Health carrier) website facilitates
communication with these partners allowing policyholders to redeem
benefits. This could take place at retail point of sale, over the
phone, or electronically in a "webmall" environment.
[0097] Some partners provide a health-related service to a policyholder,
in which case the policyholder is in a points-accumulating position.
Others provide access to goods and services at preferential rates
dependant on a status level achieved through points-accumulating
activities. In all cases, data transfer takes place between the
Vitality Management System and the partner system, depending on
requirements of the contract as well as the technical capabilities
of the partner.
[0098] To cater for multiple scenarios, the Vitality System Software
provides a set of five distinct communication templates to facilitate
data exchange with various partners. Communication with a new partner
can thus be implemented without additional development or integration,
simply by application of an appropriate software module and communication
protocol. The various methodologies are described below: [0099]
1. Base Exchange Protocol--This is used when a Vitality partner
requires constant access to the comprehensive details of the entire
Vitality policyholder base. The protocol uses mechanisms to ensure
data currency as well as to minimise data volumes. Additional algorithms
ensure the timely rectification of transmission errors, thus ensuring
total data availability at point of transaction, usually a sign-up
to a particular service. [0100] 2. Instruction Exchange Protocol--This
is used when the entire data set is not required, but when detailed
instructions for a set of actions to occur are transmitted on a
need-to-know basis. This will occur for example when a policyholder
registers for a particular service without any advance warning.
The heart of the protocol is a mechanism reducing complex (possibly
overlapping and contradicting) instructions into a single unified
transmission message. This in turn makes use of a rules engine which
makes use of specialised rules capable of expressing a variety of
core and boundary conditions. [0101] 3. Web Services Protocol--This
involves the modification of the partner systems to interface directly
to a host web server. Relevant transaction data is transmitted using
pre-built algorithms without the user of the partner software being
directly aware of this. These algorithms make use of highly componentised
code which is easily customisable to the needs of individual data
exchange agreements. [0102] 4. Modem Device Protocol--If partner
systems are not configurable to a web services protocol (or no systems
exist), use may be made of a specialised hardware device. This device
is activated (normally by a retail partner) to transmit transaction
data and usage information to the Vitality host system. A modem
linking the device with the prevailing telephone network is used
in such an instance. The applicable receiving software module will
translate and store data that arrives through this channel. [0103]
5. Online Protocol--In cases of fairly low transaction volumes,
and failing integration into an existing partner system, data exchange
is facilitated by a partner-specific website. The partner (securely)
logs into the site and transmits all relevant data through interaction
with a specialised user interface. This interface will make use
of re-usable software components expressly designed for this purpose.
[0104] Points may be earned by virtue of communication from participating
partners, or through direct communication with the policyholder
via manual, telephonic or other electronic means. The relevant claims
data will reside in the databases of the claims Management System.
The onus is on that system to notify the Vitality points calculation
module of a medical service which may be relevant (the arbiters
of relevance are rules fired within the points calculation module).
[0105] The claims module will typically poll its data at predefined
intervals and transmit the occurrence of a particular medical service
(designated by a service code) to the Vitality modules. The polling
program is a high-speed optimised module.
[0106] Points are allocated based on data received from partners
through one of the protocols described above. Frequency of calculation
is a function of stated service levels, constrained only by the
time required to ensure error-free transmissions. In many cases
points are allocated as soon as processing and verifying of an incoming
transaction takes place.
[0107] Points-allocation is based on a set of generic user-driven
data tables specifying the number of points associated with a particular
activity. A supplemental rules engine is used to implement more
complicated rules as well as for meta-rules.
[0108] Examples of complex rule formulations: 5000 points allowable
for cholesterol tests only once in a three-year period; 2 fitness
assessments allowed per year at five-month intervals; Membership
to gym cancelled if less than 10 workouts in 3 months. Complex rules
such as these are implemented in the rules base by means of Java
"strategies". These are self-testing components which
insert easily into any surrounding rules infrastructure.
[0109] A subset of the rules strategy is a three-tiered limits
engine, which ensures that allocation of points cannot exceed predefined
thresholds and sub-thresholds.
[0110] The primary determinant of Vitality status (e.g. "bronze",
"silver", "gold", "platinum") is the
number of points accrued within a policyholder portfolio. This may
however be subject to the imposition of a number of rules implied
by the Vitality contract itself, as well as the rules that inhere
in the associated private medical insurance policy.
[0111] A Java rules engine implements these rules, which are extendable
at multiple levels, right down to individual policyholder rules.
This means that a new rule can be set up to cover the entire policyholder
population, a set of employers (industry type, say), individual
employers, individual policyholders, or even dependants of individuals.
[0112] This mechanism also allows the imposition of special rules
for a group. For example a particular set of policyholders (e.g.
those suffering from a particular chronic illness) may be awarded
a higher Vitality level by the addition of an applicable rule or
meta-rule.
[0113] Ideally, the low claims bonus should be done on precisely
the renewal date of the policy. However, this is not possible for
two reasons: firstly, some communication with the policyholder must
take place in order for that policyholder to articulate benefit
preferences accruing from the bonus; secondly, a "cut off"
time prior to renewal must be imposed to allow the software to make
the required calculations. It is desirable for this cut-off point
to be as close to actual renewal as possible, to ensure that the
policyholder is credited with maximum points, that all claims have
been received, and that any premium adjustments are included in
the calculation.
[0114] To ensure that a usable approximation is reached, a "snapshot"
of all claims, points and premium activity is required from the
calculation module. This module send messages to modules corresponding
to these three sub-systems, and requests an immediate status check
on all three operators for use in the bonus calculation.
[0115] The paragraphs below delve further into the functions performed
by the calculation module 16. This module controls all necessary
activities required to obtain relevant information from related
sub-systems in the correct sequence.
[0116] The calculation module makes use of a "workflow"
sequence that calls functions within the surrounding systems to
obtain the necessary values for use in the discount formula. It
uses these values, combined with the application of a built-in intelligence
to compute the new premium. These steps are outlined below with
reference to FIGS. 4a-4c:
Get Premiums
[0117] The bonus calculation module sends a message to the premium
system. It obtains a sum of all premiums paid since the last such
calculation was performed. It then performs certain checks on the
returned value in order to address the following:
[0118] Ensure "notional" premium is used to determine
value for calculation. This is relevant in policy years two and
above, since the premium used is the amount the policyholder would
pay if no previous year's discounts apply. The calculation module
thus consults the previous year's calculation to confirm that no
such discount has been in place for the period immediately prior
to the discount calculation. If it has, then instead of using actual
premiums paid, send message to premium modules to calculate notional
premium for this policyholder (including plan changes, family changes)
as if no discount existed. As a check, the percentage discount for
the year under consideration is applied to actual premiums paid
and compared to the first value. If they do not match, the calculation
is terminated pending manual checks. An automatic message will be
sent to the party responsible for resolving this inconsistency.
[0119] Is the premium higher or lower than the previous calculation?
If lower, then send additional message to ensure that an appropriate
event occurred resulting in this change. This could be a change
in cover or change to family make-up. [0120] If premium volatility
occurs around the time of calculation, there may be some doubt as
to the exact quantum of premium to use in the formula. In this case,
certain assumptions are necessary to allow the calculation to proceed.
The use of averages and other "smoothing" strategies facilitates
an approximation of the correct premium sum, and consequently the
correct bonus amount. [0121] The calculation program must take into
account any volatility that may have existed in the makeup of the
family unit covered by the health policy. Marriages, divorces, adding
of dependents, and children becoming ineligible for coverage must
all be carefully analysed by the calculation module. This then allows
the calculation module to apply variants of the calculation formula
to the cumulative premiums attracted by the policy during the period
under scrutiny.
[0122] The calculation module is capable of interrogating the premium
subsystem for this data and to then make sense of it for the purposes
of bonus determination.
Get claims
[0123] The bonus calculation module sends requests to the claims
module subsystems as follows: [0124] 1. Preauthorisation subsystem:
this will respond with data allowing the bonus calculation module
to determine what levels of outstanding claims exposure remains
in the system. The calculation module then splits all clinical events
for the policyholder for the year into three categories: [0125]
a. Those that are concluded (all claims paid) [0126] b. Those in
progress (claims may have been partially paid) [0127] c. Those notified
and authorised, but not yet claimed on. The bonus calculation module
will then impose rules to determine which claims to use in its calculations.
Costs attached to different clinical scenarios differ depending
on associated clinical predictability. For example, tonsillectomies
always cost the same within acceptable margins of error. As another
example, certain hospitalisations such as hip replacement may be
complete, but the calculation module contains clinical knowledge
indicating that a certain amount of follow-up physiotherapy is expected.
In such clinical scenarios, and under certain criteria associated
with the authorisation itself, the claims for incomplete events
may be included in the bonus calculation. [0128] 2. Claims subsystem:
Along with premiums, the exact quanta of claims paid to a policyholder
is a primary operand within the bonus calculation. The calculation
module will request all claims paid within a certain time period.
All claims will then be checked against the clinical events as returned
by the preauthorisation subsystem. Claims that cannot be associated
with an event may indicate an error. The module contains rules to
escalate potential errors to various parties capable of resolving
them.
[0129] The calculation module also compares the overall number
of claims for a particular policyholder to the total for a previous
time period, typically the previous year. Significant changes to
this value over time are indicative of additional errors. In certain
cases, where policyholders are known to suffer from health issues
which may be predicted to incur treatments (and thus claims) a drop
in total claims for the calculation period would be flagged by the
calculation module as a potential area for investigation.
[0130] An increase in claims volumes may be due to other factors
other than ill-health. For example, a policyholder may have increased
the number of policyholders on that policy. For large claims volumes,
the calculation module will send messages to additional subsystems
in an attempt to reconcile claims quanta with individual personal
and/or clinical circumstances.
[0131] If a comparison between preauthorisations and claims results
in some discrepancy, then the bonus calculation program will attempt
to "smooth" claims to coincide with the clinical data
recorded in the system. For example, if there is an expectation
for a certain quanta of claims to be incurred by virtue of a preauthorised
clinical event for which claims have not been received, the calculation
module will make assumptions allowing it to treat undeceived claims
as if they had been received more smoothly, i.e. in line with expectations.
Get Points, Status
[0132] All points-accumulating activities will have been recorded
by software during the bonus calculation period. The calculation
module requires the total number of points which it uses to recalculate
the "status" level based on a number of criteria. [0133]
For simple cases, the status is a function of point bands, which
confer a certain "colou" status on the policyholder [0134]
In cases where the policyholder may have been married or divorced
(or divorced, then re-married), a more sophisticated calculation
is required. Since status thresholds differ for singles and families,
a pro-rating function recomputes the required threshold levels for
a particular policy. This will be the final status levels used against
points earned for the period under calculation [0135] Even more
complicated cases may exist, which the calculation software can
solve through the application of certain rules. For example, a married
man may get divorced, and his (ex) wife may marry another policyholder
(electing to transfer to that policy). In such cases, the points
earned by the wife prior to divorce need to be allocated across
both policies during the computation period. This allocation is
performed thorough various formulae depending on the nature of the
original points-scoring activities. Additionally, for activities
for which maximum allowable points are imposed, applicable limits
will need to be derived in order to compute a final points allocation
for the policy. Compute Bonus Amount
[0136] The bonus calculation module 16 will not proceed with the
final calculation module until such time as the above parameters
have been identified and resolved. The bonus calculation module
contains the ability to identify how far it has progressed with
the overall calculation, and can make visible the full set of partial
activities performed. In addition, the calculation module will identify
itself as being in a one of the following statuses: [0137] Complete--simple
calculation, no additional issues [0138] Incomplete, but some issues
pending, likely to be resolved automatically [0139] Incomplete,
but with non-serious issues requiring human intervention [0140]
Incomplete, critical issues remaining
[0141] The bonus available to the policyholder, once computed,
is subject to a number of variations depending on the nature of
the policy (individual, group) and the choices exercised by the
individual (discounts, cash-back). This is described elsewhere.
[0142] The premium for the following year can then be computed.
This is then a function of regular elements such as age, gender,
geography and the cover that a policyholder has purchased. Added
to this will be the elements of premium paid for the previous year,
claims history and lifestyle history, as described herein.
Derive Policy Message
[0143] The computation of applicable low-claims discount results
in a value available to be paid on a policy in accordance with the
process and rules described above. This amount must then be communicated
to the policyholder. The computation module is however also equipped
to discern trends and to formulate an appropriate response to the
policyholder.
[0144] For example, if a premium goes up markedly from one year
to the next (i.e. policyholder loses discount), then this could
be attributable to one of several factors: [0145] Vitality status
has dropped sharply, claims normal: in such circumstances, the calculation
module will derive which points-earning activities have been curtailed
or stopped, and will formulate an appropriate response to the policyholder.
This would include reminders to attend a gym more frequently as
may have been the case in the previous year. However, this needs
to be compared with claims data to ensure that no inappropriate
messages are generated: e.g. person had serious hip operation or
worse [0146] Vitality status normal, high claims history: this would
be a fairly normal scenario for low claimers that then experience
a serious clinical situation or other elective surgery. The correct
response in this case would be to indicate awareness of claims,
with reminders of how the overall bonus scheme operates, such that
the policyholder can set and achieve a more favourable ratio for
the following year [0147] Hybrid models--moderate changes to points
achieved as well as claims: in this case, emphasis would be placed
on more general topics, rather than on points earning and claims
issues alone.
[0148] Thus, the data processing system allows the managers of
the medical insurance plan to calculate a premium for the coming
year which is essentially linked to the amount of claims the policyholder
has made from the insurance plan as well as to the health and fitness
related activities leading to the earning of points.
|