A DATA PROCESSING SYSTEM FOR ACCURATELY CALCULATING A
POLICYHOLDER'S DISCOUNT IN A MEDICAL INSURANCE PLAN AND
A METHOD THEREFOR
BACKGROUND OF THE INVENTION
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.
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 policyhoiders of the plan and to encourage
the policyhoiders of the plan to stay healthy. To date, this has not been a
discernible trend in the United Kingdom.
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.
Another method of managing a medical insurance plan that is focused on
encouraging the policyhoiders of the plan to manage their claims is to offer
the policyhoiders 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 policyhoiders 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.
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 poiicyholder 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
v >
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.
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
According to the invention there is provided 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 t6 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.
The system preferably further comprises an incentive scheme module
adapted to access data regarding the level of the policyholder in an
incentive scheme and wherein the discount module is further adapted to
receive data from the incentive scheme module and to use this data to
calculate a discount amount.
Preferably, the discount module is adapted to check the data received from
the premiums module and the claims module.
The claims module may be 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.
Optionally, the premiums module may be 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.
The claims module may be 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.
The premium module is preferably adapted to use the calculated discount
to calculate a premium for the policyholder for the coming year.
The present invention extends to 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.
The method may include accessing data regarding the level of the
policyholder in an incentive scheme and to use this data to calculate the
discount amount.
The method may also further comprise checking the data received from the
premiums module and the claims module.
Preferably, the method may further include determining if there have been
arty claims authorised for a policyhoider which have not yet been claimed,
and if so to apply a set of rules to determine the likety 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.
If the amount of premiums paid by the policyholder of the medical
insurance plan for the predetermined period was a discounted amount,
calculating 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.
The method may further include 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.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 is a schematic representation of a discount methodology in a
medical insurance scheme;
Figure 2 is a schematic representation of a system according to the
present invention used to implement the discount
methodology illustrated in Figure 1;
Figure 3 is a schematic representation of an incentive system used
together with a medical insurance scheme; and
Figure 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
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 pointsearning
activities:
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
(FgureRemoved) that the polio/holder's status level is essentially according to the use of the
facilities and or services.
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.
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.
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
poiicyholder's premium payable in the coming year.
For example, referring to Figure 1, a married man aged 36 living in London
covering his spouse and two children could expect to pay about £80 per
month. That's p = £960 in a full year. If we assume he claims £428 during
the year for private consultations, that means the amount potentially
available as a discount off next year's premium, is £532 (£672 - £428).
If the incentive scheme is also used then the actual percentage of the £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 £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.
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
£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:
(FgureRemoved)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.
In order to implement the abovementioned method, it is necessary to
provide a data processing system which is able to calculate the discount.
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.
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.
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.
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.
The software may further be transmitted or received over a network via the
network interface device.
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, solidstate
memories, optical and magnetic media, and carrier wave signals.
Referring to Figure 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.
Furthermore, the abovementioned modules may form part of a larger
system which implements the medical insurance plan.
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.
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.
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.
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:
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
2) Each step is then processed in the order paying party, premium
component, split sequence
3) The step is applied to each premium amount of the same
component, applied to premium amounts of the same type for each
dependent
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.
5) Based on the hierarchy defined for each component, the dependant
amount types for the same component and party 6re calculated. Their split
amount for this party is calculated in the same ratio as in the as for the
principal policyholder
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
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:
1) Plan choice
2) Age of the policyholder
3) Status of the policyholder
4) Smoker/non-smoker status
5) Hospital accommodation grade
6) Location of hospital (inside/outside London)
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'
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.
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.
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.
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).
The contextuaiisation 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:
• 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)
• 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
• Identifiers of policyholders and doctors could be incorrect -or
incomplete
Cases like these may be automatically or partially resolved based on the
firing of a series of rules within the rule base.
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.
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.
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.
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:
1. Provider is registered, active and has not been marked for fraud.
2. Membership and dependant exists, is not suspended.
3. Procedure codes exist and are appropriate for the billing provider
If the service date falls within the admission and discharge dates of an
approved hospitalisation for a particular dependant, the invoice is linked to
the event.
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.
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.
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.
18
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.
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.
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.
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.
If the policyholder has selected a plan that has deductibles for specific inhospital
procedures, then the deductible amount will not be paid on the
hospital invoice corresponding to the event approved for' the specific
procedure.
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.
An invoice that is received more than 3 months after the treatment took
place is considered to have been submitted too late for payment.
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. £400 per day at an Out of Network
hospital will be paid. Other co-payment options include: a 30% copayment,
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.
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.
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.
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.
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.
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.
Figure 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™ programme.
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
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.
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.
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:
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.
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 redt»c>ng 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.
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 cornponentised code which is easily customisable to the
needs of individual data exchange agreements.
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.
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.
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).
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.
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 errorfree
transmissions. In many cases points are allocated as soon as
processing and verifying of an incoming transaction takes place.
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.
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.
A subset of the rules strategy is a three-tiered limits engine, which ensures
that allocation of points cannot exceed predefined thresholds and subthresholds.
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.
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.
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.
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.
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 subsystems,
and requests an immediate status check on all three operators for
use in the bonus calculation.
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.
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 Figures 4a-4c:
Get Premiums
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:
• 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.
• 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.
« 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.
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 dependants, 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.
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.
aims
The bonus calculation module sends requests to the claims module
subsystems as follows:
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:
a. Those that are concluded (all claims paid)
b. Those in progress (claims may have been partially paid)
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.
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.
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.
An increase in claims volumes may be due to other factors other than illhealth.
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.
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
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.
• For simple cases, the status is B function of point bands, which
confer a certain "colour" status on the policyholder
• 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
» 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
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:
•• Complete - simple calculation, no additional issues
• Incomplete, but some issues pending, likely to be resolved
automatically
• Incomplete, but with non-serious issues requiring human
intervention
« Incomplete, critical issues remaining
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.
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
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.
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:
« Vitality status has dropped sharply, claims normal: in such
circumstances, the calculation module will derive which pointsearning
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
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
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.
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.

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 or claim 2 wherein the discount
module is adapted to check the data received from the premiums
module and the claims module.
4. A system according to any preceding claim 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 any preceding claim 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 any preceding claim 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 any preceding claim wherein the premium
module is adapted to use the calculated discount to calculate a
premium for the policyholder for the coming year.
8. 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 method according to claim 8 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 method according to claim 8 or claim 9 further comprising
checking the data received from the premiums module and the
claims module.
11. A method according to any of claims 8 to 1D 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 method according to any of claims 8 to 11 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 poiicyholder would have paid if they were not
awarded a discount, wherein the notional amount is used to
calculate the discount amount.
13. A method according to any of claims 8 to 12 further comprising
comparing the number of claims submitted by a poiicyholder to the
number of claims submitted by a poiicyholder in a previous time
period as a further error check.