WO2008052289A1

WO2008052289A1 - An insurance system

Info

Publication number: WO2008052289A1
Application number: PCT/AU2007/001688
Authority: WO
Inventors: Gerard Wolfe Sormann
Original assignee: Surgicover Pty Ltd
Priority date: 2006-11-02
Filing date: 2007-11-02
Publication date: 2008-05-08

Abstract

An insurance system including a data acquisition module for acquiring event data including personal data, medical treatment data and beneficiary data; a risk module for processing the event data using risk criteria rules to determine acceptance of an insurance policy; and a delivery module for providing a policy document for the policy, in response to the acceptance, processing payment for the policy, and issuing the policy. The medical treatment data includes period data representing a time of medical treatment, and the policy covers death within the time of a person identified by the personal data and subjected to the medical treatment.

Description

AN INSURANCE SYSTEM

FIELD

The present invention relates to an insurance system.

BACKGROUND

Life insurance policies are typically acquired by individuals to cover any event that may cause death during a person's life. The term of the policy is normally indefinite and yearly premiums apply that increase as the policy holder ages. The policies are rarely taken out by individuals less than 30 years of age, and they tend to be acquired once an individual has obtained a significant level of ongoing financial commitments and/or dependents. Other detracting factors associated with the acquisition of life insurance policies include the disclosure burdens, both medical and financial, that may be placed on a prospective policy holder. For example, a stringent series of medical tests may need to be undertaken before a certain level of life insurance cover will be provided under a policy.

All of the above restricts and inhibits individuals from acquiring policies in circumstances where they would be clearly better served if some form of life insurance cover was provided. Accordingly, it is desired to provide at least a useful alternative, and preferably a system that conveniently and efficiently allows a person to acquire life insurance cover, in particular prior to potentially life threatening medical treatment.

SUMMARY

In accordance with the present invention there is provided an insurance system including: a data acquisition module for acquiring event data including personal data, medical treatment data and beneficiary data; a risk module for processing said event data using risk criteria rules to determine acceptance of an insurance policy; and a delivery module for providing a policy document for said policy, in response to said acceptance, processing payment for said policy, and issuing said policy.

The present invention also provides an insurance process including: obtaining event data including personal data for a person, medical treatment data and beneficiary data; processing said event data using risk rules to determine acceptance of an insurance policy for the death of said person during medical treatment represented by said treatment data; and issuing said policy, in response to said acceptance and processing payment for said policy.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of a preferred embodiment of an insurance system; and Figure 2 is a flow diagram of processes performed by the insurance system.

DESCRIPTION OF PREFERRED EMBODIMENTS

An insurance system, as shown in Figure 1, includes central insurance server 100 that is able to connect to and communicate with dispensing kiosks 110 and client computer systems 112 using a communications network 114, such as the Internet. The kiosks 110 and computer systems 112 are used for purchasing life insurance policies.

The kiosks 110 are located in the waiting areas and admission rooms of public and private hospitals, medical clinics and day surgery centres etc, where potentially life threatening medical treatments are to be performed. The treatments include various types of surgical and dental intervention usually involving a general or light anaesthesia. The computer system terminals 112 are used by doctors or staff at the treatment facility to obtain a policy on behalf of a patient. Alternatively, a computer system terminal 112 can be used by a patient to purchase a policy over the Internet prior to arriving at the hospital, clinic or day surgery centre.

The insurance policy distributed by the insurance system is a short term or temporary policy which covers the event of death caused as a result of or during the medical treatment. The term of the policy corresponds to the period of the treatment for the stay in the hospital clinic or day surgery centre. The restricted term and coverage of the policy assists in enabling the policy to be conveniently processed, analysed, purchased and issued by the insurance system 100.

A kiosk terminal 110, as shown in Figure 1, includes a keyboard 120 mounted on a stand 122 adjacent a screen display 124 of the kiosk. The stand 122 is a part of a cabinet 124 of the kiosk 110 that places the keyboard 120 and the screen display 124 at a height allowing a person to approach, stand and use both the keyboard 120 and screen display 124. According to one preferred embodiment, the cabinet 124 holds a personal computer 130, such as that produced by Lenovo Corporation or Apple Computer Inc, which can also be used to provide the computer system 112. Accordingly, the screen display 124 and the keyboard 120 are connected to the personal computer 130 and are the same as that would normally be provided with and connected to a personal computer 130. The personal computer 130 runs an operating system, such as Microsoft Windows or Mac OS X 132, and a web browser 134, such as Internet Explorer, Safari or FireFox.

For the personal computer 130 in the cabinet 124 of the kiosk 110, the communications configuration data is set so that the browser is only able to connect to the insurance server 100. The computer is also connected to a card reader 126 and a printer 128. The card reader 126 is for reading card detail data from payment cards, such as credit cards, and the printer 128 is used to print documents, such as receipts and policy documents. A number of alternative embodiments are available for the kiosk 110. Dedicated hardware circuits may be used to replace components of the computer 130 and used to implement the processes performed. Processes and components of the insurance server 100 can also be incorporated within the kiosk 110. This can be done even to the extent that circuits are used to perform the entire processes performed by the insurance server 110 so that no communication is required over the communications network 114 to deliver a policy document. Even payment data to attend to a payment could be processed and then payment completed offline at a particular time of day.

The insurance server 100 includes a computer server 140, such as that produced by IBM Corporation or Apple Computer Inc. The computer server 140 runs an operating system 142, such as Windows Server 2003 or Unix, and a database server 144, such as MySQL, that is used to maintain a database 150. The database 150 holds a number of relational database tables with policy data, event data, risk criteria rules etc, that is operated on by the insurance server 100. The insurance server also includes a data acquisition module 152, a risk module 154, a delivery module 156 and a web server 146, such as Apache, that also runs on the operating system 142. The components 142, 144, 146, 152, 154 and 156 control the processes performed by the insurance server 100, as described below. The components 152, 154 and 156 are implemented in computer program instruction code using languages, such as C++, Java, HTML and Java Server Pages (JSP). Other implementations are also possible. For example, the processes performed by the components 142 to 156 may be implemented at least in part by dedicated hardware circuits, such as ASICs or FPGAs. The server 140 and its components may also be distributed amongst a number of devices or computers connected by the communications network 114, which may include a local area network (LAN).

The insurance system performs a process 200, as shown in Figure 2. The acquisition module 152 polls for HTTP requests (step 202) from the web browser of a kiosk 110 or a computer system 112 when invoked. On determining a HTTP request has been received, the acquisition module 152 and the web server 146 deliver pages of a website that provide access to initial information screens concerning a temporary life insurance policy for medical treatment (204). The pages seek to illicit submission of a request for the policy, and include submission forms for users to enter event data using a kiosk 110 or system 112. The event data includes personal data, medical treatment data and beneficiary data. The personal data is associated with the patient, and includes data representing full name, address, contact details, such as phone numbers, age and any physiological risk factors or historical data that may be required by the system. The policy if accepted and issued will be in the name of the patient. The treatment data includes data relating to the procedure or treatment to be performed at the hospital, clinic or day centre. This will include details of the treatment facility and the doctors involved. The treatment may include specified surgical procedures within the following surgical fields: General; Orthopaedics; Vascular; Cardiothoracic; Urology; Plastic; Neurosurgery; Ear, nose & throat; Obstetrics & gynaecology; Paediatrics; Oral & maxillofacial; and Dental. The treatment data includes period data representing time information associated with the treatment.

The beneficiary data represents personal details of the parties who will benefit from a payment made under the policy in the event of death during the treatment during the term of the policy.

Once the event data has been submitted and received (204) by the data acquisition module 152, the data is stored in the database tables against an identifier for the patient. The risk analysis module 154 then performs a risk analysis process (206) to determine whether the event data meets risk criteria defined by a series of procedural rules stored in the database 150. The rules are accessed and processed using the event data. The rules are for the different types of medical treatment that may be covered under a policy. The rules may also determine whether the treatment facility (hospital, medical centre, etc.) is registered by the requisite Government authorities and the practitioners, eg surgeons and anaesthetists, are similarly in good standing with the relevant Medical Boards or regulatory authority. The rules also define certain basic exemptions and exclusions of the risk criteria, such as excluding treatments required as a result of trauma (such as that caused in vehicle accidents) and age based limitations that would exclude patients younger than 18 and older than 70 years. Mortality rates above 70 are low, but mortality rates below 70 years of age are extremely low. The rules also define more complicated risk criteria based on surgical mortality rate data for procedures. For example, the data held in the database 150 would include anaesthetic and surgical mortality rate data, which may vary from state to state or country to country, such as that available from (i) the Safety of Anaesthesia in Australia report published by the Australian and New Zealand College of Anaesthetists and outlined in Tables 1 and 2 below; and (ii) the Western Australian Audit of Surgical Mortality published in the Medical Journal of Australia, which relates to approximately 150,000 operations in total and is summarised in Table 3 below.

Table 1

Table 2

Table 3

The risk analysis module 154 is advantageously able to determine acceptance or not of a policy immediately, prior to the treatment, on the basis of the data acquired by the acquisition module 152.

If the risk analysis module 154 determines that the risk criteria is met (step 208), then an acceptance page or pages of the site are generated and delivered (210) by delivery module 156 using the web server 146. The acceptance page(s) advises of acceptance of a policy for the patient, and displays data setting out the conditions and terms of the policy for a user of the kiosk 110 or system 112. Payment for the policy is also requested. Typical terms and conditions may involve a payment of $25,000 to a beneficiary on death for a policy payment of $200. The policy payment and the payment to one or more beneficiaries can be varied based on the event data, such as increasing the policy payment based on age of the patient. The period or term of the policy will correspond to the time of treatment. For example, the term of the policy may extend from commencement of the anaesthetic to discharge from hospital, medical or day surgery centre or within 7 days from issuance, whichever is the shorter period. Payment data for the payment is requested on the acceptance page, which may include a form allowing the entry of credit card detail data. Credit card detail data can also be obtained using the card reader 126 which may be swiped by a user of the kiosk 110. The payment data, including the credit card details and the payment amount, once submitted to the delivery module 156, is used by the delivery module 156 to perform a payment process (212) using a payment processing system 160, such as an electronic funds transfer point of sale (EFTPOS) network. Once payment has been obtained (212) the delivery module 156 generates a final policy document for the policy and transmits it to the kiosk 110 or system 112, where the document can be printed for the user, and available to the policy holder. The document includes and describes all of the terms and conditions of the policy. By transmitting the document successfully to the kiosk 110 or the system 112, the policy is issued (214). If the risk criteria is not met (208) or payment is not successfully processed (212) then the system generates a deny message (216) for display on the screen 124.

Information for the event data could also be obtained as part of the admission procedure, and the payment for the policy incorporated as part of the admission and procedure costs. A staff member handling the admission may then use a terminal 112 to submit the event data and payment details to attend to issuance of the policy.

The insurance cover can also be provided as an extension to existing policies or as an addition to more extensive policies. For example the death cover for a period of time corresponding to a time of medical treatment can be provided as:

(i) an additional option or requirement of any external finance provided to cover the medical treatment; (ii) an additional option or benefit to existing types of personal health insurance including individual and family policies; (iii) an additional option or benefit to existing group health insurance policies such as those provided by employers; (iv) an additional uplift on current life insurance policies; and

(v) a special benefit added to any insurance policy.

Sudden death following elective surgery has severe consequences for family members other than the obvious emotional ones, and the system helps alleviate possible financial difficulties encountered with a sudden loss of income, particularly if the deceased has one or more dependents. The policy may be paid, say, within 10 days, irrespective of any fault by the practitioners or by the treatment facility, subsequent to provision of clear determination of the events associated with death of patient, eg provision of Death Certificate or Coroner's report.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

1. An insurance system including: a data acquisition module for acquiring event data including personal data, medical treatment data and beneficiary data; a risk module for processing said event data using risk criteria rules to determine acceptance of an insurance policy; and a delivery module for providing a policy document for said policy, in response to said acceptance, processing payment for said policy, and issuing said policy.

2. An insurance system as claimed in claim 1, wherein the medical treatment data includes period data representing a time of medical treatment.

3. An insurance system as claimed in claim 2, wherein said policy includes a term corresponding to said time.

4. An insurance system as claimed in claim 3, wherein said risk criteria rules are based on surgical mortality rate data to determine said acceptance, and said rules deny said acceptance for a person, represented by said personal data, having an age in at least one excluded range.

5. An insurance system as claimed in claim 3, wherein said risk criteria rules deny said acceptance for a treatment, represented by said medical treatment data, that is set as excluded.

6. An insurance system as claimed in claim 3, wherein said event data includes physiological data representing physiological factors associated with said medical treatment of a patient represented by said personal data.

7. An insurance system as claimed in any one of claims 3 to 6, wherein said policy covers death within said time of a person identified by said personal data and subjected to said medical treatment.

8. An insurance system as claimed in claim 7, including a terminal for use for a patient to communicate with a computer system including said data acquisition module, said risk module and said delivery module.

9. An insurance system as claimed in claim 8, wherein said terminal is a kiosk in a medical treatment facility for use by patients, and said kiosk includes a card reader and payment communications means.

10. An insurance process including: obtaining event data including personal data for a person, medical treatment data and beneficiary data; processing said event data using risk rules to determine acceptance of an insurance policy for the death of said person during medical treatment represented by said treatment data; and issuing said policy, in response to said acceptance and processing payment for said policy.

11. An insurance process as claimed in claim 10, wherein the medical treatment data includes period data representing a time of medical treatment.

12. An insurance process as claimed in claim 11, wherein said policy has a term corresponding to said time.

13. An insurance process as claimed in claim 12, wherein said risk criteria rules are based on surgical mortality rate data to determine said acceptance, and said rules deny said acceptance for a person, represented by said personal data, having an age in at least one excluded range.

14. An insurance process as claimed in claim 13, wherein said risk criteria rules deny said acceptance for a treatment, represented by said medical treatment data, that is set as excluded.

15. An insurance process as claimed in claim 12, wherein said event data includes physiological data representing physiological factors associated with said medical treatment of a patient represented by said personal data.

16. Computer program instructions stored on storage media for use in performing a process as claimed in any one of claims 10 to 15.

17. A policy document for an insurance policy covering death of a person within a period of time corresponding to a time of a medical treatment performed on said person.

18. A policy document, as claimed in claim 17, generated by an insurance system as claimed in any one of claims 1 to 9.

19. A policy document, as claimed in claim 17, generated by an insurance system as claimed in claim 8 or 9, wherein said document is printed by said terminal for said patient before said treatment.