KR19980025157A - Disease Management Methods and Systems - Google Patents

Abstract

The disease management system and method includes a patient medical information source 100, a predictive health outcome modeling process 102, a patient's coordination process 103, and a disease management modeling guide 104. Patient Medical Information 101 is a database containing medical records of patients participating in the provider's program. The predictive health outcome modeling process 102 generates a statistical model that is used to predict whether a patient with a particular disease is likely to suffer from poor health outcomes. The process of coordination of patients at risk 103 obtains a list of patients at high risk, who are at high risk of suffering from poor health outcomes, and adjusts in the medical treatment of selected patients to reduce the likelihood of such bad health outcomes. The predictive health outcome modeling process 102 comprises: 1) scheduled statistical information for obtaining a sample group of patient medical data from a patient medical information database 100 for a given disease, and 2) generating a predictive model represented by modeling instructions 104. 3) measure the likelihood of bad health outcomes by creating specific predictive models for specific diseases. The risk patient coordination process 103 1) receives the predictive model provided by the predictive health outcome modeling process 102, 2) analyzes specific medical data of the individual patient from the patient medical information database 100, and 3) Check the list of current patients at risk for bad health outcomes for the disease. The coordination process 103 of a patient at risk coordinates the treatment process of the patient included in the patient list through contact with the patient, doctor or health care provider, the process being externally related to the treatment ups for a given stage of disease progression. In addition to the information generated, certain adjustments are required.

Description

Disease Management Methods and Systems

Field of invention

FIELD OF THE INVENTION The present invention relates to electronic computer-aided processing techniques in the medical field of humans, and more particularly to disease coordination management using identification of patients at very risk for disease and various electronic computer-aided processing techniques.

Background of the Invention

In addition, by designing a program to maximize compliance with the current best medical practice consistent with a given preferred treatment method and on a case-by-case basis, the disease or disorder can be treated more effectively and cost-effectively. Treatment for many types of disease has changed from single symptomatic treatment to reduction and prevention of disease.

In general, medical costs rise rapidly, and in many cases, treating some patients is more expensive than treating others, so patient treatment costs are not evenly distributed across the entire population of patients. This is partly because some patients do not receive adequate treatment for their medical condition. These problems include the fact that some patients do not comply with their prescribed treatment methods, some patients do not visit doctors in a timely manner, and in some cases, some doctors may find that certain treatment methods are more effective than their current methods. There are several causes, including the fact that you do not know that they exist.

If a patient is treated according to a treatment method that is proven to be effective for a given state of disease progression, the total treatment cost of the entire population will decrease. If more patients are being treated properly, the number of cases that progress to more severe stages of the disease, which is more expensive to treat, will be reduced.

Summary of the Invention

The present invention is directed to a system and method using a computer for identifying a patient at risk, particularly a patient diagnosed with an identified disease, which extracts information about the patient from at least one pre-existing database. The system includes means for processing patient information in a database, based on certain criteria, to extract relevant information about a patient population that may have or manifest an identified disease.

System

a) processing patient information in a database based on a predetermined category to extract patient information for a patient group of identified diseases or disorders;

b) i) using the information available in the database to define a set of events or data related to the identified disease or condition;

ii) converting extracted patient information and defined events or data into a file containing event-level information;

iii) define a time window to provide a time frame for determining whether certain of the specified events should be considered in subsequent processing;

iv) identify a set of variables as valid predictors;

v) process the event-level information using a time window and a set of variables to generate an analysis file;

vi) a predictive model and a set of rules (both of which are variables) for performing statistical analysis on an analysis file to identify patients at risk of being diagnosed with an identified disease or condition, or who may develop such disease Defining a predictive model, the method comprising generating a subset of the set of?

c) Apply predictive models and rules to the same or new set of event-level information to identify patients at risk for identified diseases or conditions, or identify patients at risk of developing a identified disease or condition. To;

d) producing an adjustment list from the identified at risk patients and selecting adjustments for at least one risk patient;

e) distribute or facilitate the distribution for the patient; Randomly

f) recording and tracking adjustment results for each patient at risk based on the individual selected adjustments; Randomly

g) updating medical history data in at least one database with the result of each adjustment corresponding to the database; And

h) repeating step b (ii); And

i) Reapply the prediction model and rules to event-level information extracted from the data of the updated database to define the prediction model including the relevant rules.

The invention is best understood from the following detailed description in conjunction with the accompanying drawings.

1A is a high level diagram of the disease management system of the present invention.

1B is a high level flow chart illustrating an example of the overall process of the present invention.

2A is a high level flow chart illustrating raw patient data acquisition, pre-processing, and database formation.

2B is a high level block diagram illustrating three exemplary sources of information suitable for use with the present invention.

3 is an explanatory diagram of an embodiment of the conversion process of the raw patient data pre-processing method of the present invention.

4 is an explanatory diagram of an exemplary data model used in a disease management database of an embodiment of the invention.

5 is a diagram illustrating a survey database format for each Rx, DR, and HL claim of a record included in a survey database of an exemplary embodiment of the present invention.

6 is a high level flow chart illustrating the extraction process and predictive modeling process for the identified disease of the present invention.

7A is a diagram illustrating an event level file of one embodiment of the present invention generated for depression as a confirmed disease.

FIG. 7B is a diagram illustrating an event level file of one embodiment of the present invention generated for congestive heart failure as an identified disease.

8 is a diagram illustrating the format of an analysis file of one embodiment of the present invention for identified diseases.

9 is a timeline diagram illustrating an event and prediction window schematic used in the present invention.

FIG. 10A is a timeline diagram illustrating a first example of a time window diagram suitable for use in processing data from the event level file shown in FIGS. 7A and 7B.

FIG. 10B is a timeline diagram illustrating a second example of a time window diagram suitable for use in processing data from the event level file shown in FIGS. 7A and 7B.

FIG. 11 is a high level flow chart illustrating the risk grading process of the present invention, including a Front End process process and a Mining Engine process to produce a coordination list for identified diseases.

12 is a high level flow diagram illustrating a risk grading mining engine of the present invention.

Figure 13 is a high level diagram of the coordination management process of the present invention.

Detailed description of the invention

General overview

The disease management systems and methods of the present invention increase the number of patients who receive appropriate treatment for, adhere to, and precisely administer a disease or condition within a given population. The present invention requires identifying the desired therapy for certain stages of disease progression. This therapy may be published as a medical guideline or may be a guideline developed by a medical professional for a given type of disease. These guidelines are referred to as Best Practice Guidelines.

The term disease management is sponsored by a managed care group, medical group, user, or government that identifies, for example, individual patients with long-term chronic disease at risk of expensive hospitalization or other costly circumstances or bad health consequences. Applied to the program. Disease management services are defined as research areas combined with product development managers who serve as disease content specialists.

Disease management services are provided to sponsors (managed care organizations (MCOs) or other forms of subscribers) for the purpose of early coordination of specific disease states to improve future disease outcomes. Medical, clinical and managed medical history information of an individual is provided to the disease management system, for example, from a third processor.

The use of the disease management system of the present invention is described primarily in the medical field, in which the healthcare provider is the primary sponsor of the system, and information about the patients of these healthcare providers is a database for the practice of the present invention. Is provided. However, it should be understood that other embodiments of the present invention include other types of sponsors, such as users, government agencies, insurance providers or other users interested in managing or saving disease in a given population. Similarly, the information provided in the database of the disease management system can be expanded to include demographic data, socialization, geographic data, race history, or other information about the individual.

The basic disease management system will deal with one disease or disorder. However, multiple diseases or disorders can be factors in a single analysis and thus develop a risk profile based on multiple factors and multiple diseases or disorders. In essence, this approach is intended to consider each disease or disorder as a module that can be referenced as a field in a relevant database. It allows the analyst to rely on one or more diseases or disorders to develop risk factors for a given patient population.

Referring to FIG. 1A, a high level diagram of the disease management process of the present invention includes a patient medical information source 100, a predictive health outcome modeling process 102, a patient's coordination process 103, a disease management modeling guideline ( 104), and 105 of sources of coordination and medical guidance. The patient's risk coordination process 103 has two parts: a risk grading process 140 and a coordination management process 160. Patient medical information 101 typically includes, for example, a record of medical history, a doctor's prescription, a psychiatric record, laboratory test results, recognition and comprehension test data, prescription and treatment of a patient participating in a program of a healthcare provider. It is a form of database.

The predictive health outcome modeling process 102 of FIG. 1A is a process of creating a statistical model that can be used to predict whether a patient with a particular disease or disorder and medical history will suffer from poor health outcomes. The risk patient coordination process 103 is a risk assessment process 140, which is a database analysis process that obtains a list of patients at high risk of bad health outcomes, and to reduce the likelihood of such bad health outcomes. Health coordination management process 160 to determine coordination in the medical treatment of the selected patient.

The operation of the disease management method of the present invention as shown in FIG. 1A will now be described. First, predictive health outcome modeling process 102 receives a sample group of patient data from patient medical information database 100 for a given disease. In addition, the predictive health outcome modeling process 102 accommodates certain scheduled statistical or other information for generating the predictive model illustrated by the modeling guideline 104 of FIG. 1A and measures the likelihood of bad health outcomes. Create specific predictive models for specific diseases. This same or similar data can be used to determine the likelihood of developing a particular disease or condition associated with a poor health outcome.

The risk grading process 140 accepts the predictive model provided by the predictive health outcome modeling process 102 and uses the predictive model to determine a list of recent patients at risk of bad health outcomes. Analyze specific data of individual patients from 100). Once the list of patients is identified, the coordination management process 160 suggests coordination to the patient's treatment through contact with the patient, doctor or healthcare provider. The coordination process 103 of a patient at risk requires externally provided information regarding the treatment (eg, best practice guideline) for a given step, shown as the coordination and medical guideline 105 of FIG. 1A.

Finally, the adjustment itself can be recorded, and once the adjustment process 103 of the patient at risk is completed, these adjustment results, shown as adjustment result measurements in FIG. 1A, are recorded in the patient medical information database 100. This takes into account the feedback step, where the data after adjustment is fed back through the whole process, which is part of the basis for driving back through the risk grading step or creating a calibrated new risk grading process to assist in analyzing the results. do.

In summary, the disease management system analyzes the flow of individual patient-specific health information and adjusts the doctor or patient whenever necessary to attempt to avoid bad health outcomes and therefore expensive situations. Disease management,

1) Identify the program patient registrants and sponsor tissues that are based on the specific planned disease state obtained from the study data,

2) assess disease status using medical claims, pharmaceutical claims, clinical and laboratory data,

3) Manage the program using scheduled coordination (examples of coordination include mailing periodic notifications, mailing disease education materials, responding to telephone surveys with patients subscribed, or balanced international calls by staff of medical professionals. has exist),

4) The process is managed by a protection program manager who makes the necessary adjustments to the sponsor (eg MCO, healthcare provider), doctors and patients,

5) record patient health adjustments to determine if advance disease management services improve outcomes of specific diseases;

6) reprocessing the adjustment management information through an analysis process to measure the outcome of the adjustment.

In the method of the present invention, a case program manager (not shown in FIG. 1A but whose function is shown as part of the case management process 150 of FIG. 1B described below) may be used to treat patients who are likely to benefit from a doctor changing the therapy. Facilitate the treatment of patients by allowing them to identify them, suggest treatments to their doctors, and provide them with the help of training and compliance with treatment (with the consent of the treating physician). Case program managers do not diagnose or prescribe treatment. Medical diagnosis and treatment are the inherent responsibility of a qualified physician.

By using the method of the present invention, the case program manager identifies a population of patients to be treated, and more importantly, to patients who have not been treated with a preferred treatment for the disease state of the patient. Such patient populations are highly relevant to the present invention, where treatments of patients who do not receive the desired treatment from these populations are automatically identified, affecting habits, or influencing the recommended treatment.

In the following description of the present invention, for convenience, the case program manager is obtained from the modeling guideline 104 for the predictive health outcome modeling process 102, and the coordination and medical care of the patient's coordination process 103. It is shown as the sole source of external information, such as that obtained from tutorial 105.

In general, most functions of the case program manager are automated and implemented by, for example, provided computer systems. However, the end-user can provide external information disclosed as a disease management program, provide changed or new parameters to an experience-based disease management program, or change coordination techniques as needed.

In most embodiments of the present invention, the role of case program manager is divided into various persons or entities. For example, one case management presence may identify a patient at risk of becoming a costly patient, another may contact the doctor with this information and treatment advice, as well as the patient's educational materials and treatment compliance devices, The third being can also be in direct contact with the physician. Another entity may be responsible for managing the identification of statistical information and the generation of predictive models. As a result of carrying out the method of the present invention, more patients may receive adequate treatment than otherwise, resulting in fewer patients suffering from severe disease progression that requires special and expensive protection.

The methods of the present invention typically include at least lifelong treatment physicians. In one preferred embodiment, including about 100 treating physicians, it is effective to include a larger number of physicians, such as 250 to 500 or more physicians.

Disease management system

A high level flow chart of the disease management system of the present invention is shown in FIG. 1B. 1B, the disease management system has a disease management data storage system 101 including a patient data collection and integration process 110 and a disease management database 120. This is where event-level information exists. Next, the disease management system includes a predictive modeling process 130, a risk grading process 140, a coordination management process 160, and a coordination recording and tracking process 170.

The case management process 150 receives coordination information from the coordination management process 160 and receives results from the coordination recording and tracking process 170. Case manager 150 provides externally obtained information to predictive modeling process 130 and risk grading process 140.

The disease management data storage system 101 includes a patient data collection and integration process 110 and a disease management database 120. The patient data collection and consolidation process 110 receives raw patient data from a medical source, processes the raw patient data to remove excess information, and formats the original patient data into a conventional predetermined format. Initially, one or more sources of information are needed that consider the identification of the initial patient population.

Typical sources of raw patient data may include, for example, health care providers such as doctors, hospitals, pharmacists, other health care providers, and payers who pay for all recorded services for their patients. However, these records are distributed, difficult to access, have a difficult format and have duplicate or inappropriate information. Thus, an accessible source for such information exists in the medical claim record of a given benefit provider. These medical claim records are used in one example of the present invention.

The patient data collection and consolidation process 110 stores the formatted patient information in the disease management database 120, which is a database that stores medical records, clinical records, or other records of patients used in the present invention.

The predictive modeling process 130 of the present invention uses the identified disease, statistical limitations, and simple patient databases to produce predictive models and rules that can identify patients at high risk of poor health outcomes from a pre-determined and identified population of disease patients. Use The term identified disease, as used herein, means a specific disease of interest to the sponsor, such as asthma, depression, or congestive heart failure (CHF).

The risk grading process 140 of FIG. 1B applies statistical predictive models and rules to patient data obtained from the disease management database 120, corresponding to a group of patients selected from the disease management database 120 based on predetermined criteria. . The intended criteria may be, for example, all client (MCO) patients or all new employees. The risk grading process 140 identifies a subgroup of patients at risk and produces a list of adjustments from this subgroup.

The coordination management process 160 plans and performs coordination for each identified patient on the coordination list, such as outgoing letters or training materials sent to these patients at risk, and by telephone or home visit. Finally, the adjustment record and tracking process 170 keeps a record of adjustments made and their effects.

The operation of the disease management system as illustrated in FIG. 1B will now be described.

First, certain diseases of interest, and other predetermined limitations, are identified by the case management process 150. Identified diseases and limitations are supplied to the predictive modeling process 130. The predictive modeling process 130 receives a subpopulation of medical data of the patient from the disease management database 120 that corresponds to the patient with the identified disease and meets other predetermined statistical criteria determined from the study data. The predictive modeling process 130 then calculates the predictive models and rules from a subpopulation of medical data of the patients that can identify patients at risk of bad health outcomes from the expected and confirmed population of disease patients.

The risk grading process 140 accepts the predictive models and rules output from the predictive modeling process 130, and further the rules obtained from the case management process 150. Based on the information provided by the case management process 150, the medical and clinical information about the patient population contained in the disease management database 120 is retrieved, and the patient population is the confirmed disease patient population of the intended sponsor. The risk grading process 140 then uses predictive models and rules to identify a very dangerous subpopulation of the patient from the identified disease patient population of the intended sponsor at risk of bad health outcomes.

Identification of high-risk subgroups is a subject matter defined by the operator. This is not to be forced. For example, a high risk can be determined based on the disease or the severity of the disease. Alternatively, this may be driven by available means, where there may be quite a few means available for the cost of providing a useful adjustment. A classic example of high risk is a screening approach used to address major variability, which does not treat patients who will die anyway, does not treat patients who will survive anyway, and the available adjustments may lead to a reduction in survival or permanent inability. Treat patients who can. Another example is to define a high-risk subgroup by including a certain percentage of the total group based on how many patients a particular operation can handle. In this way, if the output of a particular system can handle or manage coordination in 1000 patients on a given day, the 1000 most needed in the total population will be defined as high-risk subgroups. In a similar manner, the coordinator may have enough money to usefully coordinate 1000 patients in 6 months. By this definition, the 1,000 most dangerous are the high-risk subgroups. Another example is that the clinical outcome is a useful outcome, rated one to five, which should be treated as a high-risk, subgroup that is likely to have good outcomes of three or more grades. You may also use age and the likelihood of adverse outcomes, or positive outcomes, in defining a high-risk subgroup. For example, it may be determined to define a high risk as women with a history of estrogen dependent disease and who are menopausal. In addition, two or more of these factors may be usefully combined in calculating algorithms for identifying high-risk subpopulations. However, these are just a few examples of how high risk is defined.

Although this step has been described as identifying one high-risk subgroup, it should be noted that a graded level of coordination can also be defined and factored in the analysis. So rather than defining a high-risk subgroup, we define a set of subgroups that each follow a specific risk factor, and then make adjustments to a subset of the selected set based on the different levels of risk accessed.

Once a high-risk subgroup, or a set of target subgroups, is identified, the risk grading process 140 produces a list of adjustments to rank patients according to predetermined criteria. The coordination list is used by the coordination management process 160 of the present invention to plan and perform coordination, such as outgoing letters or training materials sent to patients at high risk, and telephone or home visits to prevent and / or prevent their health outcomes. Improve).

Coordination management process 160 receives data supplied from disease management database 120, which is the sponsor's confirmed disease patient data normalized to the disease management data storage format. This data supply or detection process has the parameters and rules accepted from the case management process 150 to identify specific patients that satisfy the disease to participate in the disease program. This detection process provides a population taking into account specific identified disease programs.

The coordination management process 160 also passes coordination contact data back to the main disease management database 120 and the coordination list back to the case management process 150. Such coordination contact data is used, for example, in an analytical process to measure the success of certain types of coordination.

The reconciliation record and tracking system 170 maintains a record of the reconciliations and their effects, from which the case management process 150 is guided for reconciliation, as well as external information used by the predictive modeling process 130, and You can update the best practice guideline to improve treatment for identified diseases.

As illustrated in FIG. 1B in the sections below, each process of the disease management system of the present invention is described in detail.

Disease Management Data Retention and Data Integration

Disease management data storage 101 is described with reference to FIG. 2A, which is a high level flow chart illustrating raw patient data acquisition, preliminary processing, and database formation of the present invention. The disease management data archive 101 includes a patient data collection and integration process 110, a disease management database 120, and an investigation database 250.

The patient data collection and consolidation process 110 includes a reimbursement claim source 200 as a data source, an original patient data preprocessing process 210 to clean up original patient data, a conversion process 220 to convert the raw data into a predetermined format, and Update patient data process 230 for updating patient information due to subsequent events or coordination (also called event level information).

In the patient data collection and integration process 110, the reimbursement claim source 200 provides raw patient data to the original patient data preprocessing algorithm. Examples of sources of information that enable population identification of patients who have recently received medical treatment are the clinical and health claims records of many health care providers. As is known, claims for drug reimbursement, physician visits, hospitalizations and laboratory tests are filed and processed for compensation / reimbursement. In an example of embodiment of the present invention, such claim information is entered into DB2 or Sybase, for example, on a computer system (not shown).

However, the present invention is not limited to this reimbursement claim source 200 as shown. Another embodiment of the present invention includes demographic data; Sociological data; A disease management database can be created using data relating to individuals, such as personal data such as lifestyle, sexual or parental indifference or physical abuse, history of nutrition, geographic data, family history, or other data.

The method of the present invention is typically performed with the aid of an electronic database for storage and retrieval of data relating to an individual, such as medical data, demographic data, pharmacological data, diagnostic data, and treatment data, from a reimbursement claim source 200. For example, the following pharmacological data can be retrieved from redemption claims:

a) patient identifier

b) prescription medications

c) drug usage

d) amount of drug

e) duration of medication

f) Latest prescription drug refill / refill date

g) provider identifier

The data is preferably stored in machine reading form and can be recovered in a separate field of investigation recorded separately for each patient. Each record also preferably includes a chapter to determine whether one or more case management adjustments, as described herein, should be made. The data is stored in a computer and accessed through the ordered database usage software. The software provides the ability to investigate and report (display, print and electronic distribution).

2B is a high level block diagram illustrating three examples of information sources suitable for use in the present invention. As illustrated in FIG. 2B, the claim information of a particular provider typically includes three sources: pharmaceutical (Rx) claim 202, doctor (DR) claim 204, and hospital (HL) claim 206. As listed on the block representing claim information, many types of information may be obtained from each claim, including drug code, name of charge, diagnostic code, procedure, various dates, and other relevant information. Many of this information is represented using codes such as drug codes, procedure codes, and disease codes.

Continuing with FIG. 2A, the original patient information pre-processor 210 performs a data integration check to confirm and process the rejected or adjusted claims.

To use the database more effectively, the database usage subalgorithm (not shown) of the original patient data preprocessing algorithm 210 eliminates excessive introduction, eliminates the introduction of disqualified patients, and initiates case management coordination within a predetermined period of time. Have the ability to ignore recorded records.

Second, the conversion algorithm 220 reads the source data file and aggregates the disease management database 240 using patient information in a predetermined database format. The disease management database 240 of the present invention uses a seabase but may use any similar database product.

Finally, the update patient data process 230 of FIG. 2A receives coordination management information from the coordination management process 160 and the coordination recording and tracking process 170 to update the patient information in the disease management database 120. Contains information about adjustments related to the patient.

A more detailed flowchart of an exemplary embodiment of the conversion process 220 is shown in FIG. 3.

Referring to FIG. 3, file manager 310 accepts patient data files, verifies receipt files, verifies that they are suitable for processing, and stores information about each file in a file list database. If the file is hierarchical, the file manager 310 sends the file to the hierarchical file preprocessor to read the contents into a flat file. The flat file is then stored by the flat file processor 330 into the disease management database 240 using the information retained in the input table 340 and the output table 350. The patient data is then stored in the database using the data model.

4 illustrates an example of a data model used for patient data storage in an embodiment of the present invention. The data model includes a list of source data 410 that records aspects of introduction data during data creation, an exclusion manipulation process 420 that manipulates data exclusion during the creation process, a sponsor table 430 that holds a list of disease management provider sponsors, And a member table 440 including member specific confirmation information.

The data model also includes, for each member patient in the member table 440, a claim table 450, which is a record of health activity for each member, a laboratory table representing the institutions and relationships involved in collecting clinical test data for a given member. And a diagnosis and procedure table 470 that includes a record of relevant diagnostic and medical procedures for a given claim.

The organizational process of the data model is as follows. Referring to Figure 4, the source data list 410 records the progress and characteristics of the introduction data during the database creation process. Exclusion operation 420 manipulates data exclusion during the creation process. Exclusion may be caused by missing values, out-of-range values, or other errors in the data, and exclusion operation 420 discards the data when the exclusion occurs, maintains some of the data, or detects errors based on available information. Analyze resolves the exclusion. The source data list 410 provides the received client data to build a database with the client table 430.

The sponsor table 430 maintains a list of disease management provider sponsors, including patients, and further describes the systems and methods described herein. Each sponsor in the sponsor table 430 has a patient defined as a member in the member table 440. The member table 440 includes information such as member name, date of birth and gender.

Claim table 450 is maintained for each member patient in member table 440. In claim table 450, each claim is a record of health activity for a single member. For example, the recorded data item is the date on which the claim was initiated or resolved, the drug and prescription information, the details of the medical examination, the member's primary care officer or other physician and the corresponding services or procedures provided.

In addition, laboratory table 460 shows the institutions and relationships associated with laboratory test requirements, progress, and results that are made for a member. Recorded data items are, for example, blood tests, glucose tests or other tests based on a single analysis.

Finally, diagnosis and procedure table 470 records the primary and one or more secondary diagnoses for a given claim, denoted by ICD-9-CM code. Diagnosis can be classified into a diagnostic related group (DRG), which is one of 495 types of diagnosis in which patients exhibit similar resource consumption and retention pattern periods. Diagnosis and Procedures Table 470 also records the procedures corresponding to each diagnosis, and these procedures may be indicated as an outpatient CPT code, inpatient HCPCS, or other appropriate code.

Second, a specific database of identified diseases is created for the purpose of providing a database of confirmed disease patient data for the predictive modeling process 130. Referring again to FIG. 2A, this database is a survey database 250, which is a claim stage database having a predetermined format, such as the SAS format. Although the confirmed disease sample patient data used to create survey database 250 is provided by disease management database 120 in FIG. 2A, the present invention is not so limited, and survey database 250 may include suitable preliminary processing. Algorithm may be used to collect from the redemption claim source 200.

An exemplary format describing the survey database format for each of the Rx, DR, and HL claims of the records held in the survey database is shown in FIG. As shown in FIG. 5, claims are listed from claim 1 to claim x, and appropriate information is also presented if the particular service provider provided is claimed. The DB2 database also represents a source of raw data elements that require processing by the raw patient data pre-processing algorithm 210. Subsequently, the data is downloaded into survey database 250 in accordance with established procedures.

Predictive Model Creation

Returning to statistical predictive modeling, FIG. 6 is a high level flow chart illustrating a sample patient data extraction process and a predictive modeling process for a disease identified in accordance with the present invention. As shown in FIG. 6, the predictive modeling process 130 includes: 1) 610 of identified disease sample data extraction; 2) performing 620 a (optionally) quality control operation; 3) checking whether the data is statistically valid (630); 4) converting claim level data into event level data (640); 5) processing the event level file into an analysis file 650; And 6) processing the analysis file using statistical techniques to create identified disease prediction models and rules.

Referring to FIG. 6, the prediction model determination process begins with extraction of confirmed disease sample data, step 610. The extraction process of step 610 receives sample patient data from survey database 250, a disease identified from case management process 150, and if the data is converted to SAS format, then SAS processing processes the information to 1) verify. Extract the patient with a defined disease (step 610), 2) process the claim level information into event level information (step 640), and 3) generate an analysis file suitable for the purpose of the analysis using a predetermined variable and a timeframe diagram. (Step 650), and 4) build a predictive model as a function of their variables that best reflects the correlation to poor health outcomes (step 660).

An important consideration in developing a predictive model from a dataset in statistical prediction is the sample size. To maximize the completeness of the prediction model, a reasonable sample size is an important factor, and the sample size needed to determine the prediction equation depends on the size of the combination between the variables. Since this combination is unknown, all patients in any individual plan are included from the beginning.

The first step (step 610) of extracting a confirmed disease or diseased patient is to use the various variables provided by a case program manager, a research source, or another health professional to determine the total initial population of patients with confirmed disease to be considered. Define which patient is appropriate.

For example, in one exemplary aspect of the present invention, only patients who have a continuous enrollment with a benefit provider of at least 12 months and who have a claim for depression or a claim for treatment with an antidepressant are suitable. Of course, these criteria are exemplary and may be modified such that a 24 or 6 month registration is sufficient or that an individual must be 18 years old. In an exemplary aspect of the invention, the extraction of identified disease sample data (step 610) is used for the treatment of a patient or identified disease having a suitable code for the identified disease (eg, depression; see Appendix I). Extract all claim data for the next drug treatment (eg, antidepressant for depression; see Appendix III).

In the health industry, it should be recognized that various codes are used for claim information for processing, treatment, diagnosis, medication, etc. as required. For exemplary aspects of the invention, examples of selected codes are shown in Appendix I and II. These codes are described in Physician's Current Procedural Terminology (CPT), American Medical Association (1995) and in St. ICD-9-CM Code Book (1994) by Anthony, both of which are incorporated herein by reference as a source of code and teaching of their code. As will be appreciated by those skilled in the art, any set of codes representative of various treatments, treatments, diagnostics, drugs, and the like suitable for use with the present invention will all be sufficient. Such code is referred to throughout this specification.

Subsequent to the extraction process of step 610 of FIG. 6, claim adjustment and completeness checks are optionally performed at data quality management step 620. The quality control step 620 is optional such that patient data for the identified disease does not require the step or the original disease management database 120 has already been due to the original patient data preprocessing step 210. This is because it can be of sufficient quality (shown in Figure 2).

One method of quality control in step 620 generates an intermediate output file containing a set of frequencies suitable for processing purposes from the dataset. One exemplary aspect of the invention is an intermediate output file for review of the following features in the case of depression, such as an identified disease.

a. i) a table showing the number of members in the gender group, ii) a table showing the number of members in the age group, iii) a table showing the number of age groups grouped by gender, and iv) a table of enrollment periods (in months, i.e. from one month to the maximum possible number of months). Frequency of unique members by sex, age group (0-9, 10-19 ...) and enrollment period (monthly), inclusive.

b. The frequency of the ICD code for depression (Appendix I), ie the number of members having at least one for each of the ICD codes of any level ii) in Appendix I as the first code.

c. Frequency of antidepressants (Appendix II):

i) The number of members with one or more claims for each drug in Appendix III.

d. The number of members qualified for processing by both the ICD code and the drug, only by the ICD code, only by the drug.

e. Frequency of the number of all claims in each file (HL, DR, Rx) by member.

f. Frequency of any kind of ICD code (using only the first three numbers of ICD codes) in DR (any location) and HL files—two tables, each with at least the top 10, one for DR and HL files.

g. Hospitalization frequency by calendar months. Calendar months are counted backward from the last month of eligibility or data availability. The last month for which data is available will be January, the second month from the end, and so on.

h. Frequency of treatment related to depression (CPT Code, Appendix I-b)

i. Frequency of all CPT codes (up to the level of the first 3 code numbers)-at least the top 10.

The above frequencies for use in performing preliminary assessments, such as for completeness of data, are exemplary and may be modified by including / excluding parameters that appear more / less useful.

In another exemplary aspect of the invention, using congestive heart failure as the identified disease, the following frequencies occur:

A) First, the frequency of the number of registration periods for a member is calculated. Then, for members with multiple enrollment periods of at least 6 month periods, it is determined whether there is a CHF diagnosis in each enrollment period. Therefore, the registration period without CHF diagnosis is excluded, and for members with multiple registration periods with CHF diagnosis, only the latest registration period including CHF diagnosis is preserved.

B) During one registration period for all remaining members, identify the ALL COSTS for the members during the entire registration. A complete proc univariate for ALL COSTS is provided separately for each plan and for all plans. It should be noted that Flock Univariate is a SAS procedure that yields descriptive statistics (eg, mean, standard deviation, etc.).

C) From the ALL COSTS determined above, the cost (represented by CV COSTS) specified by cardiovascular (CV) is confirmed. By doing so, if the claim from the DR or HL file has any CV ICD-9 code at the first or second location, the cost is considered to be CV COST. If the claim from the Rx file is from claim classification 04000, it is counted as a CV claim and the cost is calculated as the CV cost. The complete Prok Univariate for CV COSTS is also provided separately for each and every plan.

D) From CV COSTS, these costs (represented as CHF COSTS) are specifically identified as related congestive heart failure. The cost is considered to be CHF COST if the claim from the DR or HL file has any CHF ICD-9 code in the first or second location. The complete Prok Univariate for CHF COST is also provided separately and individually for each plan.

E) Calculate the number of months of total members each and together, for all remaining member registration periods, during each plan. In doing so, members are considered to have been registered for any month for which they have been registered for at least one day. In this regard, the complete Flock Univariate is provided for each member month, individually for each plan, and with all plans.

F) Finally, a unique member count is provided for all patient status codes being 20 within the remaining enrollment period. Note that a status code of 20 indicates that the patient died or did not recover.

For cost calculations, it should be noted that the following guidelines apply to exemplary embodiments of the present invention:

a. Inpatient inpatient care, emergency services, doctor / outpatient, and other medical services per claim criteria are considered to be:

AMTPAID + AMTCOPAY + AMTRESERVE + AMTDEDUCT

b. Drug costs are considered to be:

AMTPAID + AMTCOPAY

(Where AMTPAID is the paid amount, AMTCOPAY is the co-paid amount, AMTRESERVE is the reserved amount, and AMTDEDUCT is the saveable amount.

It should also be noted that for the purposes of cost stratification, the following rules are used in the exemplary aspects of the present invention.

1. Only inpatient care for CHF can cause other events.

2. Hospital fees include Rx, procedure, and doctor's fees.

3. Hospital visits can generate Rx and procedures at a cost fixed to zero (including hospital costs).

4. A hospital visit may not result in a separate physician visit.

Once again, the above information used to perform a preliminary evaluation on the overall data can be illustrated and modified to include (exclude) parameters that appear to be more (less) useful within the spirit of the invention.

Along with this information, quality checks are performed on an initial population of disease patients whose final results, i.e. the predictive model has been identified, are not unreasonably distorted due to invalid input information. The process for maintaining data quality, quality control step 620 generates an intermediate output file, for example, to extract information as if all claims are from individuals 60 years of age or older, and all claims are from men. The extracted information is refined by checking whether there is an imbalance or other data imbalance that would contaminate the overall prediction model. In an exemplary aspect, step 620 is performed manually by reviewing the intermediate output file. However, it is contemplated that using various threshold values, frequency coefficients can be automatically scanned for potential imbalances.

Now, claim level information is extracted and refined according to various predetermined categories deemed appropriate for subsequent processing purposes to convert the information into an event level format.

6, the next step is to convert the claim level data to the event level (640). To provide processing flexibility, an analysis file can be formed using the aforementioned second step (i.e. converting claim level information to event level information, step 640), particularly when specifying a time window for analysis. Create two basic data files.

In an exemplary aspect of the present invention, the first data file 1 is a member level file, comprising 1) member key, 2) date of birth, 3) gender, 4) first useful registration date (ie, beginning of the dataset ( 1/1/92) or date of enrollment), 5) Last date of enrollment (i.e., last date of termination or enrollment of dataset), 6) Date of first confirmed disease event (e.g., initial prescription for antidepressant, or congestive heart failure) For inpatient care), 7) date of last inpatient care, 8) record number of the case file (base file 2), and 9) introduction form into the dataset (eg i) antidepressant only, ii) diagnosis of depression only , And iii) all data of static characteristics (ie, not time sensitive) such as both antidepressant and depression diagnosis.

The base data file 2 is an event level file with a record for each event, sorted by member and chronological date of the event, and is represented in descending order of event dates in the present invention.

It should be noted that the events sometimes referred to as episodes are manifestations associated with the identified disease, based on clinical knowledge. Knowing which raw data element is available from a claim, a set of events can be defined indirectly or directly from a data element on which the event can be based on a combination of individual data elements and data elements, or on individual or multiple data. Can be derived from the element.

7A is an exemplary list of formats and events for base file 2 (event level file) for depression as identified disease. As shown in FIG. 7A, the input includes the following content.

1. Inpatient care of depression

a. Any hospital claim identified by hospital site code

b. Retention of at least one complete date

c. Retention of ICD9 Code

d. Depression ICD9 Code Occurs Anywhere

e. Disease indicator (Appendix V) 1 = major disease, 2 = suicide, 3 = major disease and suicide, 0 = all other cases

2. Emergency Department of Depression

a. Emergency visits identified by the emergency site code

b. Retention of the ICD9 Code (see Appendix I-a)

3. Physician visit for depression (outside hospital)

a. Random doctor claim

b. Retention of the ICD9 Code (see Appendix I-a)

c. Category: Psychiatrist = 1, in all other cases = 0

4. SSRI Prescription

a. SSRI (Selective Serotonin Reuptake Inhibitor) Treatment Class 5.51.3

b. If accrued by hospital approval, cost = 0

c. Category Indicator = Blank

5. Prescription of TCA (tricyclic antidepressant) or MAOI (monoamine oxidase inhibitor)

a. Treatment Class 5.5.1.1 (tertiary amine), 5.5.1.2 (secondary amine), 5.5.1.4 (monoamine oxidase inhibitor). And 5.5.2

b. If accrued by hospital approval, cost = 0

c. Category indicator = treatment class 1 = 5.5.1.1, 2 = 5.5.1.2, 3 = 5.5.1.4, 4 = 5.5.2

6. Prescription of other neuroactive drugs (from Rx file)

7. Process for depression (from DR or HL file)

Category: CPT Code or ICD Course

0 = all CPT and ICD codes in Appendix I-b not listed under neurotherapy

1 = diagnostics 90801, 90820, 90825, 90830,

90862

94.0x, 94.1x, 94.21, 99.22

94.23

2 = shock therapy 890870, 908712

94.24, 94.26, 94.27

In the above inputs, the cost depends on the physician visit or inpatient care in which the process takes place.

8. Inpatient care for diseases other than depression

It should be noted that the entry under entry 8 may be carried out for a disease other than depression, although the process may be for depression by having a patient diagnosed with depression or being treated with antidepressants at some point.

a. Inpatient care for at least one full day

b. Major Disease ICD9 Codes (See Appendix V)

c. Same category as in 1 above (1 = major, 2 = suicide, 3 = both, 0 = all other cases)

The factors in entries 9-13 are collected for one month. The date is the first occurrence of the confirmed event. In the number section, add up the number of confirmed events that occurred during the month.

9. Emergency Room for In addition to Depression

a. Emergency room visit confirmed by emergency room

10. Physician visit for out of depression (outpatient)

a. Random doctor visit

b. Exclude visits following a diagnosis of depression (Appendix I-a), ie not 3 above

11. Prescription of possible related drugs

Drugs Identified in Appendix IV

12. Prescription of all other (other than depression) drugs

All drugs not included in Appendix III or IV

13. Courses in addition to depression (from Dr and HL files)

a. Category indicator 1 = main course, 2 = minor course (see Appendix IV)

7B shows an exemplary list of formats and events for base file 2 (event level file) for an exemplary embodiment of congestive heart failure as a confirmed disease. This embodiment illustrates that the base files 1 and 2 can be subdivided again using the following example grounded rules that provide coefficients for different events.

I. Count claims with HOSPITALIZATION (using the first and second ICD-9 codes) that have a complete date of at least 1 day and have a site code of 04. Note that the site code is distinguished between sites where the service under consideration (eg, an emergency room, a doctor's office, etc.) has occurred. It should be noted that costs are charged only in the first ICD-9 code category. Also, if a new hospitalization occurs within one day of discharge from the previous hospitalization, the two hospitalizations are counted as one. If a new hospitalization occurs more than one day after the discharge of the previous hospitalization, the second hospitalization is considered new.

II. Emergency code marked with ER VISIT with claims with Site Code 07, 08, or 10 with Provider Code = 81 (Hospital Common Procedure Coding System (HCPCS) codes: A0010-A0070, A0215-A0225, A0999) Count as visit events (using the first and second ICD-9 codes) It should be noted that costs are charged only in the first ICD-9 code category.

III. Claims with site code 01 or 06 and unique service date (DOS) are counted as a medical visit (using only one ICD-9 code) marked as an OFFICE VISIT event, but with the same DOS (if it is the same provider key of the same DOS) It is possible to have different provider keys for a visit) but do not generate a visit to the medical office if the medical visit event occurs during hospitalization (all costs for this event are assumed to be due to hospitalization). In addition, a claim having the following HCPCS code A0080-A0210 is counted as OFFICE VISIT using provider code = 81. For all other medical visits, costs are charged only in the first ICD-9 code category. The following provider keys are not considered separate medical visits and are the same if one is present in 1) 24 (therapeutic radiology), 2) 34, 35 (the single room), 3) 55 (hosp o / pat lab X-ray) It should be noted that this should be linked to a medical visit to DOS.

Following # 6, the three event types described above are further defined according to the relevant diagnosis.

The next step in FIG. 6 is to process the event level file into an analysis file (step 650). After creating two basic files using the aforementioned instructions corresponding to step 640, further processing is performed on the event level data using time frame information and selected variables (independent and dependent variables) to analyze the files. In step 650.

An example format for an analysis file is shown in FIG. 8. As shown, the format of the analysis file includes the member list in the first column of the table. The horizontal line at the top of the table is a list of variables as described below. The body of the table gives an indication of the member's relationship to the listed variables.

In particular, processing the base file into an analysis file in step 660 partially includes an algorithm defined by the time window and a number of variables. This algorithm can be reprogrammed for various time window adjustments and variable modifications. The analysis file created at this stage is a member level file (ie, organized for members). The main analysis file is a member level file derived from the information in the base file.

Each major analysis file is created taking into account the corresponding prediction window for that file and the single reference time window of the censored event. In an exemplary aspect, each new time window applied to the data requires a different key analysis file.

To create an analysis file, a time window diagram is applied to the event level data along with a number of variables.

If we first discuss variables, we include both independent and dependent variables during processing. The independent variable basically represents a valid predictor of bad health outcomes, and the dependent variable basically represents a bad health outcome to be predicted.

To determine an exemplary independent variable for step 650, no assumptions are made about the identified disease, and as many unique data elements as possible are used. Then, based on the clinical knowledge of the identified disease, additional variables are created. In addition, combinations of data elements and / or variables based on clinical knowledge are used as variables. Finally, some variables can be created and used based on their valid utility as a lever in disease management.

In an exemplary aspect of the invention, in addition to each item in the event file, currently used by step 650 in a SAS routine to create an analysis file for an exemplary embodiment that uses congestive heart failure (CHF) as the identified disease. A number of variables are shown in Table 1 below. Note that each event in FIG. 7B is automatically considered as an independent variable for processing.

Additional corresponding arguments: 1.Age (one of three groups at the time of first CHF diagnosis or medication) 2. Gender (M / F) 3. HMO membership (confirmation of specific HMOs) 4. Primary CHF Diagnostic Site (Site Code) 5. Ischemic Heart Disease (Y / N) 6. Diabetes (Y / N) 7. Bad lifestyle diagnosis (Y / N) 8. Heart rhythm abnormality (Y / N) 9. Other Heart Diseases (Y / N) 10. Hypertensive disease (Y / N) 11. Number of co-pathological diseases (0-x) 12.Prescribed Number of ACE Inhibitors (0-x) 13. Number of prescription digoxin (0-x) 14. Number of loop diuretics prescribed (0-x) 15. Different CV prescription count (0-x) 16. Number of non-CV prescriptions (0-x) 17. Drug Retention Ratio (Measure Compliance) 18. CHF inpatient food recovery

19.CHF First Aid Count 20. Number of medical visits 21. Total Cost: Inpatient Hospital Costs Emergency Room Costs Doctor Costs Pharmacy Costs 22. Cardiovascular Costs: Inpatient Hospital Costs Emergency Room Costs Doctor Costs 23. CHF Costs: Inpatient Hospital Costs

For example, dependent variables considered valid for use in the present invention, valid dependent variables are predicted results. With regard to CHF, predicted results include:

1. Inpatient care (HL) for CHF. This is a dichotomous variable referred to as the HL indicator, where HL = 1 if approved, otherwise the indicator is zero;

2. High cost. For example, a high cost indicator may be defined as the top 10% of the source utilization, in dollars. Sources are calculated from time to primary CHF diagnosis or primary CHF-related drug acceptance (recorded) + 1, 3 and 6 months—top 10% cost of separate assays for each time period. This is also a dichotomous variable referred to as a high cost indicator where high cost = 1, otherwise high cost = 0 if the patient is in the top 10%, for example.

In an exemplary aspect the high cost indicator may be defined as the distribution of total cost per member (PMPM) in the prediction regions B-C. The high cost indicator sets the 10% member with the highest PMPM in the total cost distribution to 1 and the rest to 0.

3. Death.

Although only three dependent variables are listed above for a given embodiment, those skilled in the art may use other known or unknown variables as appropriate as the dependent variables within the scope of the present invention to those skilled in the art. There will be.

With regard to the time window aspect in the analysis file generation, it should be noted that there is one analysis record for each selected member.

In the present invention, a scheme as described below has been developed to define a prediction area for generating an analysis file and to inspect data. That is, referring to FIG. 9, the time window basically defines the prediction region or region 910, and an event window (analysis region) 912 whose activity is used to predict something therein. As will be appreciated by those skilled in the art, additional time window schemes may also be appropriately used in the present invention.

For illustrative purposes, the time covered by the claim force is referred to as a time window starting at a point 'A' and ending at a point 'C'. The time interval is separated into an analysis and prediction area by the point 'B' so that AB≤C. 'B' represents the present. 'A' represents the oldest past event, and 'C' represents the most future event.

As an example, Jane Doe's analytical record is based on claims from 1/1/91 to 6/30/93. Thus, A = 1/1/91, C = 6/30/93, and B may be selected at any point between them, for example 12/31/92. In general, A is defined based on the data extraction protocol (ie, when data is available therefrom), and C is defined as the last date, where the member is still registered and eligible for the benefit. Of course, variations of the general aspects of these definitions may be selected within the scope of the present invention.

It is important to define B in the present invention. In the present invention, two basic definitions of B were devised to maximize the accuracy of the prediction model. As those skilled in the art will understand, alternative definitions of B may also be used.

FIG. 10A is an exemplary time window diagram (see Scheme 1) for processing data from the event level file shown in FIG. 6.

In Scheme 1, the event prediction region is set to B = C- (x months) for all members in the analysis from B to C. For example, B = C- (6 months) if you want to form a 6-month CHF inpatient (HL) model (ie HL is used as a dependent variable). In the example of Jane Dough, B would be 12/31/92. Thus, only data covering A to B (1/1 / 91-12 / 31/92) is used to predict CHF at 'next 6 months'. The term 'next six months' herein means that time point B is now and any time thereafter is in the future and any time before it is in the past. This is a key concept in Scheme 1, and is important for understanding predictive model implementation and application.

In alternative embodiments, analytical weights reflecting proximity to the event to be predicted are, for example, 3 months × 1, 3-6 months × 0.75, 6-9 months × 0.5, 9-12 months. Can be used within x 0.25, over 12 months x 1.25. As will be appreciated by those skilled in the art, other suitable gravimetric techniques, such as negative weight, can be used. For example, in an exemplary embodiment of the invention, the actual weight factor used is 1 / e- ^x , where x is the time in months from point B for each event.

Thus, given the selected time window diagram and the appropriate set of predetermined variables, an analysis file is created in processing step 650.

Referring again to FIG. 6, once an analysis file is generated in step 650, the next step 660 is analyzing the analysis file using statistical data, which provides a confirmed disease prediction model.

Using analytical files, you can develop models for identification / prediction in several ways using statistical techniques. In particular, analysis files at the current member level are processed using statistical functions available in SAS. In an exemplary embodiment of the invention, the statistical processing performed to generate the predictive model is multiple symbolic logical regression. As those skilled in the art will understand, other statistical techniques may also be suitable for use with the present invention.

In an exemplary embodiment, statistical processing identifies variables that match a predetermined level of significance (eg, a probability of 0.05) when applied to an analysis file. These variables then form a predictive model, which is of the form:

Logit (p) = a + bx ₁ + cx ₂ ... + zxi

Where x1 ... xi are the identified variables and a ... z are the parameter estimates. The individual probabilities p for the results under consideration are then measured using the following equation.

p = e- ^{logit (p)} / (1 + e ^{-logit (p)} ).

Using these steps, some experiments were performed. In one experiment, the results for a model based on Scheme 1, including all commercial members and using the HL indicator as the dependent variable, were measured. The obtained independent variables that are most likely to predict CHF health outcomes are 1) hospitalization due to CHF, 2) loop diuretics-days of supply, 3) hospitalization due to hypertension-duration of stay, 4) doctor visits due to CHF, 5) MI Doctor visits, and 6) ACE inhibitor possession (negative indicator).

In another experiment, the results for a model based on Scheme 1, including all commercial members without prior CHF hospitalization experience and using the HL indicator as the dependent variable, were measured. The independent variables obtained that were most likely to predict bad health outcomes were: 1) loop diuretics-days of supply, 2) doctor visits due to CHF, 3) hospitalization due to IHD, 4) doctor visits due to IHD, 5) emergency room due to diabetes Visit, 6) hospitalization due to hypertension-duration of stay, 7) emergency room visit due to lifestyle, 8) hospitalization due to other heart disease, 9) doctor visit due to lung disease, 10) doctor visit due to anemia / anemia Emergency room, and 11) prescription for other CV drugs (Rx).

In another experiment, the results for a model based on Scheme 1 including Medicaid members and using HL indicators as dependent variables are measured. The obtained independent variables that are most likely to predict bad health outcomes are 1) hospitalization due to CHF, 2) loop diuretics-days of supply, 3) doctor visits due to CHF, and 4) emergency room due to diabetes.

An alternative to Scheme 1, referred to as Scheme 2, is illustrated in FIG. 10B and shows a second exemplary time window scheme for use in processing data from an event level file generated in the present invention.

The difference between Scheme 1 and Scheme 2 is the definition of a predictive area for members who have experienced hospitalization or emergency room visits (HL / ER) of at least one identified disease. The prediction region starting at point B in Scheme 2 is defined as a number of paths for each member's record. Analytical records from Jane Doe (1/1/91 to 6/30/93, A = 1/1/91, C = 6/30/93) explaining how these aspects work to define point B In other words, Jane is estimated to have been hospitalized three times (4/1/91, 4/1/92 and 4/1/93) for depression.

Point B is set equal to the first identified disease HL / ER date-month or equal to point C if a member has no disease HL / ER identified in their claims. In the case of Jane Doe, B = 4/1/91. In an exemplary embodiment of the invention, the model application environment is similarly performed moving to one month before the HL date. There was probably at least 30 days of delay from model scoring to disease management activities based on the scoring report. Thus, in the Jane Doe record, B = 4/1 / 91- (1 month) = 2/28/91. In this case, Jane's record would not be used for modeling, because the analysis area takes only two months-shorter than the exemplary six-month data history requirement.

By repeating steps 1 and 2 using the second (or third or ...) HL date, the B point is set, and the writing to Jane Doe may eventually participate in model formation on the second and third paths. Will be. In an exemplary embodiment, because there are very few members of the study population with at least five confirmed disease HL / ERs, this process terminates after three or four passes.

It should be noted that as a result of repeated modeling, additional complexity of additional independent variables is introduced. However, an important advantage of Scheme 2 is that the prediction of the HL / ER ratio is likely to be higher than in Scheme 1.

In another alternative embodiment, the analytical weight reflecting proximity to the event to be predicted is, for example, 3 months × 1, 3-6 months × 0.75, 6-9 months × 0.5, 9-12 months × 0.25, 12 Can be used within months x 1.25. As will be appreciated by those skilled in the art, other suitable weight techniques may be used. This type of weight technique can be used in conjunction with Scheme 1 or Scheme 2.

Each experimental result indicates that different numbers of independent variables are used for specific predictive models, and depending on the accuracy of the desired model, more or less independent variables may be used based on their individual ability to accurately predict the selected dependent variable. It should be noted that.

Formation of risk grading and reconciliation list

Next, the determined prediction model is applied to the client's specified data. The determined model can be applied to existing data, such as regularly updated, or to other claims databases for other benefit providers. In doing so, only the determined independent variables of interest need to be processed. Of course, you can analyze the new claims database and create a new model to iterate the whole process to determine if other variables can be better predictors.

The output generated by applying the model is a file containing a list of all patients with confirmed diseases ordered by indicators indicating the likelihood that the patient will have a poor health outcome (e.g., defined by dependent variables). Experience). This list can be divided, for example, into a subgroup of 5% or 10% increase in patients who are likely to have poor health outcomes.

Model performance can now be assessed by measuring the actual number of bad health outcomes occurring in the prediction window for each of the 5% or 10% subgroups.

Applying the model to future claims data or other databases of patients with identified diseases or establishing new models in new databases as described above can identify patients with high risk identified diseases. Various types of adjustments can be made to maximize the effective placement of healthcare resources for patients. A risk grading (RS) process 140 is required to produce a list of such patients, and the coordination management process 160 receives this list and initiates coordination to patients with confirmed diseases. These processes are described in more detail below. These adjustments, as well as adherence to best practice guidelines, may include (1) specific case management, (2) new adjustments based on subgroup characteristics, (3) high risk adjustments, (4) high cost (relative) adjustments, or (5) plan It may take the form of a modification.

Referring to FIG. 1B, the risk grading (RS) process 140 assists the disease management system by providing a coordination management process 160 with a list of patients at risk of bad health outcomes for the identified disease. need. This list of patients is referred to as the coordination list.

11 shows a high level flow diagram illustrating a risk grading process 140 that includes an RS front end (FE) 1110 module, an RS mining engine (ME) 1112 module, and an RS database 1118. These two modules are commonly used to generate a steering list from the RS database 1118.

RS Front End (FE) 1110 allows end users to enter all the information necessary to maintain and operate the disease program for the sponsor.

RS FE 1110 of the present invention is written using Delphi 2.0, a 32-bit software extension tool. RS FE 1110 retains the client and disease parameters of Sybase system 11 running on a Windows NT or Unix based server. RS FE 1110 uses a Borland 32-bit Sybase SQL Links database driver. However, the present invention is not limited to this arrangement as it can be implemented using any similar extension and database tool.

RS mining engine (ME) 1112 operates the planned sponsor identified disease program to produce a list of adjustments provided to the coordination management process 160 of 1b. RS ME 1112 is a batch / daemon process and follows the basic program logic:

A. Run as a nightly (batch) or daemon process.

B. Determine which sponsors identify disease programs needed to operate based on plans and available data.

C. For all planned sponsor disease programs:

(a) Take the disease program rule elements.

(b) Take disease program parameters for each rule element.

(c) Validate that the required data flows (R _x , M _x and Lab) are present for the identified disease program.

(d) Initiate the identified sponsor's disease program.

(e) Implement the planned sponsor's identified disease program.

(f) Provide a reconciliation list for the reconciliation management process 160.

D. Set up the process to terminate (deploy) or sleep (daemon).

Write RS ME 1112 using Delphi 2.0, a 32-bit software extension tool. RS ME 1112 processes the disease parameters provided by RS FE 1110 along with sponsor drug claims, medical claims, and laboratory test information for specific disease programs that yield specific stored lists stored or stored in relevant databases. RS ME 1112 utilizes a Sybase System 11 database running on a Windows NT or UNIX base server. RS ME uses a Borland 32-bit Sybase SQL Link database driver. However, it is contemplated that the present invention may be practiced using any similar extension and database tool, and is not limited to this arrangement.

Operation of the risk grading process of FIG. 11 is described. End users, who may be attached to the case management process or another separate process of FIG. 1B, provide the end user identified disease program information to RS FE 1110. RS FE records information for newly identified diseases, new disease programs, predictive models and rules, sponsor specific parameters, disease specific rule parameters and setup of new sponsors; RS FE 1110 associates sponsors with disease programs, associates planned disease programs with disease programs, and operates information reports. RS FE 1110 records this information as a disease program format for use by RS ME 1112.

The disease program is provided to RS database 1118 by RS FE 1110, which also receives prediction model and rule information from predictive modeling process 130. Finally, disease management database 120 provides patient medical information to RS database 1118 for RS ME 1112 when RS ME 1112 applies a predictive model to patient data. Finally, RS ME 1112 accepts the information contained in RS database 1118 when RS ME executes disease program data and applies predictive models to patient data.

12 is a high level flow diagram illustrating RS ME 1112 of the risk grading process of the present invention. As shown in FIG. 12, RS ME 1112 is comprised of three main subsystems: RS Plan Manager (SM) 1210, RS Rule Manager (RM) 1214 and RS Coordination List Manager (ILM) 1216. The three subsystems interact with RS database 1118, which may be a subset of disease management database 120 of FIG. 1B, each comprising a sponsor and identified disease program analysis arrangements.

The disease management database 120 regularly updates patient information for each sponsor (member, qualification, drug (R _x ) claims, medical (M _x ) claims, and clinical laboratory (Lab) claims). As a result, the RS database 1118 regularly updates the sponsor and client member information. RS ME 1112 collects relevant sponsor patient information from disease management database 120 processed by disease program analysis rules. In an embodiment of the invention, all relevant databases are seabase system 11.

RS SM 1210 performs this by compiling a list of confirmed disease programs to check whether the program has reached the scheduled time for execution and examining the sponsors recorded in each pathology. In addition, sponsor disease programs must be approved for execution by RS ME 1112 before scheduling them. Approval means that all sponsor disease program parameters have been entered, and the entered data is validated by RS FE 1110 and ready to be processed into RS ME 1112. Finally, RS SM 1210 verifies that all required data flows are valid. RS ME 1112 may be a batch program that is performed periodically. For each identified disease program selected by the logic above, an RS RM goal is calculated. RS RM goals are performed sequentially.

RS RM 1216 then combines the rules required to in turn execute the particular identified disease program. Such rules are described in detail later and provided by the predictive modeling process 130 and the case manager 150. Each rule goal is initialized with disease program and sponsor specific rule discussions. Rule sequences preferably include one or more conventional rules and one or more so-called patient group classifiers (PGCs). PGCs are used to grade targeted sponsor patient populations into specific groups for coordination or recording based on specific standards. All adjustments and recordings are performed based on the number of patients in one or more disease program PGCs.

Conventional rules are executed in the order specified prior to all PGCs. In general, the rules are the size of the entire patient set before they are created for other rules (client involvement, R _x claims, M _x claims, etc.) or acted upon by other complex rules (patient activity, patient age, patient gender, etc.). It is designed as a general rule because it enforces exceptions that improve overall performance by reducing. Patients who do not 'satisfy' certain rules are removed from the patient set.

PGCs perform similarly to rules where each PGC performs similarly for a set of patients provided by conventional rules. PGC rules use a computational mechanism for each patient in a set to indicate the failure or passage of such patients' specific rules.

At the end of every PGC, RS ILM 1216 counts each patient as a membership of each PGC. RS ILM 1216 then generates and stores a coordination list for later processing by coordination management process 160.

RS SM 1210 initially queries RS database 1118 periodically at the start of the batch process or when operating as a daemon to ensure that the approved sponsor identified disease program has reached its scheduled work date and that all required sponsor data flows are maintained. Determine whether it has been updated. If all necessary data flows are valid, a rule manager (RM) goal is created for each sponsor disease program.

The identified disease program attributes are stored in a table. One attribute is approved. Each identified disease program is desired to be approved before it is scheduled. If any identified disease program is planned, then disease program approval cannot be revoked.

The planning table, which includes status and scheduled work dates, among other things, determines which programs need to be run and when. Once the scheduled date is reached, the program is run and the status is updated to work.

RS RM 1214 works and manages the outcome of a single disease program.

Rules are grouped according to the patient group classifier (PGC) to which they are assigned. First all normal rules (except PGC) are activated. The rules for each PGC present in the disease program then work.

RS ILM 1216 evaluates the success of each sponsor disease program and edits the list with a table of coordinating volunteers of members selected by the programs belonging to each PGC within the program.

If a member has not been removed from the set by any normal rule and the member's output for each PGC rule matches the target number (1 for invalid rules, 0 for invalid rules) Members are contained within PGCs.

Members included in the PGC are grouped into a mediation table, which may be a mediation list. This table includes the identification of information about the selected member, program operation, the PGC to which the member belongs, and the confirmed physician when a physician confirmation rule is used.

Rules-General Classification

A rule classified as a root rule indicates that the rule is needed to precede everything else and performs a specific environment initialization for all other rules. Every identified disease program should have one and only one route rule. Currently, the only route rule is Client Participation.

A rule classified as a general rule indicates that the rule is preferably executed before some PGC. Members that fail the general rule are removed from the patient set. The rule may preferably be executed simultaneously as a general rule and a PGC rule.

Rules classified as PGC rules indicate that it is desirable to execute them in parallel after the general rules. Members that 'pass through' a PGC rule are listed in the column specifically added for that rule in the table. It may be desirable at the same time that the rule is executed as a general rule and a PGC rule.

The rules forming the pharmaceutical claim form a table for the pharmaceutical claim. All identified disease programs dealing with pharmaceutical claims for data sources preferably have rules that perform this function before rules dealing with pharmaceutical claims.

The rules for forming a medical claim form a table for the medical claim. All identified disease programs dealing with medical claims preferably have rules that perform the function before rules dealing with medical claims.

The rules that form the clinical trial data form the table for the clinical trial data. All disease programs dealing with laboratory claims preferably have rules that perform this function before rules dealing with laboratory claims.

The rules for dealing with experts deal with physician expert information.

The rules governing pharmaceutical claims deal with tables containing pharmaceutical claim information.

The rules governing medical claims deal with tables containing medical claim information.

Rules governing clinical trial data deal with tables containing clinical trial information.

Every rule object in RS ME 1112 derives from a common origin, providing some basic functional structure common to all rules.

Rules-selection rules and reconciliation rules

This embodiment of RS ME 1112 supports various selection and adjustment rules:

1) Client Participation Rules

Make sure the patient is part of a group enrolled in a disease management program. This rule ensures that all patients considered by the following rule are part of a group that the sponsor wishes to participate in the program. This rule also ensures that the patient has a reasonable benefit structure for the disease program to function. Sponsor participation is currently the only route rule. Thus, it is preferably the first rule in all disease programs. This is always executed as a general rule.

2) Rx Claim Rule

The rule selects all pharmaceutical claims applicable to the execution of a single identified disease program. The rule identifies all pharmaceutical prescription claims selected for a particular drug group within the analysis time frame described above. Rx claim rules are always generic rules. The rule is typically executed only once in a given program.

3) Presence of Specific Drugs

This rule identifies members with one or more claims for drugs within a particular drug group within the rule timeframe. This rule may be executed as either a general rule or a PGC rule.

4) Recurrent Patient Rule

This rule confirms that the patient has a pattern of drug use that indicates the likelihood of multiple independent episodes of the disease (relapse). The rule will select patients who have several or more discrete episodes of a particular medication. This rule can be executed as a general rule or a PGC rule.

5) current treatment interruption rules

This rule identifies patients who have stopped drug treatment for a particular drug group. This is measured based on the final prescription of the drug in that drug group. This rule can be executed as either a general rule or a PGC rule.

6) Patient age rule

This rule identifies patients whose age is within a certain target range. This rule can be executed as a general rule or a PGC rule.

7) Minimum Patient Qualification Rules

This rule determines whether a patient is eligible for medical and / or drug benefits for a particular consecutive period of time. This rule may be executed as a general rule or a PGC rule.

8) Patient activity rule

This rule proves that the patient is active and in the group included in the program at the time of coordination. This rule may be executed as a general rule or a PGC rule.

9) Average Puff Equivalence Rule

This rule checks if a member has the required average puff equivalence of drug treatment over a particular timeframe. This rule can be executed as a general rule or a PGC rule.

10) occurrence counting rule

This rule confirms that the patient has a selected range of occurrences at different dates implemented for a particular medication. This rule may be executed as a general rule or a PGC rule.

11) Patient Gender Rule

This rule identifies members of a specific gender. This rule may be executed as either a general rule or a PGC rule.

12) Dose Level Recurrence Rules

This rule confirms that the patient has a pattern of drug use within a specific dosage range that indicates the likelihood (relapse) of multiple independent episodes of the disease at the same or similar severity. This rule may be executed as either a general rule or a PGC rule.

13) Continuous treatment rules at the required dose level

This rule identifies patients receiving continuous drug treatment within a certain dosage range for a specific time. This rule may be executed as either a general rule or a PGC rule.

14) Concurrent Treatment Rules

This rule identifies patients receiving overlapping treatment for at least one given duration for a particular drug group. This rule may be executed as either a general rule or a PGC rule.

15) Dose Level Rules

This rule identifies patients with Rx claims for specific drug treatments within certain dosage level ranges. This rule may be executed as a general rule or a PGC rule.

16) Drug Usage Level Rule

This rule identifies members whose drug usage is in a certain range relative to the expected value. Typically, this rule will be used to determine members who are not compliant with a particular drug treatment. This rule may be executed as either a general rule or a PGC rule.

17) Weighted Presence Rule of Certain Drugs

This rule identifies members whose drug treatment is within a specified risk score range. Each drug is assigned a risk score, and the drug history of the member is evaluated to determine his / her cumulative risk score. This rule may be executed as either a general rule or a PGC rule.

18) Doctor Confirmation Rule

This rule selects a specific prescriber and sends information about the identified members for reconciliation. This selection is based on pharmaceutical claims for the member and / or information about the member's primary care physician that may be found in the member data in patient data archive 120. This rule may be executed as either a general rule or a PGC rule.

19) All member rules

All member rules select all members that exist in the record set. This is used to support the PGC which includes all members selected by the general rules. This rule is also used internally by RS ME 1112 to support optimization of certain types of disease programs. This rule can only be used as a PGC rule.

Appendix VI contains descriptions and rules for selection as used in one embodiment of the present invention. It is apparent to those skilled in the art that the rules can be modified or deleted, and that new rules can be created for certain embodiments of the present invention.

Reconciliation Management Process

Once again referring to FIG. 1B, the risk rating process 140 outputs a list of adjustments for the adjustment management process 160 to initiate a particular adjustment. Coordination may include initial provision, fully administered disease programs, textbook shipments, telecommunications in and out of the country, voice response conversations with member patients identified on a fax, e-mail or coordination list. Coordination management process 160 provides coordination information to coordination recording and tracking process 170, which records coordination to determine if a previously performed disease management service enhances a particular disease outcome.

13 is a high level diagram of the coordination management process 160 of the present invention, wherein a coordination process, called a coordination program, is performed on coordination lists for sponsor members with confirmed diseases. The coordination management process 160 shown in FIG. 13 includes a program initiation 1310 to start a coordination program, a registration 1320 to enroll a patient identified as a coordination program, a coordination 1330 to initiate coordination with a registered patient, and a patient. And analysis 1340 to analyze the result of coordination with the.

The coordination management process 160 is provided with data by the coordination list from the disease management database 120 and the risk grading process 140. This data entry and detection process has parameters that identify a particular patient corresponding to a condition related to the disease program. This detection process provides a population to be considered in a particular disease program under the following conditions.

1) The disease management database 120 provides the sponsor's updated confirmed disease patient data to the coordination management system on a planned basis.

2) The mediation recording and tracking process 170 passes the mediation contact data back to the disease management database 120. This adjustment data is stored in place for use in the analysis process.

3) The coordination management process 160 detects, selects and passes new coordination data upon 'addition', which is defined as a new registrant, a change in disease detection, subsequent diagnosis or a separate registration request from a coordination manager.

4) The coordination recording and tracking process 170 revises patient data of those individuals preselected for the program. Data revision occurs when personal or medical data changes. For example, when an additional medical or pharmaceutical claim has been received or an additional research report has been obtained.

With reference to FIG. 13, the first step in the process is step 1310, program initiation. Program initiation is a process in which a disease program is initiated and an initial adjustment is given through a process of selection of a group of patients based on a predetermined category. Upon selection, a specifically scheduled program is activated.

Sample initiation may include: 1) sending a letter to their physician informing their physician of the confirmation of these patients with the program, disease protocol, and directed action from the physician, and 2) coordinating management data from the disease management database 120. And 3) adding an initial contact segment for the patient indicating passing and loading into system 160, and 3) sending a physician's letter.

Other sample initiations may include 1) sending a letter to patients and their doctors informing the patients that they have been introduced into the disease program, 2) requiring the patients to call a voice response system to answer specific questions, and 3 ) May be added to further contact and analyze the reaction.

The second step of the process is the registration step 1320. At this stage, the patient is enrolled in the program. Patients are registered as disease management services through an interface to a coordinated management system. These interfaces can be made through voice response systems, reply letters and direct calls. The registration process leads to the planning of mediation events within the mediation management system.

The next steps are 1) ensuring compliance with the treatment process, 2) providing disease textbooks to patients and physicians, 3) providing emergency assistance from a distance, 3) providing assistance in determining program effectiveness and adjusting the intermediate process to the program. 4) Coordination process (1330), which is a mediation process between physicians and sponsors for the purpose of establishing a primary study for the purpose of logging each and all coordination, and 4) reversing data to the product manager in terms of program effectiveness. to be.

The final step is an analysis process 1340 that mimics disease information for the purpose of measuring disease management service performance. Although the coordination management system does not generate an analysis report, critical information is passed back to the disease management database 120 for processing during this process.

Although the invention has been described by way of example, it is contemplated that modifications that fall within the scope of the appended claims may be made as outlined above.

Computer-aided systems and methods may be used to extract information about a patient from at least one pre-existing database to identify patients at risk, particularly those diagnosed with identified diseases. In addition, the system of the present invention may be used to process patient information in a database based on certain criteria to extract relevant information about a group of patients suffering from or capable of developing the identified disease.

Claims (4)

a) extracting patient information for the identified disease or patient population of the identified disease by processing the patient information in the database based on a predetermined category; b) i) using the information available in the database to define a set of events or data related to the identified disease or condition; ii) converting extracted patient information and defined events or data into a file containing event-level information; iii) define a time window to provide a time frame for determining whether certain of the specified events should be considered in subsequent processing; iv) identify a set of variables as valid predictors; v) process the event-level information using a time window and a set of variables to generate an analysis file; vi) a predictive model and a set of rules (both of which are variables) for performing statistical analysis on an analysis file to identify patients at risk of being diagnosed with an identified disease or condition, or who may develop such disease Defining a prediction model, the method comprising generating a subset of the set of? c) Apply predictive models and rules to the same or new set of event-level information to identify patients at risk for identified diseases or conditions, or identify patients at risk of developing a identified disease or condition. Doing; d) producing an adjustment list from the identified at risk patients and selecting adjustments for at least one risk patient; e) distributing or facilitating distribution for the patient; And optionally f) recording and tracking the outcome of the adjustment for each patient at risk based on the individual selected adjustment; And optionally g) updating medical history data in at least one database with the result of each adjustment corresponding to the database; And h) repeating step b (ii); And i) Computer use for disease or disease coordination management using information about patients present in at least one database, comprising reapplying predictive models and rules to event-level information extracted from the data of the updated database. Way. a) means for processing patient information in a database based on a predetermined category to extract patient information for the identified disease or patient population of the disease; b) event defining means for defining a set of events related to the identified disease or condition using information available in the database i); ii) switching means for converting the extracted patient information and the defined event into a file containing event-level information; iii) means for defining a time window to provide a time frame for determining whether certain of the specified events should be considered in subsequent processing; iv) means for defining a set of variables as valid predictors; v) means for processing the event-level information to generate an analysis file using the time window and the set of variables; vi) a predictive model and a set of rules (both of which are variables) for performing statistical analysis on an analysis file to identify patients at risk of being diagnosed with an identified disease or condition, or who may develop such disease Means for defining a prediction model, comprising means for generating a subset of a set of s); c) means for applying predictive models and rules to the same or new event-level information set to identify patients at risk for the identified disease or condition; d) means for producing a list of adjustments from the identified at-risk patients and selecting adjustments for at least one risk patient; e) means for distributing or facilitating distribution for the patient; And optionally f) means for recording and tracking the outcome of the adjustment for each patient at risk based on the individual selected adjustment; And g) means for updating history data in at least one database with the results of each adjustment corresponding to the database or means for creating a mirror database using the data obtained in step f); And h) means for repeating step b (i); And i) computer-assisted system for disease management utilizing information about patients present in the database, comprising means for reapplying predictive models and rules to event-level information extracted from the data of the updated database. a) using a computer to extract and process patient information in a database, based on certain categories, to obtain a data file of patient information for a patient group of identified diseases or disorders; b) defining a set of events related to the identified disease or condition using information available in the database; ii) converting the extracted patient information and the defined event into a file containing event-level information; iii) applying a time window to provide a time frame for determining whether certain of the defined events should be considered in subsequent processing; iv) introducing a set of variables as a valid predictor; v) creating an analysis file by processing event-level information using the time window and the set of variables; vi) a predictive model and a set of rules (both of which are variables) for performing statistical analysis on an analysis file to identify patients at risk of being diagnosed with an identified disease or condition, or who may develop such disease Program the constructed predictive model into a computer, the method comprising: generating a subset of the set of? next On a computer; c) running predictive models and rules on the same or new event-level information sets to identify patients at risk for the identified disease or condition; d) output a list of adjustments from the identified at risk patients and select adjustments for at least one risk patient; e) distribute adjustments for said patients; Randomly f) recording and tracking adjustment results for each patient at risk based on the individual selected adjustments; g) update the medical history data with each adjustment result corresponding to the database in at least one database or create a new database with each adjustment result described above; h) restarting step b (i); i) re-run the prediction model and rules on event-level information extracted from the data of the database created in step g); Randomly j) outputting a list of adjustments obtained by reactivating the predictive model and rules for the database created in step g). a) using a computer to extract and process patient information in a database, based on certain categories, to obtain a data file of patient information for a patient group of identified diseases or disorders; b) defining a set of events related to the identified disease or condition using information available in the database; ii) converting the extracted patient information and the defined event into a file containing event-level information; iii) applying a time window to provide a time frame for determining whether certain of the defined events should be considered in subsequent processing; iv) introducing a set of variables as a valid predictor; v) creating an analysis file by processing event-level information using the time window and the set of variables; vi) a predictive model and a set of rules (both of which are variables) for performing statistical analysis on an analysis file to identify patients at risk of being diagnosed with an identified disease or condition, or who may develop such disease Program the constructed predictive model into a computer, the method comprising: generating a subset of the set of? next On a computer; c) running predictive models and rules on the same or new event-level information sets to identify patients at risk for the identified disease or condition; d) output a list of adjustments from the identified at risk patients and select adjustments for at least one risk patient; e) distribute adjustments for said patient; Randomly f) recording and tracking adjustment results for each patient at risk based on the individual selected adjustments; g) update the medical history data with each adjustment result corresponding to the database in at least one database or create a new database with each adjustment result described above; h) restarting step b (i); i) re-run the prediction model and rules on the event-level information extracted from the data in the database created in step g); Randomly j) A list of health adjustments produced by the method of outputting a list of adjustments obtained by reactivating the predictive model and rules for the database created in step g).