Parametric System For Risk Sharing of Critical Illness Risks And
Corresponding Method Thereof
Field of the Invention
The present invention relates to resource-pooling systems for providing risk
sharing of critical illness risks of a variable number of risk exposure components by
providing a dynamic self-sufficient risk protection for the risk exposure components by
means of the critical illness insurance system. In particular, the invention relates to
automated event-driven systems triggering on the patient dataflow pathway.
Background of the Invention
These days, there is significant risk exposure related to many aspects in life
and non-life sectors. Risk exposed units a s any kinds of objects, individuals, corporate
bodies and/or legal entities, necessarily are confronted with many forms of active and
passive risk management to hedge and protect against the risk of certain losses and
events. In the prior art, one way to address such risk of loss is based on transferring and
pooling the risk of loss from a plurality of risk exposed entities to a dedicated pooling
entity. In essence, this can be executed by effectively allocating the risk of loss to this
pooling unit or entity by pooling resources of associated units, which are exposed to a
certain risk. In case, that one of the units is hit by a n event occurring related to a
transferred risk, the pooling entity directly intercepts the loss or damage caused by the
event by transferring resources from the pooled resources to the affected unit. Pooling
of resources can be achieved by exchanging predefined amounts of resources with
the resource-pooling system; e.g. payments or premiums to be paid, for the transfer of
the risk. This means that predefined amounts of resources are exchanged for the other
unit assuming the risk of loss.
For living individuals, a special kind of risk is based on the risk of loss of life
and related possible losses; i.e., losses that occur a s a consequence of the death of
that individual. Such risks are traditionally handled by so-called life insurance systems. To
administer a loss for benefits provided by a life insurance policy, a substantial amount of
information must be collected and managed by the pooling entity in order to allow risktransfer.
Appropriate documentation must be identified, captured and analyzed, such
a s death certificates or medical provider verification of condition or service in the cases
of health/supplementary health. One important problem arises by the fact that life
insurance methods are triggered by the death of the unit, which risk is transferred.
However, often problems arise for a n individual before then, in that financial resources
were threatened by losses occurring prior to death a s a consequence of the events
leading to death. This is mostly the case when the individual suffers from potentially
terminal disease, like malignant cancer, which may inevitably lead to the death of the
individual. Typically, the patient is confronted with increasing costs for medical
treatment or other related costs a s travel expenses or additional heating costs, but also
by the decreasing ability to earn the money needed to fulfill their monthly financial
needs. This may lead to the necessity of having to make many sacrifices; e.g. taking
children out of private schools, selling their house and filling for bankruptcy. All these
financial concerns contrariwise impacted on their health. Recovery is delayed, stress
additionally aggravates the anyway poor health.
As a solution, resource-pooling systems were developed that cover such "critical
illnesses", where the resource-pooling unit operated by the insurer provides a lump sum
cash payment if the risk-exposed unit, which is, seen from the perspective of the insurer
the policyholder, is diagnosed with one of the critical illnesses listed in a defined table of
transferred risk. The operation of the resource-pooling system may also be structured to
pay out regular income, and the payouts may also benefit the policyholder undergoing
a surgical procedure, for example, having a heart bypass operation. Typically, such
systems require the risk-exposed unit to survive a minimum number of days (the socalled
survival period) from when the illness was first diagnosed. The survival period can
vary; however, 1 days is the most commonly used survival period used. In the
Australian market, survival periods are set between 8 - 14 days. However, systems a s
e.g. automated systems associated with indemnity based on accelerated payment
(e.g. related to specific life insurance products) and stand alone products, are also
known. The terms, a s defined for the risk transfer, typically contain specific predefined
triggers or rules to be applied that provide the basis for the determination of when a
diagnosis of a critical illness is considered valid. Terms for survival periods may also
define parameters providing that the diagnosis need to be made by a physician who
specializes in the treatment of that illness or condition or name specific tests, e.g. ECG
changes in case of a myocardial infarctions, that confirm the diagnosis. In many
markets, the trigger parameters for many of the diseases and conditions have become
standardized; thus typically resource-pooling systems would use the same definition (cf.
stand alone products and accelerated critical illness systems). The standardization of
the critical illness definitions serves many purposes, including better clarity of coverage
for the risk-exposed units and greater comparability of terms and conditions for risk
transfers among different resource-pooling systems. Such terms and conditions are
often defined in the policy covering the risk transfer. For example, in the UK the
Association of British Insurers (ABI) has issued a Statement of Best Practice, which
includes a number of standard definitions for common critical illnesses. The prior art also
provides for alternative methods of critical illness risk transfer, other than the lump sum
cash payment method. These critical illness insurance systems can directly pay health
providers (as e.g. "tiers payant" systems) for the treatment costs involving critical and
life-threatening illnesses that are covered by the policyholder's insurance policy,
including fees for specialists and procedures at a select group of high-ranking hospitals
up to a certain amount per course of treatment a s set out in the policy, but also transfer
the payment to the customer.
In the prior art, critical illnesses are typically covered by critical illness risk transfer; these
are heart attack, cancer, stroke and coronary artery by-pass surgery. Examples of other
conditions that might be covered include: Alzheimer's disease, blindness, deafness,
kidney failure, major organ transplant, multiple sclerosis, HIV/AIDS contracted by blood
transfusion or during a n operation, Parkinson's disease, paralysis of limb, terminal illness.
One of the problems of the risk transfer system a s provided by the prior art lies in the
fact that the incidence of a condition may vary (i.e. in- or decrease) over time, and
that diagnosis and treatment may improve over time, that the financial need to cover
some illnesses deemed critical a decade ago is no longer considered necessary today.
Likewise, some of the conditions covered today may no longer need to be covered a
decade or so from now. It is very difficult to adapt the prior art systems to such
changing conditions. What is clear is the fact that the financial hardship at the time of
diagnosis and afterwards increases during the course of treatment, which seldom can
be meet by the present systems. Furthermore, operating the systems of the prior art
requires a high level of human resources, because these systems cannot be
adequately automated. Therefore, a large quantity of the pooled resources are used
by the resource-pooling system itself to administer the risk transfer, which makes the risk
transfer expensive for the risk-exposed unit. Finally, another problem comes from the
fact that, due to the medical progress, many patients no longer die but can survive for
many years after undergoing treatment for a heart attack, stroke and cancer. Due to
the long survival period, such individuals, who were struck already once by a critical
illness, continue to be exposed to the risk of a second or consequential occurrence of a
critical illness. In fact, the risk typically does not decrease, since the health of these
patients is already weakened by the first incidence of a critical illness. Since critical
illnesses are traditionally meant to lead to death, the risk involving such individuals, who
may be affected by a second or even more critical illnesses is no longer covered by
the resource-pooling system. Therefore, although the patient survived his first bout with
a critical illness, he may, a t least financially, not survive the second time.
Summary of the Invention
It is a n object of the invention to provide a system and method for risk
sharing of critical illness risks of a variable number of risk exposure components by
providing a dynamic self-sufficient risk protection for the risk exposure components by
means of a resource-pooling system. The resource-pooling system, realized a s a n
automated critical illness insurance system shall be completely automated and selfadaptable/
self-maintaining by its technical means and shall provide the technical risk
transfer basis, which can be used by service providers in the risk transfer or insurance
technology for risk transfer related to critical illness risks (CI). A further object of the
invention provides for a way to technically capture, handle and automate complex
related operations of the insurance industry related to critical illness risk transfer. Another
object is to synchronize and adjust such operations based o n technical means. In
contrast to the standard approach, the resource-pooling system shall create a
reproducible operation with the desired, technically based, repetitious accuracy based
on technical means, process flow and process control/operation.
According to the present invention, these objects are achieved particularly
through the features of the independent claims. In addition, further advantageous
embodiments follow from the dependent claims and the related description.
According to the present invention, the above-mentioned objects for risk
sharing of critical illness risks of a variable number of risk exposure components are
achieved, particularly, by providing a dynamic self-sufficient risk protection for the risk
exposure components by means of the resource-pooling system, wherein the risk
exposure components are connected to the resource-pooling system by means of a
plurality of payment-receiving modules configured to receive and store payments from
the risk exposure components for the pooling of their risks and resources, and wherein
the resource-pooling system comprises a n event-driven core engine comprising critical
illness triggers triggering in a patient dataflow pathway to provide risk protection for a
specific risk exposure component based on received and stored payments (of the risk
exposure components, in that the total risk of the pooled risk exposure components
comprises a first risk contribution of each pooled risk exposure components associated
to risk exposure in relation to a first diagnosis of a critical illness, wherein the critical illness
is comprised in a predefined searchable table of critical illnesses and wherein critical
illness losses occur a s a consequence to the first diagnosis of risk exposure components
with one of the searchable critical illnesses, in that the total risk of the pooled risk
exposure components comprises a t least a second and/or successional risk
contributions associated to risk exposure in relation to a second and/or successional
critical illnesses, wherein the critical illnesses are comprised in the predefined
searchable table of critical illness parameters, and wherein a critical illness loss losses
occurs a s a consequence to the second and/or successional diagnosis of risk exposure
components with one of the searchable critical illnesses, and in that in case of a
triggering of a n occurrence of a first or second or successional critical illness in the
patient data flow pathway of a risk exposure component, a loss associated with the first
or second or successional critical illness (es) is distinctly covered by the resource pooling
system by means of a parametric transfer of payments from the resource-pooling
system to the risk exposure component. The critical illness triggers can for example
comprise a trigger for triggering the occurrence of measuring parameters indicating
heart attack and/or cancer and/or stroke and/or coronary artery by-pass surgery in the
patient data flow pathway. Further, the critical illness triggers can e.g. comprise a
trigger for triggering the occurrence of measuring parameters indicating Alzheimer's
disease, blindness, deafness, kidney failure, major organ transplant, multiple sclerosis,
HIV/AIDS contracted by blood transfusion or during a n operation, Parkinson's disease,
paralysis of limb, terminal illness on the patient dataflow pathway. As a n embodiment
variant, it can be provided that the first parametric payment, for example can
technically be implemented in that it only is transferred by the triggering of the
occurrence of measuring parameters indicating the critical illness of malignant cancer
ό
and/or a smaller incidence for ductal carcinoma in situ (DCIS) and/or early prostate
carcinoma. Further, acute treatment phase parameters indicating surgery and/or
chemotherapy and/or radiotherapy and/or reconstructive surgery can be triggered on
the patient data flow pathway by means of a critical illness trigger by the core engine.
As a n embodiment variant, it is provided that a second parametric payment is
transferred due to the triggering of acute treatment phase parameters indicating
surgery and/or chemotherapy and/or radiotherapy and/or reconstructive surgery.
Additionally, recovery phase parameters associated with terminal prognosis data can
e.g. be triggered in a patient data flow pathway by means of a critical illness trigger of
the core engine. As a further embodiment variant, a third parametric payment is
transferred by the triggering of the recovery phase parameters and/or terminal
prognosis parameters. As a further variant, the critical illness data of the patient
dataflow pathway of the risk exposure component can e.g. additionally be transferred
to an automated employee assistance system (EAP: Employee Assistance Program)
providing automated support to the risk exposure component. Alternatively or in
addition, the critical illness data of the patient dataflow pathway of the risk exposure
component can e.g. be transferred to an alert system of a Change Advisory Board
(CAB) to activate automated or at least semi-automated, CAB actions. It can also be
advantageously that the patient dataflow pathway is e.g. monitored by the resourcepooling
system by capturing patient-measuring parameters of the patient data flow
pathway at least periodically and/or within predefined time frames or periods. Finally,
the patient data flow pathway can e.g. be dynamically monitored by the resourcepooling
system in that it triggers patient-measuring parameters of the patient dataflow
pathway transmitted from associated measuring systems. The invention has, inter alia,
the advantage that the system provides the technical means to meet customer needs
related to the financial hardships at the time of the diagnosis of a critical illness, which
will become more acute a s the treatment progresses. Therefore, cancer fears and the
related consequences that are suffered by many people can be met with the
automated resource-pooling system according to the invention. The system has,
furthermore, the advantage that smaller payments than in traditional critical illness
systems are sufficient to allow for a safe operation of the system. The operational
aspects of the system are transparent for operators a s well a s covered risk units, since
payment is transferred in response to certain triggers on the cancer patient's
information pathways. The system is able to provide an adaptable survival period e.g.
14, 2 1 or 28 days, to be confirmed or defined by the risk transfer. The system is further
able †o provide the technical implementation of a n automated system that is based on
a drawdown payment operation or a predefined payment operation. The system also
provides the technical means, which can support different underwriting options, such
a s (i) underwritten with a set of questions, (ii) in/out underwriting, (iii) inclusion or
exclusion of Pre-Existing Condition Exclusion (PECE) and/or a Related Conditions
Exclusion with the associated problems of risk transfer. PECE-problems are based on the
fact that resource-pooling systems are often required by a n employer to create safety
provisions, if there is a diagnosis of a critical illness in a n employee, in order to provide a
lump sum benefit for a n employee (or the employee's spouse or children, if comprised
in the risk transfer), who is diagnosed with one of the defined medical conditions or
undergoes one of the listed surgical procedures. However, many systems fail to take
over risk transfers if the individual suffered from the insured condition, before the risk
transfer was activated (this is known a s the Pre-Existing Condition Exclusion), or because
the individual suffered from a condition that led to a claim under the insured illness - for
example, it was known that a n individual suffered from high blood pressure before the
risk transfer being activated, and suffered a stroke after the risk transfer had been
activated. Another advantage of the system is based on the fact that payments are
directly transferred to the risk transfer unit or the consumer/client. Therefore, the system
is able to enhance critical illness insurance offerings by independent financial advisers
(IFA). IFAs are persons who give impartial advice to clients on financial matters and who
are not employed by any financial institution, although commissions for the sale of
products may be received. Especially the IFA service is made completely costtransparent
to the consumer.
In a n embodiment variant, the above-mentioned objects for risk sharing of
critical illness risks of a variable number of risk exposure components are achieved,
particularly, by providing a dynamic self-sufficient risk protection for the risk exposure
components by means of the critical illness insurance system based o n a resourcepooling
system, in that risk-related component data are processed by a n assembly
module of the resource-pooling system and the likelihood of said risk exposure is
provided by means of the assembly module for one or a plurality of the pooled risk
exposure components based on the risk-related component data, wherein the risk
exposure components are connected to the resource-pooling system by means of a
plurality of payment receiving modules, and payment data are received and stored by
means of a payment data store from the risk exposure components for the pooling of
their risks, and wherein the resource-pooling system triggers a patient dataflow pathway
by means of critical illness triggers of a n event-driven core engine in order to provide risk
protection for a specific risk exposure component based o n received and stored
payments from the risk exposure components, in that a first risk contribution of each
pooled risk exposure components related to a first diagnosis of a critical illness is
associated with risk exposure of each pooled risk exposure component, and the total
risk of the pooled risk exposure components is determined by means of the resourcepooling
system, wherein the critical illness is comprised in a predefined searchable table
of critical illnesses, and wherein critical illness losses occur a s a consequence of the first
diagnosis of risk exposure components due to any one of the searchable critical
illnesses, in that a first risk contribution of each of the pooled risk exposure components
related to a second and/or successional risk contribution diagnosis of a critical illness is
associated with risk exposure of each pooled risk exposure component, and the total
risk of the pooled risk exposure components is determined by means of the resourcepooling
system, wherein the critical illness is comprised in the predefined searchable
table of critical illnesses, and wherein critical illness losses occur a s a consequence of
the second and/or successional diagnosis of risk exposure components due to any one
of the searchable critical illnesses, in that, in case a n occurrence of a first or second or
successional critical illness o n the patient data flow pathway of a risk exposure
component is triggered, a corresponding trigger-flag is set by means of the resourcepooling
system and a parametric draw-down transfer of payments is assigned to this
corresponding trigger-flag, wherein a loss associated with the first or second or
successional critical illness is distinctly covered by the resource-pooling system based o n
the respective trigger-flag and based on the received and stored payment parameters
from risk exposure components by the parametric draw-down transfer from the
resource-pooling system to the risk exposure component, and in that a first parametric
payment is transferred by the triggering of the occurrence of the critical illness, a
second parametric payment is transferred by the triggering of a n acute treatment
phase, and a third parametric payment is transferred by the triggering of a recovery
phase associated with terminal prognosis data. This embodiment variant has the
advantage of further providing a parametric draw-down payment. It is clear to a man
skilled in the art, that the present system can easily be expanded to comprise more
than the herein described three trigger-levels.
In one embodiment variant, the receiving and preconditioned storage of
payments from risk exposure components for the pooling of their risks is dynamically
determined based o n total risk and/or the likelihood of the risk exposure of the pooled
risk exposure components. This embodiment variant has, inter alia, the advantage that
the operation of the resource-pooling system can be dynamically adapted to
changing conditions of the pooled risk, as, for example, changing demographic
conditions or changing age distributions or the like of the pooled risk components. A
further advantage is that the system needs no manual adaption, when it is operated in
different environments, places or countries, because the size of the payments of the risk
exposure components is directly related to the totally pooled risk.
In another embodiment variant, the number of pooled risk exposure
components is dynamically adapted, by means of the resource-pooling system, to a
range where non-covariant occurring risks covered by the resource-pooling system
affect only a relatively small proportion of the total pooled risk exposure components a t
a given time. This variant has, inter alia, the advantage that the operational and
financial stability of the system can be improved.
In a further embodiment variant, the critical illness triggers are dynamically
adapted by means of a n operating module based o n time-correlated incidence data
for a critical illness condition and/or diagnosis or treatment conditions indicating
improvements in diagnosis or treatment. This variant has, inter alia, the advantage that
improvements in diagnosis or treatment can be dynamically captured by the system
and dynamically affect the overall operation of the system based o n the total risk of
the pooled risk exposure components.
In yet another embodiment variant, the first, second and third parametric
payment are leveled by a predefined total payment sum determined a t least based o n
the risk-related component data and/or o n the likelihood of the risk exposure for one or
a plurality of the pooled risk exposure components based on the risk-related
component data, and wherein the first parametric payment that is transferred is up to
30% of said total payment sum, and the second parametric payment that is transferred
is up to 50% of said total payment sum, and the third parametric payment that is
transferred is up to the left over part given by said total payment sum, minus the actual
first parametric payment and the second parametric payment. The predefined total
payments can e.g. be leveled to any appropriate lump sum, such as, for example,
$50,000 up †o $500,000, or any other sum related to the total transferred risk and the
amount of the periodic payments of the risk exposure component. As embodiment
variant of the realization of the system, the critical illness trigger e.g. can comprise multi
dimensional trigger channels, wherein each of said trigger-flags is assigned to a first
dimension trigger channel, comprising a first trigger-level triggering occurrence
parameters of the critical illness, a second trigger-level triggering acute treatment
phase parameters, and a third trigger-level triggering recovery phase parameters
associated with terminal prognosis data, and each of said trigger-flags is assigned to a t
least a second or higher dimension trigger channel, and comprises additional triggerstages
based on the first, second and/or third trigger-level of the first dimension trigger
channel. As a further variant, the critical illness trigger can also comprise multi
dimensional trigger channels, wherein each of said trigger-flags is assigned to a first
dimension of a trigger channels comprising a first trigger-level relative to triggering
occurrence parameters of the critical illness, a second trigger-level relative to triggering
acute treatment phase parameters, and a third trigger-level relative to triggering
recovery phase parameters associated with terminal prognosis data, and each of said
trigger-flags is assigned to a second dimension of trigger channels comprising a first
trigger-level triggering on a first stage of progression-measuring parameters of the
occurred critical illness, and one or more higher trigger-levels triggering on higher
stages of progression-measuring parameters of the occurred critical illness. This variant,
inter alia, has the advantage that the draw-down payments or the payments of
predefined amounts, which depend on the first, second or third trigger level, i.e. the
different stages of triggers, allow for a n adapted payment of the total sum that is
dependent on the stage of the critical illness, a s triggered by the system.
In one embodiment variant, a periodic payment transfer from the risk
exposure components to the resource pooling system via a plurality of payment
receiving modules is requested by means of a monitoring module of the resourcepooling
system, wherein the risk transfer or protection for the risk exposure components
is interrupted by the monitoring module when the periodic transfer is no longer
detectable by means of the monitoring module. As a variant, the request for periodic
payment transfer can be interrupted automatically or waived by means of the
monitoring module, when the occurrence of indicators for critical illness is triggered in
the patient data flow pathway of a risk exposure component. These embodiment
variants have, inter alia, the advantage that the system allows for a further automation
of the monitoring operation, especially of its operation with regard to the pooled
resources.
In a further embodiment variant, a n independent verification critical illness
trigger of the resource pooling system is activated in cases of a triggering of the
occurrence of indicators for critical illness in the patient data flow pathway of a risk
exposure component by means of the critical illness trigger and wherein the
independent verification critical illness trigger additionally is triggering for the
occurrence of indicators regarding critical illness in a n alternative patient data flow
pathway with independent measuring parameters from the primary patient data flow
pathway in order to verify the occurrence of the critical illness a t the risk exposure
component. As a variant, the parametric draw-down transfer of payments is only
assigned to the corresponding trigger-flag, if the occurrence of the critical illness a t the
risk exposure component is verified by the independent verification critical illness
trigger. These embodiment variants have, inter alia, the advantage that the
operational and financial stability of the system can thus be improved. In addition, the
system is rendered less vulnerably relative to fraud and counterfeit.
In addition to the system, a s described above, and the corresponding
method, the present invention also relates to a computer program product that
includes computer program code means for controlling one or more processors of the
control system in such a manner that the control system performs the proposed
method; and it relates, in particular, to a computer program product that includes a
computer-readable medium containing therein the computer program code means
for the processors.
Brief Description of the Drawings
The present invention will be explained in more detail, by way of example,
with reference to the drawings in which:
Figure 1 shows a block diagram illustrating schematically a n exemplary
parametric, event-driven critical illness insurance system based o n a resource-pooling
system 1 according to the invention for risk sharing of critical illness risks of a variable
number of risk exposure components 2 1, 22, 23 by providing a dynamic self-sufficient risk
protection for the risk exposure components 2 1, 22, 23. The resource-pooling system 1
comprises a n assembly module 5 to process risk- related component data 2 11, 221 , 231
and to provide the likelihood 212, 222, 232 of said risk exposure for one or a plurality of
the pooled risk exposure components 2 1, 22, 23, wherein the risk exposure components
2 1, 22, 23 are connected to the resource-pooling system 1 by means of a plurality of
payment receiving modules 4 that are configured to receive and store 6 payments 214,
224, 234 from the risk exposure components 2 1, 22, 23 for the pooling of their risks, and
wherein the resource-pooling system 1 comprises a n event-driven core engine 3 that
comprises critical illness triggers 3 1, 32, 33, which trigger a patient data flow pathway
2 13, 223, 233 to provide risk protection for a specific risk exposure component 2 1, 22, 23.
The patient data flow pathway 213, 223, 233 is monitored by the resource-pooling
system 1 in that patient measuring parameters of the patient data flow pathway 213,
223, 233 are captured, wherein the patient data flow pathway 213, 223, 233 is
dynamically monitored and triggered for patient measuring parameters of the patient
data flow pathway 213, 223, 233, which is transmitted from associated measuring
systems.
Figure 2 shows a block diagram illustrating schematically exemplary trigger
stages of the resource-pooling system, wherein reference number 1001 is assigned to
the triggering of the critical illness, for example the malignant cancer. Reference
number 1002 designates the triggering of the treatment phase, such as, for example,
surgery, chemotherapy, radiotherapy or medications of drugs etc. Reference number
1003 designates the triggering of the recovery phase or the triggering of the terminal
illness and/or the aftercare phase. Finally, reference number 1004 designates the
triggering of additional support services. Reference number 1004 gives a n example of
additional trigger stages to the critical illness triggers 3 1, 32, 33 of the core engine
module 3.
Figure 3 shows a diagram illustrating schematically a n exemplary payment
drawdown a s it can be provided by the resource pooling system 1 in case of triggering
critical illness at a risk exposure component.
Figure 4 shows a block diagram illustrating schematically a n exemplary
parameterization of the risk exposure for critical illness of the risk exposure components
2 1, 22, 23. The reference numeral 520 gives the total transferred risk of a specific risk
exposure component 2 1, 22, 23 comprising a t least a first risk contribution 511, 521 , 531
for a first occurrence of a critical illness. Further, it comprises a second risk contribution
512, 522, 532 related to a second occurrence of a critical illness. It also can comprise
third 513, 523, 533 and subsequent 51i, 52i, 53i risk contributions thereafter; i.e., "i" herein
denotes the i-†h risk distribution.
Detailed Description of the Preferred Embodiments
Figure 1 illustrates, schematically, a n architecture for a possible
implementation of a n embodiment of the parametric, event-driven resource-pooling
system 1 for risk sharing of critical illness risks. In Figure 1, reference numeral 1 refers to
the resource-pooling system for risk sharing of the risk exposure components 2 1, 22, 23. ..
The resource-pooling system 1 provides a dynamic self-sufficient risk protection and
corresponding risk protection structure for a variable number of risk exposure
components 2 1, 22, 23, i.e.; persons or individuals, by its means. The system 1 includes a t
least one processor and associated memory modules. The system 1 can also include
one or more display units and operating elements, such a s a keyboard, and/or
graphical pointing devices a s a computer mouse. The resource-pooling system 1 is a
technical device comprising electronic means that can be used by service providers in
the field of risk transfer or insurance technology for risk transfer related to critical illness
risks (CI) . The invention seeks to technically capture, handle and automate complex
related operations of the insurance industry. An other aspect is to synchronize and
adjust such operations based on technical means. In contrast to the standard
approach, the resource-pooling system also achieves a n reproducible operations with
the desired technical, repetitious accuracy because it is completely based o n
technical means, process flow and process control/operation.
The resource-pooling system 1 comprises a n assembly module 5 to process
risk related component data 2 11, 221 , 231 and to provide the likelihood 2 12, 222, 232 of
said risk exposure for one or a plurality of the pooled risk exposure components 2 1, 22,
23, etc. based o n the risk-related component data 2 11, 221 , 231 .The resource-pooling
system 1 can be implemented a s a technical platform, which is developed and
implemented to provide critical illness risk transfer through a plurality of (but at least
one) payment receiving module 4. The risk exposure components 2 1, 22, 23, etc. are
connected to the resource-pooling system 1 by means of the plurality of payment
receiving modules 4 configured to receive and store payments 214, 224, 234 from the
risk exposure components 2 1, 22, 23 for the pooling of their risks in a payment data
store 6. The storage of the payments can be implemented by transferring and storing
component-specific payment parameters. The payment amount can be dynamically
determined by means of the resource-pooling system 1 based o n total risk of the overall
pooled risk exposure components 2 1, 22, 23. For the pooling of the resources, the
resource-pooling system 1 can comprise a monitoring module 8 requesting a periodic
payment transfer from the risk exposure components 2 1, 22, 23, etc. to the resourcepooling
system 1 by means of the plurality of payment receiving modules 2, wherein the
risk protection for the risk exposure components 2 1, 22, 23 is interrupted by the
monitoring module 8, when the periodic transfer is no longer detectable by means of
the monitoring module 8. In one embodiment variant, the request for periodic payment
transfers is automatically interrupted or waived by means of the monitoring module 8, if
the occurrence 1001 of indicators for critical illness 7 1, 72, 73 is triggered 3 1 in the
patient data flow pathway of a risk exposure component 2 1, 22, 23,...
As also illustrated schematically in Figure 1, the resource-pooling system 1
includes a data storing module for capturing the risk-related component data and
multiple functional modules; e.g., namely the payment receiving modules 4, the core
engine 3 with the triggers 3 1, 32, 33, the assembly module 5 or the operating module 30.
The functional modules can be implemented a t least partly a s programmed software
modules stored on a computer readable medium, connected a s fixed or removable to
the processor(s) of system 1 or to associated automated systems. One skilled in the art
understands, however, that the functional modules can also be implemented fully by
means of hardware components, units and/or appropriately implemented modules. As
illustrated in Figure 1, system 1 can be connected via a network, such a s a
telecommunications network, to the payment receiving module 4. The network can
include a wired or wireless network; e.g., the Internet, a GSM network (Global System for
Mobile Communication), a n UMTS network (Universal Mobile Telecommunications
System) and/or a WLAN (Wireless Local Region Network), and/or dedicated point-topoint
communication lines. In any case, the technical electronic money schemes for
the present system comprises adequate technical, organizational and procedural
safeguard means in order to prevent, contain and detect threats to the security of the
scheme, particularly the threat o f counterfeits. The resource-pooling system 1 comprises
further all necessary technical means for electronic money transfer and association e.g.
initiated by one or more associated payment receiving modules 4 over a n electronic
network. The monetary parameters can b e based o n all possible electronic and
transferable means a s e.g. e-currency, e-money, electronic cash, electronic currency,
digital money, digital cash, digital currency, or cyber currency etc., which can only be
exchanged electronically. The payment data store 6 provides the means for
associating and storing monetary parameters associated with a single of the pooled risk
exposure components 2 1, 22, 23. The present invention can involve the use of the
mentioned network, such a s e.g. computer networks o r telecommunication networks,
and/or the Internet and digital stored value systems. Electronic funds transfer (EFT) ,
direct deposit, digital gold currency and virtual currency are further examples of
electronic money. Also, the transfer can involve technologies, such a s financial
cryptography and technologies enabling the same. For the transaction of the
monetary parameters, it is preferable that hard electronic currency is used without the
technical possibilities for disputing or reversing any charges. The resource-pooling
system 1 supports, for example, non-reversible transactions. The advantage o f this
arrangement is that the operating costs of the electronic currency system are greatly
reduced by not having to resolve payment disputes. However, this way, it is also
possible for electronic currency transactions to clear instantly, making the funds
available immediately to the system 1. This means that using hard electronic currency is
more akin to a cash transaction. However, also conceivable is the use o f soft electronic
currency, such a s currency that allows for the reversal of payments, for example having
a "clearing time" o f 72 hours, or the like. The way of the electronic monetary parameter
exchange applies to all connected systems and modules related to the resourcepooling
system 1 o f the present invention, such a s e.g. the payment receiving module
4. The monetary parameter transfer to the resource-pooling system 1 can b e initiated
by a payment-receiving module 4 or o n request o f the resource-pooling system 1.
The resource-pooling system 1 comprises a n event-driven core engine 3
comprising critical illness triggers 3 1, 32, 33 for triggering component-specific measuring
parameters in the patient data flow pathway 2 13, 223, 233 of the assigned risk exposure
components 2 1, 22, 23 The patient data flow pathway 2 13, 223, 233 can e.g. b e
monitored by the resource-pooling system 1, capturing patient-related measuring
parameters of the patient data flow pathway 2 13, 223, 233 a t least periodically and/or
within predefined time periods. The patient data flow pathway 2 13, 223, 233 can, for
example, also be dynamically monitored by the resource-pooling system 1, by
triggering patient-measuring parameters of the patient data flow pathway 213, 223,
233 transmitted from associated measuring systems. Triggering the patient data flow
pathway 213, 223, 233, which comprises dynamically recorded measuring parameters
of the concerned risk exposure components 2 1, 22, 23 the system 1 is able to
detect the occurrence of a critical illness and dynamically monitor the different stages
during the progress of the critical illness in order to provide appropriately adapted and
gradated risk protection for a specific risk exposure component 2 1, 22, 23 Such a risk
protection structure is based o n received and stored payments 214, 224, 234 from the
related risk exposure component 2 1, 22, 23 and/or related to the total risk of the
resource-pooling system , 1 based on the overall transferred critical illness risks of all
pooled risk exposure components 2 1, 22, 23
Figure 2 shows a block diagram with possible trigger stages, wherein
reference number 1001 is assigned to the triggering of the critical illness, for example
cancer; reference number 1002 designates the triggering of the treatment phase, such
as, for example, surgery, chemotherapy, radiotherapy or the administration of
medication, etc.; reference number 1003 designates the triggering of the recovery
phase or the triggering of the terminal illness and/or the aftercare phase.; and
reference number 1004 designates the triggering of additional support services.
Reference number 1004 gives a n example of additional trigger stages to the critical
illness triggers 3 1, 32, 33 of the core engine module 3. The critical illness triggers 3 1, 32, 33
can e.g. comprise a trigger 3 1 for triggering the occurrence 1001 of the measuring
parameters, indicating a heart attack and/or cancer and/or a stroke and/or coronary
artery by-pass surgery in the patient data flow pathway 213, 223, 233. Further, the
critical illness triggers 3 1, 32, 33 can comprise a trigger 3 1 for triggering the occurrence
1001 of measuring parameters indicating Alzheimer's disease, blindness, deafness,
kidney failure, major organ transplant, multiple sclerosis, HIV/AIDS contracted by blood
transfusion or during a n operation, Parkinson's disease, paralysis of limb, terminal illness
in the patient data flow pathway 2 13, 223, 233. The majority of cases of occurrences of
critical illness are typically related to heart attack, stroke and cancer, a s can be
expected. The average age of individual 2 1, 22, 23, a t which a critical illness can be
detected in the patient data flow pathway 213, 223, 233, is ± 4 1 years; however, this
depends on the development of diagnostic and other medical means. These statistics
are common for all countries where statistics are maintained. However, it is of great
concern to observe the increasing number of critical illness occurrences - particularly
regarding cancer cases. In most countries, this observed increase is more than 50%, and
in some even 80%. Earlier diagnosis due to better diagnostic equipment may be
partially responsible for this. Therefore, to ensure proper operation of the resourcepooling
system 1, the definitions of the stored trigger parameters 7 1, 72, 73 of critical
illness in the trigger table 7 can be dynamically adapted based o n a monitoring of
changing risks in the risk exposure components 2 1, 22, 23. In particular, the trigger
parameters 7 1, 72, 73 can be region-specific, country-specific and/or specific of the
total pooled risk, adapted or changed. New critical illnesses 7 1, 72, 73 can be added,
while others can be deleted from the triggerable list of critical illnesses by the resourcepooling
system, owing to better treatments or other changed environmental conditions.
In one embodied variant, the critical illness triggers 3 1, 32, 33 can be dynamically
adapted by means of a n operating module 30, based o n time-correlated incidence
dates of a critical illness condition and/or diagnosis or treatment conditions indicating
improvements in diagnosis or treatment.
In addition to the adaptation of the triggers 3 1, 32, 33, the amount of
requested payments from the risk exposure components 2 1, 22, 23 can be accordingly
adjusted by the resource-pooling system 1.Therefore the receiving and preconditioned
storage 6 of payments 214, 224, 234 from risk exposure components 2 1, 22, 23, ... for the
pooling of their risks can be determined dynamically, based o n total risk 50 and/or the
likelihood of the risk exposure of the pooled risk exposure components 2 1, 22, 23, ... To
improve operational and functional security of the resource- pooling system 1 even
further, the number of pooled risk exposure components 2 1, 22, 23, ... can be
dynamically adapted by means of the resource-pooling system 1 to a range where
non-covariant, occurring risks covered by the resource-pooling system 1 affect only a
relatively small proportion of the totally pooled risk exposure components 2 1, 22, 23, ...
a t a given time.
The total risk 50 of the pooled risk exposure components 2 1, 22, 23, ...
comprises a first risk contribution 5 11, 521 , 531 of each pooled risk exposure component
2 1, 22, 23, ... that is associated with risk exposure in relation to a first diagnosis of a
critical illness. The triggering parameters 7 1, 72, 73 of the covered critical illnesses is
comprised and stored in a predefined searchable table 7, such a s e.g. a n
appropriately structured hash table, of critical illnesses 7 1, 72, 73, respectively critical
illness parameters 7 1, 72, 73. The critical illness losses occur a s a consequence to the first
diagnosis of risk exposure components 2 1, 22, 23, ... with regard to one of the
searchable critical illnesses; i.e., the possible need of a risk exposure components 2 1, 22,
23, ... to be covered by the pooled resources of the resource-pooling system 1 is linked
to the risk of the occurrence of a critical illness requiring complex medical treatment
and handling.
The total risk 50 of the pooled risk exposure components 2 1, 22, 23,...
comprises at least a second risk contribution 512,522,523 and/or third or additional
successional risk contributions 513/521/. ..51i/52i/53i; i.e., up to the i-†h risk contribution,
associated with risk exposure in relation to a second and/or successional critical
illness(es). The critical illnesses 7 1, 72, 73 for triggering the second risk contribution 512,
522, 523 and/or third or additional successional risk contributions 513/521/. ..51i/52i/53i
are the same a s for the first risk contribution and comprised in the predefined
searchable table 7 of critical illness parameters 7 1, 72, 73.
Figure 4 shows a block diagram with a n exemplary parameterization of the
risk exposure for critical illness of the risk exposure components 2 1, 22, 23. The reference
numeral 520 gives the total transferred risk of a specific risk exposure component 2 1, 22,
23 comprising a t least a first risk contribution 5 11, 521 , 531 for a first occurrence of a
critical illness. Further comprised is a second risk contribution 512, 522, 532 related to a
second occurrence of a critical illness. Also comprised can be a third 513, 523, 533 and
subsequent 51i,52i,53i risk contribution; i.e., "i" denotes the i-†h risk distribution.
In case of triggering a n occurrence of a first or second or successional
critical illness 7 1,72,73 on the patient dataflow pathway 2 13,223,233 of a risk exposure
component 2 1, 22, 23, i.e. if a triggering of a n occurrence of a first or second or
successional critical illness 7 1, 72, 73 goes into effect in the patient data flow pathway
213, 223, 233, a corresponding trigger-flag is set by means of the resource-pooling
system 1 and a parametric draw-down or predefined transfer of payments is assigned
to this corresponding trigger-flag. A loss associated with the first or second or
successional critical illness(es) 7 1, 72, 73 is distinctly covered by the resource-pooling
system 1, based o n the respective trigger-flag and based o n the received and stored
payment parameters 214, 224, 234 from risk exposure components 2 1, 22, 23 by the
parametric draw-down or predefined transfer from the resource-pooling system 1 to the
risk exposure component 2 1, 22, 23,e†c. The payment receiving module 4 can, a s a n
input device, comprise one or more data processing units, displays and other operating
elements, such a s a keyboard and/or a computer mouse or another pointing device.
As mentioned previously, the receiving operation of the payments with regard to the
risk exposure components 2 1, 22, 23 is monitored based on the stored componentspecific
payment parameters in the payment data store 6. The different components of
the resource-pooling system 1, such a s e.g. the payment receiving module 4 with the
core engine 3 and the assembly module 5 can be connected via a network for signal
transmission. The network can comprise, e.g., a telecommunications network, such a s a
wired or wireless network, e.g., the internet, a GSM network (Global System for Mobile
Communications), a n UMTS network (Universal Mobile Telecommunications System)
and/or a WLAN (Wireless Local Area Network), a Public Switched Telephone Network
(PSTN) and/or dedicated point-to-point communication lines. The payment receiving
module 4 and/or core engine 3 and the assembly module 5 can also comprise a
plurality of interfaces for connecting to the telecommunications network adhering to
the transmission standard or protocol. As a n embodied variant, the payment receiving
module 4 can also be implemented a s a n external device relative to the resourcepooling
system 1, which provides the risk transfer service via the network for signal
transmission, e.g. by a secured data transmission line.
A first parametric payment 2 11 is transferred by triggering the occurrence
1001 of the critical illness 7 1, 72, 73 by means of the critical illness trigger 3 1 of the core
engine 3, thus triggering the measuring parameters of the specific risk exposure
component 2 1, 22, 23 in the related patient data flow pathway 213, 223, 233.The core
engine 3, analogously to the resource-pooling system 1 and the other components of
the system, is implemented based on underlying electronic components, steering
codes and interacting interface devices, such a s e.g. appropriate signal generation
modules or other modules interacting electronically by means of appropriate signal
generation between the different modules, devices, or the like. For example, the first
parametric payment can be transferred by triggering 3 1 the occurrence 1001 of
measuring parameters indicating the critical illness 7 1, 72, 73 of malignant cancer
and/or smaller incidence of ductal carcinoma in situ (DCIS) and/or early prostate
carcinoma.
A second parametric payment 212 is transferred by triggering measuring
parameters in the patient data flow pathway 213, 223, 233 indicating the initiation of a n
acute treatment phase 1002 by means of the critical illness trigger 32 of the core
engine 3. For example, acute treatment phase parameters 1002 indicating surgery
and/or chemotherapy and/or radiotherapy and/or reconstructive surgery can be
triggered in patient data flow pathway 213, 223, 233 by means of a critical illness trigger
32 of the core engine 3. For example, the second parametric payment can only be
transferred by triggering 32 acute treatment phase parameters 1002, indicating surgery
and/or chemotherapy and/or radiotherapy and/or reconstructive surgery. Finally a
third parametric payment 2 13 is transferred by triggering measuring parameters in the
patient data flow pathway 213, 223, 233 indicating the initiation of a recovery phase
1003 linked to terminal prognosis data by means of the critical illness trigger 33 by the
core engine 3. For example, recovery phase parameters 1003 linked to or associated
with terminal prognosis data are triggered in patient data flow pathway 213, 223, 233
by means of a critical illness trigger 33 by the core engine 3. As a variant, the third
parametric payment is only transferrable by triggering 33 recovery phase parameters
and/or terminal prognosis parameters 1003.
Therefore, if triggering 1001 takes effect, a n occurrence of a first critical
illness 7 1, 72, 73 in the patient dataflow pathway 2 13, 223, 233 of a risk exposure
component 2 1, 22, 23, any associated loss is covered by the resource-pooling system 1
based o n the received and stored payments 214, 224, 234 from risk exposure
components 2 1, 22, 23 by transferring a parametric diagnosis payment 2001 from the
resource-pooling system 1 to the risk exposure component 2 1, 22, 23, etc.; if triggering
1002 takes effect, a n occurrence of a n acute treatment phase in the patient data flow
pathway 2 13, 223, 233 of a n associated loss is covered by the resource-pooling system
1 based on the received and stored payments 214, 224, 234 from risk exposure
components 2 1, 22, 23 by transferring a parametric treatment phase payment 2002
from the resource-pooling system 1 to the risk exposure component 2 1, 22, 23, etc.; and
if triggering 1003 takes effect, a n occurrence of a recovery phase linked to terminal
prognosis data in the patient data flow pathway and associated loss is covered by the
resource-pooling system based o n the received and stored payments 214, 224, 234
from risk exposure components 2 1, 22, 23 by transferring a parametric recovery phase
payment 2003 from the resource-pooling system 1 to the risk exposure component 2 1,
22, 23, etc. The first, second and third parametric payments can, for example, be
leveled by a predefined total payment sum determined at least based on the riskrelated
component data 2 11, 221 , 231 and/or the likelihood of the risk exposure for one
or a plurality of the pooled risk exposure components 2 1, 22, 23, etc., based on the riskrelated
component data 2 11, 221 , 231 , wherein the first parametric payment is
transferred up to 30% of said total payment sum, and the second parametric payment
is transferred up to 50% of said total payment sum, and the third parametric payment is
transferred up to the residual part given by said total payment sum minus the actual first
parametric payment and the second parametric payment. Such a n exemplary
payment draw-down a s it can be provided by the resource-pooling system 1 in the
event of a triggering of a critical illness at a risk exposure component is shown in the
diagram of Figure 3.
As a further technical variant, the critical illness triggers 3 1, 32, 33 comprise
multi-dimensional trigger channels. Each of said trigger-flags is assigned to a first
dimension trigger channel comprising a first trigger-level triggering 3 1 o n occurrence
parameter 1001 of the critical illness 7 1, 72, 73, a second trigger-level triggering 32 o n
acute treatment phase parameter 1002, and a third trigger-level triggering 33 o n
recovery phase parameter 1003 linked to or associated with terminal prognosis data;
and each of said trigger-flags is assigned to a t least a second or higher dimension
trigger channel and comprises additional trigger-stages based on the first, second
and/or third trigger-levels of the first dimension trigger channel. The critical illness trigger
3 1, 32, 33 can e.g. comprise multi-dimensional trigger channels, wherein each of said
trigger-flags is assigned to a first dimension of a trigger channel comprising a first triggerlevel
triggering 3 1 o n occurrence parameter 1001 of the critical illness 7 1, 72, 73, a
second trigger-level triggering 32 o n acute treatment phase parameter 1002, and a
third trigger-level triggering 33 on recovery phase parameter 1003 linked to terminal
prognosis data, and each of said trigger-flags is assigned to a second dimension of a
trigger channel comprising a first trigger-level triggering 3 1 on a first stage of
progression-measuring parameters of the occurrence 1001 with regard to critical illness
7 1, 72, 73, and one or more higher trigger-levels triggering 32, 33 in higher stages of
progression-measuring parameters of the occurred critical illness 7 1, 72, 73.
In addition, the resource-pooling system 1 can be realized such that it
transfers critical illness data in the patient data flow pathway 213, 223, 233 of the
related risk exposure component 2 1, 22, 23, etc., after triggering the occurrence of a
critical illness 7 1, 72, 73, to a n automated employee assistance system (EAP: Employee
Assistance Program) providing automated support to the risk exposure component 2 1,
22, 23, etc. Analogously, by triggering the occurrence of a critical illness 7 1, 72, 73 by
means of the critical illness trigger 3 1 by the core engine 3, critical illness data in the
patient data flow pathway 2 13, 223, 233 of the related risk exposure component 2 1, 22,
23, etc. can be transferred to a n alert system of a n Change Advisory Board (CAB) to
activate automated or at least semi-automated CAB actions.
Finally, in a further specified embodied variant, a n independent verification
critical illness trigger of the resource-pooling system 1 can be activated in the event of
a triggering of the occurrence 1001 of indicators for critical illness 7 1, 72, 73 in the
patient data flow pathway 2 13, 223, 233 of a risk exposure component 2 1, 22, 23, etc.
by means of the critical illness trigger 3 1, and wherein the independent verification
critical illness trigger additionally is triggering with regard to the occurrence 1001
indicators for critical illness 7 1, 72, 73 in a n alternative patient data flow pathway 2 15,
225, 235 with independent measuring parameters from the primary patient data flow
pathway 213, 223, 233 to verify the occurrence 1001 of the critical illness 7 1, 72, 73 at
the risk exposure component 2 1, 22, 23, etc, As a variant, the parametric draw-down or
predefined transfer of payments is only assigned to the corresponding trigger-flag, if the
occurrence 1001 of the critical illness 7 1, 72, 73 at the risk exposure component 2 1, 22,
23, etc. is verified by the independent verification critical illness trigger.
Claims
1. An event-driven critical illness insurance system based o n a resourcepooling
system ( 1 ) for risk sharing of critical illness risks of a variable number of risk
exposure components (21 , 22, 23, ...) by providing a dynamic self-sufficient risk
protection for the risk exposure components (21 , 22, 23, ...) by means of the resourcepooling
system ( 1 ) , wherein the risk exposure components (21 , 22, 23, ...) are
connected to the resource-pooling system ( 1 ) by means of a plurality of paymentreceiving
modules (4) configured to receive and store (6) payments (214, 224, 234) from
the risk exposure components (21 , 22, 23, ...) for the pooling of their risks and resources,
and wherein the resource-pooling system ( 1 ) comprises a n event-driven core engine (3)
comprising critical illness triggers (31 , 32, 33) triggering in a patient dataflow pathway
(21 3, 223, 233) to provide risk protection for a specific risk exposure component (21 , 22,
23, ...) based o n received and stored payments (214, 224, 234) o f the risk exposure
components (21 , 22, 23, ...), characterized
in that the total risk (50) of the pooled risk exposure components (21 , 22, 23,
...) comprises a first risk contribution (51 1, 521 , 531 ) of each pooled risk exposure
components (21 , 22, 23,...) associated to risk exposure in relation to a first diagnosis of a
critical illness, wherein the critical illness (71 , 72, 73) is comprised in a predefined
searchable table (7) o f critical illnesses (71 , 72, 73) and wherein critical illness losses
occur a s a consequence to the first diagnosis of risk exposure components (21 , 22, 23,
...) with one of the searchable critical illnesses,
in that the total risk (50) of the pooled risk exposure components (21 , 22, 23,
...) comprises a t least a second and/or successional risk contributions (512/522/...,
513/521/...) associated to risk exposure in relation to a second and/or successional
critical illnesses, wherein the critical illnesses (71 , 72, 73) are comprised in the predefined
searchable table (7) o f critical illness parameters (71 , 72, 73), and wherein a critical
illness loss losses occurs a s a consequence to the second and/or successional diagnosis
of risk exposure components (21 , 22, 23, ...) with one of the searchable critical illnesses,
and
in that in case of a triggering of a n occurrence of a first or second o r
successional critical illness (71 , 72, 73) in the patient data flow pathway (213, 223, 233)
of a risk exposure component (21 , 22, 23), a loss associated with the first or second or
successional critical illness(es) (71 , 72, 73) is distinctly covered by the resource pooling
system ( 1 ) by means of a parametric transfer of payments from the resource-pooling
system ( 1 ) to the risk exposure component (21 , 22, 23, ...).
2. The system ( 1 ) according to claim 1, wherein the critical illness triggers (31 ,
32, 33) comprise a trigger (31 ) for triggering the occurrence of measuring parameters
indicating a heart attack and/or cancer and/or a stroke and/or coronary artery by
pass surgery in the patient dataflow pathway (213, 223, 233).
3. The system ( 1 ) according to claim 2, wherein the critical illness triggers (31 ,
32, 33) further comprise a trigger (31 ) for triggering the occurrence of measuring
parameters indicating Alzheimer's disease, blindness, deafness, kidney failure, major
organ transplant, multiple sclerosis, HIV/AIDS contracted by blood transfusion or during
a n operation, Parkinson's disease, paralysis of limb, terminal illness in the patient
dataflow pathway (213, 223, 233).
4. The system ( 1 ) according to one of the claims 1 to 3, wherein the
resource-pooling system ( 1 ) comprises a n assembly module (5) to process risk-related
component data (21 1, 221 , 231 ) and to provide the likelihood (212, 222, 232) of said risk
exposure for one or a plurality of the pooled risk exposure components (21 , 22, 23, ...)
based o n the risk-related component data (21 1, and wherein the receiving and
preconditioned storage (6) of payments (214, 224, 234) from risk exposure components
(21 , 22, 23, ...) for the pooling of their risks is dynamically determinable based o n total
risk (50) and/or the likelihood of the risk exposure of the pooled risk exposure
components (21 , 22, 23, ...).
5. The system ( 1 ) according to one of the claims 1 to 4, wherein the number
of pooled risk exposure components (21 , 22, 23, ...) is dynamically adaptable by means
of the resource-pooling system ( 1 ) to a range where non-covariant occurring risks
covered by the resource-pooling system ( 1 ) affect only a relatively small proportion of
the totally pooled risk exposure components (21 , 22, 23, ...) at a given time.
6. The system ( 1 ) according to one of the claims 1 to 5, wherein the critical
illness triggers (31 , 32, 33) are dynamically adapted by means of a n operating module
(30) based on time-correlated incidence data for a critical illness conditions and/or
diagnosis or treatment conditions indicating improvements in diagnosis or treatment.
7. The system ( 1 ) according to one of the claims 1 to 6, wherein upon each
triggering (31 ) of an occurrence (1001 ) of measuring parameters indicating a critical
illness (71 , 72, 73), a total parametric payment is allocated with the triggering, wherein a
first portion of the totally allocated payment is transferrable upon triggering (31 ) the
occurrence (1001 ) .
8. The system ( 1 ) according to one of the claims 1 to 7, wherein the critical
illness triggers further comprise triggers triggering (32) acute treatment phase
parameters ( 1002) indicating surgery and/or chemotherapy and/or radiotherapy
and/or reconstructive surgery in the patient dataflow pathway (213, 223, 233).
9. The system ( 1 ) according to claim 8, wherein a second portion of the
allocated total parametric payment is transferrable upon triggering (32) of acute
treatment phase parameters (1002) indicating surgery and/or chemotherapy and/or
radiotherapy and/or reconstructive surgery.
10. The system ( 1 ) according to one of the claims 1 to 9, wherein the critical
illness triggers (31 ,32,33) further comprise triggers (33) triggering recovery phase
parameters (1003) associated with or linked to terminal prognosis data in patient
dataflow pathway (213, 223, 233).
11. The system (1) according to claim 10, wherein a third portion of the
allocated total parametric payment is transferrable upon triggering (33) of a recovery
phase parameter and/or terminal prognosis parameter (1003).
12. The method according to one of the claims 7 to 11, wherein the first and
second and third transferred portion of payment are generatable to sum up to the
allocated total parametric payment.
13. The system ( 1 ) according to one of the claims 7 to 12, wherein the
allocated total parametric payment is determined at least based on the risk-related
components data (21 1, 221 , 231 ) and/or on the likelihood of the risk exposure for one or
a plurality of the pooled risk exposure components (21 , 22, 23, ...) based on the risk
related components data 2 11, 221 , 231 and wherein the first portion is transferred up to
30% of said total payments sum and the second portion is transferred up to 50% of said
total payments sum and the third portion is transferred up to the residual part given by
said total payment sum minus the actual portion and the second portion.
14. The system ( 1 ) according to one of the claims 1 to 13, wherein the
resource-pooling system ( 1 ) comprises a monitoring module (8) requesting a periodic
payment transfer from the risk exposure components (21 , 22, 23, ...) to the resourcepooling
system ( 1 ) by means of a plurality of payment receiving modules (2), wherein
the risk protection for the risk exposure components (21 , 22, 23, ...) is interrupted by the
monitoring module (8) when the periodic transfer is no longer detectable by means of
the monitoring module (8).
15. The system ( 1 ) according to claim 14, wherein the request for periodic
payment transfer is interrupted or waived by the monitoring module (8) when the
occurrence (1001 ) of indicators for critical illness (71 ,72,73) is triggered (31 ) in a patient
data flow pathway of a risk exposure component (21 , 22, 23, ...).
1 . The system ( 1 ) according to one of the claims 1 to 15, wherein the
resource-pooling system ( 1 ) comprises a n independent verification critical illness trigger,
which is activated in the event of a triggering of the occurrence (1001 ) of indicators for
critical illness in the patient dataflow pathway (213, 223, 233) of a risk exposure
component (21 , 22, 23, ...) by means of the critical illness trigger (31 ) and which
additionally, is a triggering for the occurrence (1001 ) of indicators for critical illness (71 ,
72, 73) in a n alternative patient dataflow pathway (215, 225, 235) with independent
measuring parameters from the primary patient data flow pathway (213, 223, 233) to
verify the occurrence of the critical illness (71 ,72,73) a t the risk exposure component (21 ,
22, 23, ...).
17. The system ( 1 ) according to claim 1 , wherein the parametric transfer of
payments is only assigned to the corresponding trigger-flag, if the occurrence (1001 ) of
the critical illness (71 ,72,73) a t the risk exposure component (21 , 22, 23, ...) is verified by
the independent verification critical illness trigger.
18. The system ( 1 ) according to one of the claims 1 to 17, wherein critical
illness data of the patient dataflow pathway (213, 223, 233) of the risk exposure
component (21 , 22, 23, ...) are transferred to a n automated employee assistance
system (EAP: Employee Assistance Program) providing automated support to the risk
exposure component (21 , 22, 23, ...).
19. The system ( 1 ) according to one of the claims 1 to 18, wherein the
patient dataflow pathway (213, 223, 233) is monitored by the resource-pooling system
( 1 ) by capturing patient measuring parameter of the patient dataflow pathway (213,
223, 233) a t least periodically and/or within predefined time frames.
20. The system ( 1 ) according to one of the claims 1 to 19, wherein the
patient dataflow pathway (213, 223, 233) is dynamically monitored by the resourcepooling
system ( 1 ) by a triggering of patient measuring parameters of the patient
dataflow pathway (213, 223, 233) transmitted from associated measuring systems.
2 1. An method for risk sharing of critical illness risks of a variable number of
risk exposure components (21 , 22, 23, ...) by providing a dynamic self-sufficient risk
protection for the risk exposure components (21 , 22, 23, ...) by means of the resourcepooling
system ( 1 ) , wherein the risk exposure components (21 , 22, 23, ...) are
connected to the resource-pooling system ( 1 ) by means of a plurality of payment
receiving modules (4) and payment data (214, 224, 234) are received and stored by
means of a payment data store (6) from the risk exposure components (21 , 22, 23, ...)
for the pooling of their risks, and wherein the resource-pooling system ( 1 ) triggers a
patient dataflow pathway (213, 223, 233) by means of critical illness triggers (31 , 32, 33)
of a n event-driven core engine (3) in order to provide risk protection for a specific risk
exposure component (21 , 22, 23, ...) based on received and stored payments (214, 224,
234) from the risk exposure components (21 , 22, 23, ...), characterized
in that a first risk contribution (51 1, 521 , 531 ) of each pooled risk exposure
components (21 , 22, 23,...) related to a first diagnosis of a critical illness (71 ,72,73) is
associated with risk exposure of each pooled risk exposure components (21 , 22, 23,...)
and the total risk (50) of the pooled risk exposure components (21 , 22, 23, ...) by means
of the resource-pooling system ( 1 ) , wherein the critical illness (71 , 72, 73) is comprised in
a predefined searchable table (7) of critical illnesses (71 , 72, 73) and wherein critical
illness losses occur a s a consequence †o the first diagnosis of risk exposure components
(21 , 22, 23, ...) with one of the searchable critical illnesses,
in that a first risk contribution (51 1, 521 , 531 ) of each pooled risk exposure
component (21 , 22, 23,...) related to a second and/or successional risk contributions
(51 2/522/..., 5 13/521/...) diagnosis of a critical illness (71 ,72,73) is associated to risk
exposure of each pooled risk exposure component (21 , 22, 23,...) and the total risk (50)
of the pooled risk exposure components (21 , 22, 23, ...) by means of the resourcepooling
system ( 1 ) , wherein the critical illness (71 ,72,73) is comprised in the predefined
searchable table (7) of critical illnesses (71 , 72, 73) and wherein critical illness losses
occur a s a consequence of the second and/or successional diagnosis of risk exposure
components (21 , 22, 23, ...) with one of the searchable critical illnesses, and
in that, in case of a triggering of a n occurrence of a first or second or
successional critical illness (71 , 72, 73) in the patient data flow pathway (213, 223, 233)
of a risk exposure component (21 , 22, 23) a loss associated to the first or second or
successional critical illness (71 , 72, 73) is distinctly covered by the resource-pooling
system ( 1 ) by means of a parametric transfer of payments from the resource-pooling
system ( 1 ) to the risk exposure component (21 , 22, 23, ...) based on the received and
stored payment parameters (214, 224, 234) of the risk exposure components (21 , 22, 23).
22. The method according to claim 2 1, wherein the occurrence (1001 ) of
measuring parameters indicating a heart attack and/or cancer and/or a stroke and/or
coronary artery by-pass surgery are triggered in the patient dataflow pathway (213,
223, 233) by means of a critical illness trigger (31 ) of the core engine (3).
23. The method according to claim 22, wherein the occurrence (1001 ) of
measuring parameters indicating Alzheimer's disease, blindness, deafness, kidney
failure, major organ transplant, multiple sclerosis, HIV/AIDS contracted by blood
transfusion or during a n operation, Parkinson's disease, paralysis of limb, terminal illness
are triggered in the patient dataflow pathway (213, 223, 233) by means of a critical
illness trigger (31 ) of the core engine (3).
24. The method according to one of the claims 2 1 to 23 , wherein riskrelated
component data (21 1, 221 , 231 ) are processed by a n assembly module (5) of
the resource-pooling system ( 1 ) and the likelihood (212, 222, 232) of said risk exposure is
provided by means of the assembly module (5) for one or a plurality of the pooled risk
exposure components (21 , 22, 23, ...) based on the risk-related component data (21 1,
221 , 231 ) , and wherein the receiving and preconditioned storage (6) of payments (214,
224, 234) from risk exposure components (21 , 22, 23, ...) for the pooling of their risks is
dynamically determined based on total risk (50) and/or the likelihood of the risk
exposure of the pooled risk exposure components (21 , 22, 23, ...).
25. The method according to one of the claims 2 1 to 24, wherein the
number of pooled risk exposure components (21 , 22, 23, ...) is dynamically adapted by
means of the resource-pooling system ( 1 ) to a range where non-covariant occurring
risks covered by the resource-pooling system ( 1 ) affect only a relatively small proportion
of the totally pooled risk exposure components (21 , 22, 23, ...) a t a given time.
26. The method according to one of the claims 2 1 to 25, wherein the critical
illness triggers (31 , 32, 33) are dynamically adapted by means of a n operating module
(30) based on time-correlated incidence data for critical illness conditions and/or
diagnosis or treatment conditions indicating improvements in diagnosis or treatment.
27. The method according to one of the claims 2 1 to 26, wherein upon
each triggering (31 ) of a n occurrence (1001 ) of measuring parameters indicating a
critical illness (71 , 72, 73), a total parametric payment is allocated with the triggering
wherein a first portion of the totally allocated payment is transferred upon triggering
(31 ) the occurrence (1001 ) .
28. The method according to claim 27, wherein acute treatment phase
parameters (1002) indicating surgery and/or chemotherapy and/or radiotherapy
and/or reconstructive surgery is/are triggered in the patient dataflow pathway (213,
223, 233) by means of a critical illness trigger (32) of the core engine (3).
29. The method according to claim 28, wherein a second portion of the
allocated total parametric payment is transferred upon triggering (32) of acute
treatment phase parameters (1002) indicating surgery and/or chemotherapy and/or
radiotherapy and/or reconstructive surgery.
30. The method according to one of the claims 29 to 28, wherein recovery
phase parameters (1003) linked to terminal prognosis data are triggered in a patient
data flow pathway (213, 223, 233) by means of a critical illness trigger (33) of the core
engine (3).
3 1. The method according to claim 30, wherein a third portion of the
allocated total parametric payment is transferred upon triggering (33) of a recovery
phase parameter and/or terminal prognosis parameter (1003).
32. The method according to one of the claims 27 to 3 1, wherein the first
and second and third transferred portion of payment are generated to sum up to the
allocated total parametric payment.
33. The method according to one of the claims 27 to 32, wherein the
allocated total parametric payment is determined at least based on the risk-related
component data (21 1, 221 , 231 ) and/or on the likelihood of the risk exposure for one or
a plurality of the pooled risk exposure components (21 , 22, 23, ...) based on the riskrelated
component data 2 11, 221 , 231 ) , and wherein the first portion of payment is
transferred up to 30% of said allocated total parametric payment and the second
portion is transferred up to 50% of said allocated total parametric payment and the
third portion is transferred up to the residual part given by said total payment sum minus
the actual first portion and the second portion.
34. The method according to one of the claims 2 1 to 33, wherein the
periodic payment transfer from the risk exposure components (21 , 22, 23, ...) to the
resource-pooling system ( 1 ) via a plurality of payment receiving modules (2) is
requested by means of a monitoring module (8) of the resource-pooling system ( 1 ) ,
wherein the risk transfer or protection for the risk exposure components (21 , 22, 23, ...) is
interrupted by the monitoring module (8) when the periodic transfer is no longer
detectable by means of the monitoring module (8).
35. The method according to claim 34, wherein the request for periodic
payment transfer is interrupted or waived by means of the monitoring module (8) when
the occurrence (1001 ) of indicators for critical illness (71 ,72,73) is triggered (31 ) on
patient dataflow pathway of a risk exposure component (21 , 22, 23, ...).
36. The method according to one of the claims 2 1 to 35, wherein a n
independent verification critical illness trigger of the resource-pooling system ( 1 ) is
activated in case of triggering the occurrence (1001 ) of indicators for critical illness (71 ,
72, 73) in a patient dataflow pathway (21 3, 223, 233) of a risk exposure component (21 ,
22, 23, ...) by means of the critical illness trigger (31 ) and wherein the independent
verification critical illness trigger is, additionally a triggering for a n occurrence (1001 ) of
indicators of critical illness (71 , 72, 73) in a n alternative patient data flow pathway (215,
225, 235) with independent measuring parameters from the primary patient dataflow
pathway (213, 223, 233) to verify the occurrence (1001 ) of the critical illness (71 ,72,73) a t
the risk exposure component (21 , 22, 23, ...).
37. The method according to claim 36, wherein the parametric draw-down
transfer of payments is only assigned to the corresponding trigger-flag, if the
occurrence (1001 ) of the critical illness (71 ,72,73) a t the risk exposure component (21 ,
22, 23, ...) is verified by the independent verification critical illness trigger.
38. The method according to one of the claims 2 1 to 37, wherein critical
illness data of the patient dataflow pathway (213, 223, 233) of the risk exposure
component (21 , 22, 23, ...) are transferred to a n automated employee assistance
system (EAP: Employee Assistance Program) providing automated support to the risk
exposure component (21 , 22, 23, ...).
40. The method according to one of the claims 2 1 to 39, wherein the
patient dataflow pathway (213, 223, 233) is monitored by the resource-pooling system
( 1 ) by capturing patient measuring parameter of the patient data flow pathway (21 3,
223, 233) a t least periodically and/or within predefined time frames.
4 1. The method according to one of the claims 2 1 to 40, wherein the
patient dataflow pathway (21 3, 223, 233) is dynamically monitored by the resourcepooling
system ( 1 ) by triggering of patient measuring parameters of the patient
dataflow pathway (213, 223, 233) transmitted from associated measuring systems.