WO2000069331A1

WO2000069331A1 - Data processing system for patient outcome and risk benchmarking and healthcare data base management

Info

Publication number: WO2000069331A1
Application number: PCT/US2000/013267
Authority: WO
Inventors: Renee J. Goldberg Arnold; Krista Pettit; Harry Harjono; Yonglong Zhou
Original assignee: Pharmacon Global Enterprises, Llc
Priority date: 1999-05-17
Filing date: 2000-05-15
Publication date: 2000-11-23
Also published as: AU5133700A

Abstract

A computer (1) for decision support, and patient outcomes assessment tools for the health care industry, using internet based platforms (10, 20) that integrate with the existing health care infrastructure.

Description

PATENT APPLICATION

DATA PROCESSING SYSTEM FOR PATIENT OUTCOME AND RISK BENCHMARKING AND HEALTHCARE DATA BASE MANAGEMENT

BACKGROUND OF THE INVENTION

This application claims priority from provisional patent application Serial No. 60/134,412 filed May 17, 1999.

The constraints of economy and time have driven the healthcare industry to become increasingly reliant on computer-based systems to assist professionals in providing the best care in the most cost effective and efficient manner. In addition, the ever-increasing growth of medical, scientific and economic information and data that impacts on patient health and well being, and the ever-increasing availability of the abundance of that data and information via means such as the Internet and the World Wide Web, has placed increasing pressures on physicians, clinicians, nurses, health-care administrators and others in the healthcare field to assimilate, synthesize, and use that information for the benefit of the patient. The availability of such information and data to the point-of-care professional has, in turn, created the need for computer-implemented processes that can, through the speed of computing, assist the professional in using available data and information to manage the patient's disease state, assess the probabilities associated with a patient's particular disease and treatment choices, assist in diagnosis, assess risks and costs related to particular treatment choices, provide the professional with reports on patient health and risks, and perform various functions such as on-line prescription writing. To date, no one system is known to be available for providing all of these electronic tools, in one package, at the point-of-care.

It is expected that by the beginning of this century over 95% of the population will be receiving health care through some type of managed care organization ("MCO"). The cost of managing common patient conditions by MCOs is of considerable importance. On average, MCOs spent 9% of their 1993 operating budgets on pharmaceutical products (Marion Merrell Dow Managed Care Digest HMO edition 1994, Englewood CO; The Business Word Inc. 1994.). Thus, the cost/effectiveness of pharmaceutical therapies are an area under intense scrutiny. In addition, physicians' practices are being scrutinized by MCO administrators for quality and cost-effectiveness of care options.

The systems of the present invention provide a means for enabling better, and more cost effective, efficient physician decisions, and a means of establishing verifiable, credible justifications of those decisions. Physicians are now under considerable administrative time pressures, and often cannot afford to spend the time that patients require or request. For example, one survey, conducted by the Commonwealth Fund (New York) showed that roughly half of 1,700 physicians surveyed were "very dissatisfied" or "somewhat dissatisfied" with their ability to make the right treatment decisions for their patients (Healthcare Informatics, May 1997, 26-33). Currently, at the point-of-care, physicians have only about five minutes to review a patient's chart, look for the results of lab tests, assess past medical history, examine and speak with the patient, and determine the most appropriate course of treatment. The system of the present invention reduces the physician's time commitments, and provides patients with a valuable educational service that can make the patient more responsible for his or her own medical care.

Current Internet sites specifically related to disease state management can be divided into several areas: general "disease state management" site information, companies that provide disease management interventions, publications, conferences, associations, patient- directed information, and supporting materials. Only a few sites offer comprehensive links to specific information regarding disease management programs. For example, site offered by a telephone nursing group provides links to approximately 50 sites (http://www.katsden.com/telenurse/dm.htmn. but some of the linked sites at this address are no longer active. There have been numerous definitions of disease state management on the Internet. Whereas most definitions contained the principles of reduced treatment variation, lower costs, and increased intervention within selected populations, no two descriptions were identical. It is likely that this mirrors the wide variety of companies that maintain active websites, which include pharmaceutical companies, pharmacy benefit managers, provider organizations, individual providers, independent for-profit companies, and accounting firms. See Chris M. Kozma, "Disease State Management and the Internet."

Current websites contain information about companies that offer disease state management services. Typically, these sites focus on company background, qualifications, and rationale for their services. Very few offer details regarding specific services, but almost all offer a contact mechanism for obtaining more information. Whereas these sites represented a great source for disease state management information, they offered relatively little substance with regard to program content. Further contact with the individual companies is required. For example, one site contains a lengthy listing of pharmaceutical care-related disease management activities (http://www.nwda.org/pharm/companies.htmV Only brief descriptions of the support materials are included; however, contact information for these companies was offered. This site is valuable, because it provides information about support materials that could be used by individuals interested in developing disease management programs. Other supporting materials are available from a variety of sites such as the Medical Outcomes Trust (http://www.outcomes-trust.org/). Such materials can be found under many search terms other than "disease state management." There are many other medical information sites that may be beneficial for disease management program executives (e.g., http://www.medscape.com/home/directory-sitemap.html). Moreover, literally hundreds of disease-specific sites offer a tremendous amount of general information for those considering disease management programs. These websites are also available for patients. One website, Olsten Health Services (http://www.okqchomehealth.com/ qanda/august.html . targets patients directly.

The prior art disease management programs can be summarized as follows: Nurse Triage Systems

Health plan members may speak to registered nurses on the telephone, through the Internet, or receive educational materials tailored to meet their needs. These services are designed to guide members toward the most appropriate level of care delivery, help them to manage chronic illnesses and conditions (thereby improving outcomes) and assist them in understanding and navigating the complex health delivery system. These programs deliver proactive patient monitoring, education and counseling based on nationally recognized clinical guidelines. Appropriate intervention and self-management plans are tailored to each member's unique situation and needs. These programs also utilize proven algorithms to accurately assess the needs of members seeking emergency care. Electronic Medical Records (EMRs)

Clinicians can now use electronic medical records systems to view orders, review and trend laboratory results, and complete medical records. Such products also feature query and report capabilities across departments, facilities, and corporations. For example, these products link participating providers, create the electronic patient medical records, provide clinicians with flexible implementation and workflow management, and supply tools to analyze system-wide information to develop outcomes-based care protocols. Clinical data can be transferred over the Internet or a private Intranet to automate clinical activities. Physicians can use EMRs to receive, store, and manage clinical information in document format and automate clinical and office workflow. Information retrieval systems gather data across a network of electronic charts for protocol development, peer reviews, and regulatory filings. These programs enable users to prospectively identify high-risk patients through self- generated or industry standard assessment forms. The system captures costs, services, savings, treatments, outcomes and provider effectiveness as the patient moves through each level of care. Levels of Care or "episodes" are self-defined and may include Hospital ICU, Home Health, Outpatient Rehabilitation, etc.

The medical management software enables users to define and maintain their own code tables, care guidelines, reports, letters and other documentation. With more than eighty standard reports and unlimited ad-hoc reporting capability, the system is designed to be flexible and easy to maintain. Population Profiling for High Utilizers

Software is available that enables care providers and payers to identify the small portion of patients that consumes the largest portion of resources. The software provides individualized careplans that help healthcare organizations improve the efficiency of care delivery, especially to disproportionate healthcare consumers, such as the chronically ill.

Once the high-risk patients are identified, the system manages only those patients who consume a disproportionate share of healthcare resources. Ultimately, it enables MCOs to focus preventive and treatment resources on the 1% of the patient population that typically accounts for 30% of healthcare dollars. By minimizing costly acute care episodes associated with chronic disease, healthcare organizations can spend significantly less money while improving patient care. Using responses to a minimal set of inquiries (often as few as six questions), patient information is entered into the system following enrollment. Patients for whom additional information is needed (approximately 20%) are identified. The high-risk patients can be managed via a patient-specific care plan. The care plan that is generated is comprised of suggested activities. These activities can be distributed via computer, fax, email, web, telephone or pager. All activities are tracked to ensure completion of the specified care plan. Reports on the resource utilization for the high-risk patients are also generated. Standard reports measure resource utilization for high-risk, high cost patients by provider, diagnosis, co-morbidity and case manager. Prescription Writing Tool

Point-of-care medication management systems bring valuable clinical information directly to physicians at the exact time it's needed, that is, at the point of prescribing. As a result, physicians can make more informed prescribing decisions because they are immediately advised of plan-specific formulary recommendations, generic and therapeutic alternatives, prescribing histories, and drug utilization review alerts. These products can also generate information on disease management, physician profiling and prescribing patterns. Some systems are also fully enabled for Internet access, automatically display generic and therapeutic alternatives available on formulary, provide drug utilization review (DUR) alerts from Medi-Span, Multum or First Data Bank drug dosing, drug-drug interactions, drug-health state interactions, duplicate therapy and prior adverse reactions. Some programs also provide on-line prescription claims processing with payers and Pharmacy Benefit Management companies. Bar code safety checks also ensure that proper medications are dispensed. Prescriptions can be dispensed in the doctor's office or transmitted to a retail pharmacy or mail service depending on the patient's choice. Workflow Analyses and Administrative Support

These products are designed to accelerate and streamline the flow of work in healthcare. They integrate all clinical and administrative activities into standardized processes and deliver these processes across distributed healthcare environments. The patient management component assures patient demographics are available within all applications, increasing availability and access to important information and also manages the patient appointment scheduling system. Thus, this system helps minimize the time providers spend on administrative tasks. Claims payment determination can also be managed through these systems. The accounts receivable and billing systems are also provided. Patient Telephone Surveys

Patients to be followed by these systems are given a PIN code along with a brief introduction to the system. Later, the module contacts the patient by telephone and through the use of the touch-tone keypad, receives direct responses from the patient related to their condition and care. Results can be stored within a database and can trigger events including provider alerts, patient instructions, etc.

The products described above, however, do not have the following combination of features contained in the system of the present invention: disease screening tools, disease risk assessment models, disease-based cost-effectiveness models, patient education tools, CME programs, DUE evaluation programs, HEDIS® compliance programs, drug compliance algorithms, laboratory assessment and the ability to track an individual patient's values for these programs.

SUMMARY OF THE INVENTION

The present invention relates to an Internet-based and/or Intranet-based computer system and method for enabling healthcare professionals to perform individualized patient assessment and to determine the probable outcomes of selected patient therapies. The invention utilizes Internet-based model process engines, based on Markov models, logistic regression and/or other mathematical constructs. The system users may input relevant data using standard hypertext transfer mark-up language ("HTML") forms. The invention processes these data using programs that reflect real-world patterns among disease and patient populations. The present invention also comprises processes which are specific to certain diseases, and perform risk-assessment of the subject patients, and cost-effectiveness assessments for particular patient therapies. The inventive programs are built by and operate in accordance with certain algorithms, as described below, and data bases which include those built by the inventors and which have been derived from available sources. The model algorithms are incorporated into the overall system of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a flow diagram setting forth an overall view of the system of the present invention.

Figure 2 is a diagrammatic representation of a computer system used with the computer-implemented method for patient outcome and risk benchmarking and healthcare data base management in accordance with the present invention.

Figure 3 is a diagrammatic representation of the interrelation between the user, the Internet, and the system, in accordance with the present invention.

Figure 4 is a screen shot illustrating the various user levels available for signing into the system of the present invention.

Figure 5 is a flow diagram illustrating how a user may select the various user levels available for signing into the system of the present invention.

Figure 6 is a screen shot illustrating a sign-in form for a health practitioner to log into the system of the present invention via user ID and password.

Figure 7 is a screen shot illustrating a registration form to be completed by the user in order to select a user ID and password for access to the system of the present invention.

Figure 8 is a flow diagram illustrating how a health practitioner may sign-in in accordance with the present invention. Figure 9 is a screen shot illustrating the main menu selection of the present invention available to health practitioners who have successfully signed into the system.

Figure 10 is a flow diagram illustrating the main menu selections available to health practitioners who have successfully signed into the system of the present invention.

Figure 11 is a flow diagram illustrating how a health practitioner may select a diagnosis for the current clinic visit, according to ICD-9 or other international coding systems in accordance with the present invention.

Figure 12 is a key for the fields in the main tables in accordance with the present invention.

Figure 13 is a flow diagram illustrating the relationship between the data bases, fields and other components in accordance with the present invention.

Figure 14 is a screen shot illustrating the ability of a health practitioner to select a patient in the system of the present invention.

Figure 15 is a flow diagram illustrating how a health practitioner may select a patient in accordance with the present invention.

Figure 16 is a screen shot illustrating the patient search results of the present invention with links for viewing patient information, editing existing patient profile, and adding new patient profile.

Figure 17 is a screen shot illustrating the display of patient-related information such as result list, lab tests, drug compliance, problem list, current medication, and medication history.

Figure 18 is a screen shot illustrating patient assessment questionnaire results and patient model-specific results, with options to evaluate the patient using available models in accordance with the present invention. Figure 19 is a screen shot illustrating the list of past diagnoses for the selected patient of the present invention.

Figure 20 is a screen shot illustrating the confirmation of the selected diagnoses in accordance with the present invention. Severity and onset data are also entered by the user.

Figure 21 is a flow chart illustrating the method of selecting a diagnosis in accordance with the present invention.

Figure 22 is a screen shot illustrating a patient's unique problem list within a given time frame in accordance with the present invention.

Figure 23 is a screen shot illustrating detailed history for a specific diagnosis in accordance with the present invention.

Figure 24 is a screen shot illustrating the patient's current medication in accordance with the present invention.

Figure 25 is a screen shot illustrating drug selection to be added to the patient current medication in accordance with the present invention.

Figure 26 is a screen shot illustrating available dates for past medication in accordance with the present invention.

Figure 27 is a screen shot illustrating a patient's medication history in accordance with the present invention.

Figure 28 is a flow diagram illustrating how a health practitioner may access clinical information on a patient, including, for example, past and current medication, pre-existing diagnoses, available model results and previous clinic visits in accordance with the present invention.

Figure 29 is a screen shot illustrating the required patient information for adding a new patient into the system of the present invention. Figure 30 is a screen shot illustrating the available patient information for editing in accordance with the present invention.

Figure 31 is a flow diagram illustrating how a health practitioner may add and edit a patient's profile, such as name, address, birth date, health plan, allergies, into the database in accordance with the present invention.

Figure 32 is a flow diagram illustrating how a health practitioner may select (a) procedure(s) for the current clinic visit, according to CPT or other international procedural coding system, in accordance with the present invention.

Figure 33 is a screen shot illustrating a drug compliance report within a given time frame in accordance with the present invention.

Figure 34 is a proprietary algorithm to determine drug compliance according to pharmacology category in accordance with the present invention.

Figure 35 is a screen shot illustrating the lab test results for a selected time frame in accordance with the present invention.

Figure 36 is a screen shot illustrating a specific lab test history in accordance with the present invention.

Figure 37 is a screen shot illustrating the manual addition of a new lab value in accordance with the present invention.

Figure 38 is a screen shot illustrating a manual addition of a new lab definition in accordance with the present invention.

Figure 39 is a screen shot of a treatment guideline menu for patients' past diagnoses. Clicking the diagnosis link allows the user to access generic or institution-specific treatment guidelines in accordance with the present invention.

Figure 40 is a screen shot of a specific treatment guideline in accordance with the present invention. Figure 41 is a flow diagram illustrating the management tools the user has at his/her disposal—treatment guidelines, prescription writing, and patient education in accordance with the present invention.

Figure 42 is a screen shot illustrating the input form for determining asthma severity via the GINA treatment guidelines in accordance with the present invention.

Figure 43 is a screen shot of multiple applications of the asthma severity input screen in accordance with the present invention.

Figure 44 is a screen shot of the results of one of the applications of the asthma severity input screen in accordance with the present invention.

Figure 45 is a flow diagram illustrating how a health practitioner may write a prescription online, then have the program automatically adjudicate for formulary inclusion, check for drug interactions and electronically send the prescription via email or fax to the pharmacy of the patient's choice or print out the prescription in accordance with the present invention.

Figure 46 is a screen shot for writing a prescription. A full interface is provided for the user to write a prescription for the current visit such as choose drug, enter SIG, frequency etc., user can also view the patient prescription history A full interface is provided for the user to write a prescription for the current visit such as choose drug, enter SIG, frequency etc., user can also view the patient prescription history in accordance with the present invention.

Figure 47 is a screen shot of choosing a drug by entering a few letters to search for existing drugs in the database for writing a prescription in accordance with the present invention.

Figure 48 is a screen shot of the drug search result list for the user to prescribe in accordance with the present invention. Figure 49 is a screen shot of the drug-drug, drug-food and other interaction information after the user attempts to prescribe a new drug for the patient. The patient's current medication information is used in accordance with the present invention.

Figure 50 is a screen shot of a full prescription, which the doctor can sign, print, and/or e-mail and the patient can have it filled in accordance with the present invention.

Figure 51 is a screen shot of a patient education menu for a patient's diagnoses. The user clicks a diagnosis link to view education information in accordance with the present invention.

Figure 52 is a screen shot that displays patient education material for a specific diagnosis, in this case, asthma in accordance with the present invention.

Figure 53 is a screen shot illustrating how a health practitioner may access continuing medical or continuing pharmacy education modules in accordance with the present invention.

Figure 54 is a screen shot of the pre-test questions for, e.g., the coronary heart disease model, for continuing medical education modules in accordance with the present invention.

Figure 55 is a flow diagram illustrating how a health practitioner may access continuing medical or continuing pharmacy education modules in accordance with the present invention.

Figure 56 is a screen shot illustrating how a patient may sign in in accordance with the present invention.

Figure 57 is a screen shot illustrating how a patient may register to use the system in accordance with the present invention.

Figure 58 is a flow diagram illustrating the system sign-in procedure for patients in accordance with the present invention.

Figure 59 is a screen shot of the specific questionnaires that are available for a patient to complete after the patient signs in successfully. Figure 60 is a flow diagram illustrating how the patient completes assessment questionnaires in accordance with the present invention.

Figure 61 is a screen shot illustrating how an administrator may sign in, using their ID and password, in accordance with the present invention.

Figure 62 is a screen shot of a menu illustrating administrative functions that may be performed within the system, including determining system usage, healthcare practitioner prescribing patterns, drug and healthcare resource utilization, quality assurance and patient population risk profiling in accordance with the present invention.

Figure 63 is a flow diagram illustrating the system sign-in procedure for administrators in accordance with the present invention.

Figure 64 is a screen shot of a menu illustrating system usage reports that are available for healthcare professionals or administrators in accordance with the present invention.

Figure 65 is a screen shot of a health professional usage tool that allows the system data to be indexed or filtered by time frame, specialty, group and diagnoses in accordance with the present invention.

Figure 66 is a screen shot of a health professional usage report that shows the number of eligible users, active users, eligible patients, active patients, unique diagnoses, total number of accesses to various health practitioner modules and the average number of accesses per user in accordance with the present invention.

Figure 67 is a screen shot of an administrator usage report that allows the system data to be indexed or filtered by time frame, specialty, and group in accordance with the present invention. Figure 68 is a screen shot of an administrator usage report that shows the number of eligible users, active users, total number of accesses to various administrative modules and the average number of accesses per user in accordance with the present invention.

Figure 69 is a flow diagram illustrating the system features available to administrators who have successfully signed into the system in accordance with the present invention.

Figure 70 is a screen shot of a prescribing pattern tool that allows the system data to be indexed or filtered by time frame, specialty, group, therapeutic drug class, and patient diagnoses in accordance with the present invention.

Figure 71 is a screen shot of a prescribing pattern report showing the therapeutic drug classes and the total number of prescriptions in each class. Clicking the therapeutic class links allows the user to drill down further to drug names in accordance with the present invention.

Figure 72 is a screen shot of a "drilled down" prescribing pattern report showing the therapeutic drug classes and the total number of prescriptions in each class. Clicking the list of drug names in a given class, and the total number of prescriptions for each drug. Clicking the drug name links allows the user to drill down further to see the prescribing physician names for a given drug, and the total number of prescriptions written by each physician in accordance with the present invention.

Figure 73 is a screen shot of a "drilled down" prescribing pattern report showing the prescribing physician names for a given drug and the total number of prescriptions written by each physician in accordance with the present invention.

Figure 74 is a flow diagram illustrating the generation of a report of prescribing activities based on, for example, individual prescriber, specific medication, and/or diagnosis code (prescription report) in accordance with the present invention.

Figure 75 is a screen shot of a menu illustrating administrative system data utilization reports, including healthcare resource utilization and drug utilization reports, that are available for healthcare professionals or administrators in accordance with the present invention.

Figure 76 is a screen shot of a healthcare resource utilization tool that allows the system data to be indexed or filtered by time frame, specialty, therapeutic drug class, and patient diagnoses in accordance with the present invention.

Figure 77 is a screen shot of a healthcare resource utilization report resulting from the indexes specified in Figure 76 and showing the basic patient profiles and the healthcare cost breakdown in accordance with the present invention.

Figure 78 is a menu of services available to allow the user to generate drug utilization reports from a pharmacy claims database. Data are uploaded to the present invention web site and results are sent back by e-mail in accordance with the present invention.

Figure 79 is a menu enabling the user to set up the data base to be evaluated. The functions available include uploading the database to the EB-Health system through file- transfer protocol (FTP), importing the data into MS SQL Server, mapping all necessary fields for generating drug utilization evaluation reports, converting 2-digit years to 4 digits to avoid Y2K problems, verifying data integrity in the imported database and tools for querying the database via a user-friendly interface in accordance with the present invention.

Figure 80 is a screen shot showing results of the drug utilization evaluation reports. Currently, available reports include average daily dose, drug compliance, dose adjustment analysis, drug utilization, and data integrity in accordance with the present invention.

Figure 81 is a flow diagram illustrating how an administrator may run drug utilization evaluation reports, including, for example, average daily dose and length of therapy, compliance switches in medication therapy, concomitant medications, dosage adjustment and utilization in accordance with the present invention. Figure 82 is a screen shot of a type of quality assurance report that would be accessed by administrator-users on Health Plan Employer Data and Information Set ("HEDIS") measure compliance. For example, this figure shows measures for the depression diagnosis, which include (1) Optimal Provider Contacts for Medication Management, (2) Effective Acute Phase Treatment and (3) Effective Continuation Phase Treatment in accordance with the present invention.

Figure 83 is a flow diagram illustrating how an administrator may run HEDIS reports, including, for example, measures for the depression diagnosis, which include (1) Optimal Provider Contacts for Medication Management, (2) Effective Acute Phase Treatment and (3) Effective Continuation Phase Treatment in accordance with the present invention.

Figure 84 is a screen shot of a menu that allows the user to characterize and stratify their patient population by specific diseases according to demographics, risk of hospitalization, actual vs expected hospitalization and cost components in accordance with the present invention.

Figure 85 is a screen shot of an asthma risk stratification report in accordance with the present invention.

Figure 86 is a flowchart detailing how the user selects a risk profiling report to view in accordance with the present invention.

Figure 87 is a flow diagram illustrating how a health practitioner may access or enter patient-specific demographic or other data and run disease-specific screening, risk assessment, and or cost-effectiveness disease outcomes models in accordance with the present invention.

Figure 88 is a screen shot of the decision-analytic Acute Otitis Media (AOM) Model in accordance with the present invention. Figure 89 is a screen shot of the AOM Model Input Screen in accordance with the present invention.

Figure 90 is a screen shot of the AOM Model results screen in accordance with the present invention.

Figure 91 is a screen shot of the decision-analytic Chronic Otitis Media (COM) Model in accordance with the present invention.

Figure 92 is a screen shot of the COM Model Input Screen in accordance with the present invention.

Figure 93 is a screen shot of the continuation from Figure 92 of the COM Model Input Screen in accordance with the present invention.

Figure 94 is a screen shot of the continuation from Figure 93 of the COM Model Input Screen in accordance with the present invention.

Figure 95 is a screen shot of the continuation from Figure 94 of the COM Model Input Screen in accordance with the present invention.

Figure 96 is a screen shot of the COM Model results screen in accordance with the present invention.

Figure 97 is a screen shot of the continuation from Figure 96 of the COM Model results screen in accordance with the present invention.

Figure 98 is a simplified state transition diagram for the Osteoporosis Model in accordance with the present invention.

Figure 99 is a diagrammatic representation of the Osteoporosis Markov Model input and output variables in accordance with the present invention.

Figure 100 is a Markov decision-analytic representation of the Osteoporosis Model in accordance with the present invention. Figure 101 is a screen shot of the Osteoporosis Model input screen in accordance with the present invention.

Figure 102 is a screen shot of the continuation from Figure 101 of the Osteoporosis Model input screen in accordance with the present invention.

Figure 103 is a screen shot of the Osteoporosis Model results screen in accordance with the present invention.

Figure 104 is a screen shot of the continuation from Figure 103 of the Osteoporosis Model results screen in accordance with the present invention.

Figure 105 is a screen shot of the Asthma Risk Model input screen in accordance with the present invention.

Figure 106 is a screen shot of a summary of results from multiple previous administrations of the Asthma Risk Model, which can be drilled down further to see results from individual administrations of the questionnaire (see Figure 107) in accordance with the present invention.

Figure 107 is a screen shot of results from an administration of the Asthma Risk questionnaire, e.g., on January 26, 2000, in accordance with the present invention.

Figure 108 is a screen shot of an example of one of the health assessment questionnaires — the Asthma Diagnostic Questionnaire in accordance with the present invention.

Figure 109 is a screen shot of results of the Asthma Screening Questionnaire in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Figure 1 sets forth the overall view of the system. The present invention comprises one or more computers, such as a personal computer 1, shown in Figure 2, or a related device, that includes a central processing unit ("CPU") 2, and memory, such as Random Access Memory ("RAM") 3 and may include Read Only Memory ("ROM") 4, and which is capable of producing printed output on printer 5 or other output device, and storing data on a data disk 6, which preferably is a floppy disk, or hard disk, although other types of storage media, such as a tape or ZIP DRIVE, may be used. In general, client computer or user- computer 1 should be equipped with a CPU of sufficient operating power and processing speed to run operating systems such as WINDOWS, WINDOWS 95, 98, 2000, WINDOWS NT, MACINTOSH, LINUX or similar systems. Preferably, a CPU such as an INTEL PENTIUM chip having at least about 133Mhz processing speed and 16MB of memory, has been found to be sufficient. The type of operating system is not critical. However, such operating system should be capable of running web browser software.

Preferably, client computer 1 should also be connected to several standard peripheral devices such as a monitor 7 capable of displaying images and output, a keyboard 8, and may also include a mouse 9 for use in running a WINDOWS, or similar, operating system.

In addition, the client-user computer 1 should be configured in such a way as to be capable of accessing a public network, for example, the Internet, including the World Wide Web, or private network, such as an Intranet. Computer 1 should also be equipped with a modem, or be capable of being equipped with a modem 10, or other means of sending and receiving electronic data over telephone lines, or other transmission lines, such as fiber optics and cable. Client computer 1 should be configured with web browser software, such as NETSCAPE NAVIGATOR (version 4.x or higher), MICROSOFT INTERNET EXPLORER (version 4.x or higher), or other available web browsers that support Java applets and Java script, and that accept "cookies". Preferably, computer 1 is configured so as to be capable of being networked with other computers, such as those on the Internet, by, for example, being connected to an Internet Service Provider ("ISP"). The present invention is implemented by utilizing the World Wide Web using standard client-server web technology wherein the client computer 1 comprises a web browser, and the server 20 comprises a web server 22, as shown in Figure 3. The client initiates a request to the server by sending a web address, known as a uniform resource locator ("URL") that is entered into the web browser by typing the relevant URL into the browser window, using keyboard 8, or by clicking a link or a button on the displayed browser web page. The server responds by sending an acknowledgment or results back to the client. Depending on the request type, the server either returns a static web page, or the dynamic results of processing the request, which are then displayed back to the client-user's window.

The client or user uses the process of the present invention as follows. After booting up computer 1, the user of computer 1 runs his or her web browser software for initiation of the connection with server 20. The client-user connects to server 20 by typing in and entering the URL or web address of server 20, e.g., http://www.EB-Health.com. into the client-users web browser address box which is sent over the Internet 10 to connect computer 1 with server 20.

Preferably, server 20 may consist of multiple computers, as shown in Figure 2 all linked to each other via a high-speed network. In the alternative, all three servers could reside in one computer. As another alternative, the servers could be distributed across multiple computers e.g., via a local area network ("LAN"), in order to reduce the workload on a given computer, effectively speeding up the whole operation.

For example, as shown in Figure 3, the system of the present invention may use three kinds of servers: (1) a web server 22 to interact with users on the Internet using the standard Hypertext Transfer Protocol "HTTP" and by sending Hypertext Markup language "HTML" or JavaScript documents; (2) an applications server 24 to execute various modules in the system that comprise the execution of the model engines or algorithms described below, and (3) a database server 26 to process data-related operations, such as data retrieval, storage, and queries. As explained further below, processed data is stored in database server 26 by using Active Data Objects "ADO" calls to save new data to the database via an Open Data Base Connect "ODBC" connection.

Once connected with server 20 of Figure 2, server 20 will generate onto the screen of monitor 7 of computer 1 an initial sign-in screen display such as that shown in Figure 4. The user clicks or selects one of the sign in options, e.g., Health Care Practitioner, shown in Figures 4 and 5 (flow chart of sign in procedure). The system will then generate the screen display shown in Figure 6 prompting the user of computer 1 to sign in by entering user identification ("UserlD") and password data into the input boxes, or to register with the system by clicking the "click here to register" link in Figure 6, and completing the registration form in Figure 7.

If the user is already registered with the system, the user will select or click on the appropriate level, e.g., practitioner, patient or administrator, sign in button. As shown in Figure 8, the system of the invention will determine which level the user has selected and pass the request to the corresponding sign in procedure. As shown in Figure 8, the web server will check to verify that the identification and password data matches that stored in the system. If not, as shown in Figure 8, the system will display an error message. If the patient information does not match that in the system, the web server will generate an error message with a suggestion that the user register first. When the user name and password data matches the user level, the system will generate the system main menu screen of Figures 9 and 10, which provides a list of various menu options for using the processes of the present invention. The screen menus used in the present invention can be constructed by using standard software such as an HTML editor. Figure 7 shows the form by which a new healthcare professional-user may register with the system of the invention. Once the user inputs user data into the registration form, web server 22 of Figure 2 saves that registration data, emails the data to system administrators, and then outputs a display indicating that registration is complete. The user may then sign in to the system as described above.

The above-described procedure ensures that only authorized users are permitted to access server 20 of Figure 2. Server 20 maintains three different levels, as shown in Table I, below, which summarizes the access levels, permitted operations, and available data and functions for three user groups in the healthcare field: (1) healthcare practitioners, (2) patients, (3) healthcare administrators or case managers.

Table I

User Access Levels. Permitted Operations And Data

Server (Figure 2, 20) is also configured to provide patient-users with access to data containing electronic versions of various forms and questionnaires that patients can complete as requested by their physicians. Since these forms and questionnaires are accessible via the Internet, the patient has the flexibility of filling out the form or the questionnaire in the privacy of their own home before the actual clinic visit.

Patient data can be assembled when the physician-user, or other health practitioner, enters the patient data into the system by completing online forms. Patient data can also be obtained from other legacy database systems such as claims, billing or electronic medical records. Patient data bases include International Classification of Disease, or "ICD" codes, such as International Classification of Disease, 9th edition, "ICD-9," which is a standard coding system for patient diagnosis. The system of the present invention also allows for identification of diagnoses using ICD- 10 and Systematized Nomenclature of (Human and Veterinary) Medicine (SNOMED) diagnosis coding systems.

When entering patient data, the physician-user selects a coding system and a code to diagnose a patient (see Figure 11). This information is then captured by the system and linked to the patient prescriptions, labs, and other resources for that patient. The purpose of the data linking utilized by the present invention is to associate the resources used by the patient to the diagnosis so that diagnosis-specific resource use reports can be generated.

The data bases of the present invention that are available to users are compiled by several means, including, but not limited to, manual input of information from patient medical files, electronic accessing and retrieval of available patient claims data from care providers or insurance companies and health maintenance organizations ("HMOs"), electronic retrieval of electronic medical records ("EMRs") data, or other legacy or preexisting databases. For example, the data sets utilized herein are comprised of patient and disease demographic information, information obtained from laboratory records, records pertaining to patient visits to medical specialists, clinics, and emergency rooms, records relating to patient hospitalizations, insurance claims, and pharmacies or other related data. The data bases utilized in the present invention are set forth in Figures 12 and 13.

Figure 12 depicts the record layout for the main tables used in the present invention. Data is incorporated into the systems of the present invention by using standard database connections, for example OPEN DATA BASE CONNECT ("ODBC"), ACTIVE DATA OBJECTS ("ADO") and REMOTE DATA OBJECTS ("RDO"), that map the elements of disparate external data bases into a relational data base structure, such as that shown in Figure 12. Future standard of database connectivity could be incorporated into the system.

Figure 13 depicts the one-to-one and/or one-to-many relationships between the data tables. These database schemes were designed and built manually. Data are stored in the databases by executing an SQL statement or by direct access using ADO or ODBC technologies. The system of the present invention implements data from the data bases, Figures 12 and 13, by using a mixture of Active Server Pages (ASP) and Cold Fusion. ASP connects to the database using ADO, and Cold Fusion connects using ODBC. Returning to the user's perspective, upon successful sign-in, server, Figure 2, 20, generates the menu appropriate to the user's access level. For example, server 20 generates a 'select patient' form (as shown in Figures 14 and 15), which enables the physician-user to enter patient identification data, e.g., last name, first name, middle initial, in one or more input boxes and thus cause server 20 to generate a list of patients who meet those criteria, as shown in Figure 16, from patient data bases linked to patient identification in HTML format, as shown in Figure 15. The physician user is thus enabled to select and access data on one or more patients that have come into the physician's office for treatment and/or consultation. Such data may include, but are not limited to, patient first and last name, middle initial, a unique patient identifier "PID", birth date, pre-existing diagnoses, allergies, available model results (which are obtained as explained below), and previous visits with affiliated ICD-9, ICD- 10 or other diagnostic codes that apply to a particular patient or patients. This information is generated by server 20 on physician-user menu Figure 17, in a user- friendly HTML format. In addition, if the patient has a disease for which an economic model is available, data for this economic model is shown on the physician menu.

In connection with the treatment and evaluation of the subject patient, the physician- user, as shown in Figure 17, may access one of several patient management data bases and tool sub-menus linked to the top menu tab in HTML format, such as the "Patient Info" tab (with sub-menus "result list", "lab tests", "drug compliance", "problem list", "current meds", and "med history"), as shown in Figure 18, the "Select Diagnosis" tab, and "Management Tools" tab (with sub menus "treatment guidelines", "write prescription", and "patient education"). For example, the data bases of the present invention contains an extensive, if not complete, list of possible diagnoses. When the physician-user clicks on the "Select Diagnosis" menu tab, server 20 generates the screen display shown in Figure 11, which enables the user to select a set of diagnoses for the current visit by checking the boxes in front of the diagnosis names. If the desired diagnosis is not in the list, the user may click the "add diagnosis" button, and server 20 will generate the screen display shown in Figure 19. The user proceeds by typing a keyword into the input box to list relevant diagnoses, in this case for depression, which causes server 20 to generate categories of potential depression diagnoses correlated to the corresponding ICD9 codes that best describes the patient's condition. Once the diagnosis selection has been completed, the user clicks the "next" button, and server 20 generates the confirmation screen shown in Figure 20, for which the user can characterize a severity (e.g., mild), and date of onset. This process is outlined in the flow chart in Figure 21.

The diagnosis database can be constructed using standard medical coding (ICD-9, ICD- 10, SNOMED) for all possible diagnoses, along with a brief description of the diagnoses. Information for such data bases can be derived from published medical texts and can be entered manually into the system of the present invention. However, to expedite the building of the diagnosis data base, it is useful to locate electronic versions of diagnosis information from various sources such as medical databases, the Internet, or commercially available third-party software, and import such data into the system database.

To further the physician-user's evaluation of the patient, the user can click on the other sub menus, for example, "problem list", "lab tests", etc., to access any of the various menus shown in Figures 12 and 18. By clicking the underlined HTML links, the physician- user selects the appropriate menu from the list. As shown in Figure 13, the menu selection is transmitted to the appropriate data base of the system. As shown in this figure, the web server displays the heath practitioner user menu options, and returns the menu corresponding to the desired operation. For example, if the user selects "add patient" the system will return the add patient menu, and so on. Also, as shown in Figure 18, if the user selects the "evaluate" link, the system will return the corresponding model input screen and the user may then run the cost effectiveness/ health risk assessment/ probability models described below. When the chosen menu operation is selected, the system will then perform the requested operation and transmit back the results for viewing on screen by the user. For example, the "problem list" menu of Figure 22 contains windows for time frame data entry. Once this data is entered server 20 generates diagnoses made for the subject patient that correlate to past patient visits and ICD9 codes, as shown in Figure 23.

Also included in patient info is the opportunity to review current medications and add new medications, as shown in Figures 24 and 25. Moreover, it is possible to review a patient's medication history, by date, as shown in Figures 26 and 27. A flow diagram of the patient info tab, including the interrelation between all of these components is shown in Figure 28.

Server 20 of Figure 2 is thus configured to generate the following for a pre-selected time frame:

Store/ Add Patient Data: As shown in Figures 29, 30 and 31, the web server displays the "add patient" input form. The user enters patient data by completing the form, the server saves patient data in the data bases described in Figures 12 and 13 and displays output to the user showing that the patient information has been stored.

Select/Retrieve Patient Data: The web server displays the "select patient" form, as shown in Figures 14 and 15. The user enters the first few letters of the last name, first name, or middle initial of the patient whose data is desired. If the web server determines that there are matching names in the data base, the server displays the matching names, with patient identification, gender and birth date as shown in Figure 16. If not, the server outputs a display that no patient was found. Select Diagnosis: As shown in Figure 11, the web server displays the "search diagnosis" form, and the user enters a few letters of a diagnosis description. If the server finds a matching diagnosis in the database, the server displays matching diagnoses with ICD9CM codes. The user then selects one of the diagnoses in the returned list, sets the diagnosis as primary or secondary, and enters the severity level as shown in Figure 20, by way of example. The server then saves the selected diagnosis for the patient in the system data base. If no diagnosis is found in the database, the server outputs a display message to that effect.

Select Procedure: As shown in Figure 32, the web server displays a "search procedure" form, and the user enters a few letters of a procedure description. If the server finds a matching procedure in the database, the server displays matching procedures with CPT codes. The user then selects once of the procedures in the displayed list, and the server then saves the selected procedure for the patient in the system data base. If no procedure is found in the database, the server outputs a display message to that effect.

Medication Compliance: As shown in Figure 33, data concerning the patient's medication history is provided. The system of the present invention calculates checks on patient medication compliance based on the process methodology described in Figure 34, according to the pertinent pharmacology category, to determine whether the patient has been compliant with his or her prescribed medication regimen.

As shown in Figure 33, to run the compliance operation and algorithm, the web server displays a time frame input form, which is completed by the user for a particular patient. The system then runs a compliance algorithm, such as the one described in Figure 34, based on the patient's prescription data stored in the data base. The server then displays the patient's drug compliance for the selected time frame. The compliance algorithm of Figure 34, as applied by the system of the present invention, measures whether the patient has been taking his or her medication regularly as prescribed by the physician. It is an important measure to explain why the patient may not be getting well. The system measures compliance by analyzing data concerning patient prescription records which is stored in data bases shown in Figures 12 and 13. Figure 34 describes the process by which patient compliance is determined, including the percentage of time an individual patient is compliant, or the percentage of a patient group that is compliant with respect to a particular medication.

Problem List: As shown in Figure 22, server 20 generates and displays data concerning patient diagnoses for prior visits by visit date, and diagnoses according to the diagnostic coding system.

As shown in Figure 22, this operation is initiated when the web server displays a time frame input form, which is completed by the user for a particular patient. The server searches the data base for a patient diagnosis within the time frame and displays a diagnosis list with dates, as shown in Figure 23.

Lab Tracking: As shown in Figure 35, server 20 generates and displays available laboratory information for the patient. If electronic data are not available, it allows for manual entry of lab data. Historical laboratory information for the patient is displayed. As shown in Figure 36, this operation is initiated when the web server displays a time frame input form, which is completed by the user for a particular patient. The server searches the data base for the patient's lab test data and outputs a display with that data, as shown in Figure 36. The user can also manually add labs, as shown in Figure 37, and new lab definitions, as shown in Figure 38. Disease Severity Tracking: As shown in Figure 20, server 20 also generates and displays disease severity information for the patient. If electronic data are not available, it allows for the manual entry of disease severity data. Historical disease severity information for the patient is displayed.

Treatment Guidelines: As shown in Figure 24, this operation is initiated when the web server displays a list of diagnoses for a particular patient. The user clicks or selects one of the diagnoses. The server searches, retrieves and then displays treatment guidelines for the selected diagnosis. Based on the treatment guidelines for the patient's disease, the system of the present invention also interfaces with and automatically inserts alerts into the user's scheduling software indicating the follow-up steps and schedules those events. The alert system can be built using the ASP, ADO, ActiveX Object, SQL, Java and Cold Fusion software tools, which are loaded onto application server of Figure 2, 26. When the physician- user logs into the system of the present invention, an alert menu option is displayed to the user showing a list of outstanding patient follow-ups such as clinic visits, labs, diagnostic tests, etc., which the user can choose to print out first thing in the morning. This function alerts the user about any interventions that either have not been performed or are due to be performed based on the patient's prior encounter history according to the institution-specific guidelines, as shown in Figures 39 and 40.

Once provided with the data and results given above, the physician-user can determine if modifiable factors, i.e., conditions concerning the patient which can be changed, exist, for example, non-compliance with medication regimes, and will be able to select from several tactics or treatment guidelines generated by server 20 and displayed on the user's computer screen as shown in Figure 41. The tactics are displayed on the screen as menu options. The physician-user selects the desired treatment guidelines by clicking the appropriate menu option. The treatment guidelines can be derived based on the physician's need to be able to access and input key patient information quickly and efficiently into the system, by inputting patient information into a menu screen. The resultant output is displayed on the screen shown in Figure 41.

In addition to the "static" guidelines (i.e., listing of institution-specific guidelines), there are "interactive" treatment guidelines available for several disease states in the "evaluate" mode as previously described in the Patient Info evaluate link. In this case, using asthma as an example, once a diagnosis or treatment is selected, server 20 generates onto the physician-user's scheme an input form as shown in Figure 42. As shown in Figure 42, windows are provided for data entry concerning the patient and disease-specific information which is transmitted to server 20. This data is encrypted for privacy protection by the Secure Sockets Layer standard for data encryption so that it may be safely sent by the user to server 20 over the Internet. Results are demonstrated in Figures 43 and 44.

Prescription Writing: The system writes, adjudicates, checks for drug interactions, and electronically sends the prescription to the pharmacy of the patient's choice, and prints out a prescription as shown in Figure 45. As shown in Figure 45, this process is as follows: (1) The web server displays a prescription input form, as shown in Figure 46. The user completes the prescription input form, with prescription information such as the selected drug, as shown in Figures 47 and 48. The system then determines whether there is any drug interaction associated with the prescription and, if there is, the web server displays a drug interaction warning, as shown in Figure 49. The system then requests if the user wishes to modify the prescription. If so, the user is routed back to an input form. If there is no modification requested, the user enters data into the system, which provides a reason for overriding the interaction warning. The web server then saves the prescription in the system data base, and displays the prescription with an option to print, as shown in Figure 50. The user can then print the prescription. As shown in Figure 50, if there are no interactions, the web server will directly save the prescription and go to the print option.

Patient Education: As shown in Figures 51 and 52, the web server displays a list of diagnoses for a patient. The user selects one of the diagnoses, and the web server displays patient education for the selected diagnosis.

Continuing Pharmacy/Medical Education: This process accesses customized medical or pharmacy education programs which can be printed or are available on computer software. The educational component is primarily associated with the disease outcomes models described below. Within each disease model there is background information that briefly reviews the disease state and relevant health economic literature. In addition, the physician learns about the model and how to interpret the results. For continuing medical education, "CME", purposes, the applicants have implemented a pre- and post-test evaluation. Part of the didactic component requires the physician to run various patient scenarios through the model and interpret the results for the post-test. Additionally the program allows the physician to run his own patients through the model and submit the interpretation for review for further CME credit. Thus, the program offers the opportunity for both traditional (pre/post-test, didactic material) and non-traditional CME formats.

As shown in Figure 53, the web server displays a list of available CME/CPE models. The user selects one of the listed models available on the system of the present invention. The server displays an output of pre-test questions, as shown in Figure 54, and the user inputs answers to the pre-test questions. The server scores the test and saves the answers in the system data base. The server then displays model and disease-specific information; the user reads the information and selects 'continue', wherein the server then outputs a display list of post-test questions. The user then answers the post-test questions, which the server scores and saves the answers to the system data base, as shown in Figure 55.

Patient assessment/screening programs: After the patient signs in, as shown in Figure 56, or registers, as shown in Figures 57 and 58, he or she is presented with a menu of the appropriate assessment/screening programs. As shown in Figure 59, these tools include any disease screening tools available that the end user is interested in applying (e.g., the Patient Health Questionnaire (PHQ), Beck Depression Inventory, Quality of Life Assessment, Vermont Disability Scale, Migraine Screening Questionnaires, Patient Satisfaction Surveys, CIDI, SF-36, WHOQoL) within the system of the present invention. Results are tracked, where appropriate, after sequential administration of the form to the same patient. The risk assessment feature operates as follows: Patients sign in and complete the forms for the risk assessment. Alternatively, when there are some missing data within the system for a particular patient the physician completes the forms for risk assessment. The system then scores and saves the results in the databases. When the physician accesses that patient's record, the physician can view the model results by clicking the 'risk', 'severity' or 'evaluate' button next to that diagnosis, as shown in Figure 18.

As shown in Figure 60, this operation is initiated when the web server displays the patient assessment menu. If the user patient does not exit the system at this point, she can select a listed questionnaire, which the server will display. The user completes the selected questionnaire and the server saves the information and the user is routed back to the patient assessment menu to exit or select another questionnaire.

Administrative Reports: As shown in Figures 61-81, healthcare administrator-users, for example those employed by a patient's insurance company or HMO, have access to data concerning healthcare administrative functions stored on server 20 of Figure 2. Administrative function data includes, for example, system usage reports for healthcare professionals (report for selected criteria, as shown in Figures 64, 65 and 66), system usage reports for administrators (report for selected criteria, as shown in Figures 67, 68 and 69), a data report of prescribing patterns based on, for example, time frame, health practitioner specialty or group, medication drug class, and/or diagnosis code (i.e., prescribing report, as shown in Figures 70-74), resource utilization reports of data that detail, for example, total units and total costs for different cost centers based on selected parameters such as the International Classification of Disease, 9th edition ("ICD9") codes (standard codes for patient diagnosis), patient medication, date information for patient visits and treatments, and physician specialization (i.e., healthcare utilization report, as shown in Figures 75 through 77), and drug utilization evaluation reports such as average daily dose, drug compliance, dose adjustment analysis, and drug utilization for a selected therapeutic class and time frame (See Figures 78 through 81).

Quality Assurance/DUE and NCQA: Administrator-users can also obtain Drug Utilization Evaluation ("DUE") reports, which include information such as: average daily dose and length of therapy, average number of switches in medication therapy, average number and ranking of concomitant medications used, average number of dosage adjustments, etc. DUE reports are accessed by the user when he or she selects the 'Drug Utilization Reports' menu option in Figures 75 and 78. The data bases used in generating DUE reports are set forth in Figures 78 and 79.

The administrator-user can also access reports on Health Plan Employer Data and Information Set ("HEDIS") measure compliance. For example, as shown in Figures 82 and 83, measures for the depression diagnosis include (1) Optimal Provider Contacts for Medication Management, (2) Effective Acute Phase Treatment and (3) Effective Continuation Phase Treatment. HEDIS compliance reports are particularly useful since the development of managed care organizations ("MCOs") during the 1990's has led to a great deal of competition between the many available plans for contracts with the nation's employers.

In order to help create a market with perfect information, from which employers can make informed decisions based on quality and performance, the National Committee for Quality Assurance (NCQA) has been formed. The NCQA is an independent, non-profit accrediting organization whose mission is to conduct objective assessments on the quality of the nation's managed care plans. Comprehensive reviews are conducted by teams of managed care experts and physicians. Accreditation is granted to the managed care plans that meet the high standards of quality set forth by the NCQA. The NCQA manages the principal measuring tool, HEDIS, for assessing achievements of managed care plans. HEDIS is a set of 71 performance measures that allow for the subjective evaluation of the processes and outcomes of interventions performed by the participating health care professionals within the MCO's management. It shows how well a plan's abilities translate into results (improvements in patients' quality of life).

The system of the present invention has developed models to help MCOs meet the clinical standards set forth by HEDIS. Using the example of childhood acute otitis media (AOM), HEDIS requires reporting of how often the recommended antibiotic is not prescribed to children. The system of the present invention uses a model, as described below, that can be run individually for each child who presents with AOM in order to make prudent prescribing choices. Not only does this prevent doctors from making the wrong antibiotic choices, it can allow for computerized documentation on the therapeutic and pharmacoeconomic rationale of the decision. The system of the present invention has the advantage of being Internet-based, making its potential availability very widespread. Another example is the three measures being employed for depression. Specifically, the system of the present invention has been designed to provide the following reports to MCOs: 1) Optimal Provider Contacts for Medication Management (Percentage of adult patients with depression that had a minimum of three follow-up contacts with a primary care provider or mental health provider during a 12-week Acute Treatment Phase); 2) Effective Acute Phase Treatment (Percentage of adult patients with depression that remained on antidepressant therapy for the entire 12-week Acute Treatment Phase); and 3) Effective Continuation Phase Treatment (Percentage of adult patients with depression that remained on antidepressant therapy for the entire 6-month follow-up phase).

As shown in Figure 76, NCQA-HEDIS reports are accessed by selecting a 'QA' menu option (one of the blue tabs), and completing a displayed NCQA input form. The system generates the report by running the queries and code that implements the HEDIS algorithms as specified in the most current NCQA's HEDIS Technical Specifications. The web server displays the NCQA report to the user. Similarly, DUE reports are created by selecting a DUE menu option and completing a displayed DUE input form, wherein the sever retrieves the report and outputs a display thereof for the user.

Risk Profiling: Population Risk Reports can be accessed that detail disease-specific population profiles. Server 20 of Figure 2 is configured so as to provide administrator-users with access to data aggregate reports. For patient confidentiality reasons, data concerning patient-specific details, are generally not available to administrators. Server 20 is also configured to provide physician-users with access to data concerning patient management unctions applicable to the physician's own group of patients. For example, as shown in ~es 84 through 86 for the asthma population, the objective is to characterize the population according to risk categories for hospitalization in the next year. This will identify individual patients, by provider, who are at various levels of risk for hospitalization.

Printing: It should be noted that the physician or administrator can print any one of the screens previously accessed as a permanent record in the patient's chart or for other documentation purposes. All of the screens generated according to the present invention can be printed using the standard web browser's print menu. To exit the program, the user closes the web browser window or quits the user's web browser program.

Evaluate Models: As discussed below, the system of the present invention contains and implements a number of methods for determining the probably risks and cost effectiveness of therapies for disease states according to models built by the inventors. As shown in Figure 18, to access the model operation, the user selects a model from a list of available models for a patient displayed by the web server. The server searches the data base of the system for patient data relevant to the selected model, and outputs a display showing a pre-filled form for the selected model. The user then completes the model input form. The server runs the model with the given input, and saves the data into the data base. The web server then outputs a display of the results to the user, which may contain graphical information.

THE MODEL ENGINES

The Overall Process. Server 20 is configured to process the data entered by the physician-user and others by use of database engines or methods according to certain decision tree models, Markov models, logistic regression equations or other algorithms. The models that can be implemented by the present invention include, but are not limited to, those for acute otitis media, chronic otitis media, osteoporosis, and asthma, as described in examples 1 - 4 below, and as shown in Figures 87 to 109. Figure 1 sets forth the overall process of the system of the present invention, and the manner in which the model algorithms fit into the system. As shown in Figure 1 , after the user boots up his computer and runs her internet browser software, she points the browser to the system web site and signs in with her username and password in the menu screen as shown in Figure 3. The web server of the present invention Figure 2, 22, verifies her user identification and password, determines the corresponding user access level and displays the appropriate user menu such as that shown in Figure 4. Database server, Figure 2, 24, will generate data and information concerning the patient of interest.

The user may also select and input into the system a disease diagnosis, for example, osteoporosis, as well as a corresponding disease cycle for the purpose of requesting a determination of the various cost and effectiveness parameters for the disease, for example, one year. In general, web server 22 of Figure 2 forwards the user request to the application server 26, which performs the requested operation of determining the probable disease outcomes and costs throughout the disease cycle according to the appropriate disease model, such as those described below and in Figures 87-109. The application server 26 of Figure 2 stores and retrieves data from database server 24, which handles the data processing. The results are returned to web server 22, which transmits the results back to the user computer 1.

The system also determines whether there are any probable co-morbidities associated with the disease and, if not, will provide output indicating that the patient is in the "well state." If probable co-morbidities exist, the system will determine those co-morbidities that may be associated with the disease state or treatments contemplated, for example, in the case of osteoporosis, the probability of developing breast cancer due to estrogen treatment, and display output data concerning such co-morbidities. The algorithms applied by the system of the present invention will then determine the patient costs of the co-morbidities, for example, the costs associated with hip fracture treatment, and provide a composite out put display of those costs.

Again, referring to Figure 1 , the user can select and/or input various treatment options for use in attacking the particular disease. The system of the present invention applies the model algorithms to determine the probable outcomes for the disease per treatment option, and displays output of such probable outcomes per treatment option. The system will also determine the cost per treatment, and output or display such cost. Based on these data, the preferred cost-effective treatment can be selected by the user.

Finally, as shown in Figure 1 , the user may also decide whether a prescription for the patient is needed and, if so, select a prescription. The system will then display such prescription and print or write it for the user.

As shown in Figures 87-109, the system of the present invention employs disease- specific models or algorithms, such as decision tree models, logistic regression equations, questionnaires with an online scoring and tracking mechanisms, and other methods of assessing (1) an individual patient's risk of developing a certain illness or (2) the most appropriate treatment pathway for that patient given certain characteristics (e.g., age, gender, previous medical history) specific to that patient.

The algorithms or models are implemented by the present invention via Visual Basic, Cold Fusion, or Active Server Pages in server 24 of Figure 2. Relatively simple models can be coded directly into the computer system of the present invention by using VISUAL BASIC SCRIPT or COLD FUSION MARKUP LANGUAGE. The more complex models of the present invention may be coded into the system by using, for example, a decision tree- building program such as Data Analysis from TreeAge Software, Inc., of Williamstown, MA ("DATA™"), to produce decision trees that are accessed from within the system of the present invention using ACTIVE DATA DLL.

Each model is disease-specific, and could simply be a formula or a decision tree. According to the present invention, applicants have used DATA™ to implement the decision trees such as those shown in Figures 88-97, the Otitis Media Decision-Analytic Model Decision Trees.

As shown in Figures 87 and 109, for example, the disease model algorithms of the present invention are designed to mimic as closely as possible, in a computing environment, the physician's medical practice in terms of evaluating and treating patients. To build the models of the present invention, typically, the medical, scientific and economic literature is reviewed, for example, by a search of MEDLINE, the Internet, and other published and unpublished sources, to discern the dilemmas facing the clinician in diagnosing and/or treating a patient within a particular disease state. Preferably, prior to adoption by the system of the present invention, these models should be reviewed with qualified medical advisory panels, selected on the basis of their expertise in the particular disease area. The process can then be modified accordingly.

The model engines of the present invention reflect, in computer-implemented process terms, how clinicians diagnose or treat patients. For example, otitis media currently represents a costly disease state that is frequently encountered by clinicians. Chronic otitis media, characterized by effusion without signs or symptoms of an ear infection, is a common childhood illness. This disease state is often associated with impairment of hearing, which could have detrimental effects during crucial stages of language development in children. A review of the literature reveals that different strategies are employed in the treatment of this disease state, including: observation, pharmacologic therapy, and placement of tympanostomy tubes. These strategies were incorporated into the model shown in Figure 91. The model, as described below, provides rapid and efficient assistance to the clinician in determining the most cost-effective therapeutic sequence by mimicking the decision and outcome sequences electronically. The models incorporated into the system of the present invention are described as follows:

Example 1 The Acute Otitis Media ("AOM"l Model Background

Acute otitis media ("AOM") is characterized by inflammation of the middle ear, which presents itself with a rapid onset of symptoms including fever, pain, and irritability. AOM involves a bulging or opacification of the tympanic membrane (with or without erythema) accompanied by at least one of the following signs and symptoms of acute infection: fever, otalgia, irritability, otorrhea, lethargy, anorexia, vomiting or diarrhea, and the absence or marked decrease in mobility of the tympanic membrane. See Rosenfield RM, Vertress JE, Carr J, et al. Clinical efficacy of antimicrobial drugs for acute otitis media: meta- analysis of 5400 children from thirty-three randomized trials. J Pediatr 1994;124:335-367. In clinical trials, bacteria are cultured from middle ear aspirates in approximately 70 percent of children with AOM. See American Pharmaceutical Association. Management of pediatric acute otitis media. In: APhA Guide to Drug Treatment Protocols, 1997;p. AOM-1 - AOM-8. The most common causative organism is Streptococcus pneumoniae, accounting for 20 to 50 percent of the isolates. Haemophilus infiuenzae is the next most prevalent organism, representing 14 to 31 percent of the isolates. Other causative organisms include Moraxella catarrhalis (2-16 percent), Staphylococcus aureus (1-11 percent), and Streptococcus pyogenes (1-5 percent). Otitis media accounts for 33 percent of all medical office visits in the United States. See American Pharmaceutical Association. Management of pediatric acute otitis media. In: APhA Guide to Drug Treatment Protocols, 1997;p. AOM-1 - AOM-8. Seventy-five percent of children have one or more episodes of otitis media by six years of age. See Lanphear BP, Byrd RS, Auinger P, Hall CB. Increasing prevalence of recurrent otitis media among children in the United States. Pediatrics 1997;99(3). Among infants, approximately 17 to 29 percent have at least one episode of AOM, with 10 percent of these infants experiencing three or more episodes. The incidence of AOM generally peaks between the ages of 6 and 15 months. See Del Mar C, Glasziou P, Hayem M. Are antibiotics indicated as initial treatment for children with acute otitis media? A meta-analysis. BMJ 1997;314:1526-9.

The cost of treating AOM is considerable because of its high prevalence and incidence among U.S. children. Over the past two decades, the number of clinic visits for otitis media in the United States has increased dramatically, rising from 9.9 million in 1975 to 24.5 million in 1990. The increase has been predominantly in children less than 15 years of age. See Lanphear BP, Byrd RS, Auinger P, Hall CB. Increasing prevalence of recurrent otitis media among children in the United States. Pediatrics 1997;99(3). The total annual cost of treatment for AOM has been estimated to be between $3 billion and $4 billion. See Gates GA. Cost-effectiveness considerations in otitis media treatment. Otolaryngol Head Neck Surg 1996;114:525-30. Antibiotics are prescribed in 97.9 percent of cases in the U.S., with a cost of approximately $3 billion annually. See American Pharmaceutical Association. Management of pediatric acute otitis media. In: APhA Guide to Drug Treatment Protocols, 1997;p. AOM-1 - AOM-8.

The National Committee for Quality Assurance (NCQA) has developed strategies to establish accountability in the managed care industry, implementing the Health Plan Employer Data and Information Set (HEDIS) as a set of standardized performance measures. Treatment of children's ear infections is a HEDIS 3.0 measure, which is required for reporting by the NCQA's Committee on Performance Measurement. See National Committee for Quality Assurance. Treating children's ear infections. In: HEDIS 3.0, 1996; p. 136-138. This specification uses membership, claims/encounter, and pharmacy claims data to identify children at least 6 weeks old but less than 60 months old who were continuously enrolled during the six months immediately preceding the diagnosis of an uncomplicated episode of AOM and who were not dispensed a preferred antimicrobial agent (amoxicillin or trimethoprim-sulfamethoxazole). An uncomplicated episode is defined as no prior diagnosis of acute or chronic otitis media for 6 months preceding the first episode in the reporting year, and no infectious comorbidity or underlying disorder of immunity that may affect antimicrobial selection. Therefore, for accreditation purposes and to establish quality of care, managed care organizations are increasingly focused on demonstrating cost-effective management of otitis media. Rationale

Otitis media represents a costly disease state that is frequently encountered by clinicians. In order to select the most cost-effective treatment option, clinicians need to consider various factors such as local resistance patterns, adverse effects of the antibiotics, and resource use associated with managing successfully-treated patients as well as treatment failures. Such information may not be readily available to the clinician at the point of prescribing. The AOM model implemented by the present invention assesses the comparative cost-effectiveness of different treatment options for AOM, taking into account the patient's age and the above-mentioned factors, providing the practitioner with a practical tool in the clinical decision-making process. Model Description The AOM tool of the present invention is a decision-analytic model that evaluates a group of patients with the same characteristics as the patient currently being evaluated by the end-user. See Weinstein MC, Fineberg HV, Elstein AS, et al. Structuring clinical decisions under uncertainty. In: Clinical Decision Analysis, Philadelphia:Saunders, 1980, p. 12-35.

The AOM model assesses the most cost-effective therapy for the patient by evaluating the data entered by the end-user (e.g., age, weight), the effect of antibiotic therapy, and assessing the institution-specific costs associated with the various antibiotics which are selected by the end-user. Preferably, the model addresses acute treatment, not prophylaxis, for an episode of AOM requiring either a single antibiotic course or multiple antibiotic courses. The diagram below depicts a simplified representation of the AOM model. In the model, each antibiotic is evaluated, including the consequences of treatment with the antibiotic, and the probable outcomes (e.g., adveise events) for the patient as a result of treatment. Cost, effectiveness (chance of successful treatment), and cost-effectiveness are determined for each antibiotic that is selected for an individual patient. The model is based on local practice recommendations, a literature review, and data from a pharmacy benefits organization. The full details of the AOM model are set forth below and in Figure 88.

Diagrammatic Scheme of the AOM Model

Data Variables Processed in the AOM Model

Data input into the AOM model (see Figures 88 and 89) include efficacy data for each drug, serious adverse event ("SAE") probability data, and cost data (physician office visits, antibiotic therapy, and SAEs) for the treatment of AOM. The probability of an infection resolving with one course of antibiotics is segregated into six age groups (< 1 year, 1-3 years, >3-5 years, >5-10 years, >10-18 years, >18 years). Preferably, only SAEs (i.e., Stevens' Johnson Syndrome, erythema multiforme, serum sickness, and anaphylaxis) are considered in the AOM model due to the high costs associated with these events, including the cost of hospitalization and/or additional clinic visits.

In addition to the data that the end-user enters on the patient data form, other data variables are also processed in the AOM model. These data are derived from the literature and institutions in order to more accurately evaluate the costs associated with various therapeutic options. The following are input variables which were not derived from the patient data form, but were incorporated into the AOM model implemented by the present invention to provide the most useful and more accurate results:

• probability of infection resolving with one course of antibiotic therapy, according to the aforementioned age groupings

• local resistance patterns to the antibiotics

• costs to the institution for hospital days, antibiotics, clinic visits

• average length of hospital stay for an SAE, average number of clinic visits to treat an SAE and AOM according to information provided by the institution or health plan Cost and resource data are retrieved from the medical and pharmacy claims of the managed care organization. SAE probability and antimicrobial efficacy data are derived from the literature if not available from the institution. These data are incorporated into the AOM decision tree and costs are calculated based on probabilities for various outcomes as shown in this basic Input/Output scheme:

Treatment Options

A variety of options are available to physicians for the treatment of AOM. The treatment options into the system of the present invention were chosen because they represent the more commonly prescribed antibiotics for the treatment of AOM at a specific institution.

Outcome Measures

The AOM model incorporated into the system of the present invention provides the end-user with cost-effectiveness data in terms of cost per each additional successfully-treated patient over the least expensive option, as set forth in the scheme above. That is, the model provides data on the additional (marginal) cost to obtain increased effectiveness over the least costly agent. This reflects the mean cost required to successfully treat a patient over a 30-day evaluation period. A successfully-treated patient is defined in the system as a patient who is treated with a single course of antibiotics over a 30-day period, regardless of adverse events. Initial non-response is defined as a second prescription occurring within 48 hours of the first prescription date; relapse/recurrence is defined as a second prescription occurring greater than 4 days but less than 30 days after the start of the first prescription. Assumptions

The following assumptions were built into the AOM decision-analytic system:

• The patient factor that affects outcome is age. Data are segregated into six age groups as follows: (<1 yr, 1 to 3 yrs, >3 to 5 yrs, >5 to lOyrs, >10 to 18 yrs, >18 yrs).

• Only serious adverse events (i.e. those resulting in hospitalization and/or physician visits) have a significant effect on resource use and cost.

• Patients are treated empirically, with no tympanocentesis or culture and sensitivity tests.

Transfer of Data from Input Form to Decision-Analytic Model

The input form in Figure 89 shows the variables that are transferred from the form to the appropriate places in the AOM decision-analytic model of Figure 88.

Model Process

When the user completes the form of Figure 89, and submits it to the web server (Figure 87), the following ASP code is executed to pass the data to the decision tree utilized by the system of the present invention (see Figure 88), in order to obtain the desired output results after execution:

'Create decision tree object

S et localtree=S erver . createobj ect(" ActiveD AT A. TreeObj .1 ")

'Open AOM tree localtree.Open "AOM.tre"

Set oneNode =localtree.GetNodeObj

'Pass form variables (age and weight) into the tree oneNode.SetVariableStr "kg",Request.form("lb")*453.6/l 000 oneNode. SetVariableStr "age", datediff("yyyy", Request.form ("DOB"),Now()) 'Run Cost-Effectiveness analysis, and get the results localtree . S electRoot set lTicket=Server.CreateObject("ActiveDATA.TicketObj.l")

Set ceOutput=localtree.CostEff(lTicket)

Set htmlParams = Server.CreateObject( "ActiveDATA.HTMLTableParams.l")

Tabletext=ceOutput.GetOutputTable(htmlParams,0)

The Tabletext may contain an html table as follows:

Then the output table is formatted according to the antibiotics the end-user has chosen. The C/E becomes the Avg C/E, the Eff becomes the Chance of Successful Treatment, the Marg C/E is formatted as follows:

1. Find the lowest Cost (second field, $90 in this case), the corresponding Marg C/E is Baseline.

2. Find the Eff corresponding to the lowest Cost (0.80000 in this case)

3. The actual Marg C/E will be (actual Cost)-(lowest Cost)/((actual Eff)-(lower Eff)) (for Pediazole, ($141-$90)/(0.85-0.8)=$51/0.05=$l,013 which may be rounded up to 1,020), Marg C/E is marked "dominated" when (actual Eff)-(lower Eff) <=0.

The formatted output is shown in Figure 90. The medical practitioner selects one or more antibiotics to evaluate the parameters set forth in Figure 88 segment A, such as the unique cost of each antibiotic, (cost of drug "costRX") and dosing specifications in milligrams per kilogram (mg_per_kg) of the patient's body weight, as well as the resistance (factor "resistance fac ..."). The probability of a selected therapy being effective in a single course of therapy (i.e., "psingle"), rather than requiring multiple courses of therapy per episode of AOM, (see Figure 88, segment B, is derived from various sources, such as a managed care database or via review of the published literature. Successful treatment with antibiotics is offset by the resistance factor ("resistance_factor"), that allows the model to take local bacterial resistance patterns into consideration, thereby reducing the probability of success by the degree of resistance that has been identified in antibiograms.

Regardless of the effectiveness of a selected therapy, the system of the invention outputs the probability of developing serious adverse events ("SAEs"), or side effects ("pSAE") (see Figure 88, segment C), and the probability of hospitalization ("phosp") as a result of these SAEs, see Figure 88, segment D.

The SAEs are then managed on pathways of the decision tree as an outpatient or an the probability hospital ("phosp"), as shown in Figure 88, segment D. The system then prints a calculation of the cost of each pathway by tracking all previous parameters and adding them together (see Figure 88, segment D). The cost determinations are terminal nodes on the decision tree. For example, for the cefaclor choice of Figure 88, segment A, which is the uppermost branch of the tree (i.e., following cefaclor, single course cefaclor per episode (B), SAE (C), outpatient management (D)), the "cost" of the arm at the terminal node (triangle) is determined as the cost of a single course of therapy ("costRX") * the cost of outpatient treatment of SAEs ("costSAEOP"). Similarly, the cost of cefaclor in the lowermost branch is the cost of a number of courses ("N") of cefaclor ("costRX*N") only.

Other cost data that are input into the system include clinic visits ("CV") and hospitalizations ("hosp"), as shown in Figure 88, segment E. The "effectiveness" is the chance of successful treatment, which is, essentially, the probability of the antibiotic being effective in a single course of treatment. Also, as shown in Figure 88, the decision tree sequences of segments B, C and D are determined in the same sequence for each other chosen antibiotic or therapy, in segment A, e.g., ERYTHROMYCIN, AUGMENTIN, PEDIAZOLE, AZITHROMYCIN, AMOXICILIN or TMP/SMX.

Example 2 The Chronic Otitis Media ("COM^,r> Model

Chronic otitis media, characterized by effusion without signs or symptoms of an ear infection, is a common childhood illness. This disease state is often associated with impairment of hearing, which could have detrimental effects during crucial stages of language development in children. Different strategies are now employed in the treatment of this disease state, including: observation, pharmacologic therapy, and placement of tympanostomy tubes. This model provides assistance to the clinician in determining the most cost-effective therapeutic sequence. The model can be reviewed with advisory panelists for their expertise in the disease area, and the model can be modified accordingly.

Model Description

The COM model utilized in the system of the present invention utilizes a Markov model which evaluates a hypothetical cohort of patients with the same characteristics as the patient. See Beck, J.R. and Pauker, S.G. The Markov process in medical prognosis. Med Decis Making 1983;3:419-458. This model is based on federal practice recommendations developed by the Agency for Health Care Policy and Research (AHCPR), local practice recommendations, a literature review, data from a pharmacy benefits management company, and the medical and pharmacy claims of the user's managed care organization.

The COM model evaluates a sequence of four treatment options over a period of 24 weeks, where each treatment cycle is 6 weeks in length. Figure 91 depicts a diagrammatic representation of the COM model. Each patient in the hypothetical cohort cycles through the sequence of treatment options for each strategy until the effusion resolves or the 24-week evaluation has elapsed. During the cycles, patients who had no hearing loss initially may transition to the hearing loss health state. As conditions change with time (e.g., increased duration of effusion, patient develops hearing loss, etc.), the probabilities for the events are recalculated to ultimately determine the costs and outcomes associated with different treatment strategies. The probability of successful treatment (i.e., resolution of effusion) is modified according to the previous duration of effusion.

The model evaluates the costs associated with each treatment strategy composed of various combinations of the treatment options: first-line antibiotic therapy, second-line antibiotic therapy, observation, and tympanostomy.

Variables Considered in the Model

The COM model assesses the most cost-effective therapy for the patient by evaluating the data entered by the end-user on the patient data form (Figures 92 to 95) (age, weight, preexisting hearing status, duration of effusion) and assessing the costs associated with the various therapeutic strategies selected by the end-user to evaluate.

Inputs to the model (see Figure 91) include efficacy data for the different treatment options, and cost data (physician office visits, antibiotic therapy, tympanostomy tube placement, and hearing evaluations) for the treatment of COM. The probability of the effusion resolving is based on the duration of the effusion.

Cost and resource data are retrieved from the medical and pharmacy claims of the managed care organization, whereas probability and treatment efficacy data are derived from the literature if not available from the institution. All of these variables are incorporated into the Markov model utilized by the system of the present invention and costs are calculated based on probabilities for various outcomes.

Treatment Options

Treatment decisions among physicians vary considerably due to the lack of definitive standards regarding the treatment of COM. These treatment options considered in the model utilized by the present system were chosen because they represent the more commonly prescribed treatment options for COM. Each treatment strategy is composed of varying combinations of these treatment options.

Outcome Measures

The model provides the end-user with cost-effectiveness data (see Figure 97) in terms of cost per each additional successfully-treated patient. This reflects the mean cost required to resolve the effusion (successfully treat the patient) over the 24-week evaluation period.

A successfully-treated patient is defined as a patient in whom effusion resolves. Hearing loss is defined as a bilateral deficit of greater than 20dB hearing level threshold.

Assumptions

The following assumptions were made in developing the COM Markov model used in the present invention: • The only patient factors that affect patient outcome are age (< 1 yr, 1 to 3 yrs, > 3 to 5 yrs, > 5 to 10 yrs, > 10 to 18 yrs, > 18 yrs), weight, presence of hearing loss, and duration of effusion

• Doses of antibiotic treatment options are determined based on body weight only

• A course of antibiotics is considered to be 10 days of treatment

• No combination of treatment options occurs within a given 6-week treatment cycle Transfer of Data from Input Form to Decision-Analytic Model

The input form of Figures 92 to 95 shows the variables that are transferred from the form to the appropriate places in the COM decision-analytic model (see Figure 91).

Model Process

When the user completes the form of Figures 92 to 95, and submits it to the web server of Figure 87, the following ASP code is executed to pass the parameters to the decision tree utilized by the system of the present invention in order to obtain the desired output results after execution:

For strategy 1

'Create COM tree object

Set localTree = Server.CreateObject("ActiveDATA.TreeObj.l") localTree.OpenFile "COM.tre" localTree. S electRoot

Set oneNode = localTree.GetNodeObj age=datediff("yyyy", Request.form( "DOB"),Now())

'Change value for variables in the tree oneNode .SetVariableStr "Age", age

Same for following variables "p_hear_loss","p_no_hear_loss","peffusion_res","AB","AB2","lb", "stage_offset" 'Change table value in the tree set tblObj=localTree.getTable("Stratl_hear")'Hear_strategy For i = 1 To 4 tblObj.setValue i-1 , request.form("stratl_hear" & i)

Next set tblObj=localTree.getTable("Stratl_nohear")

For i = 1 To 4 tblObj.setValue i-1 , request.form("stratl_nohear" & i)' 'No_hear_strategy Next set ITicket = Server.CreateObject( "ActiveDATA.TicketObj.l") Set ceOutput = localTree.CostEff(lTicket)

Set htmlParams = Server.CreateObject( "ActiveDATA.HTMLTableParams.l") tableText = ceOutput.GetOutputTable(htmlParams,0)

Do the same for strategy 2,3,4

Then combine the tableText output

The formatted output results are shown in Figure 96.

Referring to Figure 91, the patient initially either has (see segment A) hearing loss (p_hear_loss = 1), as in this example, or no hearing loss (p_no_hear_loss = 0). Hearing loss is defined as a bilateral deficit of greater than 20dB hearing level threshold. As shown in Figure 91, the practitioner chooses 3 different treatment strategies (see segment B — Strategy 1). Each strategy consists of a sequence of four treatment options over a period of 24 weeks, where each treatment cycle (or stage) is 6 weeks in length. The results provided compare the cost-effectiveness of each of these strategies, graphically, to AHCPR recommendations for that particular patient. The strategies we have chosen include observation, first-line antibiotic (AB), second-line antibiotic (AB2), and placement of tympanostomy tubes. These treatment options considered in the model were chosen because they represent the more commonly prescribed treatment options for COM. Each treatment strategy is composed of varying combinations, of the practitioner's choosing, of these treatment options. For example, as strategy 1, the practitioner may want to consider observation for the first 6 weeks, prescription of a second-line antibiotic for the next 6 weeks, observation for the subsequent 6 weeks, then placement of tympanostomy tubes for the last 6 weeks, if the condition has not resolved prior to that. Strategy 2 might be observation, followed by first-line antibiotic, followed by second-line antibiotic, followed by tubes. Strategy 3 might be second-line antibiotic, followed by tubes and then two cycles of observation. The patient cycles through the sequence of treatment options for each strategy until the effusion resolves or the 24-week evaluation has elapsed.

Baseline parameters are set in Figure 91 segment B, e.g., which antibiotic is represented by AB or the first-line antibiotic and in which AB2 represents the second-line antibiotic. Each antibiotic has its unique cost, which is calculated based on the patient's body weight (e.g., amoxcost [kg]). Other costs that can be customized to the institution include cost of placement of tympanostomy tubes (cost_tubes) and cost of a hearing evaluation (cost_hear_eval). According to the AHCPR guidelines, the model charges for a hearing evaluation or not, based on the duration of effusion (stage_offset). The treatment strategies are evaluated (see Figure 91 segment C) for each treatment strategy in the sequence in which they were initially chosen. For example, here we are evaluating first-line antibiotic (strati _nohear[_stage]=l), followed by second-line antibiotic (strati _nohear[_stage]=2), followed by observation (stratl_nohear[_stage]=3), followed by tubes (strati _nohear[_stage]=4). As shown, there is a probability of successful treatment (success tx), i.e., resolution of effusion, during each 6-week treatment option period. Successful treatment with antibiotics is offset by a resistance factor (resistance_factor), that allows the model to take local bacterial resistance patterns into consideration, thereby reducing the probability of success by the degree of resistance that has been identified in antibiograms.

As shown in Figure 91 segment D, there is a probability that the effusion will resolve (peffusion_gone) or not (the "#" under the "effusion" arm means that the probability that the effusion is still ongoing is calculated as "1 - peffusion_gone) during each treatment option — in this case, observation — within each 24-week strategy. Thus, segment D of Figure 91 is actually located off of each therapeutic option in segment C. If the effusion is ongoing, there is a probability that the patient will have no hearing loss (pno_hear_tx), if they entered the model that way or the therapy has resolved the hearing loss even though the effusion has not completely resolved (see Figure 91 segment E). Regardless of the patient's hearing status after the first treatment option, if the effusion is still ongoing, the patient will "cycle" through the decision tree again — going back to Figure 91 segment A, either beginning in "hearing loss" if that is where the patient ended up or "no hearing loss", progress to the next treatment option in segment C, and on to segment D, then segment E, until the effusion resolves (terminal node). The costs of each arm in the model are multiplied by the probabilities of these events occurring, as in the AOM model, except that the model is recursive so that these probabilities and costs in the COM model may change with each 6-week cycle. Costs are divided into initial (init.) costs, if applicable, incremental (incr.) costs (which recur with each cycle of the model) and final costs. Likewise, effectiveness is apportioned as initial, incremental and final. The COM model thusly assesses the most cost-effective therapy for the patient by evaluating the data entered by the end-user on the patient data form (age, weight, pre-existing hearing status, duration of effusion) and assessing the costs associated with the various therapeutic strategies selected by the end-user to evaluate.

The model also provides the end-user with cost-effectiveness data in terms of cost per each additional successfully- treated patient. This reflects the mean cost required to resolve the effusion (successfully treat the patient) over the 24-week evaluation period. A successfully-treated patient is defined as a patient in whom effusion resolves.

The Osteoporosis ("OST^, > Model

Another example of the models that incorporates several of these elements is the osteoporosis model. Figure 98 is a simplified state transition diagram and Figure 99 shows the input variables and results for the osteoporosis model shown in Figure 100. The osteoporosis model was constructed and coded utilizing the software DATA™ according to a Markov decision-analytic model. The Markov methodology was also used to build the decision trees in Figures 88 and 91. Markov models are useful because when a decision problem involves risk that is continuous over time, the timing of events is important, and important events may happen to a patient more than once. Representing such clinical settings with a conventional decision tree is difficult and may require unrealistic simplifying assumptions. Additionally, a Markov model can be run over varying time cycles and can be projected into the future over as long a time period as clinically warranted.

A cornerstone of the process of the present invention consists of three types of evaluative mechanisms or models — screening, risk assessment and cost-effectiveness. These are constructed for use in the system by using a variety of methods, including decision- analytic models, logistic regression equations, and/or questionnaires. An example of one of the models that incorporates several of these elements is the osteoporosis ("OST") model. The physician has diagnosed a patient as having osteoporosis and, using the data menus shown in figures 101 and 102, inputs the appropriate patient, disease, diagnosis and treatment information. The user then runs the OST model. An explanation of this model and its use follows below.

The model was constructed utilizing the software DATA™ (TreeAge Software, Inc., Williamstown, MA). The applicants preferred to construct a Markov decision-analytic model as shown in Figure 100 because it is useful when a decision problem involves risk that is continuous over time, when the timing of events is important, and when important events may happen more than once. See Sonnenberg, F.A., Beck, R.J.: Markov models in medical decision making: A practical guide. Med Decis Making 13;322-38, 1993. Representing such clinical settings with a conventional decision tree is difficult and may require unrealistic simplifying assumptions. Additionally, the model can be run over varying time cycles and can be projected into the future over as long a time period as clinically warranted. A Markov model is a "health state transition" model, in which a hypothetical cohort of patients will move or transit through time in a variety of health states. The patient cohort is defined by age and bone mineral density (BMD) that is representative of the individual patient that one is attempting to evaluate. Figure 98 demonstrates a simplified state transition diagram for the osteoporosis model. For example, patients with no underlying comorbidities enter the model in the well health state. If a fracture occurs during the following cycle, the patient will move to the fracture health state. Similarly, if the patient dies, develops breast cancer or uterine cancer, she will move to the corresponding health state. Combinations of these outcomes also exist, such that a patient may have, for example, a fracture and breast cancer. In the osteoporosis model, each cycle is one year in length. The patient transits to each health state based on the corresponding table of probabilities. The probabilities for these events are derived from tables containing annual age-specific rates. The model can be run until the entire patient cohort has died or the model may be evaluated for a defined period of time, e.g., 2 years. The model then merges these cycles into a collective experience over time.

Clinical Variables and Sources

The baseline osteoporosis model uses epidemiologic and economic data derived from the literature, as well as an individual patient's clinical data to calculate the comparative cost- effectiveness of the different therapeutic options for a patient. Examples of these various inputs are illustrated in Figures 101 and 102. Preferably, the following strategies are evaluated in the model:

• no therapy

• antiresorptive agents

- estrogen/progesterone or estrogen alone¹

- alendronate (Fosamax®)

- nasal calcitonin

- parenteral calcitonin

For women with intact uteri, progesterone therapy was evaluated in combination with estrogen therapy, if a hysterectomy had been performed, only estrogen was considered This information is used to determine if progesterone therapy should be considered in combination with estrogen therapy In addition, the outcome of uterine cancer was not evaluated for these women. - estrogen/alendronate

• agents which stimulate bone formation.

- sodium fluoride These treatment options were chosen because they represent some of the more commonly instituted regimens for the treatment of osteoporosis. The cost variables for these regimens include any adjunctive drug therapy (i.e., calcium, vitamin D) which is typically instituted as part of the regimen.

The applicants preferred to utilize a series of linear regression equations previously developed by the Hawaii Osteoporosis Center to assess the number of fractures an individual would probably experience in the future. See Ross, P.D., Wasnich, R.D., Maclean, C.J., et al.: A model for estimating the potential costs and savings of osteoporosis strategies. Bone 9:337-347, 1988. See Ross, P.D., Wasnich, R.D., Davis, J.W.: Fracture prediction models for osteoporosis prevention. Bone 11:327-331, 1990. This regression equation considers a patient's age and BMD t-score (number of standard deviations below the mean for a young woman) and rate of bone loss to determine the future number of fractures expected over the patient's remaining lifespan. It was developed from data on 1226 Asian-American women (ages 30-80) who had been selected as a representative sample from the community and 1566 Asian-American women who had been referred or had volunteered for BMD measurements. Although this population might be considered less representative of the total U.S. population, it might be more representative of the world population, which is predominantly Asian. In any case, there is no evidence that the fundamental relationship between bone density and fractures differs between populations. In fact, the RLFP model, based on the distribution of age and bone density values within the population, has been applied to the U.S. population as a whole, yielding estimates of fracture incidence nearly identical to observed values. See Wasnich, R.D.: Vertebral fracture epidemiology. Bone 18:179S-183S, 1996. Also, recent data from the Hawaii study indicates that absolute bone density predicts fracture rate to an identical extent in both men and women. See Ross, P.D., Kim, S., Wasnich, R.: Bone density predicts vertebral fracture risk in both men and women: a prospective study [abstract] J Bone Miner Res 11 (Suppl 1):S127, 1996.

The model utilized in the present invention takes into account the greater mortality associated with hip fractures in the older age groups. Of some concern was the availability of only relatively short-term data for alendronate. Since actual data for expected change in BMD were only available from a figure (these data points were not available from either study authors nor from the sponsoring company), only extrapolations for the first three years (5.5%, 1.8 % and 1.2% for years 1,2, and 3, respectively) were available. See Liberman, U.A., Weiss, S.R., Broil, J., et al.: Effect of oral alendronate on bone mineral density and the incidence of fractures in postmenopausal osteoporosis. N Engl J Med 333:1437-1443, 1995. After three years of alendronate therapy, rate of bone loss was assumed to be 0%.

We preferred to also incorporate individual risk of breast cancer and individual risk of myocardial infarction (MI), which are embedded in the decision-analytic model as non- parametric logistic regression equations derived from published sources. See Melton, L.J. III. Hip fractures: a worldwide problem today and tomorrow. Bone 14:S1-S8, 1993. See Riggs, B.L., Melton, L.J.: The prevention and treatment of osteoporosis. N Engl J Med 327(9):620- 627, 1992. See Melton LJI, Kan SH, Warmer HW, Riggs BL: Lifetime fracture risk: an approach to hip fracture risk assessment based on bone mineral density and age. J Clin Epidemiol 1988; 41 : 985-994. See The Framingham Study: An Epidemiological Investigation of Cardiovascular Disease. In: US Department of Health and Human Services. The probability of developing certain cardiovascular diseases in eight years at specified values of some characteristics. 1987; Section 37: (Abstract). See Kannel WB, Dawber TR, Kagan A, et al: Factors of risk in the development of coronary heart disease-six year follow- up experience. The Framingham Study. Ann Intern Med 1961; 55: 33-50.

Cost Variables and Sources

The costs included in the model were direct medical costs (cost of hospital care, nursing home care, and other long-term care due to disease-related disabilities), as well as the costs of screening and hormone replacement therapy, HRT. Costs were updated to 1995 costs using the Medical consumer price index-urban ("CPI-U").

Outcome Measures

The primary outcome measures for this model were: 1) fractures avoided (FA) and 2) quality adjusted life years (QALY). Cost per FA was calculated by dividing the mean total per-patient cost by the number of fractures avoided over a pre-selected time period. FA is calculated by individually summing the number of fractures of the cohort in each treatment group and subtracting from the number of fractures of the cohort in the No Therapy treatment group. This model only considers hip fractures since the major source of morbidity and mortality associated with osteoporosis arises from hip fractures and a majority of the costs are related to hip fractures. Cost per QALY took into consideration the impact that variables such as breast cancer, fractures, or drug therapy may have on quality of life using individual patient preferences. It was calculated by dividing the total cost, as defined above, by the QALY (Cost/QALY). The marginal or incremental cost-effectiveness ratio, i.e., additional cost for additional benefit, was calculated as follows:

ΔC = Costi - Cost2

ΔE Effectiveness! - Effectiveness!

where Effectiveness 1 > Effectiveness!

Patient Preferences

Patient preferences can be taken into account in the osteoporosis model by making utilities for each of the health states patient-specific. A patient is asked to imagine, with the aid of short health state descriptions, how they would feel if they were experiencing that particular condition. A Visual Analog Scale with anchors of well ("1") and death ("0") may be used to translate these feelings into a numeric value (utility). See Henry, D.H., Abels, R.I.: Recombinant human erythropoietin in the treatment if cancer and chemotherapy-induced anemia: results of double-blind and open-label follow-up studies. Semin Oncol 21(2 Suppl 3):21-8, 1994. For the QALYs determination, for each cycle that the patient cohort is in a certain Markov health state, a utility value between zero and one is taken into consideration when evaluating the overall expected utility for being in this health state. For example, if a woman felt that experiencing breast cancer was almost tantamount to being dead, she might assign a value of "0.2" to this health state. Thus, two years with breast cancer would be equivalent to 0.4 (i.e., 2 x 0.2) QALYs. Conversely, if the woman felt that this health state was not so threatening to her quality of life, she might assign a value of "0.8", therefore garnering a value of 1.6 (i.e., 2 x 0.8) QALYs.

For fractures, a disutility was subtracted only within the cycle during which the fracture occurred since the majority of patients were felt to incur only short-term decrements in well-being (in comparison to breast cancer and uterine cancer). Transfer of Data from Input Form to Decision-Analytic Model

The input form in Figures 101 and 102 shows the variables that are transferred from the form to the appropriate places in the osteoporosis decision-analytic model.

Model Process:

This model consists of two Cost-Effectiveness measuring systems:

Cost per Quality- Adjusted Life Years (QALYs) and Cost per Fracture Avoided (FA).

The following is the complete algorithm for the FA system:

Cost per Fracture Avoided is calculated by dividing the mean total per-patient cost by the number of fractures avoided over a preselected time period [item number 2 in the input form in Figures 101 and 102 (number of years over which to run the model), which translates to the variable "stopmarkov" in the model]. FA is calculated by individually summing the number of fractures of the cohort in each treatment group and subtracting from the number of fractures of the cohort in the No Therapy treatment group. To do this, we use the ActiveDATA component object (for decision analysis) developed by TreeAge Software, Inc.

When the user completes the form of Figures 101 and 102, and submits it to the web server (Figure 87), the following ASP code is executed to pass the parameters to the decision tree utilized by the system of the present invention and in order to obtain the desired output results after execution:

'Create OST tree object

Set localTree = Server. CreateObject("ActiveDATA.TreeObj.l")

localTree.OpenFile "OST.tre" 'File OST.tre is a decision tree for OST cost-effectiveness analysis.

localTree. SelectRoot

Set oneNode = localTree. GetNodeObj

'Compute age and change value for age variable in the tree

age=datediff("yyyy", Request.form( "DOB"),Now())

oneNode.SetVariableStr "Age", age

The following table shows the variables and the sample values set in the decision tree:

Some variables are directly from the input form such as AgeFTP, Parity, MoBf, FDBCA, SDBCA, UnkBCA, TeenMenses, Weight, Height etc., while others are set for FA case such as pDEAD, pUCA, pBCA, pBOTHCA, pMOREFX, pMOREFXUCA, pMOREFXBCA, etc. The majority of the variables for which we need to reset values are dependent on the user input, for example, Q: Assume Baseline Risk for MI?

If you check this box, ignore the next 5 questions. In this case, we don't need to set CHOL,SBP, etc.

The RLFP (Remaining Lifetime Fracture Probability) is a mathematical model that describes the number of fractures an individual is expected to experience in the future. The RLFP incorporates age, initial bone mass (based on t-score), life expectancy and the probable magnitude of future bone loss. The RLFP for the patient was calculated via the Internet site maintained by the Society for Clinical Densitometry in Hawaii. An activeX object called "CCS. OST" was used to establish the Telnet connection between the applicant's site and the Hawaii site to retrieve the RLFP values.

addage=request.form("StopMarkov")

'addage is the preselected time period tscore=request.form("ZScore") set obj =server.createobject("CCS.OST") dim RLFP() 'declare an array to hold the values obj.setVar age, age+addage, request.form ("Meno_age"), request.form

("Meno sta"), tscore 'Get RLFP values from Hawaii obj. GetRLFP (RLFP) 'Now array RLFP() contains the values. 'Change values in the table of the OST decision tree Set tblObj=localTree.getTable("NSFP") For i = age To (age + addage) tblObj.setValue i , RLFP(i) Next

Set ITicket = Server.CreateObject( "ActiveDATA.TicketObj.l")

Set ceOutput = localTree. CostEff(lTicket)

Set htmlParams = Server. CreateObject( "ActiveDATA.HTMLTableParams.l") htmlParams.tableTag = "border=l" tableText = ceOutput.GetOutputTable(htmlParams,0)

HTML table text (raw output directly from ActiveData)

Format the output of the HTML-formatted table text: For strategy, we only display the following:

No Therapy

Estrogen/Progesterone

Calcitonin nasal

Fosamax

Calcitonin parenteral For Cost, we use the same field: Cost For Chance of Fractures, we format Eff into a percentage. For Fractures Avoided, we make the Marg Eff into positive values. For Cost per Fracture Avoided, we use the following algorithm:

Find the lowest Cost (Cost field, $590.99 in this case), the corresponding Marg C E is Baseline. Find the lower Eff corresponding to the lowest Cost (0.01203 in this case), the actual Marg C/E will be (actual Cost)-(lowest Cost)/((lower Eff)-(actual Eff)) (for Fosamax, ($1,085.25-5590.99) /(0.0120-

0.0059=$81,026.23), Marg C/E is marked "Dominated" when (lower Eff)-(actual Eff) <=0. Model Output:

[ ]The formatted output is shown in Figures 103 and 104.

The baseline osteoporosis model uses epidemiologic and economic data derived from the literature, as well as an individual patient's clinical data to calculate the comparative cost- effectiveness of the different therapeutic options for a patient. We preferred to choose the following strategies to be evaluated in the model: no therapy, estrogen/progesterone or estrogen alone, alendronate (Fosamax®), nasal calcitonin, parenteral calcitonin, estrogen/alendronate, and sodium fluoride (see Figure 100, segment A). For women with intact uteri, progesterone therapy was evaluated in combination with estrogen therapy; if a hysterectomy had been performed, only estrogen was considered. This information is used to determine if progesterone therapy should be considered in combination with estrogen therapy. In addition, the outcome of uterine cancer was not evaluated for these women. These treatment options were chosen because they represent some of the more commonly instituted regimens for the treatment of osteoporosis. The cost variables for these regimens include any adjunctive drug therapy (i.e., calcium, vitamin D) which is typically instituted as part of the regimen.

Baseline parameters are set in Figure 100 segment H, e.g. AgeFTP (age at first term pregnancy), BaseLnBCA (baseline probability of breast cancer), BaseLnCAD (baseline probability of coronary artery disease), BBDu (unknown history of benign breast disease,), BBDy (definite history of benign breast disease), BMDeval (estimated bone mineral density evaluation; value of l=very poor, 2=poor, 3=average), BMDTestedValue (actual BMD value), CHOL (serum cholesterol value), CIGS (smoking history), FDBCA (family history of first-degree breast cancer), GL_INT (glucose intolerance), HEIGHT (patient height), LVH_ECG (left ventricular hypertrophy on ECG), MenoNat (natural onset of menopause), MenoPeri (perimenopausal), MenoSurg (surgery-induced onset of menopause), MenoUnk (unknown cause of menopause), MoBf (months of breast feeding), Parity, pBCA (probability of developing breast cancer), pBOTHCA (probability of developing both breast and uterine cancer), pFRACBCA (probability of both fracture and breast cancer), pFRACBOTCA (probability of fracture and of developing both breast and uterine cancer), pFRACUCA (probability of both fracture and uterine cancer), pFXusemelton (formula derived from the Melton reference for determining probability of fracture based on patient BMD), pMOREFX (probability of starting in model with prior fracture), pMOREFXBCA (probability of starting in model with prior fracture and breast cancer), pMOREFXBOT (probability of starting in model with prior fracture and both breast and uterine cancer), pMOREFXUCA (probability of starting in model with prior fracture and uterine cancer), pUCA (probability of uterine cancer ), SBP (systolic blood pressure), SDBCA (family history of second-degree BCA ), TeenMenses (teenage onset of menses). BCA_RRisk (Relative Risk of Breast Cancer due to therapy - BCA_RRiskEarly and BCA RRiskLate), Calcitonn_acq_cost (acquisition cost of nasal calcitonin), Calp_acq_cost ((acquisition cost of injectable calcitonin), cMD VISIT (cost of physician visit), CostBCAcont (incremental, or cyclical, cost of breast cancer), CostBCAinit (initial cost of breast cancer), CostBCAterm (terminal cost of breast cancer), CostDieMI (cost of death from heart attack), CostMIcont (incremental, or cyclical, cost of death from heart attack) CostMIinit (initial cost of death from heart attack), CostMIterm (initial cost of death from heart attack), CostUCAcont /CosfUCAinit/CosfUCAterm = incremental, initial and terminal cost of uterine cancer, currentNSFP (probability of nonspinal fracture), discrt (discount rate), EffRX_MI (efficacy of drug in preventing heart attack), EstFos_acq_cost (acquisition cost of the combination of estrogen and Fosamax®), Estprog_acq_cost cost (acquisition cost of estrogen and progesterone), Fos_acq_cost (acquisition cost of Fosamax®), SloFlo_acq_cost (acquisition cost of slo fluoride), exp BreastCA (exponent that takes into consideration AgeFTP, parity, moBF, BBDy, BBDu, MenoPeri, MenoSurg, MenoNat, FDBCA, SDBCA, TeenMenses and riskBMI), FXdisutihty (perceived disability by patient subtracted during year fracture occurred), hip_frac_melt (hip fracture equation from Melton and Riggs, 1988), hip_frac_melton2 (intertrochanteric portion of Melton and Riggs, 1988 equation), newBMD (change in BMD with each cycle), pBreastCA (probability of developing breast cancer), pDieFX (probability of death due to fracture), pdieMI (probability of death due to heart attack), pDieUCA (probability of death due to uterine cancer), pMI (probability of heart attack), p hip melt tot (prob of hip fracture using cervical and intertrochanteric equations, see Melton LJI, Kan SH, Wahner HW, Riggs BL: Lifetime fracture risk: an approach to hip fracture risk assessment based on bone mineral density and age. J Clin Epidemiol 1988; 41: 985-994.), riskBMI (risk associated with body mass index), TScorelndex (picks appropriate FX rate table depending on BMD and therapy), uBothCA/ uBothCAandFX/ uBothCAandFX2/ uBreastCA/ uBreastCAandFX/ uBreastCAandFX2/ uFX/ uFX2/ uUterineCA/ uUterineCAandFX/ uUterineCAandFX2 (utility or patient preferences for each of the health states).

A Markov model is a "health state transition" model, in which a hypothetical cohort of patients will move or transit through time in a variety of health states. The patient cohort is defined by age and bone mineral density (BMD) that is representative of the individual patient that one is attempting to evaluate. As in Figure 100, segment B, for example, patients with no underlying comorbidities enter the model in the well health state. If a fracture occurs during the following cycle, the patient will move to the fracture health state (FX) at a probability of pFRACTURE. Similarly, if the patient dies (Dead), develops breast cancer (Breast CA) or uterine cancer (Uterine CA), she will move to the conesponding health state. Combinations of these outcomes also exist, such that a patient may have, for example, a fracture and breast cancer (FX and Breast CA). In the osteoporosis model, each cycle is one year in length. The patient transits to each health state based on the conesponding table of probabilities. The probabilities for these events are derived from tables containing annual age-specific rates. The model can be run on the system of the present invention until the patient dies (Dead), as in Figure 100, segment C, or the model may be evaluated for a defined period of time, e.g., 2 years. If we follow the WELL health state, the patient is alive, and may develop a hip fracture (Fracture) with the probability pFX or not, as in Figure 100, segment D. The patient may then die of the fracture (pDieFX), as in Figure 100, segment E, or live. Subsequently, as in Figure 100, segment F, the patient may develop Uterine Cancer with a probability of pUterineCA or not. The "terminal" health state reflects the total path traveled. Thus, as in Figure 100, segment G, if one enters the WELL health state, lives, develops a fracture, lives and develops Uterine Cancer, the patient ends in the health state entitled FX and Uterine CA. If the patient ultimately develops both Breast and Uterine CA in segment G, they end in the FX and BothCA health state. Regardless of the patient's "terminal" health state, if the patient is alive, the patient will "cycle" through the decision tree again — going back to Figure 100, segment B, beginning where the patient ended up previously, and progress until death or for the number of cycles (years) specified in the input form.

Probability of fracture is calculated in one of two ways. If the end-user chooses to use BMD, the system of the invention establishes a Telnet connection to an Internet site maintained by the Society for Clinical Densitometry in Hawaii to calculate the RLFP (Remaining Lifetime Fracture Probability). RLFP is a mathematical model that describes the number of fractures an individual is expected to experience in the future. The RLFP incorporates age, initial bone mass (based on t-score), life expectancy and the probable magnitude of future bone loss. If the end-user chooses not to use BMD, the system of the present invention uses a logistic regression equation we developed based on published literature and individual risk variables. See Melton, L.J. III. Hip fractures: a worldwide problem today and tomorrow. Bone 14:S1-S8, 1993. See Riggs, B.L., Melton, L.J.: The prevention and treatment of osteoporosis. N Engl J Med 327(9):620-627, 1992. See Melton LJI, Kan SH, Wahner HW, Riggs BL: Lifetime fracture risk: an approach to hip fracture risk assessment based on bone mineral density and age. J Clin Epidemiol 1988; 41 : 985-994. The osteoporosis model then calculates the results in server 20 and produces a report, which is sent back to the user via the Internet, again using the Secure Sockets Layer standard for data encryption. The transaction time depends on the complexity of the analysis. Database server 24 reports are generated by querying the database with standard Structure Query Language ("SQL") and formats the results for viewing.

A session undertaken in accordance with the present invention may involve many calculations and incorporate data from many sources. Sometimes, these data may be stored on other computers linked to the server 20. Sometimes pre-calculations may be carried out on external computers and the results incorporated into the primary transaction performed by server 20. The pre-calculations are carried out by the remote server at other organizations. The system of the present invention obtains the pre-calculated results and uses them in its own calculations. The pre-calculations can be imported into the present system via various transport protocols available at the remote site. For example, for the osteoporosis nonspinal fracture probability (NSFP) coefficients, a Telnet protocol is used to communicate to the remote NSFP server, which is physically located in Hawaii. All of these ancillary or precalculations are transparent to the user of the present invention. We preferred to also incorporate individual risk of breast cancer and individual risk of myocardial infarction (MI), which are embedded in the decision-analytic model as non- parametric logistic regression equations derived from published sources. See The Framingham Study: An Epidemiological Investigation of Cardiovascular Disease. In: US Department of Health and Human Services. The probability of developing certain cardiovascular diseases in eight years at specified values of some characteristics. 1987; Section 37: (Abstract). See Kannel WB, Dawber TR, Kagan A, et al: Factors of risk in the development of coronary heart disease-six year follow-up experience. The Framingham Study. Ann Intern Med 1961; 55: 33-50.

The costs of each arm in the model are multiplied by the probabilities of these events occurring, as in the AOM and COM models, except that the model is recursive (as is the COM model) so that these probabilities and costs in the osteoporosis model may change with each 1-year cycle. The osteoporosis model thusly assesses the most cost-effective therapy for the patient by evaluating the data entered by the end-user on the patient data form (age, BMD, risk of myocardial infarction, risk of breast cancer and number of years currently receiving therapy for osteoporosis) and assessing the costs associated with the various therapeutic options evaluated by the model.

The primary outcome measures for this model were: 1) fractures avoided (FA) and 2) quality adjusted life years (QALY). Cost per FA was calculated by dividing the mean total per-patient cost by the number of fractures avoided over a pre-selected time period. FA is calculated by individually summing the number of fractures of the cohort in each treatment group and subtracting from the number of fractures of the cohort in the No Therapy treatment group. This model only considers hip fractures since the major source of morbidity and mortality associated with osteoporosis arises from hip fractures and a majority of the costs are related to hip fractures. Cost per QALY took into consideration the impact that variables such as breast cancer, fractures, or drug therapy may have on quality of life using individual patient preferences. It was calculated simply by dividing the total cost, as defined above, by the QALY (Cost/QALY).

The marginal or incremental cost-effectiveness ratio, i.e., additional cost for additional benefit, was calculated as follows:

ΔC = Cost i - Cost2

ΔE Effectiveness i - Effectiveness!

where Effectiveness 1 > Effectiveness!

Patient Preferences

Patient preferences can be taken into account by making utilities for each of the health states patient-specific. A patient is asked to imagine, with the aid of short health state descriptions, how they would feel if they were experiencing that particular condition. A Visual Analog Scale with anchors of well ("1") and death ("0") may be used to translate these feelings into a numeric value (utility). See Henry, D.H., Abels, R.I.: Recombinant human erythropoietin in the treatment if cancer and chemotherapy-induced anemia: results of double-blind and open-label follow-up studies. Semin Oncol 21(2 Suppl 3):21-8, 1994. For the QALYs determination, for each cycle that the patient cohort is in a certain Markov health state, a utility value between zero and one is taken into consideration when evaluating the overall expected utility for being in this health state. For example, if a woman felt that experiencing breast cancer was almost tantamount to being dead, she might assign a value of "0.2" to this health state. Thus, two years with breast cancer would be equivalent to 0.4 (i.e., 2 x 0.2) QALYs. Conversely, if the woman felt that this health state was not so threatening to her quality of life, she might assign a value of "0.8", therefore garnering a value of 1.6 (i.e., 2 x 0.8) QALYs.

For fractures, a disutility was subtracted only within the cycle during which the fracture occurred since the majority of patients were felt to incur only short-term decrements in well-being (in comparison to breast cancer and uterine cancer).

The Asthma Models

A last example of the models that incorporates several of these elements are the asthma models. There are two models — one that predicts risk of hospitalization within the next year and the other that screens a previously undiagnosed patient for a diagnosis of asthma. The first is a predictive risk stratification model that was developed using pharmacy and medical claims data from approximately 50,000 asthmatic patients in a managed care database. Asthmatic patients were identified on the basis of diagnosis codes, specific procedures or medication claims. In addition, in the development cohort patients were required to be enrolled in the plan for the entire selected calendar year plus any portion of the previous year. The dependent variable is the probability of being hospitalized in the following year. Independent variables were selected for the model based on their level of significance in a stepwise regression.

The model was cross-validated using all asthmatic patients (approximately 70,000 patients) in the same managed care plan using a different time frame than that used to develop the regression equation coefficients. The intent was to evaluate the use of the equation to predict future hospitahzations, using current data. The predicted number of hospitahzations is broken down into deciles and compared to actual hospitahzations.

Variables in the model include demographic factors, presence of comorbidities, severity of illness as determined by prior usage of specific asthma medications, prior utilization of non-urgent or urgent-care services, length of enrollment and type of primary care provider. A first order logistic regression was run and given the fit, no interactions or higher order terms were required. The overall model fit the data with a P<0.0001. The most important variables in terms of predicting hospitalization were prior utilization of both inpatient and outpatient services, disease severity, absence of a pharmacy benefit and Medicaid subscriber. These have been placed in a patient data input form, as shown in Figure 106. The data are entered manually or are pulled from medical and pharmacy claims for a specific patient. When the end-user clicks "Process Patient Data", the program evaluates the model and the results are summarized for each time the patient is evaluated, as shown in Figure 106. The actual evaluation on that date can be elucidated by clicking the date in Figure 106 to show the data in Figure 107. When the physician accesses that patient's record, the physician can view the model results by clicking the 'risk' button in the 'evaluate' column next to that diagnosis, as shown in Figure 18.

Application of the Model

In the application of the model, risk strata were developed based on the case management resources and threshold for sensitivity and specificity within each managed care plan. For example, five asthma risk categories were constructed based on the predicted probability of hospitalization. In this scenario, patients at highest risk were defined as having a probability of hospitalization of 0.20 or greater, while the next risk category contained those patients with a probability of hospitalization between 0.10 and 0.199. In the managed care plan used to develop the model these two strata were responsible for 30% of asthma-related admissions, yet contained less than 4% of asthmatics. Disease management programs specific to the level of risk for hospitalization may then be implemented in the appropriate population. The second asthma model, as shown in Figure 108, is based on the National Heart, Lung, and Blood Institute- World Health Organization (NHLBI-WHO) Global Initiative on Asthma (GINA) Guidelines for diagnosis of asthma. Either the patient or healthcare practitioner completes the form and the physician can view the model results, as shown in Figure 109, by clicking the 'asthma' link under Patient Assessment Questionnaires, as shown in Figure 18.

Claims

CLAIMSWe claim:

1. A computer implemented process for assisting in the treatment of a patient with a disease comprising the following steps:

(a) storing said patient's medical history information in an electronic database;

(b) storing said patient's healthcare resource use data in an electronic database;

(d) inputting at least one diagnosis for said patient into an electronic database;

(e) storing the diagnosis for said patient into an electronic data base;

(f) selecting at least one course of treatment for said patient;

(g) inputting treatment information for said patient into an electronic database; and

(g) determining at least one probable outcome for said patient according to a quantitative model.

2. The process of Claim 1 wherein the model is a Markov model.

3. The process of Claim 1 wherein the model determines patient risk probabilities.

4. The process of Claim 1 wherein the model determines cost probabilities.

5. The process of Claim 1 wherein the model determines treatment effectiveness probabilities.

6. The process of Claim 1 further comprising the step of determining the patient's compliance with a medication.

7. The process of Claim 1 further comprising the following steps:

(h) writing at least one prescription for said patient;

(i) storing said prescription in an electronic database;

(j) displaying said prescription; and

(k) electronically transmitting said prescriptions to a computer in another location where the prescription can be dispensed.

. A computer implemented process for determining the probabilities of a patient's outcomes for a disease cycle comprising the steps of:

(a) selecting a diagnosis for the patient;

(b) inputting said diagnosis into an electronic data base;

(c) inputting a disease cycle for the patient into an electronic database;

(d) inputting the patient's past health information into an electronic database;

(e) determining the probability of at least one patient outcome based on said diagnosis and patient's past health information according to a quantitative model;

(f) displaying said patient outcome.

9. The process of Claim 8 further comprising the following steps:

(g) determining the probable costs associated with at least one such patient outcome according to a quantitative model; and

(h) displaying a summary of said costs.

10. The process of Claim 8 wherein the model is a Markov model.

11. The process of Claim 9 wherein the model is a Markov model.

12. The process of Claim 8 where in steps (a) through (f) are repeated.

13. The process of Claim 9 where in steps (a) through (h) are repeated.

14. A computer implemented process of monitoring a patient's progress through a disease cycle comprising the following steps:

(a) selecting a presumptive diagnosis for the patient's disease;

(b) inputting said presumptive diagnosis into an electronic database;

(c) obtaining a first set of screening data for said diagnosis;

(d) inputting said screening data into an electronic database;

(e) selecting a treatment for said diagnosis; (f) obtaining a second set of screening data for said diagnosis;

(g) inputting said second set of screening data into an electronic data base;

(f) determining based on said screening data the extent to which said treatment is alleviating said disease;

(g) displaying output parameters relating to whether said treatment is working to alleviate said disease.