System and Method for Detecting Fraudulent Medical Claims via Examination of Service Codes

The present invention relates to expert systems as applied to the field of medical claims analysis and decision-making mechanisms for analyzing and applying payments to such medical claims.

To date, attempts to modify fee-for-service payment of physicians have focused only on price. Evidence is accumulating that, while many errors are inadvertent, some physicians are increasing their reimbursement by targeting the other component of the equation: codes describing the procedures performed.

Declines in impatient care and physician visits over the last five years have been more than offset by the increase in prices of all providers. The net result has been an actual increase in the rate of real growth in health care expenditures in the past decade because of lower general inflation. Cost containment efforts, having so far concentrated on reducing unnecessary use, now are beginning to address price. Additionally the focus has been on hospitals more than physicians. Yet the cost of physician services, the second largest component of health care costs, was 20.1 percent of total costs in 1986, up from 18.9 percent in 1980. Physician costs climbed 11 percent in 1986, compared with 7.7 percent for all medical costs and 1.5 percent for the general economy.

In an effort to retain patients amid increased health care competition, physicians are negotiating agreements with managed care programs such as health maintenance organizations (HMOs) and preferred provider organizations (PPOs). Physicians give price concessions to these organizations through a negotiated fee schedule or a discount from historic charges. In addition, they agree to strong utilization controls to reduce unnecessary use. As a consequence, unless total patient volume increases, physicians have two primary options for maintaining their income. One is to increase dramatically their charges to fee-for-service patients whose benefit plans often pay the price that is customary in the physician community. The other is to up their charges to managed care programs by the indirect method of upcoding.

Incentives like these have driven the momentum in Washington, D.C. to reform the method of physician payment for Medicare and Medicaid. While various alternatives are being considered, such as capitation or physician diagnosis related groups (DRGs), widespread implementation of such approaches is not imminent. Instead, modifications to the fee-for-service payment system are likely in the next several years. If such reforms can maintain satisfactory levels of patient access while gaining physician support, a modified fee-for-service method may remain the major payment method.

Thus far, attempts to alter fee-for-service payment have included efforts such as: freezing Medicare physician fees for specified periods; developing a model for a Medicare resource based relative value scale to set prices for different physician services; and revising Medicaid fee schedules and Blue Shield relative value scales for physician reimbursement in Massachusetts.

These approaches address only part of the problem: establishing payment amount. A second, independent component for determining what physicians are paid is the code specifying the service provided. While true coding errors on payment claims will always occur, there also is evidence that some physicians are increasing their reimbursement by upcoding, assigning a higher paying code than a procedure merits, or by unpackaging services that were intended to be bundled into a single code. The administrative systems currently available are not adequate to detect and correct most of these errors.

Standard industry practice allows medical claims processors to enter the codes submitted on surgeon claims into a computer system. Fee screens are applied to these codes establishing the maximum amount that will be paid. Two coding methods most frequently used are the American Medical Association's "Current Procedural Terminology, Fourth Edition (CPT-4)," and the "California Relative Value Studies (CRVS)." Some claims administrators allow their claims processors to assign a code if it is absent from the claim; others return the claim to the physician's office for a code. Once entered into the claims processing systems, the code is typically edited for consistency with the age and sex of the patient, and sometimes for obvious rules in coding. After this step, if there is still a perceived problem with either the code or the fee, the claim is removed from the production process and referred for review by clinical staff. This reviewer, usually a nurse, may request the surgeon's official operative report, a required part of the hospital record, and/or call for a physician to review the claim. A payment for the claim, if approved, is established, and the claim is returned to the processor for payment. Emphasis throughout the insurance industry is on minimizing the time between when a claim is received and when it is paid, rather than on its accuracy.

While the problems detailed above are generally accepted, the concern is whether the cost of obtaining the savings will warrant the effort. The solution requires that medical judgment be applied to select the most appropriate code(s) when subtle clinical distinctions result in significant differences in payment to the medical care provider, or to decide when to request additional information from the provider. However, applying the required expert medical judgment has the potential of slowing down the processing of claims and significantly increasing the cost of doing so. At present, processing of medical claims is done on an automated basis using computer systems by relatively unskilled workers who input data, including the CPT-4 codes, into the computer and process them for payment. Usually, such an operator is unaware of whether the entity to whom the request for payment is made, such as an insurance company, should pay or not pay the claim as submitted. It is impractical for each of the operators to have a trained medical physician or technician to sit by the operator and decide whether a particular claim should be paid or not. The expense of such supervision would result in costs which would offset any savings realized by paying only the appropriate amount of the claim. Also, with a multiplicity of such medical reviewers, inconsistent results would occur. Therefore, to save expenses while maintaining productivity of the processing system, medical judgment must be incorporated in an automated data processing system which contains decision rules that can be used to automate the review of claims being processed.

In order to provide a cost effective automated data processing system for achieving the desired results in paying only appropriately coded claim amounts, expert systems or artificial intelligence software provides the vehicle for widespread distribution of an expert's decision-making guidance. An expert system in the form of a computer program is one which reasons like a human expert to solve the problems associated with appropriate coding of medical treatment for claims payments.

CodeReview, a product of HPR, Inc., the assignee of the present invention, uses expert systems techniques especially suited to representing the medical judgment required to assign appropriate codes to surgeon's claims. CodeReview prompts the user for additional information not already entered into the computer, and will either recommend appropriate code(s) or recommend pending the claims until additional information is received form the physician's office. The prompts and recommendations provided by CodeReview are based on the decision rules that physician reviewers have already used on a manual basis to solve identical problems and are consistent with informed surgical opinion.

The present invention uses a set of decision-making rules coupled to a knowledge base of facts and observations to assist the medical claims processor. There is included a knowledge base and a knowledge base interpreter which applies the knowledge base using the rules specified in the knowledge base interpreter. The process is an ongoing process which can be updated as new methods of inappropriate coding are discovered.

The present invention utilizes the CPT-4 codes in the knowledge base of the expert system, although other coding methods for classification of medical procedures such as the CRVS discussed above may be utilized as well. The knowledge base interpreter is a part of the CodeReview program and contains an association of the CPT-4 codes with the knowledge base of expert-derived decisions or rules. An example is the inclusion of one CPT-4 code procedure within another CPT-4 code procedure. As a specific and simple example of the foregoing, a physician or his or her billing company may submit a claim for payment for two procedures with appropriate CPT-4 codes for the procedures. If those two were CPT-4 numbers 49000 for Exploration of the Abdomen and 44140 for Partial Colectomy, and both procedures were performed on the same date, the program of the present invention will recommend to the claims processor that code 49000 should only be paid when it is not done as part of a code 44140 partial colectomy. Since code 44140 was performed, the claim for code 49000 should not be accepted and paid. The computer program invokes a rule which has been specified that states that if code 44140 appears with another code in a particular range, which in this example includes 49000, the second code should be rejected and only the first specified paid. The claims processor then rejects the payment code 49000, authorizes payment for code 44140, and so informs the physician or billing company, with the explanation given above. Without such a program, the claims processor usually pays both code numbers.

FIG. 1 is a block diagram of the system of the present invention;

FIG. 2 is a flowchart of the overall operation of the programmed computer of the present invention;

FIG. 3 is a flowchart depicting the entry program of the programmed computer of the present invention;

FIG. 4 is a flowchart of the operation of the programmed computer for multiple entries;

FIG. 5 is a flowchart of the operation of the computer programmed for single code entries or multiple code entries which survive the flowchart of FIG. 4;

FIG. 6 is a chart of the categories of rules applied to the entries in the present invention.

FIG. 7 is a flowchart of the operation of the programmed computer depicting the lookup function of the computer programmed in accordance with the present invention.

Referring now to the drawings, there is shown in FIG. 1 a general block diagram of a preferred embodiment of the present invention. Claims to be processed I are received by the entity from whom payments are requested. A user designated at 3 enters various facts from the claims 1 into the computer system 2. Such facts include, in addition to the entries for the one or more medical procedures for which payment is sought, other data such as age of the patient, claim number, date(s) of treatment(s) and procedure(s), the name of the physician, etc. The computer system 2 may be any type of suitable computer system which can interact with the program of the present invention. One such suitable computer system is the well-known IBM "personal computer" containing sufficient data processing capabilities and memory and suitable commercially available database management software programs to perform the desired functions. Other suitable computer systems exist and are intended to come within the scope of the present invention. The system may include a connection with another computer system 4 whereby the user 3, after having used the system and methods of the present invention, communicates his or her information to the computer 4 which approves payment for the claim submitted. It is understood that the computer 4 could, in appropriate circumstances, to be described below, refuse any payment or be instructed to request further information from the entity providing the claims 1.

Generally, the user 3 will enter into the computer system 2 a description of the medical claims for which reimbursement or payment is requested or the codes associated with such claims or both. The appropriate code(s) are then sent to the knowledge base interpreter 5 for its assessment of the coded claims. The interpreter 5, using the rules of the present invention, interacts with the knowledge base 6 of the present invention and returns to the user 3 either a recommendation as to code(s) for which payment is proper or requests the user to provide further information or to obtain further information from the entity providing the claim or refers the claim to trained medical personnel for assessment. When the knowledge base interpreter has recommended approval of payment of a particular type, the user 3 then may authorize payment to the provider of the processed claim or may forward that information via input into computer system 4. A history database 7 is provided to update and refine the knowledge base interpreter 5 and the knowledge base 6 and to monitor savings associated with the recommendation.

Referring now to FIGS. 2 and 3, the user first runs the ENTRY PROGRAM shown generally at 7 in FIG. 3. Referring now to FIG. 3, in step 8, if the CPT-4 code is given, the codes are entered into the programmed computer of the present invention and read at step 9. If the codes are or may be incorrectly given, the LOOKUP PROGRAM 10 is run, as will be explained with reference to FIG. 7. If the entity which is requesting payment has provided a code entry or entries for the treatment given, then in step 9 it is determined whether the code entry is valid or invalid by reference to the ALLCODE database 11. If an incorrect code (meaning here that there is no such alpha/numeric code or the code and description do not match) entry or entries are given or if no code entry is given at all, in step 9 the valid code entry or entries are specified by the process of the LOOKUP PROGRAM 10. By valid is meant that there is a code or codes for the treatment given a patient. It does not mean that the entry or entries are valid for payment. The ALLCODE database preferably uses the CPT-4 classification system, but other classification systems are intended to be within the scope of the present invention. The computer programmed in accordance with present invention then looks up in the SUPERSEDE database file 12 to determine whether an earlier code number has been superseded by another code entry in an updated version of the CPT-4 classification system. If the code(s) have been superseded, in step 13 the old code entry or entries are replaced by the superseded code(s) and this information is sent to the PROCESS database 17. In step 14, if another code was added in the preceding process, the program loops back to step 8 again. If not, it goes on to step 15. In step 15, any duplicate codes, if more than one code entry, are eliminated. However, in certain instances, duplicate codes are permitted, so that before eliminating the duplicate codes, a lookup in the database file 16 is performed to determine if the duplicate entries are valid. If there are no duplicate entries or or only one entry, step 15 is not performed. After step 15, the record file, as may be affected by steps 9, 10, 13, and 14, is updated and sent to the PROCESS database 17. In step 18, the number of codes resulting from the foregoing steps is counted and stored. This count will determine whether a particular program for multiple entries must be run, as will be discussed below. In step 19, the ENTRY PROGRAM 7 returns to the operations of the flowchart of FIG. 2.

It will be recalled that in step 18 the number of codes was determined and stored. In step 20, if the number of codes determined was more than one, then the MULTIPLE PROGRAM is run in step 21, as will be presently explained. Referring now to FIG. 4, this figure is the flowchart of MULTIPLE PROGRAM 21. In step 22, the multiple number of codes under consideration is read out from PROCESS database 17. Generally, in the next series of steps, the program will examine the multiple codes presented to determine whether payment or payment authorization for each of the stated codes is medically appropriate, or whether one or more of the codes is medically inappropriate, or whether one or all of the multiple codes should be replaced by other code(s).

In order to accomplish this, a set of rules developed for use of this program is now invoked. These rules were derived using the CPT-4 classification system, and from various medical procedures which were examined, classified, and possible combinations of procedures assessed by expert medical specialists. From this effort resulted a series of rules which can be and are applied to multiple code entries (and single code entries as well as will be discussed below). Each of the rules was developed as a result of reviewing medical procedures by expert medical personnel and is consistent with the CPT-4 classification system. However, expert medical personnel also applied clinical judgment to situations where the CPT-4 classification system is not explicit or nonexistent. Therefore, for both single and multiple code entries, a set of rules applicable to CPT-4 codes singlely and in combination are used to evaluate the appropriateness of the codes for payment. The operation of the rules is best illustrated by way of example with reference to the operation of MULTIPLE PROGRAM 21. In step 23, the codes, multiple in this case, which have been read into a file in step 22 from PROCESS database 17, are examined first by looking up from INTERACT database 24 any references to those specific multiple codes presented in step 22 to which will be applied one or more of the rules shown in summary form in FIG. 6 and more fully detailed in Appendix B. The first rules to be applied as shown in step 23, are rules referred to as E1 and E2 as shown in Appendix B. These first rules are utilized for multiple records wherein one of the codes may be eliminated for payment approval purposes. Thus, in rule E1, if one code number, here designated as ACODE, appears in the same list of codes as one or more codes in the range of BCODE to CCODE, then ACODE is eliminated and the code number appearing within the range of BCODE to CCODE is retained. It is this latter code number which will be further processed and perhaps approved for payment. Similarly, in the code E2, if code ACODE appears with another code in the range of BCODE to CCODE, ACODE is retained and the code within the range of BCODE to CCODE deleted. By first applying rules designated as E1 and E2, it may be possible to eliminate one or more inappropriate codes from consideration. Of course, the codes are not ACODE, BCODE or CCODE but actual code numbers from the CPT-4. In operation, when code numbers are entered into the computer programmed in accordance with the present invention, the program will perform a lookup of the code numbers ACODE and XCODE. The INTERACT database 24 in the program contains a reference that states Chat when ACODE is used with XCODE, and because XCODE is within the bounds of BCODE to CCODE, only one code can survive, in accordance with the E1 and E2 rules. By way of example, consider example 1 of Appendix A. That example implements rule E1. In example 1, code numbers 64450 and 10120 are entered in step 22 of FIG. 4. It is assumed that the date of treatment is the same for all code entries unless specified and entered otherwise. If so, after a lookup in the INTERACT database 24, which contains information relating to the appearance together of 64450 and 10120, the latter appearing in a range of codes analogous to the BCODE to CCODE example given above, by the E1 rule the program is instructed to recommend elimination for 64450, with an explanation given if desired and as contained in such example 1. Of course, many examples of the operation of the E1 and E2 rules are possible depending on the codes which are analyzed. Two additional "E" rules may be exercised over the INTERACT database 24. These are rules EP and EA. In rule EP, a code may be eliminated if the place of service is considered improper or unpractical. An example of this rule EP is given as example 17 of Appendix A. Rule EA is designed to eliminate a code where the age of the patient recommends exclusion of one of the codes. An example of the application of this rule is given as example 18 of Appendix A. Appendix A contains other examples of application of the rules.

After step 23, the results are sent to update PROCESS database 17. Then, in step 23', if there is only one code number remaining after step 23, the program exits to the RULES program of FIG. 5. This is because the "R" and the QM, QS and QB rules apply only to multiple entries. After step 231, in steps 25 and 26, rules designated as R2 and R1 are run, as will be explained below. The "R" rules of the present invention, as shown in Appendix B, generally replace the codes presented in step 22 with other code(s) not designated in the step 22. Rule R2, for example, provides that if a code ACODE appears with BCODE, both codes are deleted and replaced by CCODE. Rule R3 is similar to R2 except that more than two code entries are considered, here ACODE, BCODE, and CCODE, which are replaced by DCODE. Thus, the R1 rule means replace one code by another code; R2 means replace two codes by another single code, and R3 means replace three codes by another single code. Other "R" codes could be developed along the same line: RN would mean replacing N codes with one other code. As shown in FIG. 4, the RN-R2 rules are applied first before rule R1 is applied to the codes. Specific example of rules R2 and R1 are given in examples 2 and 3, respectively, in Appendix A. It must be understood that it is not required that each of steps 23, 25 and 26 will affect the code numbers processed, but these steps are used if expert medical judgment indicates they are required to arrive at appropriate codes.

Describing in greater detail the application of the R2 and R1 rules, step 25 is first seen after having accessed INTERACT database 24. The results of application of the R2 rule are sent to PROCESS database 17. Once again in step 25', the program queries from PROCESS database 17 whether there remain multiple entries. If negative, the program is exited from as explained above. In step 26, rule R1 is exercised and the INTERACT database 24 consulted and compared. The result is sent to the PROCESS database 17. It is to be understood that the R3 rule may be implemented for three codes. An example of the R3 rule is given in Example 4 of Appendix A. In step 27, after consulting PROCESS database 17 and determining whether a new code was added in the application of the R2 and the R1 rules and the number of codes is greater than one, the program loops back to step 23 to exercise the application of rules R2 and R1, E2 and E1, EP and EA on the newly-resulting (after step 26) codes. After step 27, in step 27' the program queries whether the remaining codes exceed one code. If not, the program exits as explained above. If, however, there remains more than one code resulting from the operations of steps 23, 25 and 26, then the program enters a new ACTION PROGRAM to apply rules QM, QS and QB, as shown in step 28. The "Q" set of rules are designed to alert the user 3 that a problem exists in the context of the codes presented for payment of that the particular syntax of the codes presented to the computer programmed in accordance with the present invention are such that they cannot be effectively dealt with by the programmed computer, and thus must be referred to a human consultant. Rule QM states that when ACODE appears with another code in the range of BCODE to CCODE, there is a question about this combination of codes. The user 3 might be instructed to review the claim and codes submitted, be asked to verify the dates(s) of treatment, or refer the matter to a human expert. An example of the QM code being utilized is set forth as example 5 of Appendix A. The code designated QS states that if code ACODE appears with another code in the range of BCODE to CCODE, then there is a question about ACODE. An example of this is given in example 6 in Appendix A. Finally, rule QB is applied to the codes presented. If ACODE appears with another code in the range of BCODE to CCODE, then there is a question about the code in the BCODE to CCODE range. The foregoing example given would apply to this code as well.

After all three "Q" codes have been run on the codes presented in step 28, having accessed the INTERACT database 24, the next step 29 is implemented wherein the PROCESS database 17 is updated with the information from the process of FIG. 4, and the program returned in step 30 to FIG. 2 and step 31. While rules Q, M, QS or QB may raise a question about a code, it will not cause interruption of the program, but will be reserved for later consideration by user 3.

Just prior to implementing the portion of the programmed computer given as step 31, the programmed computer up until this time has performed two operations, the first being the validation of the codes input by user 3, and the second being the application of certain expert rules to multiple code entries. The resulting codes which will be presented to the portion of the programmed computer in step 31 will either be a single or a multiple (due to looping through step 21) code.

In step 31, the RULES PROGRAM represented by the flowchart of FIG. 5 is run. Referring now to FIG. 5, in step 32 the records of surviving codes are read out from the PROCESS database 17. If the code or one of the codes in step 33 is referenced in the BYITSELF database 34 as having a rule or rules applicable or relevant to it, in step 35 a series of "Q" rules is applied. It must be appreciated that not all codes will be in the BYITSELF database, so that if there are three codes resulting from step 32, perhaps only one of those three will be in the BYITSELF file and will be subject to step 35. If there are no matches with codes in the BYITSELF database, then the process moves directly to step 37. The purpose of the "Q" rules is to address an individual code which is one of the surviving codes after the operation of the MULTIPLE PROGRAM or is the only code on the claim for which payment is requested. The "Q" rules are rules to request more information about a particular code. For example, rule Q1 states that if the code survived the set of rules applied to multiple codes under the MULTIPLE PROGRAM routine or is the only code submitted on the claim, then always a request for more information is made, as specified in the MESSAGE appended to the code. An example of the application of this rule is example 7 in Appendix A. In rule Q2, if certain fields have entries that match the claim, more information is specified in MESSAGE. An example of application of this rule is example 8 of Appendix A. In rule Q3, if the code survives rules applied to multiple codes or is the only code submitted on the claim, and the charge on the claim is greater than a dollar sum given for that code as DOLLARLIM, then the user 3 is directed to request more information as specified in a MESSAGE appended. An example of this rule is example 9 in Appendix A. In rule Q4, if the code survives rules applied to multiple codes or is the only code submitted on the claim, and the charge on the claim is greater then the fee screen for the code in CODELIM, then the user 3 is directed to request more information as specified in MESSAGE. AN example of this rule Q4 is example 10 in Appendix A. In rule Q5, if the code survives the rules applied to multiple codes or is the only code submitted on the claim, and the place of service is POS, then the user 3 is directed to request more information as specified in MESSAGE. In addition, if CODELIM is not equal to 0 and the place of of service is POS, the code in question is replaced by CODELIM and the message is flagged by MESSAGETYPE. An example of this rule is example 11 in Appendix A. In rule Q6, if the code survives the rules applied to multiple codes or is the code submitted on the claim, and there is no evidence GE anesthetic as specified in ANESTHESIA, then the user 3 is directed to request more information as specified in MESSAGE. An example of the application of this rule is example 12 in Appendix A. Under rule Q7, if the code survives the rules applied to multiple codes or is the only code submitted on the claim and the patient's age is between BEGAGE and ENDAGE, then the user 3 is directed to request more information as specified in MESSAGE. An example of rule Q7 is example 13 in Appendix A. In rule Q8, if the code survives the rules applied to multiple codes or is the only code submitted on the claim and the diagnosis is DX, then the user 3 is directed to request more information as specified in MESSAGE. In addition, if CODELIM is not equal to 0 and the DX or ICD9CODE is true, the code in question is replaced with CODELIM, and the reason for such action flagged by MESSAGETYPE. In all Q2 through Q9 rules, the reasons are flagged by MESSAGETYPE. An example of the foregoing rule is given in example 14 in Appendix A. In rule Q9, if the code survives the rules applied to multiple codes or code is only one submitted on the form then ACODE is replaced with CODELIM and the reason is flagged by MESSAGETYPE. An example is example 15 in Appendix A. Another rule known as L1 may be used and this rule relates to the amount of payment to be authorized to be paid. Rule L1 applies where the number of codes is greater than one. Rule L1 is different from the other rules in that while the other rules are generally concerned with the correct classification of authorization for payment, rule L1 applies to specific amounts. In rule L1, if ACODE appears with another code in the range of, and includes, BCODE to CCODE, then the payment authorized limits the payment specified in ACODE to some amount DCODE. An example of the foregoing rule is given in example 16 in Appendix A.

Once the "Q" rules have been exercised in step 35, in step 36 the PROCESS database 17 is once again updated and in steps 37 (End of File), and 38, the step 31 of FIG. 2 completes running. At this juncture, the user 3 views the recommendation screen for any relevant rules that have been applied, as discussed above. These recommendations are generally a request for more information, but may be something other than a request as in the case of a specific exclusion message.

In step 39 the PROCESS database 17 is appended to the HISTORY database 40 for recordkeeping purposes and for future use as a means to study these "case histories" and refine, update and change the rules and the knowledge base interpreter 5.

In steps 41 (End of File) and 42, the process of the computer programmed in accordance with the present invention is completed and the program exited from. At this point the user 3 has either confirmed that the code(s) for which payment is requested are valid or have been modified to become valid or have been pended so that more information may be obtained by the user 3 from the physician or his or her billing entity to aid in processing the claims.

Referring now to FIG. 7, the process of the LOOKUP portion 10 of the programmed computer will now be explained. The purpose of the program 10 is to handle those situations in which claims cannot be read out, in step 9 of FIG. 3, from database 8. In step 43, the user 3 inputs a description of the treatment noted on the claims form submitted by the physician or his or her billing entity. The LOOKUP Program 10 searches for a match in step 44 for the description given in step 43 from the index of the CPT-4 manual in a database called CPTINDX 45. The database 45 contains the records of the index, in machine-readable format, of the CPT-4 manual. If a match between input 43 and database 45 does not occur, the process loops back to step 43 for the user to reassess the description given and to give a new description. If, however, a match is made, the program will display a number of related entries from CPTINDX 45 the number of which may be selected by the programmer using well-known programming techniques. The user 3 then chooses, in step 46, what he or she considers to be the most appropriate selection, which the LOOKUP program then searches for in step 47 in the CPT-4 code or other code shown as ALLCODE database 11. In step 48, the codes fetched from the CODES database 49, a subset of ALLCODE database 11, are displayed with their descriptions. In step 50, the user 3 chooses one or more appropriate codes to match the description given in step 43 and the program updates the PROCESS database 17 with this information in step 51. Following such updating, in step 52, the program returns to step 9 as shown in FIG. 3. Of course, the process described with reference to program 10 may be performed with databases other than the CPT-4 example given.

There has been described above a programmed computer system and a method of programming a computer system so that a knowledge base interpreter and a set of rules may facilitate the classification and authorization of payment to health care providers. Since the invention resides in a programmed computer of the automatic programming category, the development of this HISTORY database 40 may lead to the development of new rules and a growth and refinement of the knowledge base interpreter 5. While the foregoing invention has been described with reference to its preferred embodiments, variations and modifications will occur to those skilled in the art. Such variations and modifications are intended to fall within the scope of the appended claims. ##SPC1##