AU2009219114B2 - An electronic claims and payment system - Google Patents

Abstract

The invention concerns an electronic claims and payment system and method. The system includes a transaction device (TD) to obtain member identifier data, member provider data, and transaction request data representative of a type and a value of a service purchased. A router communicatively coupled to the TD and a member provider which comprises a processor to (1) receive from the TD, and route to the member provider, transaction request data, associated member identifier data and member provider data and (2) receive from the member provider, and route to the TD, data representative of a first portion of the value of the service, which is to be paid by the purchaser and a second portion of the value of the service, which is to be reimbursed to a supplier of the service. The TD is further operable to receive data representative of payment of the first portion of the value of the service, and in response, instruct the member provider to credit of the supplier with the second portion of the value of the service.

Description

WO 2009/105831 PCT/AU2009/000238 1 "An electronic claims and payment system" Cross-Reference to Related Applications The present application claims priority from Australian Provisional Patent 5 Application No 2008901005 filed on 29 February 2008, the content of which is incorporated herein by reference. Technical Field The present invention relates to an electronic claims and payment system. The 10 present invention further relates to a method for processing electronic claim transactions. The present invention has particular application to the processing of health insurance claims. Background of the Invention 15 Governments in the majority of industrialized countries take responsibility for a certain degree of the cost of health care of its citizens. These citizens are then able to voluntarily take out private health insurance to, for instance, pay for additional services not covered by the government such as dental, physiotherapy, optical, dietary advice and some alternative therapies. 20 The amount of benefit that a private health insurer can provide to a member depends on the type of treatment, or service, that the member has received and the level of that member's cover. A large proportion of health funds do not cover the whole cost of its member's treatments, irrespective of a member's level of cover. The difference between the cost of the treatment, or service, and the benefit provided by the insurer is 25 referred to as the GAP. Insurers are adversely affected by the existence of fraud by health care providers. In order to reduce the level of GAP payable on a single service which a patient has received, or eliminate the GAP entirely, health care providers are able to add additional services to a claim, services which the patient may not have received, to 30 generate a greater rebate from the insurer. The level of rebate received may cover the cost of the legitimate service, or even exceed it. The patient and the health care provider benefit at the expense of the insurer. Measures to control fraud are generally not undertaken in real time. Detection of fraud may occur when an insurance company or the tax office undertakes an audit, 35 analyzing historical claims databases some time after a claim has been paid. Such 2 measures are reactive. Proactive measures are desirable, however real time claim processing functionality and measures to control fraud are usually not well integrated. Summary of the Invention 5 Some embodiments relate to an electronic claims and payment system comprising: a transaction device operable to obtain member identifier data and member provider data, and to obtain transaction request data representative of a type, and a value, of a good, or service, purchased; and 10 a host router communicatively coupled to the transaction device and a member provider, the host router comprising a processor operable to: receive from the transaction device, and route to the member provider, transaction request data, associated member identifier data and member provider data; and 15 receive from the member provider, and route to the transaction device, data representative of a first portion of the value of the good, or service, which is to be paid by the purchaser and a second portion of the value of the good, or service, which is to be reimbursed to a supplier of the goods or service; wherein the transaction device is further operable to electronically receive data 20 representative of payment of the first portion of the value of the good or service, and in response to compile a message to be routed to the member provider, the message instructing the member provider to credit the supplier with the second portion of the value of the good or service. The transaction device may comprise a memory module and a processor 25 operable to execute software stored on the memory module. The software comprises a claims application to compile a claim authorization request, the claim authorization request including at least the member identifier data, member provider data, and transaction request data. The software may further comprise a payments application to compile a 30 payment authorization request. The payments application may include any one or more of an EFTPOS payments application, a credit card payments application, a linked credit card payments application, and any other like payments application capable of processing a payment from a purchaser. The linked credit card payment application may process a payment from an account which is linked to a financial institution which 35 sponsors the transaction device.

3 Preferably the payments application and the claims application are discrete applications. The memory module may include a public data area. The public data area is an area in memory which enables data sharing between the claims application and the 5 payments application without compromising the separateness of the respective applications. Optionally, the software may further comprise an overarching application which controls each of the claims application and the payments application. The transaction device may further comprise one or more of a card communications module, a keypad and a peripheral communications module. The 10 peripheral communications module may comprise at least one of a display, a transmitter, and a printer. In one embodiment the card communications module comprises a card reader operable to obtain member identifier data and member provider data stored on a card. The transaction device may further comprise a separate data input means to obtain 15 transaction request data representative of a type, and a value, of a good, or service, purchased. The card reader may be adapted to read a smart chip embedded in, or applied to, the surface of a card. Optionally, or in addition, the card reader may be adapted to read a magnetic strip embedded in a card. Optionally, or in addition, the card reader may be 20 adapted to read a contactless card. In a further embodiment the transaction device may be a virtual terminal. The virtual terminal may be in the form of a secure webpage accessible over the internet. The electronic claims and payment system may be communicatively coupled to a payments router. 25 Preferably the payments router is operable to forward a payment authorization request issued by the payments application of the transaction device to the payments host. The payments router may have a contractual relationship with other financial institutions to provide for electronic transfer of funds in relation to acquired goods and 30 services. Preferably the transaction device is operable to send, via the payments router, to the payments host, a payment authorization request, and to receive from the payments host, a payment authorization reply, the authorization reply indicative of whether or not authorization of payment has occurred. The payments router, on receiving the 35 authorization reply, preferably forwards the authorization reply to the transaction 4 device. The authorization reply preferably includes the amount of payment. Preferably a copy of the authorization reply is stored in the public data area. Preferably, the host router further comprises a memory coupled to the host processor. The processor of the host router may be operable to execute software stored 5 on the memory. Whilst it is preferred that the payments application and the claims application are discrete applications, in an optional embodiment the claims application may be able to communicate with the payments application. In such an embodiment, the claims application is preferably operable to process information pertaining to the type of 10 account which is to be debited the first portion of the value of the goods or service. This information is preferably forwarded to the processor of the host router, via the router. The software stored to the memory of the router may comprise a bonus application operable to calculate an amount by which the first portion of the value of 15 the goods or service is to be reduced. The bonus application may compile a bonus request. The router's processor may in response forward a bonus request issued by the bonus application to the claims application of the transaction device. The bonus request may include information relating to the amount of reduction which is to be applied to the first portion of the value of the good, or service, and an offset which 20 results in an increase in the second portion of the value of the good, or service, which is to be reimbursed to the supplier of the goods or service. Optionally, the bonus application may be stored to the memory of the transaction device. In either case, the claims application, on receiving the bonus request may 25 communicate with the payment application so that the reduction is applied to the first portion of the value of the good, or service. The bonus application may refer to information stored in the memory to calculate an amount by which the first portion of the value of the goods or service is to be reduced. Optionally the bonus application may receive information directly from 30 the member provider. Where payment for a good or service is made by credit card, or linked credit card, the data representative of receipt of payment of the first portion of the value of the good, or service may be an authorization of payment. The member provider may be operable to forward to the host server data 35 representative of payment of the first portion of the value of the good, or service.

5 Other embodiments provide a method for processing electronic claims, the method comprising: obtaining information via a terminal, the information comprising: member identifier data identifying a member whom received a good or a 5 service; member provider data identifying a fund provider to whom the member belongs; and transaction request data representative of a type and a value of the good or service received by the member; 10 routing to the fund provider, the transaction request data and the associated member identifier data; receiving from the fund provider and routing to the terminal, data representative of a first portion of the value of the good or service which is to be paid by the purchaser and a second portion of the value of the good or service which is to be reimbursed to 15 the supplier of the good or service; electronically receiving at the terminal, data representative of payment of the first portion of the value of the good or service, and in response compiling a message and routing the message to the fund provider, the message instructing the fund provider to credit the supplier with the second portion of the value of the good or service. 20 The method may further comprise compiling a claim authorization request for routing to the fund provider, the claim authorization request including at least the member identifier data, member provider data, and transaction request data. The method may further comprise compiling a payment authorization request including account data representative of a type of account which is to be debited the 25 first portion of the value of the goods or service and requesting authorization of payment of the first portion of the value of the good or service. The method may further comprise routing the payment authorization request to the selected payments host, and in response, receiving a payment authorization reply from the payments host, the authorization reply indicative of whether or not 30 authorization of payment has been approved. The method may further comprise storing, in a shared data area, the authorization reply indicative of whether or not authorization of payment has occurred. The method may further comprise compiling a credit authorization request for routing to the fund provider, the credit authorization request including data 35 representative of payment of the first portion of the value of the good or service, and an 6 authorization that the fund provider credit the supplier with the second portion of the value of the good, or service. The method may further comprise executing a bonus application to calculate an amount by which the first portion of the value of the goods or service is to be reduced. 5 The amount may be any percentage of the first portion of the value of the goods or service. The method may further comprise reducing the value of the first portion of the value of the goods or service by the calculated amount. The method may further comprise increasing the value of the second portion of the value of the goods or service 10 by the calculated amount. Other embodiments further provide a computer program element comprising computer program code means to make a computer execute a procedure for processing electronic claims, comprising: computer program code means for obtaining member identifier data identifying 15 a member whom received a good or a service from a supplier of the respective good or service, member provider data identifying a fund provider to whom the member belongs, and transaction request data representative of a type, and a value, of the good or service, received by the member; computer program code means to compile a claim authorization request for 20 forwarding to the fund provider, the claim authorization request including the transaction request data and the associated member identifier data; computer program code means to receive a claim authorization reply from the fund provider, the claim authorization reply including data representative of a first portion of the value of the good or service, which is to be paid by the purchaser and a 25 second portion of the value of the good, or service, which is to be reimbursed to the supplier of the good or service; and computer program code means to electronically obtain data representative of payment of the first portion of the value of the good or service, and in response, to compile a credit authorization request requesting the fund provider to credit the 30 supplier with the second portion of the value of the good, or service. Brief Description of the Drawings An example of the invention will now be described with reference to the accompanying drawings, in which: 35 Figure 1 is a schematic illustration of an electronic claims and payment system within an operating environment; WO 2009/105831 PCT/AU2009/000238 7 Figure 2 is a flow diagram of a method of processing an electronic claims transaction; and Figure 3 is an illustration of an authorization receipt. 5 Description of the Preferred Embodiments It should be understood that the techniques of the present invention might be implemented using a variety of technologies. For example, the methods described herein may be implemented by a series of computer executable instructions residing on a suitable computer readable medium. Suitable computer readable media may include 10 volatile (e.g. RAM) and/or non-volatile (e.g. ROM, disk) memory, carrier waves and transmission media (e.g. copper wire, coaxial cable, fibre optic media) Exemplary carrier waves may take the form of electrical, electromagnetic or optical signals conveying digital data steams along a local network or a publically accessible network such as the internet. 15 It should also be understood that, unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that processes 20 and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. Turning now to the figures, figure 1 is a schematic illustration of the high level 25 architecture of an electronic claims and payment system 10, according to one embodiment of the invention. The electronic claims and payment system 10 includes a transaction device in the form of a terminal 20 and a host router in the form of a health claim switch 40. For simplicity, only a single terminal 20 is illustrated although it should be appreciated that 30 it is envisioned that each health care provider will lease one or more terminals with each terminal communicatively coupled to the health claim switch 36. Within this specification a terminal is defined as any suitable interface device that functions to transfer information and commands between a contact or contactless card and a user and/or a computing device. Such a terminal is also termed interface 35 device (IFD), a card accepting device (CAD), a chip card reader (CCR), a smart card adapter and a card reader device. A terminal may take any of a variety of physical WO 2009/105831 PCT/AU2009/000238 8 forms and may be a stand alone unit or integrated with a computer. Furthermore, a terminal may also be embodied in any portable device such as a laptop computer, a mobile telephone, or any variety of a personal digital assistant (PDA). Connectivity between the terminal 20 and the health claim switch 40 is in this 5 example by a dial up communications link 36 through a Telstra or Optus provided 1800 transaction service. The health claim switch 40 is independently connected to respective host systems 60a, 60b and 60c of various health funds via communications links 50. The type of connectivity provided by link 50 between the health claim switch 40 and the 10 respective host systems 60a, 60b and 60c of various health insurers is by a variety of different communications infrastructures reflecting the needs of both parties. For instance suitable communication links 50 include, but are not limited to, hardwired and wireless connections using traditional public service telephone networks wireless WAN, cellular networks, satellite networks or the Internet or Intranet networks. 15 Terminal 20 is further communicatively connected to a payment switch 80. The payment switch 80 may include an automated clearing house vendor, a merchant acquirer or other like service that handles credit card and/or EFTPOS card transactions. In this document the term EFTPOS should be taken to cover scheme credit cards, scheme debit cards and proprietary debit cards. Schemes should be taken to include 20 issuers of, for instance, VISA, Mastercard, AMEX and Dinners cards. As with the connectivity between the terminal and the health claim switch 40, the terminal 20 and the payment switch 80 is connected by dial up communications through a Telstra or Optus provided dedicated 1800 transaction service 36. Several applications are run on terminal 20, including a health claim application and a 25 payments application. Each of these application dials a different 1800 number which results in connection to the appropriate switch. The payment switch 80 is connected to the various card schemes 85 (such as VISA and Mastercard) and banks/interchange links 90 through a variety of secure gateway arrangements. A typical arrangement is by way of dedicated links 72 which enable the flow of authorisation messages. 30 Communication links 72 are hardwired to ensure a high level of secure communications with the various card schemes 85 and financial institutions 90 however wireless systems that demonstrate high levels of secure communications can be substituted. All messages and processes are standardised and rigidly enforced to ensure interoperability of all payment scheme participants. Payments messages must 35 comply with specific country standards (for Australia AS2805 and the international standard ISO 8583) and minimum security requirements to control the integrity of data WO 2009/105831 PCT/AU2009/000238 9 from the terminal 20 through the payment switch 80 to the card issuer's authorisation host 90 for authorisation and back through the payment switch 80 to the terminal 20. Terminal 20 includes a microprocessor module 22, a software applications/memory module 24, a card communications module 26, a keypad module 5 28 and a peripheral communications module 30. The peripheral communications module 30 includes a display 32 and printer 34. Depending on the embodiment, the card communications module 26 includes the necessary circuitry to read contact cards and/or contactless cards. Examples of contact cards include magnetic swipe cards and microprocessor 10 based cards, otherwise known as smart cards or ICCs. An example of terminal software architecture for use with smart cards is described in WO 00/08611, the contents of which are incorporated herein by reference. The terminal's microprocessor 22 is operable to execute embedded software to read data stored on such a card. Embedded software includes a health claims 15 application and a separate payments application. Current communications infrastructure dictates that the terminal 20 can only interact with either the health claim switch or the payments switch at any one time. Memory module 24 includes application-specific partitioned memory locations 24a, 24b as well as a shared memory location, referred to as a public data area 25. The terminal's microprocessor 22 determines which 20 application to run in a given situation based on either identification of a payments card or healthcare card (or in the case of shared card a particular application) or operator input via the keypad 28. The health claim application and payments application are independent applications. This separateness ensures that the acquirer (card scheme 85 or financial 25 institution 90) of the payment transaction in each case is able to deploy a common payments application across all hardware thus reducing complexity. Furthermore, it enables the health claim application and payments applications to be managed independently, both in terms of release schedules for upgrades, and in terms of physical responsibility and resources. However, the embodiment of the invention requires an 30 extent of data sharing. The public data area 25 enables interoperability between the applications whereby the payments application, for instance, can leave a message for the payments application to reference, and visa versa. The terminal 20 is now described where the card communications module is adapted to read magnetic stripe cards. In this instance, the card communications 35 module 26 includes a magnetic stripe reader and the microprocessor 22 is operable to execute embedded software stored on the memory 24 to read a card's magnetic strip.

WO 2009/105831 PCT/AU2009/000238 10 In particular, the payments application stored to memory 24 enables data to be obtained from the magnetic strip located on either magnetic strip credit cards or EFTPOS cards. In addition, the claims application stored to memory 24 enables data to be obtained from the magnetic strip located on health insurance cards. 5 The health claim switch 40 is operable to route data packages between the terminal 20 and respective host servers of health insurers 60a to 60c. The health claim switch 40 includes a host processor 42 with a system bus 44, a host memory 46 and various input/output interfaces 48. The router 40, stores to memory configuration files which contain system configuration settings. Memory 46 may include RAM for routing 10 table information and packet queues. The host processor 42 is operable to execute embedded software stored in the host memory 46. Embedded software may include a bonus application. A method of processing an electronic claims transaction in accordance with the invention is now described. In this example, the terminal is a standalone point of sale 15 terminal, configured to read magnetic strip cards and manufactured for use in EFTPOS acquiring. Deployment involves the co habitation on the terminal of both a "payments" application (which is responsible for all the EFTPOS acquiring activity) and a "health claiming" application. Having received services the purchaser (patient) swipes their health care card 20 through the card reader. The card reader identifies that the card is a health care card (as distinct from a payment card). The health claims application then determines from the card data in the magnetic strip the details of the insured, health insurer and from the terminal operator the items to be claimed. This data is passed to the health claim switch 40 via a dedicated dial up communications session 36 to the 1800 number. The health 25 claims switch 40 securely forwards the transaction to the appropriate insurers host system 60c which undertakes the authorisation process. The response message is passed from the insurer's host 60c to the terminal 20 via the health claims switch 40. The response message includes data representative of a first portion of the value of the service (i.e the GAP), which is to be paid by the purchaser and a second portion of the 30 value of the service, which is to be reimbursed to a supplier of the service. The operator has at this point the opportunity to confirm the claim or cancel the transaction. Typically the terminal operator will advise the insured of the benefit amount and takes their instruction before accepting the benefit and processing or cancelling the transaction. 35 The terminal operator informs the purchaser of the amount of the total claim entitlement, the amount of total GAP and asks the purchase how they wish to pay the WO 2009/105831 PCT/AU2009/000238 11 GAP. In the instance that the purchaser wishes to pay by way of a payment card, the payment card is presented to the terminal operator. The payment card is then swiped through the card reader 26. The card reader 26 identifies that the card is a payment card and the payments 5 application determines from the cardholder, the account choice, PIN and transaction amount. The terminal's processor 22 packages the transaction, encrypts the transaction and then passes the secure encrypted transaction via a dial up communications session to the dedicated 1800 number. The payments switch 80 directs the message to the appropriate issuer's authorisation host 90 based on the cards BIN number. The response 10 message is compiled and returned to the terminal during the same session. The terminal operator is advised of the transaction being either approved (together with the amount) or declined. In addition, the payments application is configured to leave an "outcome" message (an indication of transaction approval together with the dollar amount or an indication of transaction decline) in the secured shared memory area of 15 the terminal for the health claim application to reference. The payment session is then closed. If for any reason the transaction is required to be cancelled the operator would need to undertake a refund transaction. In a further example, the terminal 20 is a standalone terminal configured to read chip based cards. Use of a chip card changes the card user's interaction with the 20 terminal. The traditional swipe and remove for magnetic strip cards is replaced with a dip and leave in place operation. This facilitates the card's embedded microprocessors interaction with the payment application. It is only at the end of the transaction that the card is removed. When the chip based card is a "linked" card, the health card details are stored on the card's chip. 25 An example of a method of processing an electronic claims transaction where the terminal 20 is configured to read chip based cards will now be described, with reference to Fig. 2. To begin a claim transaction, the provider of the services, in this case a dentist, or their assistant, dips the purchaser's (patient's) linked credit card into the terminal 20 30 to enable the card reader 26 to communicate with the card's processor. The linked credit card contains information to identify the health fund to which the patient belongs and account information associated with a financial institution which sponsors the terminal 20. The operator enters into the keypad information that initiates the claims application 24a, step 102. Processor 22 executes the claims application and an 35 electronic handshake between the health claim switch 40 and the terminal 20 occurs which establishes a data file in the terminal's memory 24a for the particular claim WO 2009/105831 PCT/AU2009/000238 12 transaction, step 104. An identifier is associated with the transaction which is used throughout the process to enable a particular health claim session to be linked to a particular payment session. Information necessary to determine the claim entitlement is then obtained. 5 Information is displayed on display 32 prompting the assistant to "select a provider". The assistant enters the name of the provider; that is the name of the supplier of the goods or services who is claiming for the services provided, together with that provider's unique identifier. The data entered into the terminal 20 via the keypad 28 where it populates the associated data file stored in the terminals' memory 24a. 10 Information is then presented on the display 32 to prompt the assistant to enter "a patient identifier". A two digit patient identifier is embossed on the front of the card. In addition, a patient identifier is encoded in the chip embedded in the patient's card. The terminal's processor decodes the patient identifier and this data populates the associated file in memory 24a. 15 The claims application then prompts the assistant to enter details associated with the transaction starting with the identifier for the "type of service" which the patient has received. For each service which the patient received the assistant is required to enter "a value" for that service and "a date", upon which the services were received. In addition, depending on the type of service, the assistant may be prompted to enter a 20 "sub-type of service". In this example the assistant enters "014" which indicates that the patient has received a consultation to the value of $60 and two restorations, the first restoration being a four surface post composite, to the value of $240, and a second restoration being a one surface post composite, to the value of $120. The transaction data is temporarily stored to memory 24a. 25 The claims application provides the assistant with the option to process further claims for other additional patients. This is necessary as health funds typically provide a level of care for families or those with dependents. In this example the assistant keys in "no". The claims application then prompts the assistant to confirm whether the claim is ready for processing. In this example the assistant keys in "yes". 30 The claims application compiles a claim request, step 106 which includes all data associated with the transaction which has been temporarily stored to memory 24a. The claim request is routed to the health claim switch 40. The health claim switch 40 ensures that the claim request is forwarded to the identified insurer 60a, step 108. Within the server of the insurer 60a, the patient identifier is cross referenced 35 against information stored in a look up table to determine the claim entitlements remaining (for the calendar year) based on the level of health cover for that individual.

WO 2009/105831 PCT/AU2009/000238 13 The insurer 60a determines, for each service, the amount of the claim entitlement, and the amount of GAP required to be paid by the patient (or on behalf of the patient), step 110. A claim reply is created which includes the amount of the claim entitlement (in part according to each type of service, and in total) and the amount of GAP (in part 5 according to each type of service, and in total) step 112. The claim reply is then communicated back via the health claim switch 40. The health claim switch 40 determines the appropriate terminal 20 to which the claim reply is to be sent, step 113 and the claim reply is then routed to that terminal 20. Data contained in the claim reply populates the relevant data file in memory 24a, step 114. 10 In response, the terminal's processor 22 executes the incentive reduction application (bonus application) stored to memory to calculate whether the GAP payable is subject to reduction if the individual authorizes payment via a linked card, step 116. The level of reduction applicable is predetermined by mutual agreement between the health insurer and the financial institution. Data representative of the level 15 of reduction is stored in a data file in the shared memory 25. A message is compiled and presented in summary form for the assistant. The assistant informs the purchaser of the amount of the total claim entitlement and the amount of total GAP. The assistant also informs the purchaser that a bonus of 4% is applicable if the purchaser wishes to use their linked credit card. The assistant asks the 20 purchaser how they would like to pay the GAP. In this example, the purchaser informs the assistant that they would like to take advantage of the bonus by using their linked credit card. The purchaser removes their card from the terminal and then reinserts their card for a second time. The assistant keys in that a payment session is to be initiated and the account 25 associated with the linked credit card is to be used and the processor 22 executes the payments application, step 118. The payment application reads the account number. The assistant enters the amount to charge the card and the purchaser enters OK on the keypad. The payment application compiles a payment authorization request, step 120, associated with the data which is then encrypted and forwarded to the payment switch 30 80. The switch 80 reads the data and identifies a bank identification number which identifies the institution which issued the card. A routing table is looked up to see if an interchange agreement exists with that card issuer. As the card is a linked credit card the answer to these questions will always be in the affirmative and the payment authorization request is sent to the relevant institution 90 step 122. The institution 90 35 then decides whether to approve or decline the request, step 124. The payment authorization response is sent back to the payments switch 80 which routes the WO 2009/105831 PCT/AU2009/000238 14 response to the terminal 20, step 126. The payments application on receiving the response, stores a copy of the response data in the data file in the shared memory 25, step 128. The payment session is now considered closed. Receipt of the response data in the public data area 25 prompts execution of the 5 claims application. The claims application retrieves data from the public data area 25 associated with the data stored in data file 24a and determines whether the amount of GAP paid matches the value of the GAP payable, with or without the bonus, step 130. Having verified that the amount paid matches the GAP payable subject to the 4% bonus, the claims application compiles a payment authorization message. The payment 10 authorization message is forwarded to the health claims switch 40 which then routes the relevant message to the relevant insurer 60, step 132. The relevant insurer 60, only on receiving verification notification that the GAP has been paid, and the amount paid, does the insurer proceed to credit the supplier with the modified rebate, step 134. Meanwhile, the terminals' processor 22 compiles the data into summary form 15 which is then printed and presented for signature, step 130. Fig. 3 illustrates an authorization receipt presented to the patient. As illustrated, the receipt clearly shows each type of service 150, the total value for that service 152, the benefit applicable 154 and the GAP 156. If a limit has been reached for any particular type of service then that is also indicated 158. The total cost 20 for the service, together with the benefit payable and the GAP is printed for the patient. The first option, 160, shows the breakdown of the benefit payable to the supplier and the GAP payable by the patient in usual situation where an incentive bonus is not applicable (i.e. for payments made by cash, cheque or non-linked credit cards or debit cards). The second option, 160, shows the breakdown of the benefit payable to the 25 supplier and the GAP payable by the patient in the situation where the incentive bonus is applicable. . An indication, 164, as to the financial institutions 85 authorization to debit the patient's linked credit card to the value of $192.20 is printed. Of course the patient may not have a linked credit card and may wish to pay by 30 cash or cheque. In this instance the claims application proceeds as previously described. Once the claim reply is received back at the terminal 20 the assistant keys in a payment identifier representative of how the patient has paid (cash or cheque) and the processor 22, in response, executes a cash/ cheque notification application. The assistant keys in the amount received. The cash/cheque notification application routes 35 data to the health claim switch representative of the date of payment, means of payment, value of payment and who received the payment. The data is appended to the WO 2009/105831 PCT/AU2009/000238 15 relevant claim file previously stored in memory 46. Such a data record facilitates auditing of a practitioners practice for cash/cheque payments. The cash notification application prompts processor 22 to compile information into summary form which is printed and presented to the patient for signature. The health claim switch 40 routes the 5 data to host of the relevant insurer. Only on receiving verification notification that the GAP has been paid, and the amount paid, does the insurer proceed to credit the supplier with the rebate. It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific 10 embodiments without departing from the scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive. For example, references have been made to a health care card and a credit or an EFTPOS card being composed of a small plastic sheet or token with a strip of magnetised material being applied to the surface of same. Smart chips embedded in 15 or applied to the surface of card which replace the magnetic strip have also been described. Furthermore, alternative types of cards or tokens may also be employed in conjunction with the present invention and reference to the above only throughout this specification should in no way be seen as limiting. The invention is applicable to accommodate cards in emerging areas such as contactless smart cards. Contactless 20 smart cards are configured to communication through radio frequency identification induction and require only proximity to a terminal to communicate (typically less than 10cm). Non-limiting example of contactless smart cards include mobile telephones, PDAs pagers, mobile televisions, MP3 or other music players etc. It should be appreciated that such cards would at least include an antenna in operable combination 25 with a transmitter and a receiver, as well as a controller or other processing element that provides signals to and receives signals from the transmitter and receiver respectively. The contactless card will be configured such that it s capable of operating with one or more air interface standards, communication protocols, modulation types and access types. The terminal would include an antenna in operable communication 30 with a transmitter and a receiver and would include the necessary interface device to support reading and writing to such a contactless card. Similarly, those skilled in the art should appreciate that a virtual terminal, for instance, a user interface in the form of one or more secure web-pages accessible over the internet, may replace the terminal 20. Accordingly the health claim switch 40 may 35 communicate with an Internet payment service that will provide the security to deal with card authentication, transaction confidentiality, server host integrity, and server WO 2009/105831 PCT/AU2009/000238 16 virus protection. The Internet payment service should provide at the very least SSL (Secure Socket Layer) protocol security, which encrypts the customer's payment information while it moves over the Internet so that it cannot be deciphered. It should be appreciated that other protocol security measures may be utilised. Use of the virtual 5 terminal has the advantage of eliminating the cost associate with using a traditional terminal. It should be appreciated that whilst the data terminal 20 above has a digital S interface 26 for an ISDN connection to communicate with the health claim switch 40, other embodiments may utilize an ethernet interface of a relevant internet access, 10 whether that internet access is ADSL, cable, or other suitable network. The architecture of the above example reflected a communications infrastructure dictating that the terminal 20 can only interact with either the health claim switch or the payments switch at any one time, Subsequently a public data area was provided to enable the sharing of data. Optionally, an overarching application may be provided to 15 facilitate the sharing of data, or alternatively the payments application may be "wrapped" within the health claiming application. It should be appreciated that it is likely that advancements will lead to concurrent communications sessions between the terminal 20 and the health claim switch and the terminal 20 and the payments switch may be available over a single communication link and the invention is applicable to 20 such advancements. Therefore, whilst the router 36 in the above example has been described as separate from the health claim switch 40, in a further embodiment it could be incorporated as an integral part of the health claim switch 40. Further more the functionality of the router 36 and host router 60 could be combined in a single router. In one of the examples above, the incentive reduction application, or bonus 25 application, which calculated whether the GAP payable is subject to reduction if the individual authorizes payment via a linked card, was stored to terminal's memory. In an optional embodiment, this application may be embedded in the chip of the patient's card. Such architecture has the advantage whereby the processing of the bonus occurs at the terminal, without any data transactions with the health fund host. In this case, the 30 data representative of the level of reduction may be stored in the card's memory.

Claims (22)

1. An electronic claims and payment system comprising: a transaction device operable to obtain member identifier data and member provider data, and to obtain transaction request data representative of a type, and a value, of a good or service, purchased; and a host router communicatively coupled to the transaction device and a member provider, the host router comprising a processor operable to: receive from the transaction device, and route to the member provider, transaction request data, associated member identifier data and member provider data; and receive from the member provider, and route to the transaction device, data representative of a first portion of the value of the good, or service, which is to be paid by the purchaser and a second portion of the value of the good, or service, which is to be reimbursed to a supplier of the goods or service; wherein the transaction device is further operable to electronically receive data representative of payment of the first portion of the value of the good or service, and in response to compile a message to be routed to the member provider, the message instructing the member provider to credit the supplier with the second portion of the value of the good or service.

2. The electronic claims and payment system according to claim 1, wherein the transaction device comprises a memory module and a processor operable to execute software stored on the memory module.

3. The electronic claims and payment system according to claim 2, wherein the software comprises a claims application to compile a claim authorization request, the claim authorization request including at least the member identifier data, member provider data, and transaction request data.

4. The electronic claims and payment system according to claim 3, wherein the software further comprises a payments application to compile a payment authorization request.

5. The electronic claims and payment system according to claim 4, wherein the payments application and the claims application are discrete applications. 18

6. The electronic claims and payment system according to any one of claims 2 to 5, wherein the memory module includes a shared data store to enable data sharing between discrete software applications.

7. The electronic claims and payment system according to claim 4, wherein the software further comprises an overarching application which controls each of the claims application and the payments application.

8. The electronic claims and payment system according to any one of the preceding claims, further comprising one or more of a card communications module, a keypad and a peripheral communications module.

9. The electronic claims and payment system according to claim 8, wherein the card communications module comprises a card reader operable to obtain member identifier data and member provider data stored on a card.

10. The electronic claims and payment system according to claim 9, wherein the card reader is adapted to read a smart chip embedded in, or applied to, the surface of a card.

11. The electronic claims and payment system according to claim 9, wherein the card reader is adapted to read a contactless card or a magnetic strip embedded in a card.

12. The electronic claims and payment system according to any one of the preceding claims, wherein the transaction device is a virtual terminal.

13. The electronic claims and payment system according to any one of the preceding claims, wherein the transaction device is communicatively coupled to a payments router which is operable to route payment authorization requests to a payments host for authorization.

14. A method of processing electronic claims, the method comprising: obtaining information via a transaction device, the information comprising: member identifier data identifying a member whom received a good or a service; 19 member provider data identifying a fund provider to whom the member belongs; and transaction request data representative of a type and a value of the good or service received by the member; routing to the fund provider, the transaction request data and the associated member identifier data; electronically receiving from the fund provider and routing to the transaction device, data representative of a first portion of the value of the good or service which is to be paid by the purchaser and a second portion of the value of the good or service which is to be reimbursed to the supplier of the good or service; the transaction device electronically receiving data representative of electronic payment of the first portion of the value of the good or service, and in response compiling a message and routing the message to the fund provider, the message instructing the fund provider to credit the supplier with the second portion of the value of the good or service.

15. The method according to claim 14, further comprising compiling a claim authorization request to route to the fund provider, the claim authorization request including at least the member identifier data, member provider data, and transaction request data.

16. The method according to claim 14 or 15, further comprising compiling a payment authorization request including account data representative of a type of account which is to be debited the first portion of the value of the goods or service and requesting authorization of payment of the first portion of the value of the good or service.

17. The method according to claim 16, further comprising routing the payment authorization request to a server of the selected payments host, and in response, receiving a payment authorization reply from the payments host, the authorization reply indicative of whether or not authorization of payment has been approved.

18. The method according to claim 17, further comprising storing, in a shared data area, the authorization reply indicative of whether or not authorization of payment has occurred. 20

19. The method according to claim 18, further comprising compiling a credit authorization request for routing to the fund provider, the credit authorization request including data representative of payment of the first portion of the value of the good or service, and an authorization that the fund provider credit the supplier with the second portion of the value of the good or service.

20. The method according to claim 19, further comprising executing a bonus application to calculate an amount by which the first portion of the value of the goods or service is to be reduced.

21. The method according to claim 20, further comprising reducing the value of the first portion of the value of the goods or service by the calculated amount.

22. A computer program element comprising computer program code means to make a computer execute a procedure for processing electronic claims, comprising: computer program code means for obtaining member identifier data identifying a member whom received a good or a service from a supplier of the respective good or service, member provider data identifying a fund provider to whom the member belongs, and transaction request data representative of a type, and a value, of the good or service, received by the member; computer program code means to compile a claim authorization request for forwarding to the fund provider, the claim authorization request including the transaction request data and the associated member identifier data; computer program code means to electronically receive a claim authorization reply from the fund provider, the claim authorization reply including data representative of a first portion of the value of the good or service, which is to be paid by the purchaser and a second portion of the value of the good, or service, which is to be reimbursed to the supplier of the good or service; and computer program code means to obtain data from a transaction device, said data representative of electronic payment of the first portion of the value of the good or service, and in response to the receipt of electronic payment, to compile a credit authorization request and route the credit authorization request to the fund provider, the authorization request requesting the fund provider to credit the supplier with the second portion of the value of the good, or service.