WO2000066367A1

WO2000066367A1 - A method, system and network for coordinating the communication of data for a health-related transaction

Info

Publication number: WO2000066367A1
Application number: PCT/US2000/012331
Authority: WO
Inventors: Robert E. Dorf
Original assignee: Dorf Robert E
Priority date: 1999-05-04
Filing date: 2000-05-04
Publication date: 2000-11-09
Also published as: AU4822900A

Abstract

A method, system and network for coordinating the communication of data in a health network, and between the health network and a banking network, for a health-related transaction. In accordance with the present invention, a processor (100) 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. The present invention makes all data and activity for the health-related transaction available to parties to that transaction, in real-time. The present invention also provides for line-by-line reconciliation between and among the insurance provider, a health care provider (60), an insured (90), and a financial services provider. The present invention further provides for secure transmission of clinical or other sensitive patient (insured) (90) data between health care providers (60) and other participants of the health network.

Description

A METHOD, SYSTEM AND NETWORK FOR COORDINATING THE COMMUNICATION OF DATA FOR A HEALTH-RELATED TRANSACTION

CROSS-REFERENCE TO RELATED APPLICATION This application claims priority to Provisional Patent Application Serial Number

60/132,499 filed on May 4, 1999.

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 Network™ (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 deliver)' 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. 2 A and 2B are schematic block diagrams of exemplar}' 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 Network™), 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-

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.

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

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 locator 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 1 10, 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 1 10 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 1 10 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 1 10 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 1 10 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 1 10 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 1 10 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 1 10 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

1 10 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 1 10 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 1 10 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 1 10 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 1 10 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 1 10 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 1 10 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

1 10 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 1 10 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 1 10 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 1 10. 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 1 10 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 1 10.

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 1 10 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 1 10. That

data may be, by way of non-limiting example, database records requested from the host subsystem 1 10 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 1 10. Of course, any record tagged as immediate is forwarded to the site server 200 or, accordingly, to the host

subsystem 1 10, 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, exemplar}' 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 1 ("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 "I ". 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 000500 IB 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., 0005001 A, 000500 IB, 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.

Claims

CLAIMSWhat is claimed is:

1. A method of coordinating the communication of data in a health

network, and between the health network and a banking network, for a health-related transaction between and among an insurance provider, an insured, and a health care

provider, said method comprising the steps of:

(a) providing a processor for receiving data from and transmitting data to each of the insurance provider, the insured, and the health care provider;

(b) receiving identification data from the insured and the health

care provider;

(c) determining if the insured and health care provider

identification data identify an eligible insured and an eligible health care provider;

(d) transmitting a transaction authorization number to the health care provider if the identification data identify an eligible insured and an eligible

health care provider;

(e) transmitting a transaction denial number to the health care

provider if the identification data do not identify an eligible insured or an eligible

health care provider;

(f) establishing an electronic link between the health care provider,

the insured, and the transaction authorization number or transaction denial number;

and

(g) maintaining an electronic record of all activity for the health-

related transaction by electronically linking each activity to the transaction authorization number transmitted in said step (d) or the transaction denial number

transmitted in said step (e).

2. A method as recited by claim 1 , wherein the health care provider is a

primary care provider.

3. A method as recited by claim 1 , wherein the health care provider is a referred health care provider.

4. A method as recited by claim 3, wherein the referred health care

provider may be a doctor, laboratory, hospital, clinic, or pharmacy.

5. A method as recited by claim 1, wherein the data for the health-related

transaction is further coordinated and communicated between and among a health care

provider's bank and an insured's bank, and wherein the health care provider has a

computing device for communicating with the processor, said method further

comprising the steps of: receiving a payment request from the insured for payment to the health

care provider; transmitting a payment authorization number or a payment denial

number to the health care provider computing device; and updating the record of activity for the health-related transaction to

include the payment authorization or denial number.

6. A method as recited by claim 5, further comprising the steps of: formatting the payment request;

transmitting the formatted payment request to the insured's bank via the

banking network; receiving a payment authorization or payment denial from the insured's

bank; and updating the record of activity for the health-related transaction to include the transmission of the formatted payment request and receipt of the payment authorization or payment denial.

7. A method as recited by claim 6, further comprising the steps of: receiving notification from the insured's bank via the banking network

that the payment request has been satisfied; and

updating the record of activity for the health-related transaction to include the notification that the payment request has been satisfied.

8. A method as recited by claim 1, wherein the data for the health-related

provider's bank and an insurance provider's bank, and wherein the health care provider has a computing device for communicating with the processor, said method further

comprising the steps of: receiving a claim payment request from the health care provider via the

health care provider computing device for payment by the insurance provider; transmitting a claim payment authorization number or a claim payment denial number to the health care provider computing device; and

updating the record of activity for the health-related transaction to include the claim payment authorization or denial number.

9. A method as recited by claim 8, further comprising the steps of:

formatting the claim payment request; transmitting the formatted claim payment request to the insurance

provider's bank via the banking network; receiving a claim payment authorization or payment denial from the

insurance provider's bank; and

updating the record of activity for the health-related transaction to

include the transmission of the formatted claim payment request and receipt of the claim payment authorization or payment denial.

10. A method as recited by claim 9, further comprising the steps of:

receiving notification from the insurance provider's bank via the banking network that the claim payment request has been satisfied; and

updating the record of activity for the health-related transaction to

include the notification that the claim payment request has been satisfied.

11. A method as recited by claim 2, further comprising the steps of: receiving referred health care provider identification data from the

primary care provider; determining if the referred identification data identifies an eligible referred health care provider;

transmitting a referral authorization number to the primary care provider if the identification data identifies an eligible referred health care provider;

transmitting a referral denial number to the primary care provider if the identification data does not identify an eligible referred health care provider; and updating the record of activity for the health-related transaction to

include the referred health care provider identification data and the referral authorization or referral denial number.

12. A method as recited by claim 1 1, further comprising the steps of: receiving identification data from the insured and the referred health

care provider; receiving the referral authorization number from the referred health

care provider; determining if the insured and referred health care provider identification data identify an eligible insured and an eligible referred health care

provider; transmitting a referral authorization number to the referred health care provider if the insured and referred health care provider identification data identify an

eligible insured and an eligible referred health care provider; transmitting a referral denial number to the referred health care

provider if the insured and referred health care provider identification data do not

identify an eligible insured and an eligible referred health care provider; and updating the record of activity for the health-related transaction to include the referral authorization or referral denial number.

13. A method as recited by claim 12, wherein the data for the health- related transaction is further coordinated and communicated between and among a

referred health care provider's bank and an insured's bank, and wherein the referred health care provider has a computing device for communicating with the processor,

said method further comprising the steps of: receiving a payment request from the insured for payment to the

referred health care provider; transmitting a payment authorization number or a payment denial

number to the referred health care provider computing device; and updating the record of activity for the health-related transaction to

include the payment authorization or denial number.

14. A method as recited by claim 13, further comprising the steps of:

formatting the payment request; transmitting the formatted payment request to the insured's bank via the

bank; and updating the record of activity for the health-related transaction to

include the transmission of the formatted payment request and receipt of the payment authorization or payment denial.

15. A method as recited by claim 14, further comprising the steps of:

receiving notification from the insured's bank via the banking network that the payment request has been satisfied; and

16. A method as recited by claim 12, wherein the data for the health- related transaction is further coordinated and communicated between and among a

referred health care provider's bank and an insurance provider's bank, and wherein the

referred health care provider has a computing device for communicating with the processor, said method further comprising the steps of:

receiving a claim payment request from the referred health care provider via the referred health care provider computing device for payment by the

insurance provider;

transmitting a claim payment authorization number or a claim payment denial number to the referred health care provider computing device; and

17. A method as recited by claim 16, further comprising the steps of:

formatting the claim payment request;

transmitting the formatted claim payment request to the insurance provider's bank via the banking network; receiving a claim payment authorization or payment denial from the

insurance provider's bank; and updating the record of activity for the health-related transaction to include the transmission of the formatted claim payment request and receipt of the claim payment authorization or payment denial.

18. A method as recited by claim 17, further comprising the steps of:

receiving notification from the insurance provider's bank via the

banking network that the claim payment request has been satisfied; and

updating the record of activity for the health-related transaction to include the notification that the claim payment request has been satisfied.

19. A method as recited by claim 1, wherein said step (b) further comprises receiving, in real-time, insured eligibility data and insurance plan rules from the

insurance provider.

20. A method as recited by claim 1 , wherein said step (b) further comprises

receiving insured eligibility data and insurance plan rules from the insurance provider.

21. A method as recited by claim 1, wherein the data for the health-related

transaction is further coordinated and communicated between and among an

employer, and wherein said step (b) further comprises: receiving, in real-time, insured eligibility data from the employer; and transmitting, in real-time, the received insured eligibility data to the insurance provider.

22. A method as recited by claim 1, wherein the data for the health-related transaction is further coordinated and communicated between and among an

employer, and wherein said step (b) further comprises: receiving insured eligibility data from the employer; and

transmitting the received insured eligibility data to the insurance

provider.

23. A method as recited by claim 1, wherein said step (a) further comprises

providing a processor for receiving insured identification data from the insured, health care provider identification data from the health care provider, and insured eligibility and health care provider eligibility data from the insurance provider.

24. A method as recited by claim 1, wherein said step (g) further comprises

the steps of: creating an electronic record for the health-related transaction including

the authorization or denial number, insured identification data, health care provider

identification data, and insurance provider identification data; and

storing the record in the processor.

25. A method as recited by claim 11 , further comprising the steps of: transmitting a request for information to the referred health care

provider; and updating the record of activity for the health-related transaction to

include reference to the request for information transmission.

26. A method as recited by claim 25, further comprising the steps of: receiving encoded medical data for an insured from the primary care

provider; and forwarding the received encoded medical data to the referred health

care provider.

27. A method as recited by claim 25, wherein the request for information is

a request by the primary care provider that the referred health care provider provide a

particular health service to the insured.

28. A method as recited by claim 26, further comprising the steps of:

receiving encoded medical data for the insured from the referred health

care provider; and forwarding the received encoded medical data to the primary care

provider.

29. A method as recited by claim 1 , further comprising the steps of: creating a health care provider activity report for a health care provider;

and communicating the provider activity report to the health care provider.

30. A method as recited by claim 1. further comprising the steps of: creating a health care provider activity report for a health care provider;

providing access to the health care provider activity report for the

health care provider.

31. A method as recited by claim 1 , further comprising the steps of: creating an insured activity report for an insured; and

communicating the insured activity report to the insured.

32. A method as recited by claim 1 , further comprising the steps of: creating an insured activity report for an insured; providing access to the insured activity report for the insured.

33. A method as recited by claim 31 , further comprising creating an insured activity report including health and financial activity for an insured.

34. A method as recited by claim 32, further comprising creating an

insured activity report including health and financial activity for an insured.

35. A method as recited by claim 1 , wherein the record maintained in said

step (g) is a file containing data of all activity for the health-related transaction.

36. A method as recited by claim 1, wherein the record maintained in said step (g) is a file containing a plurality of pointers to a plurality of databases, each database containing part of the data of all activity for the health-related transaction.

37. A method of providing a health care network having a plurality of members each having an identification card, said method comprising the steps of:

(a) providing a processor in the health care network for

communication with a banking network;

(b) receiving by the processor data regarding a transaction from a member' s use of that member's identification card;

(c) determining if the transaction is intended for the health network or the banking network; and

(d) routing the data regarding the transaction to the health network

or the banking network depending upon the determination made in said step (c).

38. A method as recited by claim 37, wherein said step (a) comprises

providing a processor comprised of a network of computers having general purpose software and special purpose software installed thereon.

39. A method as recited by claim 37, further comprising the step of

maintaining an electronic record of every transaction for which data is received by the

processor.

40. A method as recited by claim 39, wherein said step (c) comprises determining if the transaction is a health transaction, a financial transaction, or a

combination of a health transaction and a financial transaction.

41. A method as recited by claim 40, wherein the transaction is a financial transaction, said method further comprises the steps of:

formatting the data received by the processor regarding the transaction;

and transmitting the formatted data to the banking network.

42. A method of coordinating the communication of data in a health network, and between the health network and a banking network, for a health-related

transaction between and among an insurance provider, an insured, a primary care provider, an employer, an insurance provider's bank, an insured's bank, and a primary

care provider's bank, the insurance provider having an insurance provider site server

connected to a processor in the health network, the insured and the primary care

provider each having an identification card and being separately identifiable using the identification card and a computing device selectively connectable to the processor,

said method comprising the steps of: (a) receiving insured identification data from the insured's

identification card and via the computing device;

(b) receiving primary care provider identification data from the

primary care provider's identification card and via the computing device; (c) determining if the insured identification data identifies an eligible insured;

(d) determining if the primary care provider identification data identifies an eligible primary care provider;

(e) determining if the insured and primary care provider together

are eligible;

(f) transmitting a transaction authorization number to the computing device if the insured is eligible, the primary care provider is eligible, and

the insured and primary care provider together are eligible;

(g) transmitting a transaction denial number to the computing device if the insured, primary care provider, or insured and primary care provider

together are not eligible; and

(h) maintaining an electronic record of all activity for the health-

related transaction by electronically linking each activity to the transaction

authorization number transmitted in said step (f) or the transaction denial number

transmitted in said step (g).

43. A method as recited by claim 42, further comprising the steps of: receiving a payment request from the insured for payment to the

primary care provider; transmitting a payment authorization number or a payment denial

number to the computing device; and updating the record of activity for the health-related transaction to

include the payment authorization or denial number.

44. A method as recited by claim 43, further comprising the steps of: formatting the payment request;

transmitting the formatted payment request to the insured's bank via the

banking network; receiving a payment authorization of a payment denial from the

insured's bank; and updating the record of activity for the health-related transaction to

45. A method as recited by claim 44, further comprising the steps of: receiving notification from the insured's bank via the banking network

that the payment request has been satisfied; and

updating the record of activity for the health-related transaction to

include the notification that the payment request has been satisfied.

46. A method as recited by claim 43, further comprising the steps of:

receiving a claim payment request from the primary care provider via

the computing device for payment by the insurance provider; transmitting a claim payment authorization number or a claim payment

denial number to the computing device; and updating the record of activity for the health-related transaction to include the claim payment authorization or denial number.

47. A method as recited by claim 46, further comprising the steps of: formatting the claim payment request;

transmitting the formatted payment request to the insurance provider's

bank via the banking network; receiving a payment authorization of a payment denial from the

insurance provider's bank; and updating the record of activity for the health-related transaction to

48. A method as recited by claim 47, further comprising the steps of:

receiving notification from the insurance provider's bank via the

banking network that the payment request has been satisfied; and updating the record of activity for the health-related transaction to

include the notification that the payment request has been satisfied.

49. A method as recited by claim 43, further comprising the steps of:

receiving referred health care provider identification data from the

primary care provider; determining if the referred identification data identifies an eligible

referred health care provider; transmitting a referral authorization number to the primary care

provider if the identification data identifies an eligible referred health care provider; transmitting a referral denial number to the primary care provider if the identification data does not identify an eligible referred health care provider; and

updating the record of activity for the health-related transaction to

include the referred health care provider identification data and the referral

authorization or referral denial number.

50. A method as recited by claim 49, further comprising the steps of: receiving identification data from the insured and the referred health

care provider; determining if the insured and referred health care provider

identification data identify an eligible insured and an eligible referred health care

provider; transmitting a referral authorization number to the referred health care

provider if the insured and referred health care provider identification data identify an eligible insured and an eligible referred health care provider; transmitting a referral denial number to the referred health care

identify an eligible insured and an eligible referred health care provider; and updating the record of activity for the health-related transaction to

include the referral authorization or referral denial number.

51. A method as recited by claim 50, further comprising the steps of: receiving a payment request from the insured for payment to the referred health care provider;

transmitting a payment authorization number or a payment denial number to the computing device; and

updating the record of activity for the health-related transaction to

include the payment authorization or denial number.

52. A method as recited by claim 51 , further comprising the steps of: formatting the payment request;

transmitting the formatted payment request to the insured's bank via the

bank; and updating the record of activity for the health-related transaction to

include the transmission of the formatted payment request and receipt of the payment

authorization or payment denial.

53. A method as recited by claim 52, further comprising the steps of:

54. A method as recited by claim 42, wherein the data for the health- related transaction is further coordinated and communicated between and among a

referred health care provider's bank, said method further comprising the steps of: receiving a claim payment request from the referral health care

provider via the computing device for payment by the insurance provider; transmitting a claim payment authorization number or a claim payment

denial number to the computing device; and updating the record of activity for the health-related transaction to

include the claim payment authorization or denial number.

55. A method as recited by claim 54, further comprising the steps of:

include the transmission of the formatted claim payment request and receipt of the

claim payment authorization or payment denial.

56. A method as recited by claim 55, further comprising the steps of: receiving notification from the insurance provider's bank via the

banking network that the claim payment request has been satisfied; and updating the record of activity for the health-related transaction to

include the notification that the claim payment request has been satisfied.

57. A method as recited by claim 42, wherein said step (b) further

comprises receiving, in real-time, insured eligibility data and insurance plan rules from the insurance provider.

58. A method as recited by claim 42, wherein said step (b) further

comprises receiving insured eligibility data and insurance plan rules from the insurance provider.

59. A method as recited by claim 42, wherein the data for the health-

related transaction is further coordinated and communicated between and among and

employer, and wherein said step (b) further comprises: receiving, in real-time, insured eligibility data from the employer; and

transmitting the received insured eligibility data to the insurance

provider.

60. A method as recited by claim 42, wherein the data for the health-

related transaction is further coordinated and communicated between and among and employer, and wherein said step (b) further comprises:

receiving insured eligibility data from the employer; and

transmitting the received insured eligibility data to the insurance

provider.

61. A method as recited by claim 42, wherein said step (a) further

comprises providing a processor for receiving insured identification data from the insured, primary care provider identification data from the primary care provider, and

insured eligibility and primary care provider eligibility data from the insurance

provider.

62. A method as recited by claim 42, wherein said step (g) further

comprises the steps of: creating an electronic record for the health-related transaction including

the authorization or denial number, insured identification data, primary care provider

identification data, and insurance provider identification data; and storing the record in the processor.

63. A method as recited by claim 49, further comprising the steps of: transmitting a request for information to the referred health care

provider; and updating the record of activity for the health-related transaction to include reference to the request for information transmission.

64. A method as recited by claim 63, further comprising the steps of: receiving encoded medical data for an insured from the primary care

provider; and forwarding the received encoded medical data to the referred health care provider.

65. A method as recited by claim 63, further comprising the steps of: receiving encoded medical data for the insured from the referred health care provider; and

forwarding the received encoded medical data to the primary care

provider.

66. A method as recited by claim 42. further comprising the steps of: creating a provider activity report for the primary care provider; and

communicating the provider activity report to the primary care

provider.

67. A method as recited by claim 42, further comprising the steps of:

creating a provider activity report for the primary care provider; and

providing access to the provider activity report for the primary care

provider.

68. A method as recited by claim 42, further comprising the steps of: creating an insured activity report for the insured; and

communicating the insured activity report to the insured.

69. A method as recited by claim 42, further comprising the steps of: creating an insured activity report for the insured; and

providing access to the insured activity report for the insured.

70. A method as recited by claim 49, further comprising the steps of: creating a provider activity report for the referred health care provider;

and communicating the provider activity report to the referred health care

provider.

71. A method as recited by claim 49, further comprising the steps of:

creating a provider activity report for the referred health care provider;

and providing access to the provider activity report for the referred health

care provider.

72. A method as recited by claim 42, wherein the record maintained in said

73. A method as recited by claim 42, wherein the record maintained in said

step (g) is a file containing a plurality of pointers to a plurality of databases, each database containing part of the data of all activity for the health-related transaction.

74. A system for coordinating the communication of data in a health

network, and between the health network and a banking network, for a health-related transaction between and among any of an insurance provider, an insured, an employer having a terminal, a primary care provider, an insurance provider's bank, an insured's bank, and a primary care provider's bank, each of the insured and the primary care

provider having an identification card and being separately identifiable using their respective identification card, said system comprising:

a processor;

an insurance provider site server connected to and configured for bi¬

directional data transfer with said processor, said site server periodically transferring health insurance rules and eligibility data to said processor, said server being

connectable to the employer terminal and configured for receiving insured eligibility

data therefrom; and a computing device selectively connectable to said processor and configured for bi-directional data transfer with said processor, said computing device

periodically transmitting primary care provider identification data and insured

identification data to said processor; said processor receiving identification data for the primary care

provider and the insured from said computing device and determining eligibility of the

primary care provider and the insured based on the eligibility data communicated by

said site server to said processor; said processor transmitting a transaction authorization number or a

transaction denial number to said computing device based upon said determined eligibility of the primary care provider and the insured; said processor electronically linking the insured, the primary care

provider, and the transaction authorization number or transaction denial number; said processor maintaining an electronic record of all activity for the health-related transaction by electronically linking each activity to the transaction authorization number or the transaction denial number.

75. A system as recited by claim 74, wherein said processor comprises a

network of computers each having general purpose software and special purpose software installed thereon.

76. A system as recited by claim 74, further comprising:

a data storage device connected to said processor; and

wherein said processor further comprises:

a host subsystem for controlling said processor, for processing the health-related transaction, and for managing a database resident on said data

storage device; a communication subsystem for coordinating communication

between said processor and any of said site server, said computing device, and the

banking network; an eligibility subsystem for receiving insurance provider rules

and eligibility data from said site server and for determining eligibility of the insured

and the primary care provider based upon the received insurance rules and eligibility

data, said determined eligibility being transmitted to said computing device via said

communication subsystem; a financial subsystem for receiving financial data relating to the health-related transaction from said host subsystem and for transmitting and receiving financial data to and from the banking network;

a replication subsystem for periodically bi-directionally transferring data between said processor and said site server; and

an administration subsystem for providing an administrative user interface to said processor.

77. A system as recited by claim 76, said processor comprises a network of

computers each having general purpose software and special purpose software

installed thereon, and wherein each of said subsystems is located on a different computer.

78. A system as recited by claim 74, wherein said site server further

comprises: a host subsystem for controlling said site server; a communication subsystem for coordinating communication between

said site server and said processor;

an eligibility subsystem for defining insurance provider rules and

eligibility data, the insurance provider rules and eligibility data being transmitted to said processor via said communication subsystem;

a financial subsystem for receiving data relating to the health-related

transaction from said processor; a replication subsystem for periodically bi-directionally transferring data between said site server and said processor; and

an administration subsystem for providing an administrative user interface to said site server.

79. A system as recited by claim 74, wherein said computing device comprises a magnetic card reader configured for sequentially reading a first

identification card and a second identification card.

80. A system as recited by claim 74, wherein said computing device

comprises a magnetic card reader connected to a computer having special purpose software installed thereon for enabling said magnetic card reader to sequentially read a

first identification card and a second identification card.

81. A system as recited by claim 74, wherein said processor is connected to

a first network and selectively connectable to a second network.

82. A system as recited by claim 81, wherein said first network is a routed

network and wherein said second network is a switched network.

83. A system as recited by claim 82, wherein said site server is connected

to processor via said routed network and wherein said computing device is selectively

connectable to said processor via said switched network.

84. A system as recited by claim 74, wherein said processor comprises a virtual private network comprised of a plurality of computers connected and configured as a secure network and communicating between and among each other

using special puφose software installed and operating on each of the plurality of computers.

85. A health network for coordinating the communication of data in said

health network, and between said health network and a banking network, for a health- related transaction between and among an insurance provider, an employer, an

insured, a primary care provider, an insurance provider's bank, and an insured's bank,

said health network comprising: a processor configured for communication with the insurance provider,

the insured, the employer, and the insurance provider's bank and the insured's bank via the banking network; and

a computing device configured for reading an identification card and

selectively connectable to said processor and configured for bi-directional

communication therewith; said processor receiving data from and transmitting data to any of the

insurance provider, the insured, the employer, the insurance provider's bank, and the

insured's bank, said received and translated data relating to a health-related transaction for an insured, said processor coordinating the communication of data within said

health network and electronically linking all activity relating to the health-related transaction in an electronic record.

86. A method of organizing data for a health plan provided by an insurance provider and under which health services are rendered by a health care provider, said

method comprising the steps of:

providing a processor for creating a separate electronic record for each health-related transaction under the health plan, the separate electronic records each

including a reference to each activity for their respective health-related transaction,

each activity for a health-related transaction being electronically linked to a transaction reference number; and

providing a report to the insurance provider of activity for each health- related transaction under the health plan.

87. A method as recited by claim 86, further comprising the step of

providing a report to the health care provider of activity for each health-related

transaction under the health plan.

88. A method of providing for viewing of data for a health-related

transaction simultaneously to an insured, an insurance provider, and a health care

provider, said method comprising the steps of: providing a processor for coordinating the communication of data in

the health network, and between the health network and a banking network, for the health-related transaction, the processor electronically linking the insured, the

insurance provider, and the health care provider for the health-related transaction, the

processor maintaining an electronic record of all activity for the health-related transaction that electronically links each activity to a transaction reference number; and

providing access to the electronic record to each of the insured, the insurance provide, and the health care provider.

89. A method as recited by claim 88, wherein the health care provider is a primary care provider.

90. A method as recited by claim 88, wherein the health care provider is a primary care provider and a referred health care provider.