EP0525056A1 - Real time insurance administration and medical information utility - Google Patents

Abstract

Server with health insurance management and medical information in real time comprising a server terminal (18) being in two-way and interactive communication with a central unit (3) and an updatable central database (6). The server terminal (18) includes a card reader used to enter the identification data of the insured, and a device in the form of a keyboard used to consult the central database concerning the acceptability of the insured according to his regime. insurance. and the reimbursement provided by the plan for various treatments offered, as well as a screen used to display the corresponding data in response to the request for information. A service sponsorship organization, for example an employer, is also provided with a terminal (185) being in two-way and interactive communication with the central unit so that the acceptability status of the insured can be modified directly .

Description

REAL TIME INSURANCE ADMINISTRATION AND MEDICAL INFORMATION UTILITY

Reference to Related Application

This is a continuation-in-part of serial number 068,240, filed June 30, 1987, now Patent No. 4,916,611.

Field of the Invention

This invention relates to the field of real time computerized systems for processing insurance claims and specifically providing on-line information for use by health care providers, health care intermediaries and other users of medical information.

Description of the Relevant Prior Art

A type of processing system for medical insurance claims is discussed in U. S. Patent No. 4,491,725, issued to Pritchard on January 1, 1985. This patent is incorporated by reference. The patent discusses a system in which a patient seeking medical treatment presents an identification card at a physician's office. Coded data is electronically read from the card, and transmitted to a central brokerage computer. The brokerage computer ascertains from a data base whether the patient is covered by an insurance policy, and, if so, whether the policy will fully pay for the medical treatment sought by the patient. The brokerage computer informs the physician immediately of the information found.

SUBSTITUTESHEET The Pritchard patent does not address the questions of (1) how the information contained in the data base is derived, (2) how and when data is updated, (3) how clinical data is obtained and kept current, (4) how real time eligibility determination can save money for a health care sponsor, (5) how health care providers can utilize information in the data base to provide emergency treatment to patients, (6) how the health care information utility can reduce health care costs by providing timely information necessary to minimize risk of dollar loss by various health care intermediaries, providers and plan sponsors, or (7) how a closed loop real time system provides a control mechanism necessary to make all financial and medical decisions by virtue of having the data as it occurs in the dynamics of day-to-day life. The question of how and when the data base is updated can significantly affect the cost incurred by an employer in providing a group medical insurance plan for its employees. For example, the data base contains a roster of insured employees which must be updated as employees leave the employing company. However, because of various delays, some rosters are updated only once per month. This monthly updating has the result that an employee leaving the service of a company nevertheless retains the ability, whether intended or not, to obtain treatment under the medical insurance coverage until his name is removed from the roster. If a month is assumed to have thirty days, then, on average, every employee who leaves the employment

SUBSTITUTE SHEET of a company retains insurance coverage for fifteen days afterward, at the employer's expense.

In addition, there is another possible source of expense to employers based on departing employees. The Consolidated Omnibus Budget Reconciliation Act of 1985 (COBRA) (P.L. 99-272) requires that, under certain circumstances, an employer must continue an employee's insurance coverage after terminating employment. Both the occurrence of late roster updating, together with existence of COBRA, create complications when a former employee seeks medical care, because they create uncertainty as to the insurance coverage of the employee. It is very important that the treating physician know whether the employee has insurance benefits in order to minimize the risk of non-payment.

Other players in the health care arena have similar opportunities to minimize risks of various kinds in order to save money. The cost of malpractice insurance could be reduced to a given provider based on information available to a malpractice insurance carrier through the information utility. Information regarding the nature of a physician's practice in terms of high risk procedures and other applicable information would aid malpractice insurance carriers in assessing premium costs. On the other end of the spectrum, on-line real time information could help an attending physician determine an appropriate treatment approach for an unconscious patient. This scenario benefits the patient directly by supplying valuable information to a physician when the patient

BSTITUTESHEET cannot, and serves a secondary purpose of informing the malpractice insurance carrier that this provider uses technology which minimizes his malpractice exposure which deserves reduced rates for insurance. The present invention is a computer system for the administration of medical insurance claims and through the use of real time processing techniques provides an on¬ line information utility of health care related financial and clinical data.

Summary of the Invention

In one form of the invention, a third party administrator maintains a real time data base in an administration computer. The data base includes a comprehensive roster of all persons having insurance benefits under a given insurance plan, as well as the types of benefits available, including the particular medical treatments which are reimbursable by insurance, and the dollar value of the reimbursement for each treatment. The data base may further comprise medical history and clinical data files for each group member. A treating physician or other health care provider has communication equipment which can communicate in real time with the administration computer in order to ascertain whether a given patient is on the roster of covered individuals for a given insurance plan, and whether a proposed treatment is reimbursable, as well as the amount of reimbursement. If the data base indicates that the proposed is in fact covered, the physician can request that the amount of reimbursement be

SUBSTITUTESHEET immediately credited to him, as by a funds transfer to his bank.

Preferably, the health care service provider terminal includes a magnetic card reader, a keyboard, and a display screen. Each member of the benefit group is provided with a magnetic card which has encoded thereon certain information regarding the member. The card may then be "swiped" through the card reader. By accessing the central data base, the health care provider will be able to determine whether the group member is covered by a group insurance plan, the extent of the coverage, as well as other data.

A benefit plan sponsor, such as an employer, who provides the insurance coverage for the benefit of an employee-patient, also has communication equipment which can link to the administration computer, but in a different manner than that of the physician: the employer can modify, in real time, the data base. For example, an employer can add and delete persons to the roster of those insured, as those persons enter and leave his employment. Further, the employer can change the benefits which the plan provides. For example, he may change the reimbursement amount for treatment of a sprained wrist from X dollars to Y dollars. Further, the employer can audit the activity of the insurance plan as reported by the data base. For example, the employer can track, by addressing the data base, the insurance claim activity of each insured individual.

STITUTESHEET In other aspects of the invention, the data base may further comprise a clinical data file for each group member. This file is accessible by the health care provider. Any treatment or services provided by a health care provider may be inputted via the provider terminal to update the clinical data file for the member. The clinical data file, since it is constantly updatable, also provides a dynamic medical history of the patient member which may be accessed by any health care provider who requests the information. Thus, a treating physician may use the clinical data files to supplement the records kept in his/her office.

The system may further provide funds transfer means whereby the health care provider may receive direct payment for services provided. This may take the form of a direct link between the central computer and financial institutions such as banks, credit card institutions, et cetera. After a health care provider has verified coverage for an individual member and provided appropriate treatment, the amount authorized by the plan for that particular treatment may be electronically transferred to the health care provider, or the transfer may be by check. In the event there is a deductible or co-pay, since the system is also linked to outside financial institutions, the health care provider may electronically receive the balance of the payment due the same day the treatment is provided. Thus, the system abolishes the necessity for follow-up billing and collection efforts.

SUBSTITUTESHEET Since it is common in two-earner families for individuals to have overlapping coverage from two or more plans, the group member eligibility files may include a record which can identify and rank the coverages provided by the multiple plans. Thus, the service provider will be able to ascertain what portions of reimbursements for a proposed treatment will be paid by each of the plans for an identified group member. Furthermore, the central processing unit, by using this record, will be able to authorize and transfer the funds from the multiple plans, thus providing automatic coordination of benefits.

The utility may also be used in conjunction with information subcriber terminals. By means of these information subscriber terminals, the user may interrogate the central data base regarding various data stored therein, such as plan eligibility, level of reimbursement, medical history and clinical data of a member, et cetera, as well as statistical data for the plan members. Thus, a group member will be able to verify his/her own eligibility status, and can also find out what the plan reimburses for a particular service, such as, for example, eye glasses. A researcher may wish to know how many members of the plan have been treated, for example, coronary disease. A malpractice carrier may wish to know how many high-risk procedures have been performed by a particular physician seeking malpractice insurance.

Since the system provides interrogation capability, it is possible for a health care provider, such as an emergency room personnel, to quickly interrogate the

TESHEET system via the card reader mode to find out whether a patient seeking emergency treatment is, for example, allergic to a drug, or to ascertain his/her blood type, et cetera. To this end, the central processing unit is programmed to provide a streamlined mode of inquiry whereby, after the member has been identified by operating the card reader, the emergency room personnel may quickly interrogate for the vital information without having to sort through unnecessary data. In short, the utility disclosed herein provides an on-line, interactive, real time system which allows a health care provider to instantly access the eligibility status of a patient member seeking treatment, as well as the levels of reimbursement provided. Furthermore, since the benefit sponsor also may update the eligibility status of the group member on-line, there is no "lag time" between a change in benefit status and its input into the system. The health care provider always knows with certainty the exact eligibility status of each member.

Brief Description of the Drawings

Figure 1 illustrates a simplified overview of the system;

Figure 2 illustrates a block diagram of the major system components; and Figures 3-34 are flow charts describing the operation of the respective blocks of Figure 2.

SUBSTITUTESHEET Detailed Description of the Invention

Figure 1 depicts a simplified overview of one form of the invention. An administration computer 3 maintains a data base 6 for each insurance plan provided by an employer 2. File 7 indicates the data base for plan ABC maintained by employer 2, Alpha Company. The file 7 includes a roster of all insured employees of Alpha Company, their spouses and dependents. In addition, the file includes a list of all medical treatments for which insurance compensation is available. (Each treatment is typically called a procedure, because the physician after diagnosing a problem can approach the treatment in one of several different ways depending on the surrounding circumstances of the particular patient and/or the specifics of a particular diagnosis. An example would be a diagnosis of a sprained wrist in patient Adams, followed by the procedure or treatment considered appropriate under the circumstances.) The file 7 also contains a list of the dollar amounts payable for each procedure. For example, in the file 7, X dollars is associated with the treatment for a sprained wrist, meaning that insurance plan ABC will pay X dollars for the treatment of a sprained wrist. Furthermore, if Adams has multiple coverage from another plan, that information will be contained on a record in his file, as well as the ranking and extent of coverage provided by each plan so the benefits may be coordinated.

In addition to the insurance related information pertaining to Adams, the data base contains a complete set

TITUTESHEET of medical records. If Adams had been under the care of a different physician for an unrelated problem, the patient records would indicate who the treating physician was, the nature of any recent treatment and the type of medication Adams was currently using. Having access to such information allows the physician to make a more informed decision regarding treatment and medication. It also eliminates the time necessary to make inquires of the patient directly and reduces the risk that the patient may have either forgotten or confused the nature of the treatment and/or medication.

When a patient 9 visits a physician for treatment of a sprained wrist, the patient 9 presents an identification card 15 as evidence that the patient is covered by insurance plan ABC. The physician, using data terminal 18, communicates with the administration computer 3 on data link 21, and enters into the computer the identity of the patient (Adams), the name of the patient's plan (ABC in this case) together with the diagnosis (sprained wrist) . A computer 3 locates the data base records 7 corresponding to plan ABC, confirms that the patient is on the roster of insured persons, confirms whether the plan ABC will pay the physician for the given diagnosis (sprained wrist) and gives the amount of reimbursement. If plan XYZ also provides coverage, the amount to be paid by plan XYZ is also displayed. Patient medical records can be viewed on the screen of terminal 18, or a hard copy (hard copy is a term in the art describing output in the form of printed matter) can be printed on the

STITUTESHEET terminal printer 131, and the physician can update the medical records for diagnosis, treatment and medication given and/or prescribed. Finally, the physician submits an electronic claim form which is validated in real time, allowed to be corrected if necessary and permits the physician to choose the method of payment, whether check or electronic funds transfer to his account.

If the amount of reimbursement is less than the normal charge made by the physician, a balance would exist. The physician then gives the patient an option of charging the balance to the patient's credit card 15 or debit card 15. If the patient wishes to do so, the patient provides a suitable credit or debit card 15 number which is entered into the computer 3, to appropriately charge the patient's account 65.

In addition, the computer 3 stores the diagnosis and the amount paid to the physician, together with other relevant data, in the data base records 8 associated with the patient 9. Thus, the data base for plan ABC 7 would be updated in real time at the time of the treatment, and, further, the physician's office itself does the updating, although in an indirect manner as a by-product of the transaction between physician and patient 9. The benefit sponser, employer 2, which provides insurance coverage to patient 9 also has access to the administration computer 3 along data link 24. However, the employer 2 has access to a wider range of data in the file for the ABC plan 7 than does the physician (with the

TESHEET exception of patient clinical records which will be discussed later) . As stated above, the physician only has access to data indicating whether or not a particular diagnosis is covered, the amount of reimbursement, and other similar data. In contrast, the employer 2 has access to all data contained within the data base of the ABC plan 7. Further, the employer 2 can update certain data dealing with the coverage granted to an employee 9. For example, the employer 2 can add, change and delete the names of the insured persons as appropriate. Still further, the employer 2 can change the benefits provided by the ABC plan 7 as needed. For example, the employer 2 can change the types of diagnoses for which reimbursement will be allowed. The employer 2 may decide that elective cosmetic facial surgery, as distinct from restorative facial surgery used to restore damage caused by an accident, should not be a cost borne by plan ABC 7, but should be paid by the patient 9. In such a cas , the employer 2 would change the data base records of plan ABC 7 to so indicate. The employer 2 can also change the dollar amount of reimbursement for a given diagnosis. For example, the employer 2 may change the dollars reimbursed for a sprained wrist from X dollars to Y dollars.

In addition, the employer 2 Alpha can audit the operation of its own plan ABC 7. For example, the roster of insured persons is available, so that information is known as to the eligibility of employees for insurance benefits. Also, as mentioned above, the computer 3 stores the diagnosis and treatment information as they occur.

S_UBSTITUTESHEET This allows the employer 2 to retrieve such information and to evaluate the insurance claim activity of the employees 9. The employer 2 can also make detailed statistical analyses of claim activity and plan expenditures by using the data available.

Figures 3-36 contain flow charts describing in detail the operation of the system in Figure 1 and will be described after introducing the major system components in Figure 2. Figure 2 represents a global view of the major components comprising the preferred embodiment of the invention, however, the invention may be adapted to other applications requiring the dynamics of a real time information management and control system where eligibility must be determined before granting services or disbursement of funds is allowed.

A very brief description of the Real Time Insurance Administration and Medical Information Utility follows and will be expanded in Figures 3-36. The invention has a plan eligibility 30 module which permits an employer 2 to interact with the computer 3 in real time and update the data base 6 as well as obtain information from the data base 6. The add function 33 allows an employer 2 to include new employees 9 and their dependents on the roster of persons eligible to receive medical services under the health care plan. The delete function 36 enables the employer 2 to remove employees 9 and their dependents from the eligibility roster. Since the removal of an employee 9 can be as a result of voluntary or involuntary

SHEET termination, the system ensures that involuntary terminations comply with COBRA through the COBRA compliance module 39. The employer 2 may also inquire as to whether compliance with COBRA requirements 42 has been met and whether plan continuation 45 was elected by the former employee 9.

Since the employer 2 has interest in how the plan is serving the employees 9, the plan utilization 48 module provides a menu (menu is a term in the art relating to a screen with options that may be selected depending on the nature of the work one wishes to perform) of inquires that the employer 2 can request to make the determination. The employee utilization 51 module returns information of plan utilization by individual employee 9. The provider utilization 54 module reports utilization by selected provider. The treatment utilization 57 module gives a break down of plan utilization by treatment and the age utilization 60 module reports plan utilization for any selected age range. Employers 2 may also request various reports and work lists pertaining to persons covered under the health care plan through the reports 63 module.

The plan design 66 module consists of four sub-modules which permit either the employer 2 , in the case of a self insured, or the insurance company to establish and control the plan design. There are sub-modules for deductibles 69, reimbursement amount 72, corrections and adjustments 75 and other plan options 78.

As a result of the quantity and timeliness of the data gathered, the system has substantial value as

SUB_STITUTESHEET an information utility. As a benefit, the information requestor 81 module provides subscribers with access to statistical data 84 and raw data 87 depending on their particular needs. The provider 90 module is made up of sub-modules to determine plan eligibility 93 of patients 9; claim processing 96, which is further broken down into claim validation 99, and claim payment 102; reimbursement inquiry 105, to determine how much the plan will pay for a given procedure; get patient record 108 module, provides patient history and up to the minute clinical data for a patient; update patient record 111, gives the physician a means to enter clinical information pertaining to the current visit. Patient balance payment 112, allows in office settlement of any balance remaining after the reimbursement amount is paid to the physician.

Emergency patient history abstract 114, provides a summarized patient history that would be employed in emergency medical situations. This would be particularly useful in cases where the patient was unconscious or unable to assist emergency medical personnel with information that was useful in effecting immediate treatment.

Financial information inquiry 117, permits an evaluation of expenditures for the health care plan. Funds transfer 123, performs the debiting and crediting of appropriate accounts related to a transaction between patient and provider.

Error handling 126, provides the system house keeping function related to any on-line session which may

T have been interrupted due to communications problems or termination resulting from no response by the session initiator. The error handling 126, consists of save condition codes 129, and restore condition codes 132. Together these functions will permit a session to be resumed at the point of interruption in the vast majority of the cases.

Block 200 in Figure 3 indicates that a card holder (i.e. a patient 9) brings his card 15 (the card 15 in Figure 1) to a provider site. Provider site is a term in the art used to refer to one who provides medical services, namely the physician or hospital. Block 210 indicates that the card 15 is read by an "8610." "8610" is shorthand notation for a Datatrol 8610 computer terminal 18 and associated printer 131 in Figure 1. This equipment is available from Datatrol Corporation, located in Minnetonka, Minnesota. Block 220 indicates that if the card is not readable, then in block 230, an operator at the provider site types in the client's identification number, namely his social security number (SSN) , and a client code, which is a number identifying the ABC plan 7, from which insurance coverage is sought.

Block 240 indicates that the patient's 9 date of birth (DOB) and relationship to the card holder is keyed into the terminal. In this example, the relationship is

"employee", because Adams himself is seeking treatment.

Were his wife to do so, the relationship would be "spouse."

Blocks 230 and 240 provide identification of patient 9 in order to assure that only the actual patient

S_UBSTITUTESHEET 9 whose name is on the plan's roster 7 receives medical treatment, and that no imposters do.

Block 250 refers to statement of a reason for the visit to the physician selected from a table. One type of table includes four reasons, namely, the reasons of illness, prevention, maternity or accident. The reason for the visit can be important for insurance purposes because different insurance coverage may be available for different reasons motivating a visit. For example, plan ABC 7 may provide maternity benefits for Adams' wife, but not his daughter. Further, some reasons, such as accident, can cause legal rights to arise for the benefit of the plan, and so special procedures should be taken. For example, the YES (Y) path leading to block 270 indicates that an accident motivated the visit to the physician's office. Block 270 indicates that the computer terminal 18 prompts the patient 9 to complete a subrogation form which can give certain subrogation rights to the Plan ABC 7. For example, an automobile insurance company may have a liability to the patient 9 or to Plan ABC 7.

Block 280 indicates that the patient 9 states whether he has previously been treated for the present condition. If not, then patient 9 provides the occurrence date for this problem which is entered at block 290. As block 300 indicates, another insurance plan XYZ may be liable to the patient 9 for the condition. For example, a wife may be employed and have insurance benefits making the husband's plan primarily liable, meaning that the patient 9 and the wife's plan are only liable after the husband's

STITUTESHEET plan pays. Block 320 indicates that the identity of the provider (i.e. the physician) is selected from a table of codes.

Up to block 330, no communication with the administration computer 3 has yet been undertaken. However, at block 330, the local terminal 18 in the physician's office communicates data via a local telephone call to the administration (i.e. host) computer 3. Blocks 340 and 350 indicate that until there is a connection between the host computer 3 and the local terminal 18 you may have to try again to establish the link.

Figure 4, blocks 360-420 deal with process by which the host computer 3 identifies valid access to the computer 3 and determines whether the subscriber (providers or other valid users of the host computer 3 are termed subscribers) who initiated the current session was suspended from a previous session due line noise (line noise is a term in the art pertaining to disturbances such as static that can occur on communications lines) , or a "time out" ("time out" is a term in the art pertaining to the automatic function performed by a host computer 3 to terminate a session with a remote access terminal because of no activity on the part of the terminal 18 initiating the session) . These blocks will be discussed in greater detail when we deal with error handling functions.

Once communications have been established with the providers terminal 18 and the host computer 3, the host computer 3 evaluates the transaction code received from the subscriber. In our example, dealing with a provider,

T TESHEET control passes to block 480, which in turn passes control to Figure 8, block 530. Figure 8 evaluates the various functions that providers may request and since this is the case of a patient 9 seeking services, the eligibility of the patient 9 must be determined. Block 550 determines the need for eligibility verification and transfers control to Figure 20, block 640.

Block 640 retrieves records from the real time data base 6 for employees and dependents based on the identification information entered by the provider as a key (key is a term in the art relating to data that is used in combination with other data to uniquely describe an address of data residing in a data base) . Block 650 compares the social security number (SSN) , client code, date of birth (DOB) and relationship to card holder information. At block 660 if SSN and client code do not match, the provider terminal 18 is displayed a message to retry the identification card or to call the help line because there is no plan member with the SSN and client code as entered. If there is match on SSN and client code, then control passes to block 680 to test the match on DOB and relationship to card holder. If there is no match on either or both of these identifiers, a message is displayed at block 690 on the providers terminal 18. If the provider decides not to reenter the needed information, block 700 will direct the system to terminate the session. If, on the other hand, the provider decides to reenter the data, block 710 will allow a maximum of three tries to get the data right by transferring control to Figure 3, block 240.

HEET When there are proper matches on SSN, DOB and relationship to the card holder, it indicates that the patient 9 is not an imposter and control passes to block 720 where eligibility status is retrieved from the real time data base 6. The information obtained in block 720 will leave no doubt in the provider's mind as to the status of the patient 9. If the patient 9 is currently employed by the plan sponsor 2 he will have full plan coverage and this status will be reflected in the information the provider gets. If the card holder's employment has been recently terminated and the card holder has not exercised his option to continue in the health care plan at his own expense, the indeterminate nature of the plan eligibility will be conveyed to the provider (more will be discussed about this important feature later) .

At block 730 the system retrieves the plan coverage information for Plan ABC 7 to ascertain whether the reason for the visit in block 240 of Figure 3 is covered (i.e., reimbursable) by plan ABC. In addition, the plan coverage for the diagnosis (i.e., sprained wrist) is determined at this time.

If the visit is covered, an authorization code will be assigned in block 740 for the transaction (i.e., treatment) . An authorization code is a unique number which identifies the transaction in an unmistakable manner as eligible for treatment. The authorization code functions to facilitate bookkeeping much in the way that a serial number on an invoice for other purchases does so.

STITUTESHEET Block 750 creates an open eligibility record in the administration computer 3. This refers to saving the code in anticipation of data which will later be received from the physician after treatment has been completed. Block 760 indicates that the eligibility record is transmitted to the physician's terminal 18. In most cases, this means that the patient 9 is in fact on the plan's roster, together with an affirmation that the reason for the visit is covered. However, an indeterminate status for a card holder would indicate that no reimbursement can be guaranteed and the physician should get his fee from the patient 9 at the time service is rendered in order to avoid risk of non-payment.

At this time a physician has information indicating that treatment of the diagnosed condition is covered by insurance. Following treatment, the physician, as indicated by block 790 in Figure 3A, enters the authorization code into his local terminal 18 in Figure 1. Blocks 800 and 810 indicate that the local terminal 18 searches and finds the patient's 9 name, Adams, so that the treatment portion of the transaction can be completed and transmitted to the administration computer 3.

Block 840 indicates that the physician enters a code identifying the diagnosis (sprained wrist) . Block 850 indicates that the physician enters up to ten "procedure codes", which refer to the treatment for a sprained wrist selected by the physician. Block 860 of Figure 3A and block 360 of Figure 4 indicate that the diagnosis and procedure codes are transmitted via local telephone call to the administration computer 3. Continuing in Figure 4, control passes to block 480 which determines that this transaction code is for a provider, therefore, control passes to Figure 8 block 530. Successive decisions lead to block 570 which determines that this is a claim processing request. Block 570 transfers control to block 870 of Figure 22. At block 870 the electronic claim is transmitted to the administration computer 3. Block 880 invokes a routine for performing claim validation at block 940 of Figure 31. The dynamic data base 6 for Plan ABC 7 serves as input to the validation process starting at block 940. This ensures that the claim is processed against the most current set of allowable diagnoses and procedures as provided by the card holder's employer 2. Each element of the claim is evaluated and a decision made as to the validity. At block 940 the validity of the diagnosis code is tested and if it is not valid, control passes to block 950 where a flag is set (flag is a term in the art referring to an indicator or Boolean logic which shows that the results of a particular evaluation is true or false) indicating that the diagnosis code is not valid under plan ABC 7. The diagnosis codes are under the employer's 2 control, and will discussed later in more detail. Similarly, each element of the claim is evaluated and flags set or not set depending on the results of the evaluation until block 1040 is reached. At block 1040 it is determined whether the claim as a whole has passed the validation process and if so, the claim is stored in the data base associated with patient Adams 7. If the claim

BSTITUTESHEET failed for any reason, then block 1060 converts each of the flags indicating a problems into corresponding messages which are transmitted to the provider terminal 18 in Figure 1. Block 1070 transfers control back to Figure 22 at block 890. Block 890 determines whether the claim may be processed and if so, transfers control to Figure 32 at block 1080. If, on the other hand, the claim validation process encountered any reason to reject the claim, (e.g., the procedure code to treat Adams' sprained wrist was inadvertently entered as a nonexistent code) then block 900 would determine that the claim was not processed and would pass control to block 910 to display the error messages at the provider terminal 18 in Figure 1. Blocks 920 and 930 perform a testing function to determine whether the provider terminal 18 in Figure 1 is communicating with the administration computer 3 and whether a decision has been made to correct the claim. When the corrections have been made in response to the error messages issued in block 910, and the provider continues the claim processing, control passes back to block 870 to transfer the corrected claim.

Block 1080 of Figure 32 calculates payment amounts for each diagnosis and procedure covered under plan ABC 7 and takes into consideration any specific arrangements made between the employer 2 and the participating physician (e.g., amount for diagnosis of sprained wrist, anesthetics applied, immobilization by a plaster cast, etc.) , as well as the coordination of payment between ABC plan and any other plans under which the

EET patient has coverage. Block 1085 determines any co- payment (co-payments refer to amounts which the patient 9 may be required to pay, e.g., plan ABC 7 may pay fully for treatment of a sprained wrist, but only pay one-half for cosmetic surgery) amounts and deductibles that are applicable under plan ABC 7 and deducts these amounts from the reimbursement total. At all applicable times, the information contained in data base 6 is the most recent by virtue of the on-line update capability to the employer in designing and maintaining plan ABC 7.

Block 1090 determines whether plan ABC 7 will pay directly to Adams, and if so, performs block 1100 to set the card holder flag. Block 1110 determines whether the plan will pay to Adams' physician, and if so, performs block 1120 to set the provider flag. At block 1130 the system determines whether electronic funds transfer (EFT) arrangements have been made with the party to be reimbursed (either Adams or his physician) , and if so, sets the EFT flag in block 1140. Block 1150 determines whether payment will be performed by the EFT subroutine, and if so, transfers control to block 1160 to perform the EFT. Further discussion of systems which accomplish the funds transfer in block 1160 is found in U.S. Patent No. 4,346,442 to Musmanno, which is incorporated by reference. Block 1170 determines whether EFT has not been selected as the mode of payment, and if so, transfers control to block 1180. Block 1180 transfers control to block 1220 at Figure 34. If the provider flag is set, the check will be printed with the physician as payee at block

_UBSTITUTESHEET 1230. If the card holder flag is set, block 1240 will transfer control to block 1250 and a check will be printed with the card holder as the payee. This means that the administration computer 3 prints a bank check drawing upon a bank account which is funded by plan ABC, or by the insurance company itself. The check is then mailed to either the physician or the patient 9, depending on the financial arrangements decided by them. Block 1260 will return control back to Figure 32. Upon returning from block 1180 the system resets the flags in block 1190 and continues with block 1200 by updating the data base 7 records. The update of database 7 records will reflect that Adams had been diagnosed as having a sprained wrist, and the treatment he received included an immobilizing cast. The financial records of Adams' employer 2 will reflect that payment of the allowable claim and that payment was in the form of a check. The check number, the date, the name and address of the payee. The plan records 7 of the employer 2 will be updated to reflect the services rendered to Adams, the amount allowed by the plan, the amounts allowed by any other plans, the amount of co-pay that Adams is responsible for, the amount of deductible that was fulfilled by this transaction, the identification of the physician providing the service, and the date of the transaction. The record of the financial transaction is available to either the employer 2 or the insurance company via data 24 in Figure 1.

Block 1210 prepares and transmits a receipt to the physician's terminal 18 and exits the claim processing

TESHEET routine via block 1215. The patient 9 signs the receipt as acknowledgment that treatment was performed. Since it is possible that the reimbursement amounts are less than the physician's customary charges, or that the patient 9 owes a deductible, or that the administration computer 3 found the patient 9 or the treatments to be non-insured, a patient balance of payment remains. The physician's terminal 18 while still in communication with the administration computer 3 after printing the receipt from the claim processing function described above, has an option under which the patient 9 can charge the balance to a credit card 15 or have the funds transferred from his checking account 65.

Upon returning from the claim processing function, the administration computer 3 will be waiting for further instructions from the physician terminal 18 as shown in Figure 8 blocks 530 and 540. A request to process the patient balance will lead to block 565 which transfers control to Figure 33, block 1263. If the patient 9 chose to use a credit card 15, the card would be swiped through the physician's terminal 18, and block 1266 would perform the transaction requirements. If instead, the patient 9 decided to transfer the funds from his account 65, block 1269 will transfer control to the EFT routine in block 1272 to make the appropriate transfer of funds. Upon returning from either the credit card routine in block 1266 or the EFT routine in block 1272, block 1275 will check the status of the transaction to make sure that it was successfully completed. If the transaction was successful, then block

UBSTITUTE SHEET 1278 will transmit a receipt for the EFT transaction or a credit card slip for the credit card transaction to the physician's terminal 18 for printing on printer 131. If the transaction was denied for insufficient funds or because of an over limit status, block 1281 will transmit the reason for denial. Block 1290 will transfer control back to the provider functions in Figure 8 at which point the physician may select other functions, or terminate the session. In addition to the above mentioned discussion of eligibility determination and reimbursement, one of the truly valuable features provided by the administration computer 3 comes from the physician's ability to keep a comprehensive clinical record 8 for each patient 9. This goes beyond the traditional and financial based tracking of various diagnoses and treatments of most "backward looking" (historically, computer systems have been designed to keep track of events or transactions that were relatively remote in time to the actual event and are termed backward looking systems) systems. By contrast, the administration computer 3 with its real time data base 6 captures events as they occur. The value of this capability is immeasurable when two independent events occur relatively closely together in time, but separated by some distance. Imagine Adams after leaving the physician's office is involved in a serious automobile accident while on his way home. Adams is seriously injured and remains unconscious. Adams' visit to the physician's office had led to a determination that he suffers from a rare blood

ITUTESHEET disorder necessitating an unusual procedure when being administered a blood transfusion. Adams' physician had updated Adams' clinical records in due course before he left his office. Adams' injury has resulted in substantial loss of blood requiring a transfusion. Fortunately for Adams, he lives in a community whose physicians and hospitals all subscribe to the services provided by the administration computer 3. An inquiry of Adams' clinical records made minutes after arriving to the emergency room of the local hospital provides the necessary information needed to save Adams' life. The emergency room personnel will use the patient's card 15 to access the administration computer 3 as previously described starting at Figure 3 block 200. Information on the card 15 is both in magnetically readable form and embossed on the card 15 in the event the magnetic stripe is not readable. Additionally, DOB and relationship information is on the card permitting the emergency room personnel to enter the information without the patient being conscious.

The emergency room personnel make a connection at block 340 of Figure 8, and control passes to Figure 4 block 360. After the administration computer 3 makes the validation of the log on as a valid subscriber in block 370, and determines that this was not an interruption of a previous session in block 420, control passes to block 430 which determines that this is an emergency room inquiry. Control passes to Figure 4A, block 1530. At block 1530, the patient history and clinical records 8 are retrieved in

SUBSTITUTESHEET the form of an emergency patient abstract (the emergency patient abstract will be discussed in detail later) and transmitted to the emergency room terminal 18 from block 1540. The records can be optionally printed as indicated in block 1550 and a return will be issued at block 1560 bringing control back to Figure 4 at block 440. All of the blocks starting with block 440 will take the "no" branch until reaching 500. At block 500 the "yes" branch will cause the transaction processed flag to be reset at block 510 and transfer control to block 380 to await further instructions.

Adams' condition would not have been discovered without the information that had been supplied by his physician from his earlier visit. The value of real time clinical data is immeasurable in cases such as these.

The on-line real time data base 6 makes possible today what futurists dreamed of only a short time ago. The effect of this invention is to make point-of-contact data management a reality in today's medical office context. This in turn makes it possible to optimize the practice of medicine. Optimizing the practice of medicine includes the use of the captured data by a triage-type person in interviewing patients to reconcile their wants and needs. Additional information on triage and point-of- contact data management can be found in an article published by Jeffrey G. Kaplan, M.D. in the February 1989 issue of Medical Interface entitled "An Argument for a Point-of-Contact Data Management System," which is hereby incorporated by reference.

UBSTITUTESHEET The physician in the above mentioned visit by Adams did not terminate his session after processing the patient's claim. Instead, he continued in Figure 8 by selecting an update to the patient's records in block 560. Block 560 transfers control to Figure 21, block 1300. At block 1300 the patient's 9 clinical record 8 is retrieved using SSN, client code, DOB and relationship to employee as a retrieval key. Once retrieved, the record is transmitted to the physician's terminal 18 for review of the record and for updating. The physician performs the update of the clinical record with pertinent information which may include results from lab work, medication prescribed, injections given and the evaluation of the patient's condition and recommendations for follow-up treatment etc. The physician may optionally print the record update for the office file as indicated in block 1325. After the update is entered and optionally printed, the record is transmitted via data link 21 to the administration computer 3, and the update is stored in the data base 8 at block 1330. Block 1340 causes a return to Figure 8 and the physician can terminate the session by requesting a "quit" command.

With the combined power of the administration computer 3 and the on-line data base 6, physicians have the option of reducing the volume of records they keep in their office. The electronic medical and clinical records maintained by the administrative computer 3 can provide an alternative to cabinets full of patient records in the physician's office. This not only reduces or eliminates

SUBSTITUTESHEET the need for maintaining office records, but also provides the additional assurance that records will always be available, because of the built in safety features and disaster recovery procedures maintained on the administrative computer 3.

Continuing with the example of patient 9 Adams, it often happens that a second opinion may be necessary before treatment will be authorized. If Adams came in for this purpose, and the physician is one he never or seldom visits, the scenario would be as follows. The physician would follow the procedure as previously mentioned starting in Figure 3, block 200 in order to ascertain the patient's eligibility. However, the physician would first want to review the patient's history and present clinical information 8. This can be accomplished by instructing the administration computer 3 to get patient records 8 in Figure 8. This request would be processed via block 590 of Figure 8 which transfers control to Figure 24, block 1350. Block 1350 would display a set of menu options to retrieve patient history, clinical records or exit from this request. Block 1360 accepts the selected options and proceeds to block 1370 to determine whether to exit this process, or to continue with record retrieval. Assuming record retrieval has been selected, block 1390 will get the patient records 8. Block 1400 displays the patient records 8 at the physician's terminal 18 and allows the physician to print all or selected^'portions of the record on the terminal printer 131. At block 1420 a decision to continue will redirect the process to block 1350, or if no

UBSTITUTESHEET one makes the decision, the time out function of block 1430 will end the processing via the error handling features of Figure 9. The normal path of continuing the process at block 1420 will permit the physician to exit the record retrieval by selecting a "quit" from the menu at block 1350 and subsequent return to Figure 8 via block 1380.

After Adams is examined, the physician can tell Adams how much co-payment the proposed treatment will result in, by performing a reimbursement inquiry. Block 580 of Figure 8 will transfer control to Figure 23, Block 1440. At block 1440, plan ABC diagnosis and treatment records 7 will be retrieved to validate the codes corresponding to the diagnosis and the proposed treatment for Adams' condition. If there are errors in the codes submitted, the "No" branch will be taken to block 1460 to display errors and request corrections. Blocks 1470 and 1480 will evaluate the responses or lack of responses to the error messages and branch accordingly. If the codes submitted are valid, control passes to block 1490 where the patient's plan records 7 are retrieved in order to make the final computations for the diagnosis and treatment proposed by the physician. At block 1500, the actual computations are made and the results transmitted to the physician's terminal 18 as shown in block 1510. Block 1520 passes control back to Figure 8.

The physician can compare his customary charge with the reimbursable amount transmitted by the inquiry and give this information to the patient 9. In addition, any

SUBSTITUTESHEET co-payment amount that the patient 9 would be expected to pay under the plan would also be available.

The possibilities for improved effectiveness of the medical community through use of such techniques as expert sytems, personal diagnostic tests, patient referrals to various specialists and other information oriented uses of computer technology starts with a systematic and organized capture and retrieval of data. H.R. Berry explores these and other uses of comprehensive data base 6 in his article, "Managed Care's 4th Generation" in the July/August, 1989 issue of Gray's Practice Journal which is hereby incorporated by reference.

The foregoing discussion focused on the way provider-patient transactions have "closed loop" relationships that only a real time system can effectively control. Other "closed loop" relationships requiring real time update capabilities are between employer-sponsor, service provider and employee-patient. Table I outlines a sequence of steps taken by, and in connection with the administrative computer 3.

Table I 1. Delete Adams 9, spouse, and dependents from roster 7 of insured persons. 2. Notify Adams 9 and perhaps others of the termination of insurance coverage. Notify them that they have the option within X days to continue certain insurance benefits at stated premium rates. Send these notices 40 by certified mail.

B_STITUTESHEET 3. If notified persons respond within predetermined time, indicating desire to purchase insurance, print and send a package of payment coupons 50 for making periodic payments. 4. If participants make no response within the predetermined time, record this fact in the data base for plan ABC 7.

5. (Optional) If, as in paragraph 4, no response has been received, print and transmit to the former participants a second, backup notice 40.

Line 1 in Table I indicates that the Adams family 9 is deleted from the roster of insured persons under plan ABC, perhaps because of termination of employment. This is done directly by the employer 2 on data link 24. One significant consequence of this deletion from the roster is that, should a physician make inquiry using the physician's data link 21, the administration computer 3 has information immediately, allowing the computer 3 to inform the physician that the Adams family 9 is no longer covered by plan ABC. However, in some cases, discussed later, the computer 3 may refrain from stating that the family is not covered by the plan, and instead indicate that the family presently has an indeterminate status as to coverage.

Upon deletion of the Adams participants 9 from the plan, and if the employer 2 so requests, either at the time of deletion, or at a prior time, the administration computer 3 activates a printer 170 which prints a notice 40 which is transmitted to one or more members of the family 9, notifying them of the fact of termination, and offering

SUB_STITUTESHEET them the option to purchase within a stated period of time the same or similar insurance which they previously had, at stated premium rates. The letter 40 is transmitted to the Adams family 9, and the administration computer 3 then sets into motion a programming routine, known in the art, to track the response of the Adams' family 9, when it occurs. If one or more of the family members 9 respond favorably, in writing, an operator enters the proper data into the administration computer 3. In response; the computer 3, using printer 170, prints a group of payment coupons 50, which are mailed to the electing participants 9. The participants 9 return the coupons with payment, on a periodic basis, and the coupons assist the administration computer 3 in tracking the payment history of the electing participants 9. The coupons bear sufficient information to do this, and can be machine readable by the administration computer 3, as known in the art.

If no response is received in the stated time, the computer 3, having an internal clock, as known in the art, notifies the data base 6 for plan ABC 7, and a program is performed to change the status of the Adams family 9 from indeterminate to terminated, as will be discussed.

As was stated earlier, it may be the case that an option was given to the Adams family 9 to elect to purchase insurance within a stated time period. This option can be given in fulfillment of a collective bargaining agreement, state or federal statutes, or for other reasons. Further, the option may have certain retroactive aspects. For example, the employer may be required to give the former

SHEET employee the right to exercise the option for a stated period of time, such as sixty days. If the option is retroactive, the following sequence of events can occur. Termination of employment can occur on July 1. The notice 40 can be sent the same day, July 1. The notice 40 can be received by the employee 9 on July 2 and the notice 40 can give him sixty days within which to decide whether to purchase insurance. The employee 9 may visit a physician on July 15, but before he exercised the option. If he exercises the option on July 20, and pays the insurance premium as required, The ABC plan may be required to pay for the July 15 visit to the physician. Therefore, the administration computer 3, in searching plan ABC of data base 6 in response to the physician's inquiry on July 15, classifies the Adams family 9 as indeterminate until the option is exercise, or the option expires.

Continuing the example, if the option expires on September 1, without being exercised, and if Adams 9 visits a physician on September 10, the administration computer 3, in response to the physician's inquiry states that Adams 9 is terminated from the ABC plan 7, and not under indeterminate status. Further, the classification was made by the computer 3 immediately upon expiration of the option, which was a stated period, (sixty days in this case) after mailing of the notice 40.

Several important aspects of the invention are the following:

1. As Figure 1 indicates, an employer 2 can add and delete beneficiaries 9, as well as change provisions of

S_UBSTITUTESHEET a plan (e.g., plan ABC), by using data link 24. Further, as the discussion above indicates, these changes can be done in real time, causing the currency of the data base 6 to be limited only by the diligence of the employer 2. The fact that the data base 6 is current has two significant results: first, the average lag period of fifteen days, discussed above, is eliminated. Therefore, a former employee 9 cannot exploit the existence of the lag and obtain treatment, because treating physicians will be able to know immediately when an employee is deleted from the roster of insured persons.

A second result relates to COBRA requirements. The occurrence of updates to the roster can trigger the notification procedure described above into action. For example, a detection routine known in the art, detects a deletion of a person from the roster and, in response, immediately causes a notification to be sent, as outlined in Table I. The immediate notification prevents COBRA mandated insurance from arising at the employer's 2 expense.

These two results are similar in the respect that they both limit the liability, borne by an employer, which arises through the running of time. Viewed another way, the same event which eliminates the fifteen day lag in insurance termination (i.e., the event of real time deletion from the roster) also triggers into action the notification procedure of Table I.

2. The computation of the patient's bill, discussed in connection with block 1085 of Figure 32

TESHEET includes a computation of any deductible amount owed by the patient, as well as the allocation of payment between overlapping plans, if Adams has multiple coverage. This is possible because the administration computer 3 retains records of all insurance activity by the Patient Adams 9, and records of the existence of and extent of coverage by one or more additional plans. For example, if Adam 9 has a one hundred dollar deductible amount per year, and if Adam 9 has received no other treatment in the year, and if the charge for the present treatment is eighty dollars, the entire eighty Dollars is paid by Adams 9. Similarly, if Adams has coverage from XYZ plan through his wife's employment, plans XYZ may pay part or all of the charge, including the deductible or co-pay. These facts are indicated on the bill printed by terminal 18 in Figure 1.

3. The preceding discussion has been made in context of a patient visiting a physician. However, it should be understood that the invention can be used by any provider of health care services, including physicians, dentists, hospitals, pharmacists, podiatrists, chiropodists, and psychologists. In this respect, a programming routine can be added which examines whether the given provider is authorized to perform the treatment for which payment is sought. For example, a podiatrist may not be authorized by state law to perform some types of surgery. The limits on the treatments which a provider can perform are stored in the administrative computer 3, and are retrieved at the time the identity of the provider is

S_UB_STITUTESHEET verified in Block 360 of Figure 4. This routine prevents payments to unauthorized providers.

4. The card 15 in Figure 1, which is carried by the patient, is the only card used by him, irrespective of the type of health care sought. That is, the patient presents the same card to his dentist, his pharmacist, his psychologist, etc.

5. A telephone connection between the physician's terminal 18 and the administration computer 3, and also between the administration computer 3 and the employer 2, has been discussed. The preferred telephone connection uses a communications network, known in the art, such as Tymnet, available from McDonnel Douglas Corporation. The network allows a physician in one city to communicate with the administration computer 3 located in a different city, by making a local, non-toll, telephone call.

6. If the patient has recently terminated employment, and then seeks medical treatment, the administration computer, as outlined in Table I, records the patient's insurance status as indeterminate and informs the physician accordingly. In such a case, the physician must decide the manner in which to collect payment, as plan ABC makes no commitment at this time. 7. The invention has been described in terms of health benefits claims. However, it is applicable to any generic plan under which a third party pays money on behalf of a beneficiary. One example is a food stamp program, in which a beneficiary presents food stamps (i.e., the "card"

TESHEET 15 in Figure l) to a supermarket (the "provider") which can verify, using terminal 18, whether the stamps are valid, and whether the beneficiary is entitled to use them. In this case, the roster is a roster of food stamp beneficiaries.

In another example, a governmental workman's compensation program is treated as analogous to plan ABC, and provides payment.

8. In addition to the verification procedures described above for verifying the identity of the patient, other procedures can be used. Voiceprint, fingerprint, and signature verification can be used, as know in the art.

9. Plan ABC has been described as an insurance plan. However, it need not be such. Plan ABC can be a self-insurance plan of the employer, or any entity which provides benefits to beneficiaries for specified types of health care.

The Employer 2 plays an integral part in maintaining the dynamics and therefore the utility of this invention. In essence, the Employer closes the information loop between patient 9 and provider by maintaining data that determines (1) a patient's 9 eligibility in the employer's plan 7 and (2) the patient's entitlements based on the plan design. The following introduction to the flow charts associated with these two vital functions details the actual process.

Figure 35 describes the process of accessing the administration computer 3 via data link 24. Block 1570 has the employer 2 selecting a log on procedure menu. At block

SUBSTITUTESHEET 1580, the employer enters a password (password is a term in the art relating to a combination of letters and numbers used as a security device in order to limit access to the system to only authorized personnel) to gain access to specific system functions authorized for the given password. In block 1590 the employer 2 selects specific functions from a menu of available and authorized functions. Block 1600 dials the administration computer 3. If a connection is made, block 1610 passes control to block 360 of Figure 4. If there is no connection, then block 1620 allows the employer to retry the process, or to terminate and try later.

Figure 4, as discussed previously, determines where to branch based upon who the subscriber is and the transaction code supplied from the function menu. Assuming for illustration purposes that employer 2 Alpha, planned to do eligibility maintenance. The various decision points would lead to block 450, where the plan eligibility transaction code would be recognized and taking the "yes" branch, control would pass to Figure 5, block 1630.

Figure 5 processes the valid requests submitted by employer 2 Alpha, and passes control to the sub-modules to perform the specific function. Blocks 1630 and 1640 perform a monitoring function for terminal activity as discussed previously. A request by employer 2 Alpha passes control to block 1650 which evaluates whether the request was to add an employee to the roster of eligible employees under plan ABC 7. Assuming employer 2 Alpha was adding new

ITUTESHEET employees to the roster, the "yes" branch will transfer control to Figure 10, block 1750.

Block 1750 will pass control to block 1770 so that employer 2 Alpha can enter the various demographic and personal information related to the new employee. Block 1780 permits entry of information for each of the employee's dependents. Block 1790 decides whether any corrections have been requested, and if so, transfers control back to block 1770. If no corrections are necessary, then the "no" branch leads to block 1800 to update the data base 6 with new employee information for the ABC plan roster 7 and creates clean patient records 8 (the clean patient record assumes that the new employee was never covered by a plan subject to the administration computer 3, otherwise, the patient records could be transferred from the previous plan) for each person covered under plan ABC 7. Block 1810 checks whether a "quit" command has been issued leading to block 1820 and a return to Figure 5, block 1660, or if not, a branch to back 1750 to add more new employees.

Upon returning to Block 1660 of Figure 5, the administration computer 3 will take the "no" branch of the successive decision blocks until it reaches block 1720 where the "yes" branch will lead to block 1730 and a reset on the flag dealing with the processing of the commands. Control will then pass back to block 1630 where additional requests will begin the request evaluation process again.

Assuming that employer 2 Alpha next requests a delete function, the decision mechanism will evaluate and

SUBSTITUTESHEET transfer control to Figure 11, block 1830 via the "yes" branch of block 1660. At block 1830 and 1840 the familiar "command ready" and "time out" feature begins the process. Since the command request had been issued in the previous module, control passes to block 1850 to determine whether the termination is involuntary. Assuming an involuntary termination, the "yes" branch of the block 1850 will pass control to Figure 25, block 1900. The consequences of an involuntary termination will differ from one employer to another and from time to time depending on the contractual obligations of the employer, and as the government mandated programs change. As a minimum, the present invention is responsive to the federal government's mandated COBRA requirements discussed earlier. Block 1900 sets the employee's health care status to indeterminate pending notification and either acceptance or rejection of the option to purchase health care coverage from the employer. At block 1910, the response time clock for this employee is set to count down the acceptance period that the employee has to respond with his decision and still legally bind the employer to provide health care benefits. Block 1920 prints a notice to the terminated employee and to any additional persons covered by his plan who have the power of exercising the option. For example, if the employee has a spouse and/or other dependents covered by the plan, they may the right to elect the health care option independent of the decision made by the terminated employee.

ITUTESHEET Block 1930 updates the data base 6 and more specifically the ABC plan employee roster 7 with the indeterminate status of the terminated employee and dependents. The clock function having been armed, will commence running to count down the option period. All of this information will reside on the data base 6 as soon as the employer enters the delete command for the terminated employee. As previously mentioned, any attempts to obtain health care services by the terminated employee will alert the provider that reimbursement status is indeterminate and the provider must make financial arrangements accordingly. Block 1940 returns the process back to Figure 11, block 1860.

Decision blocks 1860 and 1880 will both take the "no" branch, returning control to block 1830. If a voluntary termination needs to be processed, the decision blocks will lead to a "yes" branch at block 1860 and block 1870 will be performed. A voluntary termination by the employee will not normally require the employer to maintain health care coverage on him and his dependents. In that case, termination will permit immediate revocation of health care benefits. This means that the employer will not incur any additional expense related to health care costs and the provider will not be at risk either, because the dynamic data base 6 will alert him that no coverage exists for the voluntarily terminated employee.

Block 1880 will determine whether to quit the deletion process and return via block 1890, or to continue

SUBSTITUTESHEET at block 1830. Assuming a quit has been issued, control passes back to Figure 5, block 1670.

Staying with the functions of this of Figure 5, control will pass back to block 1630 where the employer next issues a plan utilization inquiry. The decision blocks will pass control to block 1670 where the "yes" branch will pass control to Figure 12, block 1950. Figure 12 basically evaluates the options that are available in the plan utilization module and branches to the requested function.

The plan utilization module offers a very useful tool for employers by allowing them to review as often as necessary how the plan is currently being used. This information can help spot deficiencies in the current plan, possible abuses of the existing plan, and serve as a basis for designing future plans. The selected options are illustrative of the types of inquires that can be made and are in no way meant to limit the utility of the invention. Assuming a request for plan utilization by employee, control passes to Figure 26, block 2060. At block 2060, employer 2 Alpha will input the name and SSN for the employee of interest. Block 2070 will retrieve the employee's record which contains the raw data of each transaction that was processed on the employee's behalf. This would include not only the employee's transactions, but all transactions for dependents of the employee. Block 2080 will take the raw data and summarize it in a meaningful fashion to get total costs incurred for each

SUBSTITUTESHEET dependant, and a chronological breakdown of plan benefits for the corresponding dependant.

The report may be printed at the employer's local printer 180 as indicated in block 2100, or optionally displayed at employer's terminal 185 according to block 2120. Upon completion of the plan utilization inquiry by employee, a quit command issued by the employer 2, will result in control returning to Figure 12, block 1980.

The operation of the inquiry function by provider, treatment, and age is similar to the operation for inquiry by employer described above and illustrated in Figure 26. The flow charts for these three inquiry functions are found respectively, in Figures 27-29.

Returning from Figure 12 to Figure 5, block 1680, the decision blocks will pass control back to block 1630 for another request. Assuming the employer 2 selects an inquiry of COBRA compliance, control will pass to Figure 13 block 2500 from block 1680. Block 2520 requests the name and SSN of the former employee. Block 2530 performs record retrieval and passes control to block 2533 to determine whether the record exists. If the record does not exist, block 2536 sets the flag indicating that either the employee did not have an option to continue the plan, or that the option was not exercised within the option period and the employee was removed from the roster. Block 2540 ascertains whether the former employee is still in the option period. If not, the administration computer 3 displays the fact that no COBRA requirements attach to this employee, or that requirements have been fulfilled, and

SU_BSTITUTESHEET control passes back to block 2500 for additional inquiry by employer 2. If employee is within the option period, then control passes to block 2560 and it is determined whether notices have been sent to all persons affected by the employees' termination. If no notices have been sent, the notices flag will be set to "no" at block 2570 and control passes to block 2580. Block 2580 determines whether any responses have been received from the terminated employee and if the answer is "yes," control passes to Figure 30, block 2640.

Block 2640 permits employer 2 to indicate whether the response from employee was to continue the plan or not to elect the option. If the response was not to elect the option, the employee's record will be removed from the plan roster 7 and a report entry of this decision will be written to and audit trail report (an audit trail report is used in the art to show the occurrence of a significant event such as the removal of a record from the data base 6) . Block 2660 will return control back to Figure 13 at block 2590. If employee response was to elect the plan continuation option, block 2670 will retrieve the former employee's record from plan ABC roster. At block 2680 a payment schedule will be computed. Block 2690 will update the plan roster 7 to reflect the election of the option. Block 2700 will print a payment book that will be sent to the former employee, and block 2710 will return control back to Figure 13 at block 2590.

Block 2590 will determine whether follow-up notices have been sent, and if not, the follow-up flag will

SUBSTITUTESHEET be set to "no". Block 2610 will display the current status of the former employee based on the foregoing evaluation. The display will include information on notices, follow-up notices, responses received and the status of the option decision. Block 2620 determines whether employer has decided to quit the inquiry, and if so, returns control to Figure 5, block 1690. If not, control passes back to block 2500 for additional input by employer.

Returning from Figure 13, control will pass back to block 1630 of Figure 5. Assuming employer 2 next selects the reporting functions, the decision blocks will transfer control to block 1690, which in turn passes control to Figure 14, block 2720. Reports and work lists are convenient ways for the employer to get information in a media that is conducive for doing some preliminary work. Figure 14 explains how fairly standard work lists or reports may be generated. The process is supplemented by ad hoc reporting capabilities in those instances where the employer may need information that addresses some non-recurring problem.

Assuming that the employer has requested to audit the health care plan, block 1695 of Figure 5 will transfer control to Figure 35, block 2880. A plan audit can take on an infinite number of permutations and combinations of factors depending on the results of preliminary inquiries. To facilitate this type of approach, this module contains no predefined inquiries, but instead, allows dynamic selection of audit criteria. Block 2900 displays a menu of available parameters which can be used in "what if" fashion

SUBSTITUTESHEET to perform an audit of the plan. Block 2910 will sweep the plan data base 7 (sweeping the data base is a term in the art referring to the process of examining every record in the data base 6, rather than specific records) to select the records that fall within the selected parameters. Block 2920 will compute the results and format a report for display at block 2930, or for optional printing at block 2940. If employer decides to quit, block 2950 will transfer control to block 2960 which in turn will pass control back to Figure 5, block 1700. If employer does not quit, then control passes to block 2880 and additional auditing may continue.

The plan audit function is an important feature in recognition of the fact that a dynamic environment requires vigilance, as there is no lag time in transaction processing. The frequency will be a decision made by individual employers; however, it useful to know that the capability is available on request.

Upon returning to Figure 5 from Figure 36, control will pass to block 1630. Issuing a request to quit at that point will cause block 1700 to transfer control to

1710 which passes control back to Figure 4, block 460.

Decision blocks 460 through 490 will take the "no" branch, but 500 will branch "yes" since the previous transaction request had been processed. Block 510 will reset the transaction processed flag and pass control to block 380 which monitors receipt of additional transaction requests.

Assuming that employer 2 in our case is self insured and would like to perform tasks related to the

S_UB_STITUTESHEET design of the health care plan, the appropriate transaction code will pass control to block 460. Block 460 then passes control to Figure 6, block 2970. Figure 6 determines the nature of the request which falls into four categories. Employer 2 Alpha can change either the deductible amount, the amount reimbursable for a given diagnosis or treatment, make corrections or adjustments for amounts paid and a catch all category of other plan options.

Blocks 2970 and 2980 evaluate the presence of a new request and when received, control passes to block 2990. Block 2990 determines if the request was to change deductible amount. Assuming that it was, block 3000 would permit employer 2 Alpha to enter the new deductible amount which would then replace the previous deductible amount in the ABC plan records 7. In addition, and audit record will be written to memorialize this event. Control would pass to block 2970.

If the request was to change the reimbursable amount on the various diagnoses and treatments, control would pass to block 3010 where the "yes" branch would invoke Figure 15, block 3090. Blocks 3090 and 3100 need no explanation as control will pass to 3110 with the new request. Block 3110 requests employer 2 Alpha to enter the treatment code for which the reimbursement amount is about to change. At 3120 the record corresponding to the selected code is retrieved. Block 3120 displays the record and the current reimbursement amount. At 3130 the new reimbursement amount is entered and a request to verify is issued at block 3140. block 3150 determines whether the

SU_BSTITUTESHEET record has been verified as being correct. If not, the "no" branch is taken and control passes back to block 3130 in order that a corrected amount may be entered. If the record is verified as being correct, block 3160 updates the record in plan ABC and writes an audit record to memorialize the change. At 3170 a quit command will return control to Figure 6, block 3020. If no quit is issued, control passes to block 2970 for additional update requests. Upon returning to Figure 6, decision blocks 3020 through 3040 will take "no" paths. Block 3060 will Branch "yes" because the previous request was processed, passing control to block 3070 to reset the request code flag. Control then passes back to block 2970 to accept new requests.

If corrections or adjustments to payment records are required, a request for this function will pass control to block 3020. Block 3020 will take the "yes" branch, passing control to Figure 16, block 3190. Since this is a new request, control passes to block 3210 where the name and SSN of the plan member whose records need to be corrected or adjusted are entered. At block 3220, the plan member's records are retrieved. Block 3230 permits entry of an adjusting or correcting transaction to remedy a delayed transaction or discovered problem (problems may have arisen from such things as an erroneously processed treatment code, or a delayed transaction needed to adjust the amount of payment because of reimbursement from the responsible party as a result of subrogation to the claimant's rights) .

T TESHEET Verification occurs at block 3240 and block 3250 directs control to pass back to 3230 upon failure to verify, or 3260 if verification is successful. Block 3260 updates the transaction record to the plan member's records of plan ABC 7. Block 3270 determines whether to continue and pass control to block 3190, or to return to Figure 6.

When employer 2 Alpha completes the corrections and adjustments function, control passes to Figure 6, block 3030, and ultimately to block 2970. If employer next requests to change other plan options, control passes to block 3030 which passes control to Figure 17, block 3290. Since the previous functions adequately illustrated the scheme for making changes to the plan design and performing routine maintenance of the plan, Figure 17 is not described in great detail.

The preferred embodiment of this invention has distinct advantages over the prior art from the standpoint of the extent of the data residing in its database 6, and data's currency due to the real time updating that occurs with each transaction. This makes the data itself a resource with commercial value. This aspect of the invention has been developed to provide information to fee paying subscribers with a need for medical data for varying purposes. Government agencies and private organizations often experience the need for data related to identification and control of disease. Traditional methods of gathering this data is both time consuming and expensive. Early detection of disease and medical

SUBSTITUTE SHEET disorders in large part contributes to providing a cure or isolating a source of problems before it becomes widespread. Since the present invention provides timely data, it is to the advantage of various agencies to subscribe to a service which provides access to this data at an affordable price. The combination of timeliness and affordability of the data means that these agencies will be able to devote more of their funds to providing cures.

Also, individual group members may wish to access their own files to learn, for example, how long it has been since their last check-up. Pay-as-you-go terminals could be provided in such places as public libraries.

The information subscriber will be able to access the administration computer 3 with a standard personal computer. The access procedures reviewed for employers at Figure 35 are essentially the same for the information subscriber. Once logged on. Figure 4 will provide the control mechanism as described before to invoke information retrieval capabilities of Figure 7, block 3390. Figure 7 has been already described as a means of selecting one of N number of choices. Information subscribers have but three choices in Figure 7. They can either choose to retrieve statistical data or raw data, or they can quit and exit the administration computer 3. If the subscriber chooses statistical data, control will pass to Figure 18, block 3480 via block 3410 of Figure 7.

Figure 18 block 3480 displays a menu of statistical options. This is essentially a list of particular types of computations that a subscriber wishes

TITUTESHEET to perform (e.g., mean, median, standard deviation, frequency distribution, regression analysis, etc.). Block 3490 retrieves the options selected by subscriber and determines whether the option to quit was selected in block 3500. If the option was to quit, the "yes" branch of block 3500 will lead to block 3510 which returns to Figure 7, block 3420.

If option was not to quit, control passes to block 3520 where a second menu displays the parameters that determine which data qualifies for inclusion in the population to be measured (this could be as simple as specifying an age range, or as complicated as selecting all males under the age 12 whose father has a history of high blood pressure and whose mother is a diabetic who smokes) . Block 3530 retrieves the parameters and passes control to block 3540 to determine whether the quit option was selected. Assuming that quit was not selected, block 3560 reads the data base 6 and selects data from the records meeting the population requirements. Block 3570 will perform the computations selected in the first menu and pass the results to block 3580 where they are displayed. An optional hard copy of the results will be printed by block 3585. Blocks 3590 and 3600 perform the familiar routine to determine whether to continue. Upon returning to Figure 7, block 3420, the computer will cycle through the remaining blocks until it branches back to block 3390 to await a new request. Assuming the subscriber would prefer to retrieve raw data and perform the analysis on her own computer, the host

SUBSTITUTESHEET computer 3 will branch at block 3420 to Figure 19, block 3610.

Block 3610 displays various options for selecting data and choosing the output media best suited for the information subscriber's 11 purposes. At block 3620 the computer 3 gets the options. Block 3630 determines whether "quit" was selected. If "quit" was selected, block 3640 would return control to Figure 7 at block 3430. If "quit" was not selected, block 3650 will sweep the data base 6 selecting all data fitting the requested options in block 3610. Block 3660 will determine if the output request was to print, and if so, output the data to a printer. If request was not for a hard copy, Block 3680 determines whether the output request was for magnetic tape. If magnetic tape was the requested media, block 3690 outputs to magnetic tape. If the media request was for Diskette, block 3700 will determine this fact, and output the data to diskette at block 3710. If output was requested as display, block 3720 will determine this fact and output the data to the requesting terminal. Blocks 3740 and 3750 need no explanation.

When the information subscriber 11 completes acquisition of data, a request to quit will return her to Figure 7. An additional request to quit in Figure 7 passes control to Figure 4 and ultimately terminates the session. Interruption of a session with the host computer 3 can occur for one of several reasons. Two of the reasons that can be detected and handled in a planned manner result from no activity at the terminal initiating the session.

TESHEET The first occurs when someone is distracted from what they are doing and actually leave the terminal unattended for a period of time. The second occurs when problems on the communications lines causes a disruption to the communications carrier signal. In either case the computer 3 will detect these conditions and branch to Figure 9, block 3760. Various condition codes at the point of interruption will gathered at block 3760 and saved in a temporary file at block 3770. At block 3780, any temporary files that where created in support of the requestor will be saved also. Block 3790 will then terminate the session for the requestor.

When the person using the terminal realizes that she is no longer in communication with the computer, she will go through the log on process again. This time, in Figure 4, block 420 the "yes" branch will be taken and control will pass to Figure 9, block 3800. The various condition codes will be reset to the pre-interruption state at block 3800. All suspended temporary files will be opened at block 3810, and control will pass to the point of interruption in the program via block 3820. This approach ensures that work performed by the host computer 3 in support of a request will not be lost unnecessarily. The resumed session will give the same results as if no interruption of service had occurred.

As mentioned previously, the administration computer 3 in Figure 1 receives data concerning not only (a) a diagnosis made by a physician, or health care provider, but also (b) the treatment given. The physician

SUBSTITUTE SHEET has complete access to the patient's clinical records as described in Figure 21, to update the information as required. This data is used to create an Emergency Abstract for the patient, or to update an existing abstract. The abstract is a medical history in the form of a computer file which contains a summary of diagnosis and treatments, including medications prescribed, received by the patient up to the present date, and which is generated automatically by the administration computer 3, without intervention of either the patient or the physician.

The initial medical history record is generated by obtaining information from the patient either directly, by a questionnaire, or indirectly, by requesting that the patient arrange to have his physician transmit the necessary information.

In the case of a newborn infant, a medical history record is created at the time that transactions described in the flowcharts earlier are undertaken on behalf of a parent. The infant's medical history and clinical record is updated automatically, throughout his life, as health care transactions are executed with the administration computer.

In the case of the infant, an identifying number, such as a social security number, is not immediately available, and the abstract will be given a record identifier associated with the card holder, who will probably be a parent. When the identifying number (eg, social security number) becomes available, a separate file for the infant's abstract is created.

UBSTITUTESHEET In the case where a medical history is incomplete, as when a patient provides no initial history, that fact is noted in the medical history record.

The medical history and clinical records provide a medical history to a treating physician when they are requested as indicated by block 1530 in Figure 4A. It is noted that records are not provided unless a proper patient identifying number has been given in blocks 210 or 230, in order to protect confidentiality. The medical history and clinical records can be particularly useful in emergency treatment of patients, especially if the patient is unable to provide information on his own, as when he is unconscious. This was illustrated earlier. Further, in connection with emergency treatment, selected information contained in the abstract can be copied by the administration computer into a second, Emergency Abstract. The Emergency Abstract is available to the health care provider and contains a selected amount of data, which is that believed to be the most relevant to a physician who has only a limited time to read a medical history under emergency conditions.

There is a general consensus in the medical profession as to the nature of this data, and one suggested list of the data is shown in the questionnaire of Figures 37-39. The Emergency Abstract is updated from data contained in the patient's 9 medical history and clinical records.

Further information concerning which types of data in the medical history and clinical records should be

SUBSTITUTESHEET selected and copied into the Emergency Abstract is available from the Council of Medical Specialty Societies, P.O. Box 70, Lake Forest, Illinois 60045, and from Medic Alert Foundation International, P.O. Box 1009, Turlock, California 95380, from both of which is available a book entitled Proceedings - Conference on Coordinating Emergency Medical Information Systems February 9-10, 1987. which is hereby incorporated by reference.

Two important features of the medical history and clinical records are the following. One, the data is updated at the time when the physician informs the administration computer 3 in Figure 21. The information contains the identities of diagnoses and treatments given, and these are entered into the medical history and clinical records. It is noted that the modification of the records is within the control of the physician to the extent that he adds to the clinical records data base any pertinent information that is not derived from the mere entry of diagnosis and treatment codes as necessary to be properly reimbursed for services. He may not alter existing information contained in the records through process of updating. Of course if the physician withholds information properly belonging in the patient's clinical records, this affects the integrity of the records. The Emergency Abstract is but a summary of the medical history and clinical data which is derived under program control and independently of the physician.

Two, the Emergency Abstract need not exist as a separate file in the computer, and probably should not in

TITUTESHEET order to save storage space. Instead, a streamlined routine which searches the medical history and clinical records and extracts selected information can be used at the time a request is made by a health care provider. Further, the routine can be interactive, in the sense that it need not search for a predetermined list of data, but can respond to a specific request made by an emergency room physician, as indicated in Figure 4A. For example, the physician may ask only one question, such as, "when did the patient last receive a tetanus shot?" The computer, in searching a file of the type shown in Figures 37 and 38 would supply the answer. In point of fact, the physician would not actually ask the question, but would request the data on a designated line in the file illustrated Figure 37, such as line 20.

The foregoing discussion described the preferred embodiment of this invention, a Real Time Insurance Administration and Medical Utility system. Ideally this invention would serve the total health care needs of a community by providing the necessary information for each person in the health care equation to make an informed decision based on timely information. The invention solves the recurring problem of timing, inaccessible and incomplete or missing data by capturing vital data at the source. Additionally, the data becomes immediately available to others by way of the real time data base.

The value of the real time data base is realized when numerous decisions have to be made by various persons who are geographically disbursed. For the health care

_UBSTITUTESHEET recipient, it means knowing exactly how much it will cost for a visit to a health care provider. To the health care provider, it means knowing how much she will be reimbursed when rendering services, and actually receiving the payment at the point the transaction occurs in many cases. To the health care plan sponsor, it means paying only for the services for which eligible employees are entitled. It also means that plan sponsors will be in compliance with provisions of collective bargaining agreements and state and federal laws which place certain restrictions and burdens on plan sponsors. To health care intermediaries, it means providing financial services that makes payment for health care services manageable to the average service recipient. To the information subscriber, it means access to vital statistics as well as raw data for evaluation and decision making, both medical and financial.

Numerous substitutions and modifications can be undertaken without departing from the true spirit and scope of the invention as defined in the claims. What is desired to be covered by Letters Patent is the invention as defined in the following claims.

EET

Claims

Claims 1. A real time health care insurance administration and medical information utility comprising:

A) a central processing unit maintained by a health care plan administrator;

B) an updatable central data base in communication with said central processing unit and including:

1) group member identification data files;

2) group member benefit eligibility status data files; and

3) group member medical history data files;

C) a service provider terminal in two-way, on-line communication with said central processing unit and including: 1) means for inputting group member identification data of a member seeking medical treatment from a service provider and for inputting treatment data indicating treatment provided said member by said service provider; 2) means for interrogating said central data base regarding plan eligibility of the group member, reimbursement provided by the plan for various proposed services for the group member, and the group member medical history; and 3) means for displaying data responsive to said means for interrogating and said means for inputting;

D) a benefit sponsor terminal in two-way, on-line communication with said central processing unit including:

SUBSTITUTE SHEET 1) means for inputting group member benefit eligibility status data; and

2) means for displaying data responsive to said updating means; and E) program means resident in said central processing unit and responsive to said interrogating means, said service provider inputting means, said benefit sponsor inputting means, and to said data base for:

1) generating benefit eligibility status data of the member;

2) generating calculated benefit amounts corresponding to the proposed services;

3) generating calculated benefit amounts corresponding to the provided treatment; and 4) creating a medical history data file for the group member.

2. The utility of claim 1 further comprising funds transfer means in communication with said central processing unit for transferring the calculated benefit amounts to the service provider.

3. The utility of claim 1 further comprising means for printing responsive data in communication with said service provider terminal.

4. The utility of claim 1 wherein the program means further comprises an audit system whereby the benefit

SHEET sponsor may access statistical data concerning the benefit plan.

5. The utility of claim 1 wherein the data base further includes plan definition files, and the benefit sponsor may establish and update the plan definition files.

6. The utility of claim 1 wherein the service provider terminal includes a card reader, and the group members are provided with magnetic cards which include sufficient group member identification data to allow the service provider to access the utility.

7. The utility of claim 1 further including a subscriber terminal in communication with said central processing unit and including: means for interrogating the central data base regarding various data stored therein; and means for displaying data responsive to said interrogation means.

8. The utility of claim 1 wherein the service provider terminal further comprises a medical emergency inquiry function.

9. The utility of claim 1 wherein the updatable central data base further includes group member clinical data files, the service provider terminal further includes means for interrogating the central data base regarding the

SUBSTITUTESHEET group member clinical data file and means for inputting data to update the group member clinical data file, and the program means further includes means for updating the clinical data files with the inputted treatment data and the inputted clinical update data.

10. The utility of claim 1 wherein the group member benefit eligibility status data file includes a record containing information regarding coverage provided the member under a second plan and the central processing unit is programmed to coordinate benefits for the member between the health care plan and the second plan.

UBSTITUTE SHEET