[go: up one dir, main page]

WO2000069331A1 - Systeme de traitement de donnees pour l'estimation des risques encourus par un patient et des resultats probables chez ce patient et pour la gestion d'une base de donnees de sante - Google Patents

Systeme de traitement de donnees pour l'estimation des risques encourus par un patient et des resultats probables chez ce patient et pour la gestion d'une base de donnees de sante Download PDF

Info

Publication number
WO2000069331A1
WO2000069331A1 PCT/US2000/013267 US0013267W WO0069331A1 WO 2000069331 A1 WO2000069331 A1 WO 2000069331A1 US 0013267 W US0013267 W US 0013267W WO 0069331 A1 WO0069331 A1 WO 0069331A1
Authority
WO
WIPO (PCT)
Prior art keywords
patient
model
data
treatment
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2000/013267
Other languages
English (en)
Inventor
Renee J. Goldberg Arnold
Krista Pettit
Harry Harjono
Yonglong Zhou
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PHARMACON GLOBAL ENTERPRISES LLC
Original Assignee
PHARMACON GLOBAL ENTERPRISES LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by PHARMACON GLOBAL ENTERPRISES LLC filed Critical PHARMACON GLOBAL ENTERPRISES LLC
Priority to AU51337/00A priority Critical patent/AU5133700A/en
Publication of WO2000069331A1 publication Critical patent/WO2000069331A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/50—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for simulation or modelling of medical disorders

Definitions

  • MCO managed care organization
  • 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.
  • 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).
  • 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.
  • Nurse Triage Systems The prior art disease management programs can be summarized as follows: Nurse Triage Systems
  • 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.
  • the 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.
  • 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.
  • 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.
  • 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.
  • 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
  • Results can be stored within a database and can trigger events including provider alerts, patient instructions, etc.
  • 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.
  • 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.
  • FIG. 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.
  • FTP file- transfer protocol
  • Figure 80 is a screen shot showing results of the drug utilization evaluation reports.
  • 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.
  • HEDIS Health Plan Employer Data and Information Set
  • 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.
  • 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.
  • CPU central processing unit
  • RAM Random Access Memory
  • ROM Read Only Memory
  • 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.
  • 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.
  • 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.
  • 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.
  • 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".
  • 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").
  • ISP Internet Service Provider
  • 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.
  • 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.
  • URL uniform resource locator
  • 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.
  • server 20 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.
  • server 20 may consist of multiple computers, as shown in Figure 2 all linked to each other via a high-speed network.
  • all three servers could reside in one computer.
  • 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.
  • LAN local area network
  • 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.
  • 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
  • an applications server 24 to execute various modules in the system that comprise the execution of the model engines or algorithms described below
  • a database server 26 to process data-related operations, such as data retrieval, storage, and queries.
  • 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.
  • ADO Active Data Objects
  • 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 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.
  • UserlD user identification
  • password data password data
  • the system of the invention will determine which level the user has selected and pass the request to the corresponding sign in procedure.
  • 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.
  • 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.
  • FIG. 7 shows the form by which a new healthcare professional-user may register with the system of the invention.
  • 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.
  • 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.
  • 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.
  • ICD International Classification of Disease
  • 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.
  • the physician-user 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.
  • HMOs health maintenance organizations
  • EMRs electronic retrieval of electronic medical records
  • 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.
  • ODBC OPEN DATA BASE CONNECT
  • ADO ACTIVE DATA OBJECTS
  • RDO REMOTE DATA OBJECTS
  • 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.
  • ASP Active Server Pages
  • ASP Active Server Pages
  • Cold Fusion connects to the database using ADO
  • ODBC Cold Fusion
  • 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.
  • patient identification data e.g., last name, first name, middle initial
  • server 20 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.
  • PID patient first and last name
  • middle initial a unique patient identifier "PID”
  • birth date birth date
  • pre-existing diagnoses e.g., 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.
  • data for this economic model is shown on the physician menu.
  • the physician- user 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”).
  • the data bases of the present invention contains an extensive, if not complete, list of possible diagnoses.
  • server 20 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.
  • server 20 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.
  • a severity e.g., mild
  • 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.
  • 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.
  • the physician-user selects the appropriate menu from the list.
  • the menu selection is transmitted to the appropriate data base of the system.
  • 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.
  • 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.
  • the system will then perform the requested operation and transmit back the results for viewing on screen by the user.
  • 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.
  • patient info tab 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:
  • 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.
  • 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 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.
  • 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.
  • the web server displays a time frame input form, which is completed by the user for a particular patient.
  • the system 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 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.
  • server 20 generates and displays data concerning patient diagnoses for prior visits by visit date, and diagnoses according to the diagnostic coding system.
  • 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.
  • 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.
  • 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.
  • server 20 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.
  • server 20 uses 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.
  • 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.
  • 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.
  • 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.
  • the web server will directly save the prescription and go to the print option.
  • 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.
  • 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.
  • the physician learns about the model and how to interpret the results.
  • CME 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.
  • 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 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.
  • the physician 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.
  • 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
  • DUE reports 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.
  • HEDIS Health Plan Employer Data and Information Set
  • 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.
  • MCOs managed care organizations
  • NCQA National Committee for Quality Assurance
  • 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.
  • AOM childhood acute otitis media
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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 ("DATATM”), to produce decision trees that are accessed from within the system of the present invention using ACTIVE DATA DLL.
  • DATATM Data Analysis from TreeAge Software, Inc., of Williamstown, MA
  • Each model is disease-specific, and could simply be a formula or a decision tree.
  • applicants have used DATATM to implement the decision trees such as those shown in Figures 88-97, the Otitis Media Decision-Analytic Model Decision Trees.
  • 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.
  • 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.
  • 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.
  • 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:
  • AOM Acute otitis media
  • tympanic membrane with or without erythema
  • 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.
  • 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.
  • 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).
  • 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.
  • NCQA National Committee for Quality Assurance
  • HEDIS Health Plan Employer Data and Information Set
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Data input into the AOM model 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.
  • SAE serious adverse event
  • cost data physician office visits, antibiotic therapy, and SAEs
  • 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).
  • SAEs i.e., Stevens' Johnson Syndrome, erythema multiforme, serum sickness, and anaphylaxis
  • 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.
  • 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 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).
  • 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.
  • the Tabletext may contain an html table as follows:
  • 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:
  • 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”
  • 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.
  • 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.
  • SAEs serious adverse events
  • pSAE side effects
  • phosp probability of hospitalization
  • 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.
  • 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))
  • costRX single course of therapy
  • costSAEOP cost of outpatient treatment of SAEs
  • costRX*N the cost of cefaclor in the lowermost branch
  • 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.
  • 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.
  • AHCPR Agency for Health Care Policy and Research
  • 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.
  • patients who had no hearing loss initially may transition to the hearing loss health state.
  • 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
  • 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.
  • 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 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.
  • 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.
  • 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
  • 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).
  • Hearing loss is defined as a bilateral deficit of greater than 20dB hearing level threshold.
  • 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).
  • cost_tubes cost of placement of tympanostomy tubes
  • cost_hear_eval cost of a hearing evaluation
  • 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.
  • 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.
  • 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).
  • 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.
  • FIG 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 DATATM 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 DATATM (TreeAge Software, Inc., Williamstown, MA).
  • DATATM TeAge 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.
  • 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.
  • 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:
  • 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
  • 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.
  • 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%.
  • 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").
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • QALYs Cost per Quality- Adjusted Life Years
  • FA Cost per Fracture Avoided
  • 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.
  • OST.tre 'File OST.tre is a decision tree for OST cost-effectiveness analysis.
  • 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?
  • 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.
  • 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.
  • 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.
  • 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 incrementmental, 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),
  • 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.
  • BMD bone mineral density
  • 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.
  • FX fracture health state
  • the patient dies develops breast cancer (Breast CA) or uterine cancer (Uterine CA)
  • She will move to the conesponding health state.
  • a patient may have, for example, a fracture and breast cancer (FX and Breast CA).
  • FX and Breast CA fracture and breast cancer
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • SQL Structure Query Language
  • 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.
  • NSFP osteoporosis nonspinal fracture probability
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • a last example of the models that incorporates several of these elements are the asthma models.
  • 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.
  • 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 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.
  • NELBI-WHO Blood Institute- World Health Organization
  • GINA Global Initiative on Asthma

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Data Mining & Analysis (AREA)
  • Biomedical Technology (AREA)
  • Databases & Information Systems (AREA)
  • Pathology (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

L'invention concerne un système informatique (1) pour outils d'assistance à la décision et d'évaluation des résultats obtenus chez un patient, pour l'industrie de la santé, faisant appel à des plates-formes (10, 20) fondées sur l'Internet qui s'intègrent à l'infrastructure de santé existante.
PCT/US2000/013267 1999-05-17 2000-05-15 Systeme de traitement de donnees pour l'estimation des risques encourus par un patient et des resultats probables chez ce patient et pour la gestion d'une base de donnees de sante Ceased WO2000069331A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU51337/00A AU5133700A (en) 1999-05-17 2000-05-15 Data processing system for patient outcome and risk benchmarking and healthcare data base management

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13441299P 1999-05-17 1999-05-17
US60/134,412 1999-05-17

Publications (1)

Publication Number Publication Date
WO2000069331A1 true WO2000069331A1 (fr) 2000-11-23

Family

ID=22463273

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/013267 Ceased WO2000069331A1 (fr) 1999-05-17 2000-05-15 Systeme de traitement de donnees pour l'estimation des risques encourus par un patient et des resultats probables chez ce patient et pour la gestion d'une base de donnees de sante

Country Status (2)

Country Link
AU (1) AU5133700A (fr)
WO (1) WO2000069331A1 (fr)

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1440389A2 (fr) * 2001-11-02 2004-07-28 Siemens Medical Solutions USA, Inc. Exploration de donnees de patient pour observance automatisee
US6879970B2 (en) 2001-04-02 2005-04-12 Invivodata, Inc. Apparatus and method for prediction and management of subject compliance in clinical research
US20060282244A1 (en) * 2004-11-30 2006-12-14 Sham Chotai Method and system for modeling scenarios in clinical trials
US7698156B2 (en) 2002-01-29 2010-04-13 Baxter International Inc. System and method for identifying data streams associated with medical equipment
US7873589B2 (en) 2001-04-02 2011-01-18 Invivodata, Inc. Operation and method for prediction and management of the validity of subject reported data
US8065180B2 (en) 2001-04-02 2011-11-22 invivodata®, Inc. System for clinical trial subject compliance
US8712748B2 (en) 2007-06-27 2014-04-29 Roche Diagnostics Operations, Inc. Medical diagnosis, therapy, and prognosis system for invoked events and methods thereof
US8818782B2 (en) 2007-06-27 2014-08-26 Roche Diagnostics Operations, Inc. System for developing patient specific therapies based on dynamic modeling of patient physiology and method thereof
US20150127375A1 (en) * 2013-11-01 2015-05-07 Ta-Hsiung Hu Methods and systems for cloud-based medical database management
US9750872B2 (en) 1999-10-22 2017-09-05 B. Braun Medical Inc. Method and apparatus for controlling an infusion pump or the like
US10025910B2 (en) 2008-07-25 2018-07-17 Eresearchtechnology, Inc. Endpoint development process
US10061899B2 (en) 2008-07-09 2018-08-28 Baxter International Inc. Home therapy machine
WO2018222898A1 (fr) * 2017-06-02 2018-12-06 Mayo Foundation For Medical Education And Research Système et procédé pour fournir une expertise guidée par des résultats cliniques pour le traitement d'une maladie
US10173008B2 (en) 2002-01-29 2019-01-08 Baxter International Inc. System and method for communicating with a dialysis machine through a network
US10276054B2 (en) 2011-11-29 2019-04-30 Eresearchtechnology, Inc. Methods and systems for data analysis
US10347374B2 (en) 2008-10-13 2019-07-09 Baxter Corporation Englewood Medication preparation system
US10646405B2 (en) 2012-10-26 2020-05-12 Baxter Corporation Englewood Work station for medical dose preparation system
US10818387B2 (en) 2014-12-05 2020-10-27 Baxter Corporation Englewood Dose preparation data analytics
US10943676B2 (en) 2010-06-08 2021-03-09 Cerner Innovation, Inc. Healthcare information technology system for predicting or preventing readmissions
US10971257B2 (en) 2012-10-26 2021-04-06 Baxter Corporation Englewood Image acquisition for medical dose preparation system
US11107574B2 (en) 2014-09-30 2021-08-31 Baxter Corporation Englewood Management of medication preparation with formulary management
US11367533B2 (en) 2014-06-30 2022-06-21 Baxter Corporation Englewood Managed medical information exchange
US11574731B2 (en) 2020-06-17 2023-02-07 Optum, Inc. Computer-based systems and methods for action item evaluation and initiation via task data object generation
US11575673B2 (en) 2014-09-30 2023-02-07 Baxter Corporation Englewood Central user management in a distributed healthcare information management system
CN116092616A (zh) * 2022-12-15 2023-05-09 北京中科睿医信息科技有限公司 医疗数据传输方法、装置、设备及存储介质
US11948112B2 (en) 2015-03-03 2024-04-02 Baxter Corporation Engelwood Pharmacy workflow management with integrated alerts
CN118050982A (zh) * 2024-04-16 2024-05-17 山东黄海智能装备有限公司 一种基于改进同核子算法的小儿针灸仪微刺控制方法
US12412644B2 (en) 2014-10-24 2025-09-09 Baxter Corporation Englewood Automated exchange of healthcare information for fulfillment of medication doses

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5860917A (en) * 1997-01-15 1999-01-19 Chiron Corporation Method and apparatus for predicting therapeutic outcomes
US5993388A (en) * 1997-07-01 1999-11-30 Kattan; Michael W. Nomograms to aid in the treatment of prostatic cancer
US6022315A (en) * 1993-12-29 2000-02-08 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US6063028A (en) * 1997-03-20 2000-05-16 Luciano; Joanne Sylvia Automated treatment selection method

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6022315A (en) * 1993-12-29 2000-02-08 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US5860917A (en) * 1997-01-15 1999-01-19 Chiron Corporation Method and apparatus for predicting therapeutic outcomes
US6063028A (en) * 1997-03-20 2000-05-16 Luciano; Joanne Sylvia Automated treatment selection method
US5993388A (en) * 1997-07-01 1999-11-30 Kattan; Michael W. Nomograms to aid in the treatment of prostatic cancer

Cited By (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9757509B2 (en) 1999-10-22 2017-09-12 B. Braun Medical Inc. Method and apparatus for controlling an infusion pump or the like
US9750872B2 (en) 1999-10-22 2017-09-05 B. Braun Medical Inc. Method and apparatus for controlling an infusion pump or the like
US7873589B2 (en) 2001-04-02 2011-01-18 Invivodata, Inc. Operation and method for prediction and management of the validity of subject reported data
US6879970B2 (en) 2001-04-02 2005-04-12 Invivodata, Inc. Apparatus and method for prediction and management of subject compliance in clinical research
US9881062B2 (en) 2001-04-02 2018-01-30 Eresearch Technology, Inc. Operation and method for prediction and management of the validity of subject reported data
US8065180B2 (en) 2001-04-02 2011-11-22 invivodata®, Inc. System for clinical trial subject compliance
US7617078B2 (en) 2001-11-02 2009-11-10 Siemens Medical Solutions Usa, Inc. Patient data mining
US8949079B2 (en) 2001-11-02 2015-02-03 Siemens Medical Solutions Usa, Inc. Patient data mining
EP1440389A2 (fr) * 2001-11-02 2004-07-28 Siemens Medical Solutions USA, Inc. Exploration de donnees de patient pour observance automatisee
US7181375B2 (en) 2001-11-02 2007-02-20 Siemens Medical Solutions Usa, Inc. Patient data mining for diagnosis and projections of patient states
US7698156B2 (en) 2002-01-29 2010-04-13 Baxter International Inc. System and method for identifying data streams associated with medical equipment
US10173008B2 (en) 2002-01-29 2019-01-08 Baxter International Inc. System and method for communicating with a dialysis machine through a network
US10556062B2 (en) 2002-01-29 2020-02-11 Baxter International Inc. Electronic medication order transfer and processing methods and apparatus
US20060282244A1 (en) * 2004-11-30 2006-12-14 Sham Chotai Method and system for modeling scenarios in clinical trials
US8712748B2 (en) 2007-06-27 2014-04-29 Roche Diagnostics Operations, Inc. Medical diagnosis, therapy, and prognosis system for invoked events and methods thereof
US8818782B2 (en) 2007-06-27 2014-08-26 Roche Diagnostics Operations, Inc. System for developing patient specific therapies based on dynamic modeling of patient physiology and method thereof
US10061899B2 (en) 2008-07-09 2018-08-28 Baxter International Inc. Home therapy machine
US10095840B2 (en) 2008-07-09 2018-10-09 Baxter International Inc. System and method for performing renal therapy at a home or dwelling of a patient
US10224117B2 (en) 2008-07-09 2019-03-05 Baxter International Inc. Home therapy machine allowing patient device program selection
US10068061B2 (en) 2008-07-09 2018-09-04 Baxter International Inc. Home therapy entry, modification, and reporting system
US10025910B2 (en) 2008-07-25 2018-07-17 Eresearchtechnology, Inc. Endpoint development process
US10347374B2 (en) 2008-10-13 2019-07-09 Baxter Corporation Englewood Medication preparation system
US10943676B2 (en) 2010-06-08 2021-03-09 Cerner Innovation, Inc. Healthcare information technology system for predicting or preventing readmissions
US11664097B2 (en) 2010-06-08 2023-05-30 Cerner Innovation, Inc. Healthcare information technology system for predicting or preventing readmissions
US10276054B2 (en) 2011-11-29 2019-04-30 Eresearchtechnology, Inc. Methods and systems for data analysis
US11798660B2 (en) 2011-11-29 2023-10-24 Eresearch Technology, Inc. Methods and systems for data analysis
US11367512B2 (en) 2011-11-29 2022-06-21 Eresearchtechnology, Inc. Methods and systems for data analysis
US10089443B2 (en) 2012-05-15 2018-10-02 Baxter International Inc. Home medical device systems and methods for therapy prescription and tracking, servicing and inventory
US10646405B2 (en) 2012-10-26 2020-05-12 Baxter Corporation Englewood Work station for medical dose preparation system
US10971257B2 (en) 2012-10-26 2021-04-06 Baxter Corporation Englewood Image acquisition for medical dose preparation system
US20150127375A1 (en) * 2013-11-01 2015-05-07 Ta-Hsiung Hu Methods and systems for cloud-based medical database management
US11367533B2 (en) 2014-06-30 2022-06-21 Baxter Corporation Englewood Managed medical information exchange
US11107574B2 (en) 2014-09-30 2021-08-31 Baxter Corporation Englewood Management of medication preparation with formulary management
US11575673B2 (en) 2014-09-30 2023-02-07 Baxter Corporation Englewood Central user management in a distributed healthcare information management system
US12412644B2 (en) 2014-10-24 2025-09-09 Baxter Corporation Englewood Automated exchange of healthcare information for fulfillment of medication doses
US10818387B2 (en) 2014-12-05 2020-10-27 Baxter Corporation Englewood Dose preparation data analytics
US11948112B2 (en) 2015-03-03 2024-04-02 Baxter Corporation Engelwood Pharmacy workflow management with integrated alerts
WO2018222898A1 (fr) * 2017-06-02 2018-12-06 Mayo Foundation For Medical Education And Research Système et procédé pour fournir une expertise guidée par des résultats cliniques pour le traitement d'une maladie
US11574731B2 (en) 2020-06-17 2023-02-07 Optum, Inc. Computer-based systems and methods for action item evaluation and initiation via task data object generation
CN116092616A (zh) * 2022-12-15 2023-05-09 北京中科睿医信息科技有限公司 医疗数据传输方法、装置、设备及存储介质
CN116092616B (zh) * 2022-12-15 2024-05-14 北京中科睿医信息科技有限公司 医疗数据传输方法、装置、设备及存储介质
CN118050982A (zh) * 2024-04-16 2024-05-17 山东黄海智能装备有限公司 一种基于改进同核子算法的小儿针灸仪微刺控制方法
CN118050982B (zh) * 2024-04-16 2024-06-14 山东黄海智能装备有限公司 一种基于改进同核子算法的小儿针灸仪微刺控制方法

Also Published As

Publication number Publication date
AU5133700A (en) 2000-12-05

Similar Documents

Publication Publication Date Title
WO2000069331A1 (fr) Systeme de traitement de donnees pour l'estimation des risques encourus par un patient et des resultats probables chez ce patient et pour la gestion d'une base de donnees de sante
US20220138689A1 (en) Generation and Data Management of a Medical Study Using Instruments in an Integrated Media and Medical System
US8296164B2 (en) Pharmacy benefits management method and apparatus
US7647234B1 (en) Cardiovascular healthcare management system and method
US7076437B1 (en) Process for consumer-directed diagnostic and health care information
US7251609B1 (en) Method for conducting clinical trials over the internet
AU2007202746B2 (en) Systems and methods for refining identification of clinical study candidates
US7693728B2 (en) System and method for administering health care cost reduction
CA2734080C (fr) Systeme de communication de donnees de soins de sante
US8725534B2 (en) Systems and methods for enrollment of clinical study candidates and investigators
US20140316810A1 (en) Integrated health management system
US20030208108A1 (en) Cardiovascular healthcare management system and method
Hohmeier et al. Implementation of a health information exchange into community pharmacy workflow
US20090012816A1 (en) Systems and methods for clinical analysis integration services
WO2002086655A2 (fr) Systeme de marketing base sur l'autorisation destine a etre utilise avec des ordonnances medicales
US20040172305A1 (en) Method and appartus for delivering healthcare
US20120166226A1 (en) Healthcare management system
US20070179806A1 (en) Medication therapy management process
US20110099024A1 (en) Healthcare management system
KR100538580B1 (ko) 온라인 상에서의 병원 업무 처리 방법
US20060080145A1 (en) Method for reviewing electronic patient medical records to assess and improve the quality and cost effectiveness of medical care
WO2001033378A1 (fr) Procede relatif a un diagnostic conduit par le sujet et a une information portant sur les soins de sante
Arnold et al. Retrospective database analysis
Solz et al. Health claims data as a strategy and tool in disease management
Lorence et al. Toward a patient–centric medical information model: issues and challenges for US adoption

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP