Computer-Implemented Method for Profiling Medical Claims

The present invention relates generally to computer-implemented methods for processing medical claims information. More particularly, the present invention relates to a computer-implemented method for receiving input data relating to a person's medical claim, establishing a management record for the person, establishing episode treatment groups to define groupings of medical episodes of related etiology, correlating subsequent medical claims events to an episode treatment group and manipulating episode treatment groups based upon time windows for each medical condition and co-morbidities.

Due to an increase in health care costs and inefficiency in the health care system, health care providers and service management organizations need health care maintenance systems which receive input medical claim data, correlate the medical claim data and provide a means for quantitatively and qualitatively analyzing provider performance. Because of the complex nature of medical care service data, many clinicians and administrators are not able to efficiently utilize the data. A need exists for a computer program that transforms inpatient and out patient claim data to actionable information which is logically understood by clinicians and administrators.

Performance is quickly becoming the standard by which health care purchasers and informed consumers select their health care providers. Those responsible for the development and maintenance of provider networks search for an objective means to measure and quantify the health care services provided to their clients. Qualitative and quantitative analysis of medical provider performance is a key element for managing and improving a health care network. Operating a successful health care network requires the ability to monitor and quantify medical care costs and care quality. Oftentimes, success depends on the providers' ability to identify and correct problems in their health care system. A need exists, therefore, for an analytical tool for identifying real costs in a given health care management system.

To operate a more efficient health care system, health care providers need to optimize health care services and expenditures. many providers practice outside established utilization and cost norms. Systems that detect inappropriate coding, eliminate potentially inappropriate services or conduct encounter-based payment methodology are insufficient for correcting the inconsistencies of the health care system. When a complication or comorbidity is encountered during the course of treatment, many systems do not reclassify the treatment profile. Existing systems do not adjust for casemix, concurrent conditions or recurrent conditions. A system that compensates for casemix should identify the types of illnesses treated in a given population, determine the extent of resource application to specific types of illnesses, measure and compare the treatment patterns among individual and groups of health care providers and educate providers to more effectively manage risk. When profiling claims, existing systems establish classifications which do not contain a manageable number of groupings, are not clinically homogeneous or are not statistically stable. A need exists, therefore, for a patient classification system that accounts for differences in patient severity and establishes a clearly defined unit of analysis.

For many years, computer-implemented programs for increasing health care efficiency have been available for purchase. Included within the current patent literature and competitive information are many programs which are directed to the basic concept of health care systems.

The Mohlenbrock, et al. patent, U.S. Pat. No. 4,667,292, issued in 1987, discloses a medical reimbursement computer system which generates a list identifying the most appropriate diagnostic-related group (DRG) and related categories applicable to a given patient for inpatient claims only. The list is limited by a combination of the characteristics of the patient and an initial principal diagnosis. A physician can choose a new designation from a list of related categories while the patient is still being treated. The manually determined ICD-9 numbers can be applied to an available grouper computer program to compare the working DRG to the government's DRG.

The Mohlenbrock, et al. patent, U.S. Pat. No. 5,018,067, issued in 1991, discloses an apparatus and method for improved estimation of health resource consumption through the use of diagnostic and/or procedure grouping and severity of illness indicators. This system is a computer-implemented program that calculates the amount of payment to the health provider by extracting the same input data as that identified in the Mohlenbrock '292 Patent teaching the DRG System. The system calculates the severity of the patient's illness then classifies each patient into sub-categories of resource consumption within a designated DRG. A computer combines the input data according to a formula consisting of constants and variables. The variables are known for each patient and relate to the number of ICD codes and the government weighing of the codes. The software program determines a set of constants for use in the formula for a given DRG which minimizes variances between the actual known outcomes and those estimated by use of the formula. Because it is based upon various levels of illness severity within each diagnosis, the results of this system provide a much more homogenous grouping of patients than is provided by the DRGs. Providers can be compared to identify those providers whose practice patterns are of the highest quality and most cost efficient. A set of actual costs incurred can be compared with the estimated costs. After the initial diagnosis, the system determines the expected costs of treating a patient.

The Schneiderman patent, U.S. Pat. No. 5,099,424, issued in 1992, discloses a model user application system for clinical data processing that tracks and monitors a simulated out-patient medical practice using database management software. The system allows for a database of patients and the entry of EKG and/or chest x-ray (CXR) test results into separate EKG/CXR records as distinct logical entities. This system requires entry of test results which are not part of the medical claim itself. If not already present, the entry creates a separate lab record which may be holding blood work from the same lab test request. Portions of the information are transferred to the lab record for all request situations. Although the lab record data routine is limited to blood work, each time the routine is run, historical parameter data are sent to a companion lab record along with other data linking both record types. The system also includes a revision of the system's specialist record and the general recommendation from an earlier work for more explicit use in information management.

The Tawil patent, U.S. Pat. No. 5,225,976, issued in 1993, discloses an automated health benefit processing system. This system minimizes health care costs by informing the purchasers of medical services about market conditions of those medical services. A database includes, for each covered medical procedure in a specific geographic area, a list of capable providers and their charges. A first processor identifies the insured then generates a treatment plan and the required medical procedures. Next, the first processor retrieves information related to the medical procedures and appends the information to the treatment plan. A second processor generates an actual treatment record including the actual charges. A third processor compares the plan and the actual records to determine the amounts payable to the insured and the provider.

The Ertel patent, U.S. Pat. No. 5,307,262, issued in 1994, discloses a patient data quality review method and system. The system performs data quality checks and generates documents to ensure the best description of a case. The system provides file security and tracks the cases through the entire review process. Patient data and system performance data are aggregated into a common data base which interfaces with existing data systems. Data profiles categorize data quality problems by type and source. Problems are classified as to potential consequences. The system stores data, processes it to determine misreporting, classifies the case and displays the case-specific patient data and aggregate patient data.

The Holloway, et al. patent, U.S. Pat. No. 5,253,164, issued in 1993, discloses a system and method for detecting fraudulent medical claims via examination of service codes. This system interprets medical claims and associated representation according to specific rules and against a predetermined CPT-4 code database. A knowledge base interpreter applies the knowledge base using the rules specified. The database can be updated as new methods of inappropriate coding are discovered. The system recommends appropriate CPT codes or recommends pending the claims until additional information is received. The recommendations are based on the decision rules that physician reviewers have already used on a manual basis.

The Cummings patent, U.S. Pat. No. 5,301,105, issued in 1994, discloses an all care health management system. The patient-based system includes an integrated interconnection and interaction of essential health care participants to provide patients with complete support. The system includes interactive participation with the patients employers and banks. The system also integrates all aspects of the optimization of health-inducing diet and life style factors and makes customized recommendations for health-enhancing practices. By pre-certifying patients and procedures, the system enhances health care efficiency and reduces overhead costs.

The Dorne patent, U.S. Pat. No. 5,325,293, issued in 1994, discloses a system and method for correlating medical procedures and medical billing codes. After an examination, the system automatically determines raw codes directly associated with all of the medical procedures performed or planned to be performed with a particular patient. The system allows the physician to modify the procedures after preforming the examination. By manipulating the raw codes, the system generates intermediate and billing codes without altering the raw codes.

The Kessler, et al. patent, U.S. Pat. No. 5,324,077, issued in 1994, discloses a negotiable medical data draft for tracking and evaluating medical treatment. This system gathers medical data from ambulatory visits using a medical data draft completed by the provider to obtain payment for services, to permit quality review by medical insurers. In exchange for immediate partial payment of services, providers are required to enter data summarizing the patient's visit on negotiable medical drafts. The partial payments are incentives to providers for participating in the system.

The Torma, et al. patent, U.S. Pat. No. 5,365,425, issued in 1994, discloses a method and system for measuring management effectiveness. Quality, cost and access are integrated to provide a holistic description of the effectiveness of care. The system compares general medical treatment databases and surveyed patient perceptions of care. Adjustments based on severity of illness, case weight and military costs are made to the data to ensure that all medical facilities are considered fairly.

Health Chex's PEER-A-MED computer program is a physician practice profiling system that provides case-mix adjusted physician analysis based on a clinical severity concept. The system employs a multivariate linear regression analysis to appropriately adjust for case-mix. After adjusting for the complexity of the physician's case-load, the system compares the relative performance of a physician to the performance of the peer group as a whole. The system also compares physician utilization performance for uncomplicated, commonly seen diagnosis. Because the full spectrum of clinical care that is rendered to a patient is not represented in its databases, the system is primarily used as an economic performance measurement tool. This system categorizes the claims into general codes including acute, chronic, mental health and pregnancy. Comorbidity and CPT-4 codes adjust for acuity level. The codes are subcatagorized into twenty cluster groups based upon the level of severity. The system buckets the codes for the year and contains no apparent episode building methodology. While the PEER-A-MED system contains clinically heterogeneous groupings, the groupings are not episode-based and recurrent episodes cannot be accounted.

Ambulatory Care Groups (ACG) provides a patient-based system which uses the patient and the analysis unit. Patients are assigned to an diagnosis group and an entire year's claims are bucketed into thirty-one diagnosis groups. By pre-defining the diagnosis groups, this is a bucketing-type system and claim management by medical episode does not occur. The system determines if a claim is in one of the buckets. Because different diseases could be categorized into the same ACG, this system is not clinically homogeneous. An additional problem with ACGs are that too many diagnosis groups are in each ACG.

Ambulatory Patient Groups (APGs) are a patient classification system designed to explain the amount and type of resources used in an ambulatory visit. Patients in each APG have similar clinical characteristics and similar resource use and cost. Patient characteristics should relate to a common organ system or etiology. The resources used are constant and predictable across the patients within each APG. This system is an encounter-based system because it looks at only one of the patient's encounters with the health care system. This system mainly analyzes outpatient hospital visits and does not address inpatient services.

The GMIS system uses a bucketing procedure that profiles by clumps of diagnosis codes including 460 diagnostic episode clusters (DECs). The database is client specific and contains a flexible number and type of analytic data files. This system is episode-based, but it does not account for recurrent episodes, so a patient's complete data history within a one year period is analyzed as one pseudo-episode. Signs and symptoms do not cluster to the actual disease state, e.g. abdominal pain and appendicitis are grouped in different clusters. This system does not use CPT-4 codes and does not shift the DEC to account for acuity changes during the treatment of a patient.

Value Health Sciences offers a value profiling system, under the trademark VALUE PROFILER, that utilizes a DB2 mainframe relational database with 1,800 groups. The system uses ICD9 and CPT-4 codes which are bucket codes. Based on quality and cost-effectiveness of care, the system evaluates all claims data to produce case-mix adjusted profiles of networks, specialties, providers and episodes of illness. The pseudo-episode building methodology contains clinically pre-defined time periods during which claims for a patient are associated with a particular condition and designated provider. The automated practice review system analyzes health care claims to identify and correct aberrant claims in a pre-payment mode (Value Coder) and to profile practice patterns in a post-payment mode (Value Profiler). This system does not link signs and symptoms and the diagnoses are non-comprehensive because the profiling is based on the exclusion of services. No apparent shifting of episodes occurs and the episodes can only exist for a preset time because the windows are not recurrent.

The medical claim profiling programs described in foregoing patents and non-patent literature demonstrate that, while conventional computer-implemented health care systems exist, they each suffer from the principal disadvantage of not identifying and grouping medical claims on an episodic basis or shifting episodic groupings based upon complications or co-morbidities. The present computer-implemented health care system contains important improvements and advances upon conventional health care systems by identifying concurrent and recurrent episodes, flagging records, creating new groupings, shifting groupings for changed clinical conditions, selecting the most recent claims, resetting windows, making a determination if the provider is an independent lab and continuing to collect information until an absence of treatment is detected.

Accordingly, it is a broad aspect of the present invention to provide a computer-implemented medical claims profiling system.

It is a further object of the present invention to provide a medical claims profiling system that allows an objective means for measuring and quantifying health care services.

It is a further object of the present invention to provide a medical claims profiling system that includes a patient classification system based upon episode treatment groups.

It is a further object of the present invention to provide a medical claims profiling system that groups claims to clinically homogeneous and statistically stable episode treatment groups.

It is a further object of the present invention to provide a medical claims profiling system that includes claims grouping utilizing service or segment-level claim data as input data.

It is a further object of the present invention to provide a medical claims profiling system that assigns each claim to an appropriate episode.

It is a further object of the present invention to provide a medical claims profiling system that identifies concurrent and recurrent episodes.

It is a further object of the present invention to provide a medical claims profiling system that shifts groupings for changed clinical conditions.

It is a further object of the present invention to provide a medical claims profiling system that employs a decisional tree to assign claims to the most relevant episode treatment group.

It is a further object of the present invention to provide a medical claims profiling system that resets windows of time based upon complications, co-morbidities or increased severity of clinical conditions.

It is a further object of the present invention to provide a health care system that continues to collect claim information and assign claim information to an episode treatment group until an absence of treatment is detected.

It is a further object of the present invention to provide a health care system that creates orphan records.

It is a further object of the present invention to provide a health care system that creates phantom records.

The foregoing objectives are met by the present system which allows an objective means for measuring and quantifying health care services based upon episode treatment groups (ETGs). An episode treatment group (ETG) is a clinically homogenous and statistically stable group of similar illness etiology and therapeutic treatment. ETG grouper method uses service or segment-level claim data as input data and assigns each service to the appropriate episode.

ETGs gather all in-patient, ambulatory and ancillary claims into mutually exclusive treatment episodes, regardless of treatment duration, then use clinical algorithms to identify both concurrent and recurrent episodes. ETG grouper method continues to collect information until an absence of treatment is detected for a predetermined period of time commensurate with the episode. For example, a bronchitis episode will have a sixty day window, while a myocardial infarction may have a one year window. Subsequent records of the same nature within the window reset the window for an additional period of time until the patient is asymptomatic for the pre-determined time period.

ETGs can identify a change in the patient's condition and shift the patient's episode from the initially defined ETG to the ETG which includes the change in condition. ETGs identify all providers treating a single illness episode, allowing the user to uncover specific treatment patterns. After adjusting for case-mix, ETGs measure and compare the financial and clinical performance of individual providers or entire networks.

Medical claim data is input as data records by data entry into a computer storage device, such as a hard disk drive. The inventive medical claims profiling system may reside in any of a number of computer system architectures, i.e., it may be run from a stand-alone computer or exist in a client-server system, for example a local area network (LAN) or wide area network (WAN).

Once relevant medical claim data is input, claims data is processed by loading the computer program into the computer system memory. During set-up of the program onto the computer system, the computer program will have previously set pointers to the physical location of the data files and look-up tables written to the computer storage device. Upon initialization of the inventive computer program, the user is prompted to enter an identifier for a first patient. The program then checks for open episodes for the identified patient, sets flags to identify the open episodes and closes any episodes based upon a predetermined time duration from date of episode to current date. After all open episodes for a patient are identified, the new claims data records are read to memory and validated for type of provider, CPT code and ICD-9 (dx) code, then identified as a management, surgery, facility, ancillary, drug or other record.

As used herein, "Management records" are defined as claims which represent a service by a provider engaging in the direct evaluation, management or treatment or a patient. Examples of management records include office visits and therapeutic services. Management records serve as anchor records because they represent focal points in the patient treatment as well as for related ancillary services.

"Ancillary records" are claims which represent services which are incidental to the direct evaluation, management and treatment of the patient. Examples of ancillary records include X-ray and laboratory tests.

"Surgery records" are specific surgical claims. Surgery records also serve as anchor records.

"Facility records" are claims for medical care facility usage. Examples of facility records include hospital room charges or outpatient surgical room charges.

"Drug records" are specific for pharmaceutical prescription claims.

"Other records" are those medical claim records which are not management, surgery, ancillary, facility or drug records.

Invalid records are flagged and logged to an error output file for the user. Valid records are then processed by an ETG Assignor Sub-routine and, based upon diagnosis code, is either matched to existing open episodes for the patient or serve to create new episodes.

Management and surgery records serve as "anchor records." An "anchor record" is a record which originates a diagnosis or a definitive treatment for a given medical condition. Management and surgery records serve as base reference records for facility, ancillary and drug claim records relating to the diagnosis or treatment which is the subject of the management or surgery record. Only management and surgery records can serve to start a given episode.

If the record is a management record or a surgery record, the diagnosis code in the claim record is compared with prior related open episodes in an existing look-up table for a possible ETG match. If more than one open episode exists, the program selects the most recent open episode. A positive match signifies that the current episode is related to an existing open episode. After the match is determined, the time window is reset for an additional period of time corresponding to the episode. A loop shifts the originally assigned ETG based on the additional or subsequent diagnoses. If any of the additional or subsequent diagnoses is a defined co-morbidity diagnosis, the patient's comorbidity file updated. If no match between the first diagnosis code and an open episode is found, a new episode is created.

Grouping prescription drug records requires two tables, a NDC (National Drug Code) by GDC (Generic Drug Code) table and a GDC by ETG table. Because the NDC table has approximately 200,000 entries, it has been found impracticable to directly construct an NDC by ETG table. For this reason the NDC by GDC table serves as a translation table to translate NDCs to GDCs and construct a smaller table based upon GDCs. Reading, then from these tables, the NDC code in the claim data record is read and translated to a GDC code. The program then identifies all valid ETGs for the GDC codes in the claim data record then matches those valid ETGs with active episodes.

These and other objects, features and advantages of the present invention will become more apparent to those skilled in the art from the following more detailed description of the non-limiting preferred embodiment of the invention taken with reference to the accompanying Figures.

Briefly summarized, a preferred embodiment of the invention is described in conjunction with the illustrative disclosure thereof in the accompanying drawings, in which:

FIG. 1 is a diagrammatic representation of a computer system used with the computer-implemented method for analyzing medical claims data in accordance with the present invention.

FIG. 2 is a flow diagram illustrating the general functional steps of the computer implemented method for analyzing medical claims data in accordance with the present invention.

FIG. 3 is a flow diagram illustrating an Eligible Record Check routine which validates and sorts patient claim data records.

FIGS. 4A to 4F are flow diagrams illustrating the Management Record Grouping Sub-routine of the ETG Assignor Routine in accordance with the computer-implemented method of the present invention.

FIGS. 5A-5D are flow diagrams illustrating a Surgery Record Grouping Sub-routine of the ETG Assignor Routine in accordance with the computer-implemented method of the present invention.

FIGS. 6A-6E are flow diagrams illustrating a Facility Record Grouping Sub-routine of the ETG Assignor Routine in accordance with the computer-implemented method of the present invention.

FIGS. 7A-B are flow diagrams illustrating an Ancillary Record Grouping Sub-routine of the ETG Assignor Routine in accordance with the computer-implemented method of the present invention.

FIGS. 8A-8C are flow diagrams illustrating a Drug Record Grouping Sub-routine of the ETG Assignor Routine in accordance with the computer-implemented method of the present invention.

FIG. 9 is a flow diagram illustrating the Episode Definer Routine in accordance with the computer-implemented method of the present invention.

FIG. 10 is diagrammatic timeline illustrating a hypothetical patient diagnosis and medical claims history during a one year period and grouping of claim records as management records and ancillary records with cluster groupings.

FIG. 11 is a diagrammatic representation of a I-9 Diagnosis Code (dx) X ETG table illustrating predetermined table values called by the Episode Definer Routine of the present invention.

FIG. 12 is a diagrammatic representation of an I-9 Diagnosis Code 9 (dx) X CPT Code table illustrating predetermined table values called by the Episode Definer Routine of the present invention.

FIG. 13 is a diagrammatic representation of a National Drug Code (NDC) to Generic Drug Code (GDC) conversion table illustrating predetermined Generic Drug Code values called by the Drug Record Grouping Sub-routine of the Episode Definer Routine of the present invention.

FIG. 14 is a diagrammatic representation of a Generic Drug Code (GDC) to Episode Treatment Group (ETG) table illustrating predetermined table values called by the Drug Record Grouping Sub-routine of the Episode Definer Routine of the present invention.

Referring particularly to the accompanying drawings, the basic structural elements of a health care management system of the present invention are shown. Health care management system consists generally of a computer system 10. Computer system 10 is capable of running a computer program 12 that incorporates the inventive method is shown in FIG. 1. The computer system 10 includes a central processing unit (CPU) 14 connected to a keyboard 16 which allows the user to input commands and data into the CPU 14. It will be understood by those skilled in the art that CPU 14 includes a microprocessor, random access memory (RAM), video display controller boards and at least one storage means, such as a hard disk drive or CD-ROM. The computer system 10 also contains a video display 18 which displays video images to a person using the computer system 10. The video display screen 18 is capable of displaying video output in the form of text or other video images.

Episode Treatment Groups (ETGs) are used to define the basic analytical unit in the computer-implemented method of the present invention. ETGs are episode based and conceptually similar to Diagnostic Related Groups (DRGs), with a principal difference being that DRGs are inpatient only. ETGs encompass both inpatient and outpatient treatment.

Using ETGs as the basic episodic definer permits the present invention to track concurrently and recurrently occurring illnesses and correctly identify and assign each service event to the appropriate episode. Additionally, ETGs account for changes in a patient's condition during a course of treatment by shifting from the initially defined ETG to one which includes the changed condition once the changed condition is identified.

The inventive medical claims profiling system defines Episode Treatment Groups (ETGs). The number of ETGs may vary, depending upon the definitional specificity the health care management organization desires. Presently, the inventive system defines 558 ETGs, which are assigned ETG Numbers 1-900 distributed across the following medical areas: Infectious Diseases, Endocrinology, Hematology, Psychiatry, Chemical Dependency, Neurology, Ophthalmology, Cardiology, Otolaryngology, Pulmonology, Gastroenterology, Hepatology, Nephrology, Obstetrics, Gynecology, Dermatology, Orthopedics and Rheumatology, Neonatology, Preventative and Administrative and Signs and Isolated Signs, Symptoms and Non-Specific Diagnoses or Conditions. Under the presently existing system, ETG 900 is reserved to "Isolated Signs, Symptoms and Non-Specific Diagnoses or Conditions," and is an ETG designation used where the diagnosis code is incapable of being assigned to another ETG. A listing of exemplary ETGs for typical episodes is attached as TABLE 1. Those skilled in the art will understand, however, that the number of ETGs may change, the ETG numbering system is variable, the ETG classifications may be defined with relatively broader or narrower degrees of specificity and the range of medical specialties may be greater or fewer, as required may be require by the management organization in their medical claims data analysis protocols.

An episode may be considered a low outlier or high outlier. Low outliers are episodes with dollar values below the minimum amount which is specific to each ETG. Examples of low outliers include patients which drop from a plan during mid-episode and patients who use out-of-network providers and do not submit claims. High outliers are those episodes with high dollar values greater than the 75th percentile plus 2.5 times the interquartile based upon a predefined database. The low and high outlier points are pre-determined and hard-coded into the inventive system and will vary across analysis periods.

If no ICD-9 (diagnosis code) on a given record matches the CPT-4 code, i.e., a diagnosis of bronchitis and a CPT of knee x-ray, an invalid code segment results. The inventive system outputs invalid records and discontinues the processing of these records. An invalid ICD-9 code is assigned to ETG 997, an invalid CPT-4 code is assigned to ETG 996 and an invalid provider type is assigned to ETG 995. A sequential anchor count and a sequential episode count are incremented after each ETG assignment. Active open and closed ETG files include ETG number, sequential episode number,. most recent anchor from date of service and most recent sequential anchor record count. An alternative embodiment creates a single record for each individual episode containing ETG number, patient age, patient sex, episode number, total charges, total payments, earlier anchor record, last anchor record, whether the episode was closed ("clean finish"), number of days between database start date and earliest anchor record, whether a number of days between database start date and earliest anchor record exceeds the ETG's days interval, patient identification, physician identification, management charges, management paid, surgery charges, surgery paid, ancillary charges and ancillary paid.

The inventive system uses clinical algorithms to identify both concurrent and recurrent episodes. Subsequent episodes of the same nature within a window reset the window for an additional period of time until the patient is asymptomatic for a pre-determined time period. If an ETG matches a prior ETG, a recurrent ETG is created and the window is reset. The most recent claim is selected if more than one matched claim exists. If the ETG does not match an active ETG, a new concurrent ETG is created.

Comorbidities, complications or a defining surgery could require an update of the patient's condition to an ETG requiring a more aggressive treatment profile. ETG's changes in the patient's clinical condition and shift the patient's episode from the initially defined ETG to an ETG which includes the change in clinical condition.

If the claim is an ancillary record and it does not match an active ETG it is designated an "orphan" ancillary record.

Termination of an episode is detected by an absence of treatment for a period of time commensurate with the episode.

If the claim is a prescription drug record, two pre-defined tables written to the computer data storage medium, are read. The first of the tables is a National Drug Code (NDC) by Generic Drug Code (GDC) table. The GDC code is equivalent to the Generic Drug Code table known in the art. This table acts as a translator table to translate a large number of NDCs to a smaller set of GDCs. A second pre-defined table is employed and is constructed as a GDC by ETG table. The GDC by ETG table is used, in conjunction with the NDC by GDC translator table, to identify all valid ETGs for a particular NDC code in the claim record.

To determine specific treatment patterns and performance contributions, the computer-implemented method identifies all providers treating a single illness episode. If a network of providers contains Primary Care Physicians (PCP), the ETGs clearly identify each treatment episode by PCP. Financial and clinical performance of individual providers or entire networks may be monitored and analyzed. To monitor health care cost management abilities of providers, components of a provider's treatment plan may be analyzed by uncovering casemix-adjusted differences in direct patient management, the use of surgery and the prescribing of ancillary services. By identifying excessive utilization and cost areas, continuous quality improvement protocols are readily engineered based on internally or externally derived benchmarks. After adjusting for location and using geographically derived normative charge information, ETG-based analysis compares the cost performance of providers or entire networks. By using geographically derived utilization norms, the present invention forms the methodology base for measuring both prevalence and incidence rates among a given population by quantifying health care demand in one population and comparing it to external utilization norms. This comparison helps to identify health care providers who practice outside established utilization or cost norms.

Turning now to FIG. 2, there is illustrated the general operation of the computer-implemented method of the present invention. Those skilled in the art will understand that the present invention is first read from a removable, transportable recordable medium, such as a floppy disk, magnetic tape or a CD-ROM onto a recordable, read-write medium, such as a hard disk drive, resident in the CPU 14. Upon a user's entry of appropriate initialization commands entered via the keyboard 16, or other input device, such as a mouse or trackball device, computer object code is read from the hard disk drive into the memory of the CPU 14 and the computer-implemented method is initiated. The computer-implemented method prompts the user by displaying appropriate prompts on display 18, for data input by the user.

Those familiar with medical claims information processing will understand that medical claims information is typically received by a management service organization on paper forms. If this is the case, a user first manually sorts claim records by patient, then input patient data through interfacing with the CPU 14 through the keyboard 16 or other input device.

Prior to being submitted to the grouping algorithm, records must be sorted by patient by chronological date of service. An Eligible Record Check routine 48 to verify the validity and completeness of the input data. As each record is read by the software, it first checks the date of service on the record and compares it to the last service date of all active episodes to evaluate which episodes have expired in terms of an absence of treatment. These episodes are closed at step 50. Next the record is identified as either a management 52, surgery 54, facility 56, ancillary 58 or drug 60 record. These types of records are categorized as follows:

"Management records" are defined as claims which represent a service by a provider engaging in the direct evaluation, management or treatment or a patient. Examples of management records include office visits, surgeries and therapeutic services. Management records serve as anchor records because they represent focal points in the patient treatment as well as for related ancillary services.

"Ancillary records" are claims which represent services which are incidental to the direct evaluation, management and treatment of the patient. Examples of ancillary records include X-ray and laboratory tests.

"Surgery records" represent surgical procedures performed by physicians and other like medical allied personnel. Like management records, surgery records also serve as anchor records.

"Facility records" are claims for medical care facility usage. Examples of facility records include hospital room charges or ambulatory surgeryl room charges.

"Drug records" are specific for pharmaceutical prescription claims.

A "cluster" is a grouping of one, and only one, anchor record, management or surgery, and possibly ancillary, facility and/or drug records. A cluster represents a group of services in which the focal point, and therefore the responsible medical personnel, is the anchor record. An episode is made up of one or more clusters.

After the management, surgery, facility, ancillary and drug records are identified at steps 52, 54, 56, 58 and 60, respectively, an ETG Assignor Sub-routine is executed at step 62. The ETG Assignor Sub-routine 62 assigns patient medical claims to ETGs based one or more cluster of services related to the same episode, and provides for ETG shifting upon encountering a diagnosis code or CPT code which alters the relationship between the diagnosis or treatment coded in the claim record and an existing ETG assignment. For example, ETG's may be shifted to account for changes in clinical severity, for a more aggressive ETG treatment profile if a complication or comorbidity is encountered during the course of treatment for a given ETG or where a defining surgery is encountered during the course of treatment for a given ETG.

When the last claim data record for a given patient is processed by the ETG Assignor Routine 62, the Episode Definer Routine is executed at step 64. Episode Definer Routine 64 identifies all open and closed ETG episodes for the patient and appropriately shifts any episodes to a different ETG if such ETG is defined by age and/or the presence or absence of a comorbidity. The patient records are then output to a file with each record containing the ETG number, a sequential episode number, and a sequential cluster number. Upon input of an identifier for the next patient, the processing of medical claims for the next patient is initiated at step 66 by looping back to check for eligible records for the new patient at step 48.

Operation of the Eligible Record Check routine 100 is illustrated in FIG. 3. The patient records input by the user are read from the recordable read-write data storage medium into the CPU 14 memory in step 102. From the patient records read to memory in step 102, a record validation step 104 is carried out to check provider type, treatment code and diagnosis code against pre-determined CPT code and diagnosis code look up tables. The diagnosis code is preferably the industry standard ICD-9 code and the treatment code is preferably the industry standard CPT-4 code. All valid patient records are assigned as one of a) management record, b) ancillary record, c) surgery record, d) facility record, e) drug record or f) other record, and coded as follows:

m=management record;

a=ancillary record;

s=surgery record;

f=facility record;

d=drug record; or

o=other record.

A sort of valid records 106 and invalid records 108 from step 104 is made. For valid records 106 in step 110, patient age is then read to memory from the first patient record from step 106. All valid records are then sorted by record type in step 112, i.e., record type m, a, s, f, d or o by a date of service from date (DOS-from). A sort index of all record-type sorted records from step 116 is generated and written to the hard disk, and the ETG Assignor routine 120 is initialized.

For invalid records 108 identified at step 104, the records are assigned ETG designations reserved for records having invalid provider data, invalid treatment code, or invalid diagnosis code, e.g., ETG 995, 996 and 997, respectively, at step 111. An error log file is output identifying the invalid records by reserved ETG and written to disk or displayed for the user and processing of the invalid records terminates at step 113.

The computer-implemented method of the present invention then initializes an Episode Assignor Routine 200, the operation of which is illustrated in FIGS. 4A-8C. Episode Assignor Routine 200 consists generally of five Sub-routine modules for processing management records, surgery records, facility records, ancillary records and drug records and assigning claims to proper ETGs. FIGS. 4A-4F illustrate initial identification of records as management, surgery, facility ancillary and drug records and the Management Record Grouping Sub-Routine. FIGS. 5A-5E illustrate operation of the Surgery Record Grouping routine 400 for matching surgery claim records to proper ETGs. FIGS. 6A-6E illustrate operation of the Facility Record Grouping routine 500 for matching facilities records to proper ETGs. FIGS. 7A-7 illustrate operation of the Ancillary Record Grouping routine 600 for matching ancillary records to proper ETGs. Finally, FIGS. 8A-8C illustrate operation of the Drug Records Grouping routine 700 for matching drug records to proper ETGs.

The Episode Assignor routine begins by executing a Management Records Grouping Sub-routine 200, illustrated in FIGS. 4A-4F, first reads the input claim record for a given patient in step 202. The first processing of the input claim record entails categorizing the record as a management, surgery, facility, ancillary or drug record at step 204. A series of logical operands 208, 210, 212 and 214, read the record and determine whether the record is a management record at step 204, a surgery record at step 208, a facility record at step 210, an ancillary record at step 212 or a drug record at step 214. If an affirmative response is returned in response to logical operand 204, grouping of the management record to an ETG is initialized and processing of the management record proceeds to step 215. If, however, a negative response is returned in response to the logical operand 206, logical operand 208 is executed to determine whether the record is a surgery record. If an affirmative response is returned from logical operand 208, the Surgery Record Grouping routine 400 is initialized. If, however, a negative response to logical operand 208 is returned, logical operand 210 is executed to determine whether the record is a facility record. If an affirmative response is returned in response to logical operand 210, the Facility Record Grouping Sub-routine 500 is executed. If, however, a negative response is returned in response to the logical operand 210, logical operand 212 is executed to determine whether the record is an ancillary record. If an affirmative response is returned from logical operand 212, the Ancillary Record Grouping Sub-routine 600 is executed. If, however, a negative response to logical operand 212 is returned, logical operand 214 is executed to determine whether the record is a facility record. At this point all records except drug records have been selected. Thus, all the remaining records are drug records and the Drug Record Grouping Sub-routine 700 is executed.

Returning now to the initialization of the Management Record Grouping routine 200, and in particular to step 215. Once the record has been categorized as a management record in step 206, the DOS-to value is compared to active episodes for the patient to determine if any active episodes should be closed. Closed episodes are moved to an archive created on the storage means, such as a hard disk or CD-ROM.

The management record is examined and the first diagnosis code on record is read, a diagnosis code (dx) by ETG table 201 is read from the storage means and all valid ETGs for the first diagnosis code on record are identified at step 216. The dx by ETG table 201 consists of a table matrix having diagnosis codes on a first table axis and ETG numbers on a second table axis. At intersection cells of the dx by ETG table are provided table values which serve as operational flags for the inventive method. In accordance with the preferred embodiment of the invention, dx by ETG table values are assigned as follows:

P=primary, with only one P value existing per ETG;

S=shift;

I=incidental;

A=shift to ETG with C value; and

C=P, where P' is a shiftable primary value.

An illustrative example of a section of a dx by ETG table is found at FIG. 11.

ETG validation in step 216 occurs where for a given diagnosis code on record, the code has either a P, S, I, A or C dx-ETG table value. The ETGs identified as valid for the first diagnosis code on record in step 216, are then matched with active open ETGs in step 217 by comparing the valid ETGs with the open ETGs identified in step 215. A logical operand is then executed at step 218 to determine whether a match exists between the valid ETG from the management record and any open ETGs. A negative response at step 218 causes execution of another logical operand at step 220 to determine whether for the first diagnosis code is the P value in the dx-ETG table equal to the ETG for non-specific diagnosis, i.e., ETG 900. If an affirmative response is returned at step 216, ETG identifiers for the second to the fourth diagnosis codes in the management record are established from the dx-ETG table and the ETG identifier value is matched to active specific ETGs in step 222 and execution of the program continues as represented by designator AA 236 bridging to FIG. 5B. If, however, a negative response is returned from logical operand 220, a value of one is added to the management record or anchor count and to the episode count and the ETG with a P value on the dx-ETG table is selected and a new episode is initialized. Further processing of the new episode by the program continues as represented by designator F 236 bridging to FIG. 5C.

If an affirmative response is returned at logical operand step 218, the matched active ETG with the most recent DOS-to are selected at step 230. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. A value of one is then added to the management record or anchor record counter at step 232 and further processing continues as represented by designator G 238 bridging to FIG. 5C.

Turning now to FIG. 4B, which is a continuation from designator AA 236 of FIG. 4A, identifier ETGs for the second to fourth diagnoses in the management record are matched to active ETGs in logical operand 237. If an affirmative response is returned in response to logical operand 237, the matched active ETG with the most recent DOS-to is selected in step 240. If there is a tie between two or more ETGs with the most recent DOS-to value, the most recent DOS-from ETG is selected. If, however, there is a tie between two or more active ETGs with the most recent DOS-from value, then the first encountered ETG is selected in step 240. A value of one is then added to the sequential anchor record counter in step 241 and operation of the computer-implemented method continues as indicated by designator G 243 bridging to FIG. 5C.

From logical step 237, if a negative response is returned, the ETG with the second diagnosis value of P is selected at step 242, then a logical query is made to determine whether the selected ETG is a non-specific ETG, i.e., ETG 900 at step 244. A negative response to logical query 244 causes a value of one to be added to the sequential anchor count and to the sequential episode count at step 254. If an affirmative response to logical query 244 is returned, logical queries 246 and 248 are sequentially executed to select ETGs with the third and fourth diagnosis values of P from the dx-ETG table written on the storage means, respectively, and logical query 244 is executed to determine whether the selected ETG is the non-specific ETG, i.e., ETG 900. If a negative response is returned to logical query 244 for the ETG selected in step 248, a value of one is added to the sequential anchor count and to the sequential episode count in step 254. If an affirmative response is returned from logical query 244, a value of one is added to the sequential anchor count and the sequential episode count at step 250.

From step 250, the non-specific ETG, i.e., ETG 900 is selected and a new episode is started in the active ETG file. The updated sequential episode number, the updated sequential anchor count, the DOS-from and the DOS-to from the record are written to the new episode in the active ETG file in step 252.

From step 254, the ETG with a dx-ETG table value of P is selected and a new episode is started in the active ETG file. The updated sequential episode number, the updated sequential anchor count, the DOS-from and the DOS-to from the record are written to the new episode in the active ETG file in step 256. A comorbidity file written on the storage means is then updated with all the dx codes in the management record in step 258.

From each of steps 252 and steps 258 a check is made to determine whether the processed management record is the last record for the patient at logical step 260. An affirmative response returned to logical step 260 prompts the program operation to the Episode Definer Sub-routine 264, bridging to FIG. 9 with identifier GG, while a negative response to logical step 260 returns program operation to the beginning of the ETG Assignor routine 200 and the next patient record is read at step 262.

Turning now to FIG. 4C, the bridge reference G 238 is continued from FIG. 4A. For those records having a match with an open ETG, a query is made at step 270 of the dx-ETG table 201 to determine the table value of the dx code for the selected ETG. Again, valid table values are one of P, S, I, A, or C. If the table value returned from step 270 is A, the selected ETG in the active file is changed at step 272 to the ETG number having an equivalent table value of C for the diagnosis on record. If the table value returned from step 270 is S, the selected ETG in the active file is shifted at step 274 to an ETG value having a table value of P for the diagnosis code on record. If the table value is one of P, I or C, the ETG remains the same and the selected active ETG's most recent DOS-to is updated by writing the record date to the ETG DOS-to field, and the sequential anchor count in the selected active ETG is updated to reflect writing of the record to the ETG at step 276.

At step 278, the record is then written with a sequential episode number and the sequential anchor count of the selected ETG from the selected active ETG. In this manner, the record is identified with the ETG and the specific episode. The patient's co-morbidity file is flagged with the output read from bridge designator F at step 234. A patient's comorbidity file is a predefined list of diagnoses which have been identified as comorbidities. If during the course of grouping a patient's records, a management record is encountered which is a comorbidity diagnosis, the ETG for that diagnosis is flagged or "turned on" in the comorbidity file. Then, during the execution of the Episode Definer Routine, all the patient's episodes with an ETG which can shift based on the presence of a comorbidity and which are "turned on" are appropriately shifted to the ETG "with comorbidity".

A loop beginning at step 282 is then executed to determine whether the ETG assigned by the first diagnosis code should be shifted to another ETG based upon the second, third and fourth diagnoses on record. At step 282, the second diagnosis is read from the patient's claim record and all valid ETGs for the second diagnosis are read from the dx-ETG table 201. A logical operand 284 is executed to determine whether one of the valid ETGs for the second diagnosis matches the primary diagnosis ETG. If a negative response is returned to logical operand 284, a loop back at step 285 is executed to step 282 for the next sequential diagnosis code on record, i.e., the third and forth diagnosis codes on record. If an affirmative response is returned to the logical operand 284, the a logical operand 286 queries the table value of the matched ETG to determine if a value of A is returned from the dx-ETG table. If a negative response is returned, the loop back step 285 is initialized. If an affirmative response is returned, the first dx ETG is flagged for change to a second dx ETG having an equivalent table value of C for the second diagnosis code on record at step 288 and all valid ETGs for the current diagnosis code on record are identified at step 290 from the dx-ETG table. The identified C-value ETG is then matched with any open active ETGs at step 292. Program operation then continues at bridge H 292 to FIG. 4D.

At FIG. 4D the continued operation of the Management Grouping Sub-routine from bridge H 292 of FIG. 4C. Logical operand 296 queries the open active ETGs to determine whether a valid match with the identified C-value ETG exists. If a negative response is returned to logical operand 296, a value of 1 is added to the sequential episode count at step 297 and a new episode having a P value ETG is started in the patient's master active ETG file at step 299. The new episode is written with a sequential episode number, DOS-from and DOS-to values and forms a phantom management record. A phantom record is an anchor record, management or surgery, with more than one diagnosis, which is assigned to one episode and its corresponding ETG based on one diagnosis, but can start a new episode(s) or update the most recent date of another active episode(s) based on other diagnoses on the record.

If an affirmative response is returned from logical operand 296, the matched active ETG with the most recent DOS-to value is selected at step 298. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. The selected ETG's most recent DOS-to and sequential anchor count are updated in the patient's master active ETG file in step 300.

For either the new episode created at step 299 or the updated ETG from step 300, the patient's co-morbidity file is then updated with the second diagnosis code on-record at step 302. Processing then continues to identify all valid ETGs for a third diagnosis code on record at step 304 and the identified valid ETGs from step 304 are compared to the active ETGs in the patient's master active ETG file in step 306.

Bridge I 308 continues to FIG. 4E, and a logical operand 310 is executed to query the patient's master active ETG file to determine whether a match exists between the valid ETGs identified in step 304 with any active ETG from the patients master active ETG file. If a negative response is returned to logical operand 310, a value of 1 is added to the sequential episode count at step 311 and a new episode having a P value ETG is started in the patient's master active ETG file at step 313. The new episode,is written with a sequential episode number, DOS-from and DOS-to values and forms a phantom management record.

If an affirmative response is returned from logical operand 310, the matched active ETG with the most recent DOS-to value is selected at step 312. Again a decisional hierarchy is executed. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. The selected ETG's most recent DOS-to and sequential anchor count are updated in the patient's master active ETG file in step 314.

For either the new episode created at step 311 or the updated ETG from step 314, the patient's co-morbidity file is then updated with the third diagnosis code on-record at step 316. Processing then continues to identify all valid ETGs for a fourth diagnosis code on record at step 318 and the identified valid ETGs from step 3318 are compared to the active ETGs in the patient's master active ETG file in step 320. Bridge reference I 322, bridges to FIG. 4F.

Turning to FIG. 4F, a logical operand 324 is executed to query the patient's master active ETG file to determine whether a match exists between the valid ETGs identified in step 320 with any active ETG from the patients master active ETG file. If a negative response is returned to logical operand 324, a value of 1 is added to the sequential episode count at step 325 and a new episode having a P value ETG is started in the patient's master active ETG file at step 337. The new episode is written with a sequential episode number, DOS-from and DOS-to values and forms a phantom management record.

If an affirmative response is returned from logical operand 324, the matched active ETG with the most recent DOS-to value is selected at step 326. Again a decisional hierarchy is executed. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. The selected ETG's most recent DOS-to and sequential anchor count are updated in the patient's master active ETG file in step 328.

For either the new episode created at step 337 or the updated ETG from step 324, the patient's co-morbidity file is then updated with the fourth diagnosis code on-record at step 330. A check is then made to determine whether the processed record is the last record for the patient by execution of logical operand 332 and reading the input claim records from the storage means. If logical operand 332 returns an affirmative value, the ETG Definer Sub-routine is called at step 334, as represented by bridge reference GG. If, however, a negative response is returned to logical operand 332, program execution returns to the step 204 of the Episode Assignor routine 200 and the next patient claim record is read from the storage means.

Grouping of Surgery Records to ETGs is governed by the Surgery Record Grouping Sub-routine 400, the operation of which is illustrated in FIGS. 5A-5D.

For those patient claim records identified as Surgery Records at step 208, the DOS-from value on-record is compared with the DOS-to value read from the patient master active ETG file at step 402. This identifies and flags those active ETGs which are to be closed, the flagged ETGs are then moved to the patient master closed ETG file. The first diagnosis code on-record is then read and compared to the dx-ETG table 201 to identify all possible valid ETGs for the first diagnosis code on-record in step 404.

Surgery records are coded with treatment codes (CPT codes). Each surgery record has a single CPT code value. The CPT code on-record is then read, and compared to a CPT by ETG table 401 previously written to the storage means. The CPT-ETG table will have pre-determined table values. For example, in accordance with the preferred embodiment of the invention, the CPT-ETG table 401 has table values of R, W and X, where R is a value shiftable to W and X is a validator value. All valid ETGs for the on-record CPT code are identified by this comparison at step 406. A logical operand 408 is then executed to determine whether there is a match of valid ETGs returned from the dx-ETG table 201 and the CPT-ETG table 401. If an affirmative response is returned to logical operand 408, a second logical operand 410 is executed to determine whether a match of valid specific ETGs exists. Again, if an affirmative response is returned from second logical operand 410, the valid specific ETGs matched in step 410 are then compared at step 414 with the open active ETGs for the patient read from the patient's master active ETG file at step 412. If an affirmative response is returned from step 414, the matched ETG with the most recent DOS-to is selected at step 416 and a value of 1 is added to the sequential anchor count in the selected ETG at step 418. In step 416, if a tie is found based upon most recent DOS-to values, then a decisional hierarchy is followed to select the most recent DOS-from value for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched.

If a negative response is returned to any of logical operands 408, 410 or 414, second, third and fourth dx codes on-record are read and all possible valid ETGs are read in step 411 from the dx-ETG table 201. Further processing of the valid ETGs output from step 411 is continued at FIG. 5B identified by bridge reference P, 413.

Turning to FIG. 5B, a logical operand 415 compares the valid ETGs for the second, third and fourth dx codes with the valid ETGs for the CPT code on-record in step 411. If a negative response is returned from logical operand 415, the patient claim record is assigned to an ETG reserved for match errors between dx code and CPT code, e.g., ETG 998, and further processing of the match error ETG bridges at reference R, 431, to FIG. 5D.

If an affirmative response is returned from logical operand 415, the matched ETGs are compared with active ETGs read from the patient master active ETG file at step 417 and logical operand 419 is executed at step 419 to determine whether any valid matches between matched ETGs and active ETGs. If a negative response is returned to logical operand 419, a value of 1 is added to the sequential anchor count and to the sequential episode count at step 425 and a new episode is started at step 437 with the first dx code on-record having a P value for a specific ETG in the dx-ETG table 201. If no specific ETG has a P value, a non-specific ETG having a P value for the dx code on record is used to start the new episode. The new episode is started by writing the sequential episode number, the sequential anchor count, the DOS-from and the DOS-to values on the record.

If an affirmative response is returned from logical operand 419, the matched specific ETG with the most recent DOS-to is selected at step 421. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. A value of 1 is added to the sequential anchor count at step 423. Processing the new episode started at step 427 or of the selected matched specific ETG at step 421 continues to bridge Q, 420, continued at FIG. 5C.

Turning to FIG. 5C, bridged from reference Q, 420, logical operand 422 is executed which reads the CPT-ETG table 401 and determines the table value of the selected ETG from step 421 and step 427 based on the CPT value on-record. If a table value of R is returned from the read of the CPT-ETG table 401 at step 422, the matched ETG in the master active ETG file is shifted at step 424 to the ETG with an equivalent value of W for the CPT code on-record. If a table value of X or W is returned from step 422 or from step 242, the dx-ETG table 201 is read at step 426 and the dx code for the selected matched ETG from the CPT-ETG table 401 or the shifted ETG from step 424 is read. From the dx-ETG table 201, if a value of S is returned, the matched ETG in the patient master active ETG file is shifted at step 428 to the ETG with a table value of P for the dx code on-record. If a table value of A is returned, the matched ETG in the patient master active ETG file is changed in step 430 to an equivalent value of C for the dx code on-record. If a table value of P, I or C is returned either from logical operand 426, or from the ETG change step 428 or the ETG shift step 430, the DOS-to and the sequential anchor count of the ETG in the patient master active ETG file are updated in step 432. The patient claim record is then assigned and written with the sequential episode number and the sequential anchor count of the selected ETG at step 434. The patient comorbidity file is then updated with all diagnosis codes on-record at step 436.

FIG. 5D bridges from FIG. 5C with bridge reference BB, 438. In FIG. 5D, the diagnosis codes on-record which were not used in the ETG selection described above, are then read from the patient claim record to identify all possible valid ETGs in the dx-ETG table 201. The identified possible valid ETGs are then matched against the patient master active ETG file in step 442 and logical operand 444 is executed to validate the matches. If an affirmative response is returned to logical operand 444, for each matched dx code on-record, the matched active ETG with the most recent DOS-to is selected at step 446. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. The selected ETG's most recent DOS-to value is updated to the date of the patient medical claim, and the sequential anchor count in the active ETG is updated in step 448.

If a negative response is returned to logical operand 444, a value of 1 is added to sequential episode count at step 456 and a new episode having a P value ETG is started in the patient's master active ETG file at step 458. The new episode is written with a sequential episode number, DOS-from and DOS-to values and forms a phantom surgery record. If an affirmative response is returned to logical operand 444, the matched active ETG for each diagnosis code is selected at step 446 on the basis of the most recent DOS-to value. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. The DOS-to field of the selected ETG from step 446 is updated in step 448 to the date of service on-record and the sequential anchor count in the active ETG file is updated. From either step 458 or from step 448, the patient co-morbidity file is updated to reference the selected ETG and a check is made to determine whether the patient claim record processed in step 429, which assigned an invalid dx-CPT code match to the record, or from step 450, which updated the co-morbidity file, is the last record for the patient at logical operand 462. If an affirmative response is returned to logical operand 462, record processing proceeds to the Episode Definer Sub-routine at step 464, bridged reference GG, to FIG. 9. If, however, a negative response is returned to logical operand 462, a loop back 468 to the beginning of the ETG Assigner routine 200 is executed and the next patient claim record is read.

The Facility Record Grouping Sub-routine 500 assigns facility records to ETGs on the basis of diagnosis codes on-record. The patient claim record is read and the first diagnosis code on-record is read to the dx-ETG table 201 to identify all valid ETGs for the first dx code at step 502. The identified valid ETGs are then compared to the open active ETGs in the patient master active ETG file in step 504. Logical operand 506 executes to determine whether any valid matches exist between identified ETGs for the dx code and the active ETGs for the patient. If a negative response is returned to step 506, a value of 1 is added to the sequential episode count at step 507 and a new episode is started in step 509 in the patient active ETG file with the ETG corresponding to the dx-ETG table value of P. If logical operand 507 returns an affirmative response, a query of the matched ETG value is made at step 508 to determine whether the matched ETG has a table value of P, C, A or S. If a negative response is returned to step 508, the matched active ETG with the most recent DOS-from value is selected at step 511. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. If an affirmative response is returned at step 508, the table value of the matched ETG table value is identified at step 510. If the table value for the matched ETG in the dx-ETG table 201 is S, the matched ETG is shifted at step 514 to the ETG having a table value of P for the dx code. If the table value for the matched ETG returns a value of A, the matched ETG in the patient master active ETG file is changed at step 512 to an ETG having an equivalent table value of C for the dx code. If a table value of either P or C is returned at step 510, the most recent DOS-to is updated at step 516 in the ETG to the on-record claim date. Further processing of the claim record from steps 509, 511 and 516 bridges at reference 1, 520, to FIG. 6B.

Turning to FIG. 6B, bridged from reference 1, 520, in FIG. 6A, the patient's co-morbidity file is updated with the first dx code at step 522. A loop beginning at step 524 is then executed to determine whether the ETG assigned by the first diagnosis code should be shifted to another ETG based upon the second, third and fourth diagnoses on record. At step 524, the second diagnosis is read from the patient's claim record and all valid ETGs for the second diagnosis are read from the dx-ETG table 201. A logical operand 526 is executed to determine whether one of the valid ETGs for the second diagnosis matches the primary diagnosis ETG. If a negative response is returned to logical operand 526, a loop back at step 527 is executed to step 524 for the next sequential diagnosis code on record, i.e., the third and forth diagnosis codes on record. If an affirmative response is returned to the logical operand 524, the logical operand 528 queries the table value of the matched ETG to determine if a value of A is returned from the dx-ETG table. If a negative response is returned, the loop back step 527 is initialized. If an affirmative response is returned, the first dx ETG is flagged for change to a second dx ETG having an equivalent table value of C for the second diagnosis code on record at step 530. All valid ETGs for the second diagnosis code on record are identified at step 532 from the dx-ETG table. The identified ETGs are then matched with any open active ETGs at step 532. Program operation then continues at bridge 2, 536 to FIG. 6C.

At FIG. 6C the continued operation of the Facility Record Grouping Sub-routine 500 from bridge 2 of FIG. 6b is illustrated. Logical operand 538 queries the open active ETGs to determine whether a valid match with the identified ETGs exists. If a negative response is returned to logical operand 538, the patient co-morbidity file is updated with the second diagnosis code at step 544. If an affirmative response is returned from logical operand 538, the matched active ETG with the most recent DOS-to value is selected at step 540. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. The selected ETG's most recent DOS-to and sequential anchor count are updated in the patient's master active ETG file in step 542.

Processing then continues to identify all valid ETGs for a third diagnosis code on record at step 546 and the identified valid ETGs from step 546 are compared to the active ETGs in the patient's master active ETG file in step 548.

Bridge 3, 550, continues to FIG. 6D, and a logical operand 552 is executed to query the patient's master active ETG file to determine whether a match exists between the valid ETGs identified in step 548 with any active ETG from the patients master active ETG file. If a negative response is returned to logical operand 538, the patient's comorbidity file is updated with the third diagnosis code at 558.

If an affirmative response is returned from logical operand 552, the matched active ETG with the most recent DOS-to value is selected at step 554. Again a decisional hierarchy is executed. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched.

The patient's co-morbidity file is then updated with the third diagnosis code on-record at step 558. Processing then continues to identify all valid ETGs for a fourth diagnosis code on record at step 560 and the identified valid ETGs from step 3318 are compared to the active ETGs in the patient's master active ETG file in step 562. Bridge reference 4, 564, bridges to FIG. 6D.

Turning to FIG. 6D, a logical operand 566 is executed to query the patient's master active ETG file to determine whether a match exists between the valid ETGs identified in step 562 with any active ETG from the patients master active ETG file. If a negative response is returned to logical operand 566, the patient's comorbidity file is updated with the fourth diagnosis code.

If an affirmative response is returned from logical operand 566, the matched active ETG with the most recent DOS-to value is selected at step 568. In the event of a tie, a decisional hierarchy is executed. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected and matched. The selected ETG's most recent DOS-to are updated in the patient's master active ETG file in step 570 and the patient's co-morbidity file is then updated with the fourth diagnosis code on-record at step 572. A check is then made to determine whether the processed record is the last record for the patient by execution of logical operand 574 and reading the input claim records from the storage means. If logical operand 574 returns an affirmative value, the ETG Definer Sub-routine is called at step 576, as represented by bridge reference GG. If, however, a negative response is returned to logical operand 574, program execution returns to the step 204 of the Episode Assignor routine 200 and the next patient claim record is read from the storage means at step 578.

Operation of the Ancillary Record Grouping Sub-routine 600 is illustrated in FIGS. 7A-7B. Like surgery records, ancillary records are grouped to ETGs on the basis of both dx codes and CPT code on record. First all valid ETGs for the treatment or CPT code on-record are identified in step 602 from the CPT-ETG table 401. Then all valid ETGs for the first dx code on record are identified in step 604 from the dx-ETG table 201. The ETGs from the CPT-ETG table 401 are then compared at step 606 to the ETGs from the dx-ETG table 201 and a logical operand 608 determines whether there is an ETG match. An affirmative response returned from logical operand 608 continues record processing at bridge D, 610, which continues on FIG. 7B. A negative response returned from logical operand 608 prompts a look up on the dx-ETG table to determine all valid ETGs for the second diagnosis code on record in step 611. Step 613 again compares the valid ETGs for the CPT code on record and with the valid ETGs for the second dx code on record and a logical operand 614 is executed to match the second dx code ETG with the CPT code ETG. Again, an affirmative response returned from logical operand 614 continues record processing at bridge D, 610, which continues on FIG. 7B. If a negative response is returned to logical operand 614, a look up on the dx-ETG table occurs to determine all valid ETGs for the third diagnosis code on record in step 615. Step 616 again compares the valid ETGs for the CPT code on record and with the valid ETGs for the third dx code on-record, which bridges E, 619, to FIG. 7B for identification of all valid ETGs for the fourth dx code on-record at step 625.

Step 627 then compares the valid ETGs for the CPT code on record and with the valid ETGs for the fourth dx code on record and a logical operand 629 is executed to match the fourth dx code ETG with the CPT code ETG. An affirmative response returned from logical operand 629 continues to step 616 which compares the matched ETGs with the ETGs in the patient master active ETG file and a query is made at logical operand 618 to determine whether any valid matches exist. If a negative response is returned to logical operand 629, the record is output to the ETG reserved for a CPT code-dx code mismatch at step 631 and a check is made at step 635 to determine whether the record is the last record for the patient.

If a match is found between the matched ETGs from the dx code-CPT code comparison in step 616. The matched active ETG with the most recent DOS-to value is selected. In the event of a tie, a decisional hierarchy is executed. If a tie is found based upon most recent DOS-to values, then the most recent DOS-from value is selected for matching with active ETGs. If a tie is found at most recent DOS-from values is found, the first encountered ETG is selected. The sequential episode number of the selected ETG is assigned to the record and the most recent sequential anchor count of the episode from the active ETG file is assigned to the record at step 622.

If the response to logical operand 618 is negative, the record is assigned to an orphan record ETG at step 633 and maintained in the claims records until subsequent record processing either matches the record to an ETG or the orphan record DOS-from exceeds a one-year time period, at which time the record is output to an error log file.

A check is then made to determine whether this record is the last record for the patient at step 635. If logical operand 635 returns an affirmative value, the ETG Definer Sub-routine is called at step 642, as represented by bridge reference GG. If, however, a negative response is returned to logical operand 635, program execution returns to the step 204 of the Episode Assignor routine 200 and the next patient claim record is read from the storage means at step 644.

FIGS. 8A-8C illustrate the operation of the Drug Record Grouping Sub-routine 700. Drug Record Grouping Sub-routine 700 references two predetermined tables previously written to the storage means. The first of the tables is a National Drug Code (NDC) by Generic Drug Code (GDC) table 800. This table acts as a translator table to translate a large number of NDCs to a smaller set of GDCs. A second pre-defined table is employed and is constructed as a GDC by ETG table 900. The GDC by ETG table is used, in conjunction with the NDC by GDC translator table, to identify all valid ETGs for a particular NDC code in the claim record.

Once identified as a drug record in the initial operation of the Episode Assignor Routine 200, the drug record is read from storage to memory in step 702. The NDC code on-record is converted to a GDC code by reading from the NDC-GDC table 800 in step 704. Using the GDC number so identified, all possible valid ETGs for the GDC code are identified in step 706. The possible valid ETGs for the GDC code are then compared to the patient master active ETG file in step 708. Following bridge LL, 710, to FIG. 8B, a logical operand is executed in step 712 based upon the comparison executed in step 708, to determine whether a match occurs having a table value of P, A, C or S.

If a negative response is returned to logical operand 712, a check is made to determine whether a match having table value I in the GDC-ETG table 900 exists in step 713. If another negative resonse is returned to logical operand 713, the record is flagged an orphan drug record and assigned to an orphan drug record ETG in step 715. If an affirmative response is returned to logical operand 713, the ETG with the highest second value is selected in step 718 (e.g. I1, I2, I3 and so on). If more than one ETG having the highest second value exists, the ETG having the most recent DOS-from value is selected. If a tie is again encountered, the first encountered ETG is selected. A sequential episode number and the most recent sequential anchor count of the episode from the patient master active ETG file is assigned to the drug record for the selected ETG in step 720.

If an affirmative response is returned to logical operand 712, the ETG having the highest second value, in order of P, S, A, C is selected in step 714 (e.g. P1, then P2 . . . then S1, then S2 . . . and so on). The record is then assigned a sequential episode number of the selected ETG and the most recent sequential anchor count of the episode from the patient master active ETG file in step 716.

Further processing of the drug record continues from steps 716, 715 and 720 through bridge MM, 724 and is described with reference to FIG. 8C. A check is made in step 726 to determine whether the drug record is the last drug record for the patient on the record date. If a negative response is returned, a loop back to the top of the Drug Record Grouping Sub-routine 700 is executed. If an affirmative response is returned at step 726, a check is made to determine whether the drug record is the last record for the patient in step 728. If logical operand 728 returns an affirmative value, the ETG Definer Sub-routine is called at step 732, as represented by bridge reference GG. If, however, a negative response is returned to logical operand 728, program execution returns to the step 204 of the Episode Assignor routine 200 and the next patient claim record is read from the storage means at step 730.

The Episode Definer Sub-routine is illustrated with reference to FIG. 9. Episode Definer Routine 118 is employed to assign all non-specific claims records, i.e., those initially assigned to ETG 900, to specific more appropriate ETGs. Episode Definer routine 750. Once all episodes have been grouped to ETGs, all ETG episodes in both active and closed ETGs are then identified in step 752 by patient age and presence or absence of a comorbidity. The ETG number for each episode is then shifted and re-written to an ETG appropriate for the patient age and/or presence or absence of a comorbidity in step 754. All patient records are then output in step 756 to the display, to a file or to a printer, along with their shifted ETG number, sequential episode number of the record and in patient master active and closed ETG file for the patient. The Episode Definer routine 750 then writes a single record at step 758 for each episode containing key analytical information, for example: the ETG number, patient age, patient sex, the sequential episode number, the total sum charges, the total sum paid, the earliest anchor record DOS-from value, the last anchor record DOS-to value, patient identification, physician identification, management charges, management charges paid, surgery charges, surgery charges paid, ancillary charges, and ancillary charges paid.

After the single record for each episode is written in step 758 for the patient, processing for the next patient begins by initialization of the next patient master active and closed ETG file, the next patient co-morbidity file, and the patient age file in step 760 and the Eligible Record Check Routine is reinitiated for processing claims records for the next patient at step 762.

FIG. 10 provides an example of a hypothetical time line for a single patient over a one year duration from January, 1995 to December, 1995. FIG. 10 depicts time frames of occurrences for claims classified as management records, i.e., office visit 84, hospital or emergency room visit 85, and surgery and surgical follow-up 86 and for claims records classified as ancillary records, i.e., laboratory tests 87, X-ray and laboratory tests 88 and x-ray 89. Two time lines are provided. A first timeline 71 includes the diagnosis and the time duration of the diagnosed clinical condition. A second timeline 72 includes the claim events which gave rise to the medical claims. Where claim events occur more than once, an alphabetic designator is added to the reference numeral to denote chronological order of the event. For example, the first office visit is denoted 84a, the second office visit is denoted 84b, the third denoted 84c, etc.

A first office visit 84a resulted in a diagnosis of bronchitis. Office visit 84a started an episode for this patient based upon the bronchitis diagnosis. A second office visit resulted in a diagnosis of eye infection.

It will be apparent to those skilled in the art, that the foregoing detailed description of the preferred embodiment of the present invention is representative of a type of health care system within the scope and spirit of the present invention. Further, those skilled in the art will recognize that various changes and modifications may be made without departing from the true spirit and scope of the present invention. Those skilled in the art will recognize that the invention is not limited to the specifics as shown here, but is claimed in any form or modification falling within the scope of the appended claims. For that reason, the scope of the present invention is set forth in the following claims.