FIELD OF THE INVENTION The present invention relates to the electronic coordination and communication of data in a health network, and between the health network and a banking network, for a health- related transaction.

BACKGROUND OF THE INVENTION The health care industry today is highly fragmented. Information and data are not readily retrieved by or transmitted to the appropriate party in an efficient, cost effective manner. Information and data may be held in many different places within an insurance company and is costly to collate. Health care providers (doctors, laboratories, pharmacies, hospitals, etc.) have a great deal of difficulty being paid for their services or proving to the insurance providers (i. e., insurance companies) that they actually provided service to an insured. Many people are fraudulently using the health care system by receiving services that they are not entitled to, thus adding costs to others. On the other hand, people who are eligible to receive services may not because of time consuming methods of verifying their eligibly.

There is a need for organizing data, and for coordinating the communication of data between and among the participants of various health plans provided by various insurance

providers, within the healthcare system which will reduce the cost for managing data for all participants, and thus reduce the time required by each to review, analyze, edit, track, etc., data such as. for example, eligibility and financial data.

The need to coordinate and communicate data between and among the insurance providers (i. e., insurance companies), health care providers, insured parties, and their respective financial service providers, for a health-related transaction is manifest.

Providing individual or group health care requires coordination between and among many parties including an insurance provider (i. e., insurance company), an insured, an employer, health care providers (e. g., primary care providers (PCP), specialists, laboratories, pharmacies, hospitals, etc.), and financial service providers (e. g., banks, debit-credit networks, etc.). With regard to the providing of health care, those various parties may be considered members of a form of health network. Information relating to a health-related transaction may be communicated between and among the members using a variety of paper and electronic forms and incompatible computer systems. That communication is time intensive, requires significant amounts of paperwork, slows the health care service process, is subject to errors and abuses, and generally increases health care costs.

While the various computer systems may communicate with each other at some level, complete and current data for a health-related transaction is not electronically linked, coordinated, organized, or otherwise managed and is generally not available to all members in real-time. In addition, not every member of the health network has electronic access to complete and current data themselves, their patients, doctors, pharmacies, labs, hospitals, insurance providers, etc. for a health-related transaction. Moreover, significant paperwork is still required to communicate and coordinate data for a health-related transaction between and among the members. That paperwork is still used primarily because a reasonable alternative

has heretofore not been presented. For the sake of efficiency, accuracy, fraud-prevention and elimination, and costs, it is desirable to eliminate forms as a means for communicating and coordinating data for a health-related transaction.

A great deal of time is wasted between and among parties communicating on the phone or by mail without the benefit of each party having access to the same information or data. Confusion, frustration, and adversary actions have become the norm. There is a need to organize and share data within a health network so that every member of the health network, including but not limited to, insurance providers, health care providers, the insured, and employers have access to the same data and information at the same time. This is especially true when various members need to review a particular claim or health-related transaction.

Providing simultaneous access to those various members to data for the health-related transaction yields significant advantages that are not currently available.

Several alternative approaches are available to meet this objective. Without a discussion on a completely new health delivery paradigm, they fall into two major categories: portable (distributed) data systems; and centralized data systems.

Portable data systems allow existing documentation to be converted into an electronic format to be carried by the insured through the delivery process and deposited with the primary care provider for processing. Existing technology may enable conversion of limited patient data (e. g., name, insurance provider, etc.) into a portable format (e. g., a portable data system such as a floppy disk, CD-ROM, Palm Pilot smart card or optical card) that may be carried by the patient. The patient would carry the limited patient data to every health care provider for processing-the electronic equivalent of carrying a portfolio containing all of the required information and paperwork. The limited patient data would be immediately available at a point of service without the need for overly sophisticated equipment-a

personal computer may provide the desired functionality. However, any data stored on the portable device would be lost if the patient lost the device. That scenario becomes more likely over a protracted health service period. In addition, fraudulent alteration of the data is a distinct possibility.

Centralized data control systems eliminate the lost data issue and with proper precautions, minimize fraud. Such a system requires the use of electronic data collection systems that are generally cheaper and simpler than the a portable data system. However, the investment in equipment for a centralized data system is considerably larger than that for a portable data system. Moreover, a centralized data system does not coordinate and link the various disparate types of data involved in a health-related transaction (e. g., identification data, medical data, financial data, etc.).

It is thus desirable to provide a cost effective, secure, and efficient health network for the communication and coordination of data for a health-related transaction that overcomes the above-described shortcomings of the prior art.

SUMMARY OF THE INVENTION The present invention is directed to a method, system, and network for coordinating the communication of data in a health network (such as, for example, an Intelligent Card Health NetworkTM (ICHN)), and between the health network and a banking network, for a health-related transaction between and among members of the health network. In accordance with the present invention, a processor creates and maintains an electronic record of a health- related transaction by providing or transmitting an original transaction authorization or transaction denial for that health-related transaction. Thereafter, all activity for that health- related transaction is electronically linked via the electronic record to the original transaction

authorization or transaction denial. For example, all referrals, laboratory/hospital authorizations, prescriptions, payments, etc., are authorized or denied, with an appropriate authorization or denial being provided by the processor, and linked to the original transaction authorization or denial in the electronic record. All data for a health-related transaction is thus collected, linked, and made available to relevant members of the health network in accordance with the present invention.

The electronic record (and thus all activity relating to the health-related transaction) is maintained by the processor to ensure that accurate, up-to-date data of the health-related transaction is available to members participating (i. e., receiving and/or providing health care services) in the health-related transaction. By linking all activity for a health-related transaction to a single reference (e. g., an original transaction authorization or transaction denial), the present invention simply and efficiently coordinates the communication of data in a health network, and between the health network and a banking network, for a health-related transaction.

The present invention thus provides electronic data linkage of all activity in a health- related transaction; electronically linking an insurance provider, a health plan, health care provider (s), an insured, an employer, referrals between and among health care providers, claim submittal and reconciliation (i. e., insured co-payment and insurance provider claim payment), clinical data, health care provider requests for information, and other data relating to the health-related transaction. In addition, the present invention ensures that data relating to the insurance providers, health plans, health care providers, insured parties, and employers is current, and further communicates changes in any of that data in real-time throughout the health network.

For each health-related transaction (also referred to herein as a case), the present invention creates an electronic record of activity relating to that health-related transaction.

Every doctor visit. every referral, all diagnoses, prescriptions, tests, clinical data, etc., and all payments, are linked together via the electronic record. All data associated with the electronic record is secure and readily accessible by the health care providers, insured parties, and insurance providers. The electronic record may be a single file containing all data for the health-related transaction. Alternatively, the electronic record may be a pseudo case file containing a plurality of pointers to a plurality of databases, with each database containing part of the data for the health-related transaction. The embodiment of the electronic record is preferably transparent to members of the health network within which the present invention is employed. The data included in the electronic record may include, by way of non-limiting example, a reference to: the insured; their insurance provider; each doctor visit and the service provided by the doctor; all referrals by the primary care provider to other health care providers; each laboratory visit and the service provided by the lab; each hospital visit and the services provided by the hospital; each pharmacy visit and the prescription (s) dispensed; authorization or denial records; and every financial transaction. That data is all linked to the original transaction authorization or transaction denial provided by the processor at the initial visit between the insured and the primary care provider.

In an embodiment of the present invention, a health network includes a processor that provides the functionality necessary to coordinate the communication of data in the health network, and between the health network and a banking network, for a health-related transaction between and among the members of the health network, and as described herein.

The processor may be comprised of a computer or a plurality of connected and connectable computers having general purpose software (e. g., operating system, database creation and

management, etc.) and special purpose software (defined by the desired functionality of the computer upon which the special purpose software is installed and operates).

Communication by the processor to other computers, electronic devices, networks, etc., may be via a hardwired or routed network, a dial-up or switched network, a virtual private network, the Internet, wireless, or virtually any communication protocol, method, system, device, etc..

Access to the processor by members of the health network may be via local land- based or cell-based computing devices such as. for example, personal computers, site servers, identification card reading devices, hand-held computing devices (e. g. personal digital assistants), cellular devices, etc. For example, member insurance providers may connect to the processor via a site server located at the insurance provider. The site server provides the functionality required for the insurance provider to operate and manage its health plans, interface with its legacy computer systems, and communicate with the processor of the health network of the present invention. The site server provides a means for the insurance providers to communicate rules and eligibility data specific to their respective health plans to the processor. Update to the rules and eligibility data is made by the insurance providers via their respective site servers and uploaded to the processor in real-time or in batch processing.

However, a site server is not required for an insurance provider to access the processor. In that case, the previously-described functionality of the site server is provided by the processor and is customized to the requirements of the insurance provider.

Employers may also connect to the processor using employer computing devices (e. g., a personal computer). While providing less functionality than an insurance provider server, the employer device enables the employer to modify eligibility data for employees by adding, deleting, or modify employee data for a particular insurance provider and upload that data to

the processor. The processor, in turn will upload the data to the appropriate insurance provider. Alternatively. the employer computing device may upload such eligibility changes directly to the insurance provider site server which will, in turn, download the data to the processor. Thus, up-to-date eligibility data for the member insurance providers is ensured.

Each member of the health network is provided with an identification card that may be a magnetic card, a smart-card, or other portable device upon which data may be magnetically, electrically or optically stored. The data provided on the card may include any of identification data for the card holder, insurance provider identification data, employer identification data, medical data (e. g., allergies, physical/mental impairments, etc.), and financial data (e. g., bank identification number (BIN), personal identification number (PIN), etc.).

Health care providers may also connect to the processor via computing devices (e. g., identification card readers, personal computers, software, etc.) installed in the health provider's office. The computing device for the health care providers may be an identification card reading device such as, by way of non-limiting example, a magnetic card reader, connected to the processor. Software at the processor may provide additional functionality for the card reading device such as, for example, dual-swipe functionality, or that functionality may be provided for in the magnetic card reader, or shared between the reader and the processor. Alternatively, the health provider computing device may be an identification card reading device connected to a personal computer or other functionally similar electronic device and which may include software for providing additional functionality for the card reading device.

The health care provider computing device may be configured for single-or dual- swipe card reading. For single-swipe functionality and for a magnetic card reader, a member

insured may swipe his/her identification card through the reader, and that member's identification data will be transmitted to the processor. For dual-swipe functionality, a member insured and a member health care provider may sequentially swipe their respective cards through the reader and their respective identification data will be transmitted to the processor. The processor may identify the member using a look-up table, for example, and also determine whether the transaction is a health-related transaction that should be routed to the health network, or a financial transaction that should be routed to the banking network.

The processor also links the insured identification number and the health care provider identification number for future use with regard to a particular health-related transaction.

The processor of the present invention is certified to create automated clearing house (ACH) and electronic funds transfer (EFT) files and transmit those files to financial service providers. Thus, the processor can transmit financial transactions directly to the banking network to satisfy co-payment obligations of the insured and claim payment requests of the health care provider (s) via a connection to the banking network and transmission of an appropriate file to a bank, for example. Upon receipt of an ACH or EFT file, a bank will carry out the instructions provided in the file and transfer the necessary funds from the insured's or insurance provider's bank and to the health care provider's bank The present invention provide benefits and advantages to insurance providers, health care providers, patients (i. e., insured parties), and employers. For the insurance providers, the benefits and advantages may include: increased efficiency and accuracy; reduced costs; reduced opportunity and occurrence of fraud; increased ability to generate provider and insured usage data; automated eligibility determination, referral authorization, pre- certification, and claim and premium payments; eliminate duplicate payments by the use of EFT and payment reconciliation; customized reports for health care providers, employers, and

insured parties; electronic fund transfer and reconciliation; the ability to electronically link a specific health plan, health care provider (s). and insured party for each health-related transaction or case; real-time updates of health plan rules and health care provider and insured eligibility; secure transmission of sensitive data over a health network; the ability to generate contract profitability reports ; and the ability to provide an audit trail for each health-related transaction.

For health care providers, the benefits and advantages of the present invention may include: increased time available per patient due to decreased time required for paperwork; better patient management through the use of linked patient data (including clinical data); better communication of clinical data between and among health care providers; increased profits due to reduced staff and health plan administrative requirements; pre-certification available for PCP, specialist providers, and other health care services (e. g., labs, hospitals, etc.); real-time eligibility determination, referral authorization and service authorization; real- time co-payments and claim submittals; EFT for co-payments and claim payments; and the ability to generate complete patient reports, keyable by case or health-related transaction, that enable the health care provider to evaluate the effectiveness of certain treatment for a particular patient, thus resulting in better health care for the patient.

Mutual benefits for both insurance providers and health care providers may include reduced time for eligibility determination and pre-authorized payment for certain procedures.

Health care providers may be paid more quickly because the time required for the insurance provider to review each case (which is currently a manual procedure) and authorize and reconcile payment is significantly reduced by the present invention.

For the insured (i. e., patient), the benefits and advantages of the present invention may include: receiving a detailed statement of health-related and financial activity; decreased time

spent communicating with insurance provider ; and reduced premiums due to the increased efficiencies provided to the insurance providers by the present invention.

For the employer, the benefits and advantages of the present invention may include: increased efficiency of the health delivery system; decreased cost of health care due to the efficiencies provided by the present invention; and possible rewards (economic or otherwise) provided by the insurance providers for an employer's loyalty to that provider.

The following illustrative, non-limiting example describes a health-related transaction and how the present invention coordinates the communication of data in a health network, and between the health network and a banking network. When an insured first visits a primary care provider (PCP), a new case or health-related transaction is initiated. At the initial office visit (with the PCP), identification data for the insured and PCP is transmitted, via their respective identification cards and the health care provider computing device, to the processor which can determine, in real-time, the identity of the insured and PCP, and whether they are individually and collectively eligible under a predetermined insurance plan (that of the insured). The processor, recognizing that this is a new case, assigns a new (i. e., original) authorization number to the case and transmits that authorization number to the PCP. The processor also creates and maintains an electronic record of all activity for the case; the record being keyed or based on the original authorization number.

At the end of the office visit, the PCP may refer the insured to another health care provider by transmitting to the processor the referred provider's identification number and the original authorization number previously provided to the PCP for this health-related transaction. If the processor approves the referral, a referral authorization number is communicated by the processor to the PCP and provided as part of the electronic record. The PCP also communicates the referral authorization number to the insured.

The insured then proceeds to the referred health care provider. The front office staff at the referred provider go through a process similar to that at the PCP, except that they indicate to the processor that the visit is a referral and provide the referral authorization number provided by the PCP to the insured. The referred office receives approval from the processor and is provided with a claim authorization number for use in their later submittal of a claim for payment for the health care services provided to the insured.

The insured may return to the PCP for a follow-up visit. Here the PCP communicates to the processor that this is a follow-up visit and also communicates the original authorization number. A new claim authorization number is communicated by the processor to the PCP.

The PCP may later submit a claim for payment with the new claim authorization number and receive an approval code for that claim from the processor.

As discussed above, the processor is configured for routing health-related transactions to the health network, and financial transactions to the banking network. A single identification card may thus be used for both health-related and financial transactions (and possibly other uses). One method of determining whether a transaction is health-related or financial is the number of identification cards swiped; a dual-swipe indicating a health-related transaction and a single-swipe indicating a financial transaction along with accompanying data such as, for example, dollar amounts for co-payment.

The insured may also elect to satisfy a co-payment obligation at the time the health care service is rendered by the health care provider. When an insured first becomes a member of a particular health plan, typically through the insured's employer, the insured may elect to electronically satisfy any co-payment obligations using their identification card, the present invention, and the banking network. If an insured has so elected, the processor coordinates the electronic transfer of funds from the insured's bank account to the PCP's bank account and

updates the record of activity for the health-related transaction. The processor may receive a request from the insured, via the health care provider computing device. to electronically coordinate payment from the insured's bank account to the PCP's bank account. The processor may facilitate all aspects of that request, including formatting the request for communication to the banking network, communicating the formatted request to the insured's bank, receiving approval or denial of payment from that bank, communicating that approval or denial to the health care provider computing device, and electronically transferring the necessary funds from the insured's account to the PCP account. if approved. An approval or denial number is assigned by the processor to that transaction and included in the electronic record.

At some convenient time, the PCP may submit claim payment requests to the insurance provider (via the processor) for each separate health-related transaction. Each claim payment request is transmitted by the PCP along with the original transaction authorization number for that specific health-related transaction. In response, the processor transmits to the PCP a claim payment authorization number that is linked to the original transaction authorization number. The processor may facilitate all aspects of the claim payment request, including formatting the request for communication to the banking network, communicating the formatted request to the insurance provider's bank, receiving approval or denial of payment from that bank, communicating that approval or denial to the health care provider computing device, and electronically transferring the necessary funds from the insurance provider's account to the PCP account, if approved. If a PCP submits a claim for payment that has been pre-approved by the insurance provider, electronic transfer by the insurance provider's bank to the PCP's bank is automatic. An approval or denial number is assigned by the processor to that transaction and included in the electronic record.

The present invention also provides for pre-certification. For example, a health care provider and an insured may communicate with the insurance provider prior to an initial office visit, and obtain from the insurance provider authorization for the health care provider to provide certain health care services for the insured. That pre-approval may be accessed by the processor so that when the health care provider submits a claim for payment for those pre- approved services, that claim is passed directly to the banking network, and an electronic transfer is automatically carried out by the appropriate bank to transfer the necessary funds from the insurance provider's bank to the health care provider's bank. That activity is included as part of the electronic record for the health-related transaction.

Fee-for-service relationships may also be managed by the present invention. For that scenario, the insured is responsible for paying the health care provider, and that payment may be facilitated and effected by the present invention, as described in more detail below. After rendering service to the insured, the health care provider submits a claim to the insurance provider, receives an authorization number, and the insurance provider pays the insured.

Health care services provided by out-of-network providers may also be authorized using the present invention by permitting the out-of-network provider to access the health network 10 and processor 100.

Throughout the above-described health-related transaction, the processor creates and maintains an electronic record that links every authorization and/or denial number provided by the processor to the various health care service providers and provided as part of any financial transactions attendant the health-related transaction. That electronic record links the various authorization numbers, insured identification number, insurance provider, health care provider (s), health care services, and financial transactions to a specific health-related transaction. All of the information exchanged during each activity is logged by the processor

and tagged with an appropriate authorization number, date, time, and other important information. When that data is needed, the complete chronology of the activities and the associated data for that health-related transaction may be recalled as a pseudo case file similar to the paper files maintained at the offices of the PCP and insurance providers.

Thus, in accordance with the present invention, all aspects of a health-related transaction are coordinated by the processor and communicated between and among the members of the health network. The present invention organizes, logs, coordinates, catalogs, etc., all data relating to a health-related transaction and makes that data available to all parties to that transaction in real-time. The present invention does that for every health-related transaction; meaning for every insurance provider (and for every health plan offered by the insurance providers), for every insured, and for every health care provider, regardless of the type of data, its source or destination, and regardless of the party desiring access to the data.

Other objects and features of the present invention will become apparent from the following detailed description, considered in conjunction with the accompanying drawing figures. It is to be understood, however, that the drawings, which are not to scale, are designed solely for the purpose of illustration and not as a definition of the limits of the invention, for which reference should be made to the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS In the drawing figures, which are not to scale, and which are merely illustrative, and wherein like reference characters denote similar elements throughout the several views: FIG. 1 is a schematic block diagrams of a representative health network having a processor and connected to a banking network in accordance with the present invention;

FIGS. 2A and 2B are schematic block diagrams of exemplary preferred interconnections between and among the processor and members of the health network and the banking network in accordance with the present invention; FIG. 3 is a block diagram of an exemplary processor comprised of a plurality of subsystems and connected to a site server and a health care provider computing device in accordance with the present invention; FIG. 4 depicts an exemplary relationship between and among the members of the health network, the processor, and the electronically linked data in accordance with the present invention; FIG. 5 depicts an exemplary interrelationship between and among the various members and the electronic data linkage performed in accordance with the present invention; FIG. 6 depicts an exemplary linkage provided by the processor in the electronic record for clinical data in accordance with the present invention; FIG. 7 depicts an exemplary linkage provided by the processor in the electronic record for financial data in accordance with the present invention; FIG. 8 depicts a sample activity report for a health care provider in accordance with the present invention; FIG. 9 depicts a sample activity report for a patient in accordance with the present invention; and FIG. 10 is a block diagram of an exemplary computing device including an identification card reader and connectable to the processor in accordance with the present invention.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS The present invention is directed to a method, system and network for coordinating the communication of data in a health network (referred to herein as an Intelligent Card Health NetworkTM), and between the health network and a banking network, for a health- related transaction between and among members of the health network. In accordance with the present invention, a processor creates and maintains an electronic record of a health- related transaction by providing or transmitting an original transaction authorization or transaction denial for that health-related transaction. All activity for that health-related transaction is electronically linked via the electronic record to the original transaction authorization or transaction denial. For example, all referrals, laboratory/hospital authorizations, prescriptions, payments, etc., are authorized or denied, with an appropriate authorization or denial being provided by the processor and linked to the original transaction authorization or denial in the electronic record.

The electronic record (and thus all activity relating to the health-related transaction) is maintained by the processor to ensure that accurate, up-to-date data of the health-related transaction is available to members participating (i. e., receiving and/or providing health care services) in the health-related transaction. By linking all activity for a health-related transaction to a single reference (e. g., an original transaction authorization or transaction denial), the present invention simply and efficiently coordinates the communication of data in a health network, and between the health network and a banking network, for a health-related transaction.

The present invention thus provides electronic data linkage of all activity in a health- related transaction; electronically linking an insurance provider, a health plan, health care provider (s), an insured, an employer, referrals between and among health care providers,

claim submittal and reconciliation (i. e.. insured co-payment and insurance provider claim payment), clinical data, health care provider requests for information, and other data relating to the health-related transaction. In addition, the present invention ensures that data relating to the insurance providers, health plans, health care providers, insured parties, and employers is current, and further communicates changes in any of that data in real-time throughout the health network.

As used herein, the term members, when used in reference to the health network, may include doctors (both primary care providers and specialists), laboratories, hospitals. ambulatory and out-patient treatment centers, pharmacies, insured parties, insurance providers (e. g., insurance companies providing health coverage under a health plan), employers, and banks (e. g., financial service providers, credit-debit networks, ATM-debit networks, etc.).

As used herein, the terms case and health-related transaction refer to the totality of doctor visits, including those to the primary care provider and specialists (i. e., referrals), laboratory visits, hospital and out-patent center visits, and the health care services provided at those visits, follow-up doctor visits, pharmacy services, and financial transactions (e. g., co- payments, claim payments, etc.) for a particular insured and relating to a particular malady.

However, payment to a health care provider (whether by an insured (i. e., fee-for-service) or insurance provider (i. e., pre-certification or otherwise)) may be for individual health services provided by the health care provider for the insured. Thus, reconciliation between the health care provider and the insured or the insurance provider, as the case may be, can be for the individual health services, and need not be for the entire health-related transaction. The present invention thus provides for line-by-line reconciliation by the health care provider and the insurance provider for the various health services provided by the health care provider.

(See, e. g., FIGS. 8 and 9).

With reference to the drawings, FIGS. 1,2A and 2B depict a health network 10 having a processor 100 and connected to a banking network 16 in accordance with the present invention. The processor 100 provides the functionality necessary to coordinate the communication of data in the health network 10, and between the health network 10 and the banking network 16, in accordance with the present invention. The processor 100 may be comprised of a computer or a plurality of connected and/or connectable computers (not shown) having general purpose software (e. g., operating system, database creation and management, etc.) and special purpose software (for implementing the desired functionality of the inventive system on the computer upon which the special purpose software is installed and operates). The processor 100 may also include or be connected to a data storage device 170 (see, e. g., FIG. 2B) having a plurality of databases stored thereon. The data storage device 170 may comprise RAID (Redundant Arrays of Independent Disks) level 5 arrays.

Those databases may include insurance provider identification data, health care provider identification data, health care provider computing device identification data, insured identification data, and other data, as needed, by the processor 100 to provide its desired functionality and to facilitate coordinating the communication and linking or interrelating of data in the health network.

The communication of data in the health network refers generally to providing access to complete and up-to-date data for a health-related transaction to all parties to that transaction; e. g., namely, the insured, the insurance provider, and the health care provider.

As used herein, the term data refers generally to text, numerical, charts, pictures, graphics, voice (sound), images, video, and the like, that may be used between and among the insurance provider, the health care provider, the insured, an employer, and a financial services provider in accordance with the present invention.

Communication by the processor 100 to other computers, electronic devices, networks, etc. (i. e., those not comprising the processor 100), may be via a hardwired or routed network 12. a dial-up or switched network 14, a virtual private network, the Internet, wireless, or virtually any communication protocol, method, system, or device for facilitating such electronic communication as now known or as will later become known. The processor 100 may be considered a virtual central processor in that the functionality provided by the various hardware and software components of the processor 100 appear to members of the health network 10 to be centrally located. While that may be the case, the various hardware and software of the processor 100 may also be distributed among a variety of locations, as a matter of design choice.

The health network 10 depicted in FIG. 1 includes a plurality of members including one or a plurality of health insurance providers 20. A site server 200 may be provided as an interface between an insurance provider 20 and the processor 100, if desired. That site server 200 will comprise computer hardware and a site server subsystem 210 comprised of general purpose software and special purpose software. The special purpose software is preferably customized for the insurance provider 20 and the site server subsystem 210 enables the insurance provider 20 to efficiently operate and manage all aspects of its health plans. The site server 200 also provides the functionality for the site server 200 (and insurance provider 20) to interface with the processor 100 and with any legacy computer systems of the insurance provider 20. Access to the site server 200 by the insurance provider 20 may be via a computer 22 or a plurality of computers 22 linked via a local-area-network. Those computers 22 may provide the insurance provider 20 with administrative access to the site server 200 to enable the insurance provider 20 to change specific aspects of its various health plans (e. g., health plan rules, health provider eligibility, insured eligibility, authorized health

care services, etc.). The processor 100 preferably includes a mimic of the site server subsystem 210, to provide redundancy. The functionality provided by the processor 100 for each insurance provider 20 is customized based on the insurance provider's requirements.

If a site server 200 is not provided at a health care provider 20, the processor 100 will include special purpose software specific to that insurance provider 20 to facilitate communication between the provider 20 and processor 100.

The processor 100 may also be connected to one or a plurality of employers 30, each having a data entry terminal 32 (i. e., a computer) connectable to the processor 100 and to the insurance provider site server 200. Via the terminal 32, the employer 30 may add/delete employees for specific insurance providers 20 and for insurance provider specific health plans, and may transmit those changes to the insurance provider site server 200 and to the processor 100. Alternatively, the changes may be transmitted only to the site server 200 or to the processor 100 which, in turn, respectively transmit the changes to the processor 100 or site server 200.

Health care providers and insured parties that are members of the health network are each provided with a uni-functional identification card 250 or a multi-functional identification card 252, depending on the needs of the particular party Both types of identification cards will be generally referred to herein using reference numeral 250, unless a specific card is intended, in which case its specific reference numeral will be used. The identification card 250 may be a magnetic card, a smart-card, or other portable device upon which data may be magnetically, electrically, optically, or otherwise stored. The identification card 250 is preferably a magnetic strip card of the type disclosed in U. S. Patent Number 6,000,608, the entire content and disclosure of which is hereby incorporated by reference. The data provided on the identification card 250 preferably provides only for

identification of the card holder. However, additional information may be provided on the card, as a matter of design choice. The identification card may be a multi-functional card 252, usable for health-related, financial, and other types of transactions. Alternatively, the identification card may be a uni-functional card 250, usable only for health-related transactions.

As an alternative to each insured receiving an identification card, one card 250 may be issued per family with each family member having a different pin number identifying the member to the system. The processor 100 (i. e., the eligibility subsystem) would maintain data about the cardholder referred to with a specific pin number. The data might include name, address, health plan reference number, and information pertaining to the eligibility of the member to receive certain services from certain providers. That data might also include information about bank accounts related to the card (as in the case of a multi-function card) thus allowing co payments to be effected at the appropriate point in the health-related transaction. The health care provider or the insured may also manually enter the identification card number (which may be printed or otherwise provided on the card) if card number is not available.

If an insured 90 changes health plans (i. e., within an insurance provider or moves to another insurance provider), the present invention facilitates that insured's change without the need to issue a new identification card 250. The relative database (s) are merely updated in the processor 100 to associate the insured with the new health plan or insurance provider.

Similarly, if a new primary card provider is required, that change may be made at the processor and communicated to the interested parties in the health network.

The processor 100 is further connected to one or a plurality of health care providers 60 such as, for example, doctors, laboratories, out-patient treatment centers, hospitals,

pharmacies, clinics, etc. Each health care provider 60 has a health care provider computing device 300 (see, e. g., FIG. 10) that may include general and special purpose software. and may be configured to communicate data from an identification card 250 to the processor 100 via the health network 10. The provider computing device 300 may comprise an identification card reading device 320 such as, by way of non-limiting example, a magnetic card reader, connected to the processor 100 that is configured for sequentially swiping multiple cards, and for communicating the data from the sequentially swiped cards to the processor 100 for processing together. Reading device 320 is described below as a magnetic card reader, but it will be recognized from the teachings herein that reading device 320 may be any device for reading data from any type of data card, storage device, smart card, PDA, or the like, as a matter of design choice. For example, a health care provider 60 and an insured 90 may sequentially swipe their respective identification cards 250 through the card reading device 320 (or otherwise cause the data on the card to be sent to the processor 100) and their respective identification data is transmitted to the processor 100 and process as described in more detail below. The dual-swipe functionality for the card reading device 320 may be provided by software resident in the card reading device 320, software resident in the processor 100, or a combination of both.

Alternatively, the health care provider computing device 300 may be an identification card reading device 320 connected to a personal computer 310 (see, e. g., FIG. 10) or other functionally similar electronic device, which may include general purpose software (e. g., ICHN browser or other communication software) and special purpose software for providing additional functionality (e. g., dual-swipe) for the card reading device 320. Alternatively, software resident in the card reading device 320 may also provide the dual-swipe, or other functionality.

The provider computing device 300 may be configured for single-swipe, dual-swipe, or either single-or dual-swipe functionality. When configured for single-swipe functionality, the provider computing device 300 permits an insured to swipe his/her identification card 250 through the reading device 320, and that member's identification data will be transmitted to the processor 100. When configured for dual-swipe functionality, the provider computing device 300 permits an insured and a health care provider to sequentially swipe their respective identification cards 250 through the reading device 320 and their respective identification data will be transmitted to the processor 100. In either case, the processor 100 may identify the member using a look-up table, for example, and also determines whether the transaction is a health-related transaction that should be routed to the health network 10, or a financial transaction that should be routed to the banking network 16.

In an alternative embodiment, the health care provider computing device 300 may comprise a stand-alone computing device (e. g., a kiosk) that connects to the health network 10 (i. e., to the processor 100), but not to the health care provider's office computers or network.

Access to the health network 10 and to the data provided thereby is also available to the insured 90 using a personal computer and the Internet, for example. The insured 90 thus has access to all data for a health-related transaction for that insured 90, that data being the same data available to the health care provider 60 and the insurance provider 20 of that health related transaction.

The processor 100 also connects to a banking network 16 comprised of a plurality of financial service providers 40. Since the processor 100 is configured to determine whether incoming data is for a health-related transaction or for a financial transaction, the latter can be routed or otherwise directed to the banking network 16. Approval or denial of the requested

financial transaction is provided by the financial service provider 40 to the processor 100, which communicates that approval or denial to the requesting party (e. g., insured, health care provider. or insurance provider).

The processor 100 is preferably also designed to determine if a claim or claims have been pre-approved for payment by the insurance provider 20. In that case, when the health care provider 60 submits a claim for payment for a pre-approved health service rendered to an insured, that payment request is formatted by the processor 100 (see description below) and routed directly to the banking network 16, which executes an electronic fund transfer from the insurance provider's bank to the health care provider's bank. That functionality accelerates payment to the health care provider (and thus, reconciliation between the insurance provider and health care provider), reduces administrative costs for the insurance provider, and considerably reduces the potential for fraud.

The processor 100 is certified to create automated clearing house (ACH) and electronic funds transfer (EFT) files and transmit those files to financial service providers 40.

Thus, the processor can transmit financial transactions directly to the banking network 16 to satisfy co-payment obligations of the insured 90 and claim payment requests of the health care provider (s) 20 via a connection to the banking network 16 and transmission of an appropriate file to a bank, for example. Upon receipt of an ACH or EFT file, a bank will carry out the instructions provided in the file and transfer the necessary funds from the insured's or insurance provider's bank directly to the health care provider's bank.

With continued reference to FIG. 2A, the processor 100 may comprise a main computer 104 and a plurality of satellite computers 106 connected together via a secure local- or wide-area-network (LAN/WAN) 102, or a virtual private network. Each of the main and satellite computers 104,106 may be comprise identical hardware and software, providing for

multiple redundancy. Alternatively, each of the main and satellite computers 104,106 may be comprise hardware and software configured to provide a predetermined functionality of set of functionality of the processor 100. Although the functionality of the processor 100 may be distributed between and among the main and satellite computers 104,106, the processor 100 will preferably appear as a single system (i. e., a virtual central processor) external to the processor 100.

Access and connection to the processor 100 by the insured 90, health care providers 60, insurance providers 20, and employers 30, may be via virtually any land-based or wireless connection device, system, or method, as a routine matter of design choice. Connection between the processor 100 (i. e. health network 10) and the banking network 16 is preferably via existing secure devices, systems, or methods, as known and used in the art for such sensitive transactions.

The health network 10 and processor 100 of the present invention also facilitate visits by the insured to non-member health care providers 180 (see, e. g., FIG. 1). In that case, the insured 90 may be entitled to reimbursement from the insurance provider 20, but the non- member health care provider 180 is paid directly by the insured 90 and does not submit a claim to the insurance provider 20. The insured's identification card 252 may be used to request payment from the insured's bank to the non-member health care provider's bank. The processor 100 will facilitate that financial transaction and reconcile reimbursement by the insurance provider 20 to the insured 90 by communicating a claim for reimbursement to the insurance provider 20. Of course, the insurance provider 20 has access to all data for the health related transaction.

Data flow within the health network 10 as coordinated by the processor 100 is depicted in FIG. 2B. Bi-directional data communication occurs between the processor 100

and insurance providers 20 (identified as"Health Plan"in the figure), financial service providers 40 (identified as"Bank"in the figure), and the health care provider 60 (identified as "Provider"in the figure). Once an insured's identification number has been received and verified by the processor 100, uni-directional data flow can occur between the processor and insured 90 (identified as"Member"in the figure). For the insurance providers 20, communication may be from the processor 100 and include health-related transaction data received by the processor 100 from a health care provider 60, and database updates from the processor 100. Alternatively, communication may be from the insurance provider 20 to the processor 100 and include health plan changes and database updates. For the financial service providers 40, communication may be from the processor 100 and may include financial transaction data such as, for example, ACH and EFT files, or it may be from the financial service providers 40 to the processor 100 and may include authorization and/or acknowledgement of completion of a requested financial transaction. For the health care providers 60, communication may be from the provider 60 to the processor 100 and may include identification data (for the insured and health care provider), requests for information (typically transmitted via the processor 100 to another health care provider 60), clinical data, referral requests, co-payment requests, claim submittals, and other data for the health-related transaction. Communication to the health care provider 60 by the processor 100 may include authorization data, information from another health care provider and clinical data.

Communication from the processor 100 to the insured 90 may include that insured's account data.

Referring next to FIG. 3, the processor 100 the processor functionality may be provided by a plurality of subsystems 110,120,130,140,150,160, each providing a particular functionality or set of functionalities, as described in more detail below. While

particular preferred embodiments of the processor 100 and associated subsystems as taught herein are described in detail herein, it should be noted that the functionality of the processor 100 and subsystems may be implemented in various ways using various combinations of computer hardware, general purpose software, and special purpose software, as a matter of design choice. In addition, the specific subsystems that comprise the processor functionality may be different for different insurance providers, and may change as the needs of the health care network 10 change (i. e., subsystems may be modified, added, and/or deleted). Thus, the embodiments discussed herein and depicted in the figures are provided as illustrative, non- limiting examples of the functionality of the processor 100.

As depicted in FIG. 3, the processor preferably has a plurality of subsystems, including, but not limited to: a host subsystem 110; a communication subsystem 120; an eligibility subsystem 130; a financial subsystem 140; a replication subsystem 150; and an administration subsystem 160. Each of these subsystems will now be described in greater detail. The following description of the subsystems of the processor 100 of the present invention and the accompanying drawing figures are provided as illustrative, non-limiting examples of the functionality of those subsystems and the interrelation between and among the subsystems, the processor 100, the insurance provider (s) 20, the health care provider (s) 60, the insured 90, the employer (s) 30, and the banking network 16. Configurations and embodiments other than those described below and depicted in the drawings figures may be readily constructed by those skilled in the art in accordance with the present invention and in accordance with the disclosure provided herein. Such other configurations and embodiments are thus contemplated by the present invention.

1. The Host Subsystem

The host subsystem 110 provides overall control of the processor 100 and health network 10, communicates with the other subsystems of the processor 100, and controls and electronically links all activity for the health-related transaction. That electronic linking provided by the host subsystem 110 establishes an audit trail by creating and maintaining an electronic record of all transactional and all manual access to these transaction data records.

Transactional access and transactional data, as used herein, respectively refer to access to the processor 100 and/or any subsystem during a health-related transaction, and any data (e. g., text, graphical, images, ACH, EFT, etc.) associated with the health-related transaction including, but not limited to, health care provider identification number, insured identification number and personal identification number (PIN), health plan identification number, insurance provider identifier, and various other identification numbers, codes, etc. Manual access, as used, herein, refers to access by a system administrator to the processor 100 and/or any subsystem to manually change data (e. g., insurance provider changes health plan rules, insurance provider add/deletes doctors, employer adds/deletes, etc.). The electronic record may include the date, time, user identification or terminal identification, and an indication of what data was altered and how it was altered.

The host subsystem 110 coordinates access to the data storage device 170 and to the databases stored thereon. Those databases may include data used by the processor 100 (by the various subsystems) to provide the coordination of data communication in accordance with the present invention. The data in the databases may be provided by the insurance providers, employers, health care providers, financial service providers, and the insured.

Some of that data is updated automatically, while some data is updated manually. For example, changes by the insurance provider in health plan data are automatically uploaded by the insurance provider site server 200 to the processor 100 via the host subsystem 110.

The host subsystem 110 automatically uploads/downloads data to and from the site servers 200 and health care provider computing devices 300 via the communication subsystem 120. The host subsystem 110 may, in addition, handle all authorizations for access to the data contained in the plurality of databases on the data storage device 170.

The host subsystem 110 also creates and maintains an electronic record that links all activity associated with a specific health-related transaction. That electronic record may be treated as a pseudo case file by the processor and is retrievable by the processor 100, when desired. The electronic record links all transactions (activity) associated with one health- related transaction or case and permits the processor 100 to treat that record as a pseudo case file that may be communicated, in whole or in part, to members and within the health network 10. The database structure of the pseudo case file may contain a field, or several fields if needed, to allow for the desired electronic linkage of all transactions (activity) for a health- related transaction. Records linked in that fashion may be retrievable individually or as a set when necessary. Multiple open cases (i. e., electronic records) for one insured are permitted.

An illustrative example of the electronic record and linkage provided in accordance with the present invention is depicted in FIGS. 4-7, and discussed in more detail below.

The host subsystem 110 also communicates with the eligibility subsystem 130 and passes all transactional data received by the processor 100 to the eligibility subsystem 130 when an eligibility determination is required for the health-related transaction. For example, when a member (insured or health care provider) attempts to access the processor 100 using his/her identification card 250 and a computing device 300, identification data received by the host subsystem 110 is communicated to the eligibility subsystem 130. The eligibility subsystem 130 accesses a database of member identification data on the data storage device 170 and determines if the member is an eligible member. The processor 100 further

maintains or has access to a list of active insured 90, health care providers 60, and health care provider computing device 300 identification numbers for each insurance provider 20 and for each health plan offered by the various insurance providers. If it is determined by the processor 100 that any of the insured 90, health care provider 60, or health care provider computing device 300 is excluded from the health network 10 (i. e., is not eligible), the host subsystem 110 shall cause the communication subsystem 120 to terminate the connection to the health care provider computing device 300.

During the initial authorization/eligibility determination process, the host subsystem 110 receives an original transaction authorization number (or code) or transaction denial number (or code) from the eligibility subsystem 130, depending upon the eligibility determination performed by the eligibility subsystem 130. The host subsystem 110 links the transaction authorization or denial number with the electronic record and communicates that number to the communication subsystem 120 for transmission to the health care provider computing device 300 from which the transaction data was communicated. The electronic record now contains a link to the original transaction authorization or transaction denial number.

The host subsystem 110 also communicates with the financial subsystem 140. When data received by the processor 100 is determined to be a purely financial transaction, that data may be formatted (e. g., an ACH or EFT file created) and communicated directly to the financial subsystem 140 for transmittal to the financial service provider 40 via the banking network 16. A purely financial transaction may include, by way of non-limiting example, a request from the insured 90 for co-payment to a health care provider 60, receipt by the insurance provider 20 of a claim from a health care provider 60 for payment by the insurance provider 20 for health care services rendered by the health care provider 60 to the insured 90,

and the insurance provider's 20 approval or denial of the health care provider's 60 claim for payment. The host subsystem 110 may also receive data from the financial subsystem 140 that includes approval and denial of the requested payment received from the financial service provider 40. Both the request for payment from the member and the approval or denial from the financial service provider 40 are linked to the electronic record as part of the activity for the health-related transaction. The host subsystem 110 may, upon request, furnish financial data statements to authorized insurance providers 20, health care providers 60, insured 90, and financial service providers 40.

The host subsystem 110 also communicates with the replication subsystem 150 so that up-to-date health plan rules, eligibility data, and various other data associated with the respective insurance providers 20, employers 30, health care providers 60, insured 90, and financial service providers 40 is available in real-time throughout the health network 10. The replication subsystem 150 may identify changes in database records relating to an insurance provider, a specific health plan, an insured, a health care provider, an employer, or a financial service provider, and ensures that all changes are replicated throughout the health network 10.

The host subsystem 110 may either receive change data and update the replication system 150 databases or, alternatively, the replication subsystem 150 may send change data to the host subsystem 110 for communication to relevant devices (e. g., site server 100, financial service provider 40, health care provider computing device 300) in and connected to the health care network 10.

The host subsystem 110 also communicates with the administration subsystem 160 to enable administrative personnel to manually change data stored in the processor databases.

For example, addition or deletion of a health care provider computing device 300 would require the identification number for that device to be added or deleted. That task may be

manually carried out by a network administrator. In addition, network administration, such as for example, data backup, may be coordinated by the host subsystem 110 according to parameters and conditions defined by the administration subsystem 160.

The host subsystem 110 may also build data sets for export and use by other subsystems or by other computers within or out of the health network 10. The host subsystem 110 may also coordinate the generation of ad hoc reporting such as a health care provider or insured activity report. Standard and customized reports may be developed and generated, as a routine matter of design choice. For example, an insurance provider may require monthly reports for each health care provider providing services under specific health plans. Reports may also be generated for use in accounting, statistical analysis, inventory, and system management.

The general purpose software provided as part of the processor facilitates building database structures, database content, and creating, rebuilding, or repairing database indices.

All database functions (e. g., searching, sorting, updating, etc.) and transaction processing is preferably performed with commercially available database products including, by way of non-limiting example, Visual FoxPro, SQL Server, Access, Visual Basic, or Visual C++, or other similar are-recognized software products.

Transaction processing refers to the communication of data within the health network 10 and to the manipulation and processing of that data by the processor 100 and connected hardware and software components (i. e., site servers 200, health care provider computing devices 300, financial service providers 20, etc. Transaction processing includes creating and maintaining, by the host subsystem 110, an electronic record of all transactional and all manual access to the transaction data records to provide an audit trail for each health-related transaction. This electronic record may include the date, time, member and/or computing

device identification number, and an indication of what data was altered and how it was altered.

Transaction processing also refers to receiving data from and sending data to the communication subsystem 120. Data received from a health care provider computing device 300 may be entered into the electronic record and parsed for a transaction type field (e. g., health-related or financial). The content of the transaction type shall result in data being forwarded to the appropriate processing function for action (e. g., to the financial subsystem 140 for a purely financial transaction). Data sent to the communication subsystem 120 shall be logged in the electronic record and prepared (formatted, if necessary) for forwarding to the communication subsystem 120. This data preferably includes a destination identifier (i. e., address).

The host subsystem 110 maintains a database of valid health care provider computing device identification codes, and/or health care provider personal computer identification codes. When a terminal session is begun (i. e., when a health care provider computing device 300 begins transmission to the processor 100), the host subsystem 110 interrogates this database to determine if that health care provider computing device 300 has access rights to the health network 10. If the terminal 300 has been marked for exclusion from the health network 10, for whatever reason, the host subsystem 110 causes the communication subsystem 120 to transmit a terminate command to the terminal.

The host subsystem 110 operates as a gateway for all authorizations for access to the data contained in the data storage device 170. Rights to access the data contained in the storage device 170 shall be assigned to authorized subfunctions as necessary to maintain the integrity and security of that data. All requests for rights shall be authenticated before access is allowed using software such as, for example, Microsoft Windows NT.

2. Eligibility Subsystem The eligibility subsystem 130 performs rules-based testing on each insured 90 and health care provider 60 prior to authorizing performance of a health care service by the health care provider 60. In particular, the eligibility subsystem 130 performs tests on the transactional data received from the host subsystem 110 using specific insurance policy and health network data provided by the insurance providers 20. Multiple instances of the eligibility subsystem 130 may be provided in the processor 100, to accommodate multiple insurance provider eligibility rules.

The eligibility subsystem 130 determines eligibility for the insured, health care provider, and those parties together. When eligibility is determined, the health-related transaction i has been approved.

As discussed above, the eligibility subsystem 130 receives data from the host subsystem 110. This data may include transactional records to be tested to determine if the insured 90 is eligible to receive health care services and if the health care provider 60 is eligible to provide those services. Also, the eligibility subsystem 130 will preferably be capable of sending data to the host subsystem 110. That data may be comprised of, for example, authorization or denial information as determined by the appropriate subsystem.

There are generally two major subdivisions of the eligibility subsystem 130 for each insurance provider 20: the insured and the health care provider authorization, which may be simultaneously processed by the eligibility subsystem 130.

When determining whether the insured 90 is authorized under a health plan, a rules- based eligibility test is preferably used. In particular, the policy data provided by the insurance provider 20 can be used to determine if the insured 90 is currently covered by a

health plan. The rules-based eligibility test may include a test of the current validity of the plan itself as well as the insured's current participation in the plan, the applicable coverage for that insured under that plan, and any financial and/or temporal limitations. Up-to-date data is ensured by automatic transmission of eligibility data between and among the processor 100, the insurance provider 20, and employer 30. More specifically, the replication subsystem 150 (discussed below) ensures that changes to any of the data maintained and used by the processor 100, insurance providers 20, employers 30, and financial service providers 40, is replicated throughout the network 10, regardless of where the changes were made (e. g., at the insurance provider site server 200, at the employer 30, at the processor 100 via the administration subsystem 160, etc.).

In the event that the current transaction is not a referral visit, a test may be performed to determine whether the health care provider 60 is the primary care provider (PCP). If the provider is not the insured's primary care provider, a notice of the potential financial risk to the health care provider 60 and the insured 90 shall be forwarded to the provider's health care provider computing device 300. In the event that emergency services are required, the health network 10 will preferably not cause emergency services to be denied (unless, of course, the insurance provider's 20 contract explicitly orders such a denial).

The eligibility subsystem 130 may determine eligibility for any type of insurance provider 20 offering any type of health plan. For example, an insurance provider 20 may offer insurance under a variety of health plans, e. g., HMO, etc. Different rules (provided by the insurance provider 20) may be applied by the eligibility subsystem 130 for the different health plans.

In a preferred embodiment, referral visits will require the use of a previously issued referral authorization number or code. Such an authorization number may, for example, be

provided by the processor 100 to the PCP, and communicated by the PCP to the insured 90.

Also, a provision shall be made to retrieve the referral authorization number from the referred health care provider 60 in the event that such authorization number is not readily available to the insured 90. In such a case, for example, the referral authorization number may be retrieved from the referred health care provider 60 by using the PCPs'identification number and the insured's identification number; those two data being part of the electronic record and previously linked by the processor 100 when the referral authorization number was provided.

In addition, given that the eligibility test will require a very high number of very complex searches through massive databases, the eligibility subsystem 130 may be provided on more than one of the main processor 104 and satellite processor 106. In such a configuration, the main processor 104 will coordinate the distributed functionality of the eligibility subsystem 130.

When determining whether or not the health care provider 60 is currently under contract, i. e., is currently eligible, the eligibility subsystem 130 may utilize data provided by the insurance provider 20. That data may be provided in real-time or previously downloaded by the insurance provider 20 to the processor 100. In the event that the health care provider 60 is not under contract, the processor 100 shall provide notice that the cost of any services provided may not be paid by the insurance provider 20 and a transaction denial number is transmitted to the health care provider 60. The date, time, authorization number, and notice number shall be logged for use in payment adjudication. Additionally, in the event that a health care provider 60 explicitly identifies such service requests as unauthorized. the eligibility subsystem 130 shall deny all such service requests.

3. Communication Subsystem

The communication subsystem 120 facilitates communication between the processor 100 and the health care provider computing device 300, and the insured 90. Since all of the health care provider computing devices 300 are part of the health network 10, those computing devices 300 will preferably employ the same communication techniques and protocols. However. the communication subsystem 120, or any other subsystems of the processor 100, may be adaptable to enable communication between the processor 100 and a device, system, etc. that employs a different communication technique or protocol.

The communication subsystem 120 may receive data from the health care provider computing device 300, including, but not limited to, transactional data for communication to the host subsystem 110 so that such transactional data may be properly routed (e. g., to the eligibility subsystem 130, the financial subsystem 140, etc.). The communication subsystem 120 may also transmit data to the health care provider computing device 300. That data may include, for example, transactional records forwarded from the host subsystem 110.

Additionally, the communication subsystem 120 may include voice response functionality provided by a voice response unit (VRU), for example, or other art-recognized voice recognition and conversion devices or systems, to enable communication between an insured 90 and the processor 100 using spoken commands. The communication subsystem 120 may receive data that may consist of, for example, numerical responses or voice responses by the insured 90 in response to predetermined requests, instructions, commands, etc. (i. e., scripts) provided by the communication subsystem 120. These"scripts"shall define the individual steps required of the insured to obtain the desired data. Prior to allowing the user access to any data, the communication subsystem 120 shall authenticate (in connection with the eligibility subsystem 130) the insured's identity and access permission.

4. Financial Subsystem The financial subsystem 140 facilitates communication between the processor 100 and the banking network 16 for purely financial transactions, and for financial transactions associated with a health-related transaction. Transactional data received by the processor 100 for a purely financial transaction may be formatted by the financial subsystem 140 (e. g., an ACH or EFT file created) and communicated directly to the appropriate financial service provider 40 via the banking network 16. That activity becomes part of the electronic record.

If the transactional data is for a health-related transaction yet includes a financial transaction request (e. g., co-payment, claim settlement), the data is communicated to the financial subsystem 140 for processing. That processing may include proper formatting, transmission to the financial service provider 40, receipt by the financial subsystem of an authorization, denial, or acknowledgement from the financial service provider 40, communication to the host subsystem 110 for update of the electronic record, and communication to the health provider computing device 300 of the authorization or denial of payment.

The financial subsystem 140 may facilitate the electronic transfer of funds from an insured's bank to a health care provider's bank to satisfy the insured's co-payment obligation.

The financial subsystem 140 may also facilitate the electronic transfer of funds from the insurance provider's bank to the health care provider's bank to settle claims.

The financial subsystem 140 may have access to a list of pre-approved health care services, provided by the insurance provider 20 to the processor 100. When a health care provider 60 submits a claim for a pre-approved health care service, the financial subsystem 140 may automatically create and transmit an ACH file to the appropriate bank thus permitting that bank to transfer the necessary funds directly to the health care provider's bank That activity is captured by the host subsystem 110 and included in the electronic record.

Various tags may be assigned to specific transactions by the financial subsystem 140.

Authorized co-payments may be tagged as received, denied co-payments tagged as denied, claims tagged as pending, and a completed health-related transaction (i. e., a closed case) tagged as closed.

5. Replication Subsystem The replication subsystem 150 maintains database synchronization throughout the health care network 10. More specifically, the replication subsystem 150 ensures that all database changes, whether initiated by the processor 100, insurance provider 20, or employer 30, are communicated in real-time throughout the network 10 so that data throughout the network 10 is current and consistent. The replication subsystem 150 may automatically transmit and receive data to and from the site servers 200 or according to a predetermined schedule (i. e., batch processing). One instance of the replication subsystem 150 may be necessary to communicate with each site server 200.

The replication subsystem 150 may receive data from the host subsystem 110. That data may be, by way of non-limiting example, database records requested from the host subsystem 110 for transmission to the site servers 200. The replication subsystem 150 also receives data, such as, for example, unsolicited database records downloaded from the site servers 200, and co-payment authorization result records.

The replication subsystem 150 may also, in a preferred embodiment, decrypt and expand database records that have been received in encrypted and/or compressed form from the various site servers 200. The replication subsystem 150 may also, if desired, compress and encrypt database records which are to be sent to the various site servers 200 to ensure secure transmission of those database records. Additionally, the replication subsystem 150

preferably maintains a log of all communication between the processor 100 and the site server (s) 200.

The replication subsystem 150 may also transmit data to the site server (s) 200 such as, for example, synchronization records, synchronization requests, and real-time co-payment authorization requests from the insured 90. The replication subsystem 150 may also send database record requests and database update records to the host subsystem 110. Of course, any record tagged as immediate is forwarded to the site server 200 or, accordingly, to the host subsystem 110, without delay. The replication subsystem 150 preferably has the functionality to control transmission to (uploads) and from (downloads) the site servers 200.

6. Administration Subsystem The administration subsystem 160 provides the graphical user interface (GUI) to the processor 100, thus allowing for maintenance of system level information by a health network administrator. This subsystem can either be locally or remotely accessed for administrative actions and is generally responsible for monitoring the operational statues of the health network 10.

The administration subsystem 160 communicates with and can send, receive, and process data from the host subsystem 110. That data may include responses to administrative requests such as filtered database records, status reports, database record counts, storage use reports, usage statistics, transaction volumes, and requested administrative actions. The administration subsystem 160 may send data to the host subsystem 110 including, updates to master database records, requests for data, requests for status, and log data for maintenance use. The processing may include health plan changes, member changes, policy changes, suspensions, deletions, warnings, password changes, and other such requests. Additionally,

the administration subsystem 160 may process diagnostic tests and provide data about the operational status of the health network 10, including all subsystems, hardware and software components.

Referring next to FIG. 10, each health care provide 60 is equipped with a health care provider computing device 300 that may comprise an identification card reading device 320 such as, by way of non-limiting example, a magnetic card reader, connected to the processor 100. In such an embodiment, software at the processor 100 may provide additional functionality for the card reading device 320 such as, for example, dual-swipe functionality.

Alternatively, the health provider computing device 300 may be an identification card reading device 320 connected to a personal computer 310 or other functionally similar electronic device, which may include special purpose software for providing additional functionality (e. g., dual-swipe) for the card reading device 320. Communication between the computing device 300 and the processor 100 may be via modem 350, for example, or via virtually any land-based or wireless communication method, device, protocol, or the like The health care provider computing device 300 preferably has one or more of the following: a display 340 such as, for example, a liquid crystal, liquid plasma, or light emitting diode display; a keypad 330; a magnetic strip reader 320; and a modem 350, or other art- recognized communication device.

The modem 350 may be used by the computing device 300 to dial or otherwise connect to the processor 100 and transmit collected data transactions, protocol messages, terminal identification messages, and other requested data to the communication subsystem 120. It is preferred that a predetermined login sequence be followed to assure authorized connection to the processor 100. Additionally, the modem 350 may answer incoming calls and receive data from the communication subsystem 120. In a preferred security

arrangement, a"secret"key received and recognized by the modem 350 will ensure authorized connection with the calling device or system (i. e., the processor 100). If the key is not received or recognized, the line shall be dropped. A record will be kept of these attempted communications, and failed attempts be communicate with the computing device 300 shall cause a message to be displayed indicating the date and time of the last failed attempt. If a predetermined threshold of failed dial-in attempts is exceeded, the computing device 300 shall automatically lock-out incoming calls, requiring manual intervention to remove the lock. Of course, the person of skill will recognize from the teachings herein that a variety of now known or later developed security methodologies can be implemented as part of the inventive system. The data received by the computing device 300 may include, for example, protocol messages, uploaded programs, and uploaded database records.

When the computing device 300 comprises a card reading device 320 connected to a computer 310, the special purpose software provided on the computer 310 is preferably programmed to recognize attempts to tamper with the reading device 320. The special purpose software also has access to the manufacturer's embedded serial number for the card reading device 320, and may communicate that serial number as a computing device identification number to the processor 100.

The computing device 300 can optionally maintain a database in its internal memory that may contain records of each transaction made at the device 300. The database may be used to allow the health care provider 60 to review past transactions and to make entries needed to support claims for payment. The database may be maintained for no less than one previous day's transactions, or as many days as are desired, as a matter of application specific design choice. The deletion of database records shall require at least two acknowledgments and shall be allowed only for records already transmitted to the processor 100.

7. Site Server Subsystem The site server 200 include a resident site server subsystem 210 that is customized for each insurance provider 20 and that provides the functionality to enable the insurance provider 20 to operate and manage all aspects of each health plan offered by that provider 20. including functionality for interfacing with any legacy computer systems of the provider 20.

A duplicate of the site server subsystem 210 is provide within the health network 10 and preferably comprises a part of the processor 100. Depending upon the requirements of each insurance provider 20, the site server subsystem 210 may include all or some of the subsystems provided in the processor 100 and described above.

Referring next to FIG. 4, the linkage provided by the electronic record for all activity (i. e., data and transactions) for a health-related transaction in accordance with the present invention is there depicted. The starting point for the electronic data linkage is the insured's initial visit to the PCP. At that visit, if both the insured and PCP are eligible members of a health plan, the processor 100 provides an original authorization number that becomes a reference number to which all subsequent activity and transactions for the health-related transaction refer. Thereafter, all activity for the health-related transaction are linked to the original authorization number via the electronic record. Thus, all claims, financial, eligibility, referral, clinical, pre-certification, hospital, pharmacy, health care provider, insured, insurance provider, employer, and subsystem generated or related data are linked via the electronic record (depicted as"Electronically Linked Data"in the figured) and thus available to the processor 100 for various uses.

Referring next to FIGS. 1,3,5, and 10, an illustrative, non-limiting example of how the electronic data linkage and preferred data flow is carried out in accordance with the

present invention is there depicted. Note that the labels and codes are merely exemplary, and may be implemented in myriad ways as a matter of application specific design choice. That depiction is for a typical series of office visits to a PCP and three referred health care providers (no distinction is made between health care provides, other than the PCP).

At the top of FIG. 5, exemplary parties (i. e. participants) to a health-related transaction (or at least a part of a health-related transaction) are identified. Starting at the left, they are: the insured 90; the PCP ("Primary"); referred provider I ("Ref 1"), a provider referred by the PCP; referred provider 2 ("Ref 2"), another referred provider; referred provider 3 ("Ref 3"), a third referred provider; and references to all activity for the health- related transaction, represented by authorization numbers, and that may comprise a part of the electronic record. Data flow between the members is indicated by the directional arrows.

The health-related transaction begins in the insured column, with the activity at the circle marked"1". Here the insured appears at the office of the PCP. The front office staff of the PCP determine that this is a new case, i. e., this visit is not a follow-up visit, nor is it a referral from another provider. The notation"New"in the top box in the Primary column indicates this fact. First the provider's card is swiped through the health care provider computing device 300, a response comes back from the processor 100 directing the insured to swipe his or her card and enter a PIN number. The identification data is then transmitted to the processor 100, depicted by an arrow from the"New"box under Primary to the"OK"box under the processor column. If the member is eligible to receive service from the specific provider, an original transaction authorization number is sent from the processor 100 (from the eligibility subsystem 130) to the computing device 300. This first transaction also identifies the eligibility of member and service. Both card numbers are then linked in the electronic record to the authorization number with time and date. This begins the linked data

flow of the present invention. The"OK"indicates that the processor 100 has determined that the insured 90 is eligible for services from this PCP. The processor 100, recognizing that this is a new case, assigns an original transaction authorization number (123450) to the case and transmits it to the PCP. This is noted by the"Auth"in the second box from the top of the Primary column.

The insured 90 may elect to pay for the health care services using his/her identification card 250 by swiping the card 250, enter a PIN, and selecting to pay for services, or pay co-pay, through processor 100. That payment request is communicated to the financial subsystem 140 and to the insured's bank. Alternatively, the insured may have previously authorized co-payment to the health care provider.

At the end of the office visit, the PCP refers the insured to three different providers.

This is indicated by the series of activities beginning with the"Ref 1"box in the Primary column. Here the PCP provides the processor 100 with the original transaction authorization number. Also provided, but not shown for the sake of clarity is the referred provider's identification number. This tells the processor 100 that a referral is to be made and if the processor 100 finds no reason to deny the referral, it is"OK"and a referral authorization number (123451) is provided by the processor 100 to the PCP. This process is repeated for referrals two and three, with the processor 100 transmitting or providing referral authorization numbers 123452 and 123453, respectively.

At some convenient time, the PCP's office enters the list of services provided to the insured. This is again identified with the original transaction authorization number (123450).

The processor 100 provides a return approval code 123450C to the PCP.

The insured, in the interim, has appeared at the first referred provider indicated by the circle in the Insured column marked"2". The front office staff at the referred provider goes

through a process similar to that at the PCP, except that they indicate to the processor 100 that the visit is a referral and provide the referral authorization number (123451) the insured carries with them on a referral form. The referral office receives an"'OK"from the processor 100 and is provided with a claim authorization number (123454) for use in their later submittal of the list of services they provided. This process is repeated at the other two referred providers, shown as circles marked"3'and"4"'resulting in claim authorization numbers 123455 and 123456.

The insured then returns to the PCP for a follow-up visit shown as circle"5". Here the PCP indicates that this is a follow-up visit and provides the original authorization number (123450). A new claim authorization number is supplied (123457). The PCP later submits their claim with this number and receives an approval code of 123457C.

Also note, on the far right edge of the figure there is a heavy black line labeled "Linked Database record pointers". This line is meant to indicate that the processor 100 has created and maintained (linked) an electronic record of all activity for the health-related transaction, including all authorization numbers provided to the service providers. All of the information exchanged during each activity is also logged in the electronic record by the processor 100 and tagged with the authorization number, date, time, and other important information. When this data is needed later, the complete chronology of the activities and the associated data can be recalled as a pseudo case file similar to the paper files maintained at the health care providers'and insurance providers'offices.

The insurance provider 20 may then choose to pay for claims via the processor 100 by authorizing the electronic payment of specific claims, or multiple claims and using the authorization code (s) to direct the processor 100 to transmit to the appropriate financial service provider 40 a request for EFT. The processor 100 links the claim payment request to

the original transaction authorization number, and the referred health care provider's bank receives the funds from the insurance provider's bank. The referred provider also receives an electronic statement for settlement of claims, referring back to each claim and/or the relevant authorization number.

Illustrative activity reports that may be produced by the processor 100 using all or part of the data in the electronic record are depicted in FIGS. 8 and 9 for a health care provider and an insured, respectively. In those figures it can readily be seen that line-by-line reporting and reconciliation are available to the health care provider and insured. In addition, the report provided to the insured may include information in addition to that for health-related transactions. For example, when the insured 90 is provided with a multi-function card 252, various other information relating to the other functionality provided by the card may be included in the insured's activity report, such as, for example, debit card, prepaid phone card, loyalty card, and gift certificate card activity.

The data linkage provided by the electronic record in accordance with the present invention is depicted in FIGS. 6 and 7 for clinical data and financial data, respectively. For each example depicted, all subsequent activity is linked to the original transaction authorization number and maintained as part of the electronic record. For the clinical data linkage depicted in FIG. 6, this aspect of the present invention is particularly useful to health care providers in communicating clinical data between and among themselves, and provides for easy qualification and quantification of the health care services being provided for a particular patient (i. e., insured). The ability of health care providers to communicate clinical data in the manner provided by the present invention, and to provide electronic linkage between the clinical data at all stages of the insured's treatment, has heretofore not been available. Moreover, the clinical data communicated between health care providers is secure

in that only the insured's identification number is transmitted along with the clinical data; there is no identifier or means of linking the clinical data with the actual insured 90 until the insured provides their identification number (e. g., by swiping their identification card 250).

The clinical data thus merely passes through the processor 100, encoded or encrypted, thus ensuring the anonymity of sensitive patient medical information.

With continued reference to FIG. 6, an original transaction authorization number 0005000 is provided by the processor 100 following an initial eligibility determination for the insured 90 and health care provider 60. At that initial visit, referral authorization numbers 0005001 A and 0005002 may also be provided by the processor 100, thus authorizing the insured's treatment by one or more referred health care providers 60. When visiting each referred heath care provider 60, the provider and insured both swipe their respective identification cards, and the processor thus links that visit, those parties, and the referral authorization number to the original transaction authorization number 0005000 together in the electronic record. Other referral authorization numbers 0005001B and 0005001C may also be provided by the processor 100 for various health care services to be performed by the referred health care provider 60.

The insured 90 may also return to the primary care provider 60, with that visit being authorized by the processor via authorization number 00050003, when than is also linked by the processor 100 to the original transaction authorization number 0005000.

Clinical data communication in accordance with the present invention is also depicted in FIG. 6. When a primary care provider desires a referred care provider to perform certain tests, procedures, etc., the primary care provider may transmit a request for information (RFI) to a referred care provider. That RFI may include specific instructions regarding tests, information, etc., that the primary care provider desires the referred care provider to obtain.

Also transmitted with the RFI may be clinical data for a particular insured. However, nowhere in the transmission is there any identifier for the insured. Only the original transaction and/or referral authorization numbers are transmitted between the health care providers with the clinical data. When the RFI (and clinical data) arrive at the referred care provider's computing device 300, the referred care provider cannot link that data to a person until the insured provides his/her identification number during an office visit with the referred care provider. At no time is any insured identification data transmitted with clinical data.

Communication of the clinical data from the referred care provider to the primary care provider is similarly secure.

With reference next to FIG. 7, financial data linkage in accordance with the present invention is there depicted and will now be discussed. As with all other activity for the health-related transaction, all financial activity is linked to the original transaction authorization number 0005000. When a health care provide 60 submits a claim for payment to the insurance provider 20 via the processor 100, the appropriate authorization number is also transmitted (e. g., 0005001A, 0005001B, etc.). Having been previously linked to the original transaction authorization number 0005000 and making up a part of the electronic record, reconciliation of the claim is automatic. The electronic record may also include a reference to whether a claim has been paid or remains pending.

The processor 100 ensures (via the replication subsystem) that the insurance provider (s), health care providers, and health network 10 (processor 100) maintain exact duplicate records for every office visit, health care service provided, payments, etc., of the health-related transaction, through financial settlement. Members (health care providers and insured parties) may be provided with a written statement or an electronic statement of that members activity relating to a health plan for a predetermined time period or health-related

transaction. Electronic statements may be transmitted by the processor 100 to the member using the Internet or other means of electronic transfer, or through a voice response unit (not shown). In one embodiment the data may be provided in a monthly statement similar to the methods that banks and bank cards utilize to provide data to their cardholders. The identification card 250 and the health network 10 constructed in accordance with the present invention provide a way to maintain medical history information for members. That data could be recalled using the member's identification card via fax, voice or electronic means.

The processor 100 of the present invention enables a member to change health plans for a particular insurance provider, and even to change insurance providers without having to issue a new identification card. Such changes are provided in the eligibility subsystem by the insurance provider, employer or processor 100.

Thus, while there have been shown and described and pointed out fundamental novel features of the invention as applied to preferred embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the disclosed invention may be made by those skilled in the art without departing from the spirit of the invention. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.