+

WO2008103749A1 - Système et procédé pour fournir aux utilisateurs à distance des rapports et des analyses en fonction de données utilisateur et de rapport adaptable ayant la capacité de modifier ou d'augmenter de tels rapports et analyses par l'intermédiaire d'une technologie web - Google Patents

Système et procédé pour fournir aux utilisateurs à distance des rapports et des analyses en fonction de données utilisateur et de rapport adaptable ayant la capacité de modifier ou d'augmenter de tels rapports et analyses par l'intermédiaire d'une technologie web Download PDF

Info

Publication number
WO2008103749A1
WO2008103749A1 PCT/US2008/054451 US2008054451W WO2008103749A1 WO 2008103749 A1 WO2008103749 A1 WO 2008103749A1 US 2008054451 W US2008054451 W US 2008054451W WO 2008103749 A1 WO2008103749 A1 WO 2008103749A1
Authority
WO
WIPO (PCT)
Prior art keywords
patient
user
data
database
physician
Prior art date
Application number
PCT/US2008/054451
Other languages
English (en)
Inventor
Thomas Dent
Theresa Hush
William M. Aube
Original Assignee
Iclops, 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 Iclops, Llc filed Critical Iclops, Llc
Publication of WO2008103749A1 publication Critical patent/WO2008103749A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • 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
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • 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
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • 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
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • 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
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation

Definitions

  • This invention is directed generally to a system and method of providing reports and analyses through web-based technology, and more particularly to a system and method of providing remote users in the health care or other professional industry, via their computer web browser, with reports and analyses related to physician or provider performance based on data from information systems in a fashion that allows them to alter, modify or augment the contents and presentation of such reports and analyses by the use of a web application utilizing database technology.
  • Health care enterprises are measured by insurance plans and governmental bodies on their ability to provide measurable quality care to discrete populations, such as diabetic, hypertensive, and asthmatic patients, and to provide screening programs appropriate to age and gender.
  • Physician practices currently lack the tools needed to efficiently respond to these issues.
  • Typically the only method of compiling financial and market data is through the practice's billing or clinical information systems. Even when used (some practices outsource billing functions), these systems are usually designed for transactional processing and provide limited management reporting and little, if any, practice profile data. Tools for the management of Clinical Quality are even scarcer.
  • programming staff are still required to write and reformat static reports for true analytical purposes, which can be very costly.
  • practices of all sizes are lacking the information critical to success and sustainability.
  • One embodiment of the invention is directed to creating meaningful business and clinical quality analysis tools based on data from a client's practice management system, external billing systems, external insurance systems, external pharmacy systems, external laboratory systems, and other sources of client data; and providing such clients at remote locations with web-based access to those tools.
  • an analysis database that is used to develop custom OLAP cubes built especially to address business and clinical analyses and to serve as a platform for enhanced clinical quality measurement.
  • the analysis database feeds analyzed patient and practice information into a Master Patient Registry (MPR) database.
  • MPR Master Patient Registry
  • the MPR database grants the ability to accurately identify and evaluate patient groups, as well as generate mechanisms for validation and the capture of additional clinical data.
  • Business and clinical performance indicators used by external experts, purchasers of health care, and patients were analyzed and itemized to determine what queries may be needed by a practice. These performance indicators included financial performance measures used by accountants, billing agents, and other organizations assessing the financial health of the customer entity; financial and other measures used by provider contracting organizations in assessing the impact of contracts between health care payers and the customer entity; market performance measures used to assess the growth potential and survivability of the customer entity; productivity and operational performance measures used to determine the efficiency of the operation of the customer entity; and clinical performance measures used to evaluate compliance with established clinical protocols and accepted quality of care guidelines.
  • Transactional data needed to develop queries that result in the performance analyses are identified and listed.
  • the client data is then combined with the performance identifiers to create a standard dataset for extraction from the sources of client data.
  • the standard dataset is then organized into OLAP datamarts and cubes to create modules, dimensions, and measures by which the performance analysis may be displayed to customers.
  • the result of this process is an analytical tool that can be customized for individual customers, but which contains a model for organizing and displaying analyses of business and clinical performance.
  • Transactional data from the sources of client data is copied or extracted into a file or set of files.
  • the system that stores these files possesses a client application for encrypted file transfer, and is connected to a transmission system (such as the Internet or a corporate local area network (LAN)) via a first transmit/receive device (such as an Ethernet network interface card (NIC)).
  • Data files are sent from the source system to a host server.
  • Data files are analyzed and a relational database is created.
  • the relational database is further analyzed to determine the possible analytical content.
  • the analysis database (also technically termed as datamarts) is created based on what analytical content is possible, according to the processes previously determined to be needed by a practice and for clinical quality evaluation.
  • the analysis database is created to respond to queries in the areas of financial performance, patient flow, patient satisfaction, physician productivity, contract profitability, and clinical quality. Cubes are then created based on the analysis database.
  • the analysis database is structured to contain not only data that has been sourced from client data, but registry information and quality measurements as well.
  • the MPR database imports data from the datamarts and evaluates what data has changed since the previous import.
  • the MPR database uses business rules to determine how the registries will be modified by the new information. Additionally, some registry information can be corrected through the use of a secure web-based application interface.
  • the MPR database also uses the registry information to determine if prompt-based data capture techniques are applicable, and generate the needed materials if so.
  • Data within the analysis database may be used to calculate a score that provides an indication of a physician's performance.
  • the physician score is determined by analyzing data from multiple data sources. The data is stored within a patient registry and filtered prior to analysis. The physician score may be determined by examining critical points of care to patients who represent a critical or measurable component of the physician's patient base.
  • the following describes the method by which a user gains access to the OLAP cubes or registry validation functions and makes use of them via a web application.
  • the user logs onto the web page, selects the appropriate application, and enters authentication information, which may vary from entering a password to more complex entry authorization protocols.
  • the user may access the web site by using a computer to open a web browser and entering a universal resource locator (URL) for the web server hosting a web application.
  • the web server sends a homepage to the web browser of the user via a transmission system.
  • the user accesses the web application via the web browser, and the web server sends a login form in which the user enters his credentials/password to obtain access. Once accessed, the web server sends a dynamic custom application page to the user.
  • the user then performs application options, such as alter, modify, and augment the contents of views. For example, the user may use the application to review the status of all patients assigned to all measures for a physician. Additionally, the user may use the application to enter quality codes and clinical values in response to a measure in which a patient has been included. In this manner, use of the application enables users to understand and maintain their business and clinical operations, and to improve business performance and patient care.
  • application options such as alter, modify, and augment the contents of views.
  • the user may use the application to review the status of all patients assigned to all measures for a physician. Additionally, the user may use the application to enter quality codes and clinical values in response to a measure in which a patient has been included. In this manner, use of the application enables users to understand and maintain their business and clinical operations, and to improve business performance and patient care.
  • FIG. 1 is a block diagram of a system for data extraction and conversion, according to an example
  • Fig. 2 is a table of data fields for client data, according to an example
  • FIG. 3 is a flowchart of a method of data extraction and conversion using the system depicted in Fig. 1, according to an example;
  • Fig. 4 is a block diagram of a system for client access to analytical data and patient registries, according to an example;
  • Fig. 5 is a flow chart of a method of accessing analytical data and patient registries using the system depicted in Fig. 4, according to an example;
  • Fig. 6 is a screen shot of a sample view, according to an example;
  • Fig. 6A is a screen shot of a web page for entering user credentials, according to an example
  • Fig. 6B is a screen shot of a web page for selecting an application component, according to an example
  • Fig. 6C is a screen shot of a web page for reviewing the status of all patients assigned to all measures for a physician, according to an example
  • Fig. 6D is a screen shot of a web page for reviewing the status of all measures for a patient, as well as for the input of new information and the correction of erroneous information, according to an example;
  • Fig. 6E is a screen shot of a web page for reviewing the status of all measures for a patient, as well as for the input of new information and the correction of erroneous information, according to an example;
  • Fig. 6F is a screen shot of a web page for entering quality codes in response to a measure which a patient has been included; according to an example
  • Fig. 6G is a screen shot of a web page for entering quality codes that pertain to specific clinical metrics in response to a measure which a patient has been included; according to an example;
  • Fig. 6H is a screen shot of a web page for reviewing the data history for a patient as well as for the input of new information and the correction of erroneous information, according to an example;
  • Fig. 61 is a screen shot of a web page for selecting one of two possible ways to generate data capture tools for quality management, according to an example
  • Fig. 6 J is a screen shot of a web page for selecting groups of patients based on last visit date for the bulk creation of data capture tools for quality management, according to an example
  • Fig. 6K is a screen shot of a web page for selecting groups of patients based on registry membership for the bulk creation of data capture tools for quality management, according to an example
  • Fig. 6L is a screen shot of a web page for selecting groups of patients based on provider and last visit date for the bulk creation of data capture tools for quality management, according to an example according to an example
  • Fig. 6M is a screen shot of a web page for selecting groups of patients based on registry membership for the bulk creation of data capture tools for quality management, according to an example;
  • Fig. 60 is intentionally omitted;
  • Fig. 6N is a screen shot of a web page for selecting groups of patients based on patient name for the creation of data capture tools for quality management, according to an example;
  • Fig. 6P is a sample of a component used in the dynamic construction of data capture tools for quality management according to an example
  • Fig. 6Q is a sample of a fully constructed data capture tool, personalized for an individual patient's specific measure assignments, according to an example
  • Fig. 6R is a screen shot of a sample analytical view, according to an example
  • Fig. 7 is a screen shot of practice revenues, according to an example
  • Fig. 8 is a screen shot of patient visits, according to an example
  • Fig. 9 is a screen shot of charges and revenues, according to an example
  • Fig. 10 is a screen shot of charges by financial class, according to an example
  • Fig. 11 is a screen shot of revenues by financial class, according to an example
  • Fig. 12 is a screen shot of collection rates, according to an example
  • Fig. 13 is a screen shot of collection rates by payer, according to an example
  • Fig. 14 is a screen shot of financial data, according to an example
  • Fig. 15 is a screen shot of data shown in Fig. 14 including percent charges of RBRVS, according to an example
  • Fig. 16 is a screen shot of data shown in Fig. 15 by payer, according to an example
  • Fig. 17 is a screen shot of data shown in Fig. 16 by a selected financial class, according to an example;
  • Fig. 18 is a screen shot of data shown in Fig. 17 including charges with adjudicated payments, denied charges, and payment lag, according to an example;
  • Fig. 19 is a screen shot of financial data, according to another example
  • Fig. 20 is a screen shot of financial data, according to another example
  • Fig. 21 is a screen shot of a number of diabetic patients and a number of visits these patients made to a practice in a given time, according to an example;
  • Fig. 22 is a screen shot of data shown in Fig. 21 separated by age category, according to an example;
  • Fig. 23 is a screen shot of data shown in Fig. 22 separated by financial class, according to an example
  • Fig. 24 is a screen shot of a number of diabetic patients that also suffer from hypertension, according to an example;
  • Fig. 25 is a screen shot listing diabetic patients that also suffer from hypertension and the associated number of visits, according to an example
  • Fig. 26 is a screen shot listing place of service, according to an example
  • Fig. 27 is a screen shot of data shown in Fig. 26 for patients that visited a practice in the last two quarters, according to an example;
  • Fig. 28 is a screen shot of data shown in Fig. 27 including date of visit, according to an example
  • Fig. 29 is a screen shot of data shown in Fig. 28 including primary diagnosis, according to an example
  • Fig. 30 is a screen shot of data shown in Fig. 29, including charge to patient, according to an example
  • Fig. 31 is a block diagram that shows how a patient registry database may be created and updated, according to an example;
  • Fig. 32 is a screen shot of a patient registry, according to an example;
  • Fig. 33 is a physician prompt for diabetes treatment, according to an example
  • Fig. 34 is a patient prompt, according to an example.
  • Fig. 35 is a physician score report, according to an example.
  • Fig. 1 is a block diagram of a system 100 for data extraction and conversion.
  • the system 100 includes a client server 102 and a database server 104.
  • the system 100 may include additional entities not shown in Fig. 1. Additionally or alternatively, the servers 102,104 may be co-located and/or integrated.
  • the client server 102 may be a client's source computer system.
  • the client server 102 may include a processor 108, data storage 110, at least one application 112, an encryption/decryption utility 114, and a transmit/receive device 116.
  • the client server 102 may be located behind a client firewall 118.
  • the client server 102 may include additional entities not shown in Fig. 1.
  • the processor 108 may be a microprocessor suitable for receiving input signals, executing machine language instructions, and providing output signals.
  • the processor 108 may receive input signals internally, such as from the data storage 110. Additionally or alternatively, the processor 108 may receive input signals externally using the encryption/decryption utility 114 and the transmit/receive device 116.
  • the application 112 may include machine language instructions executed by the processor 108.
  • the processor 108 may provide the output signals to entities within the client server 102, such as the data storage 110. Alternatively, the processor may provide the signals to an external entity, such as the database server 104, using the encryption/decryption utility 114 and the transmit/receive device 116.
  • the data storage 110 may comprise one or more volatile and/or non- volatile storage mechanisms, such as random-access-memory (RAM), flash memory, an optical disk drive, a magnetic disk drive, and so on.
  • Client data 120 in the form of a file or set of files that contain details of client transactions, may be stored in the data storage 110. Additionally or alternatively, some or the entire client data may be stored one or more other servers. For example, the client data 120 may be stored on an external billing, insurance, pharmacy, and/or laboratory system. The client data 120 may be stored in the data storage 110 in a table format.
  • the client data 120 may include customer/patient demographic information and transactional details, such as charges, payments, payment sources, diagnoses, services rendered, service provider, and so on.
  • the application 112 may be a software program, such as a practice management system, used by the client.
  • the application 112 may facilitate the collection of client data 120 that is stored in the data storage 110.
  • the application 112 may display a form on a computer display that enables a user to enter client data 120 to be stored in the data storage 110.
  • the same or a different application 112 may be used to generate reports for the client.
  • the reports may include some or the entire client data 120 stored in the data storage 110.
  • Figs. 2A-2B is a table of data fields for the client data 120, according to an example.
  • the first column, "Source Field Data,” includes the types of data in a data field, while the second column, “Source Field Description,” includes a definition of the client data associated with the data field. Additional data fields may be included in the table.
  • the client server 102 may collect client data 120 regarding the practice, the patient, the diagnosis, insurance, and other transactional information regarding a patient's visit to a physician's office.
  • the encryption/decryption utility 114 may be used to ensure data security for both transmitted and received data.
  • the encryption/decryption utility 114 may be a secure shell (SSH) utility.
  • SSH secure shell
  • the client server 102 may securely transmit and receive data over a network, such as a local area network (LAN), a wide area network (WAN), intranet, and the Internet.
  • a network such as a local area network (LAN), a wide area network (WAN), intranet, and the Internet.
  • the client may copy the client data 120 stored on the data storage 110 onto a physical medium, such as a magnetic storage device or an optical storage device, and deliver the physical medium to a user of the database server 104.
  • the transmit/receive device 116 may allow data to be transmitted and received over a network.
  • the transmit/receive device 116 may be an Ethernet network interface card (NIC).
  • the transmit/receive device 116 may allow the client data 120 to be transmitted and received over network 122.
  • the client firewall 118 may prevent unauthorized entities attached to the network 122 from obtaining the client data 120.
  • the network 122 may provide a communication pathway between the client server 102 and the database server 104.
  • the network 122 may be a LAN, WAN, intranet, or Internet.
  • the client server 102 and the database server 104 may be co-located and/or integrated and the network 122 may be unnecessary to transfer client data between the client server 102 and the database server 104.
  • the database server 104 may receive client data 120 from the client server 102 or other external sources using an encryption/decryption utility 130 and a transmit/receive device 132.
  • the encryption/decryption utility 130 may be a SSH utility. However, other encryption/decryption methods may be used to allow the database server 104 to securely transmit and receive data over the network 122.
  • the transmit/receive device 116 may be an Ethernet NIC.
  • the transmit/receive device 132 may allow data to be transmitted and received over the network 122.
  • the database server 104 may be a computer designed to extract and convert client data 120 that was originally stored on the client server 102 or other system.
  • the database server 104 may receive client data 120 from external billing systems, insurance systems, pharmacy systems, laboratory systems, and other sources.
  • the database server 104 may be running a database program, such as Microsoft SQL Server.
  • the database server 104 may create a temporary staging database 134.
  • the temporary staging database 134 may be a tabular or relational database that includes some or the entire client data 120.
  • the contents and details of the client data 120 in the temporary staging database 134 may be quantified and mapped.
  • the contents of the client data 120 may be quantified based on analytic definitions.
  • the analytic definitions are an identification of what questions a practice may ask to further understand their business and clinical operations, and to improve business performance and patient care.
  • the analytic definitions may be performance measures used to gauge a practice. Some of the analytic definitions used by the system 100 are listed below. The analytic definitions are grouped by financially focused analytic definition examples and clinically focused analytic definition examples.
  • Collections • Determine the collection rates by financial class and by payer, on charge base and on
  • RBRVS Resource-Based Relative Value Scale
  • E&M Evaluation and Management
  • the content of the data in the temporary staging database 134 may be analyzed to locate sets of information required by the analytic definitions.
  • a practice management system may store the different types of data separately. For example, the following data types may be stored separately: charges, payments, appointments, aging accounts receivable, and clinical records.
  • the identification of tables and fields need for the analytic definitions may be performed manually or by using a database schema document. Inconsistencies, such as erroneous data types, may be isolated and/or corrected while the client data 120 is in the temporary staging database 134.
  • the database server 104 may create a clean database 136.
  • the clean database 136 may be created by identifying the relevant sets of data in the temporary staging database 134 and disregarding the non-relevant data sets. The relevant sets of data are then copied to the clean database 136.
  • the clean database 136 may be used to further explore the contents of the client data 120.
  • queries may be executed to group sets of data together in ways dictated by the analytic definitions. For example, a query may be performed that analyzes the CPT codes found within each transaction and categorizes these transactions by where services were provided. This new categorization may allow the practice to see how many patients have been treated in an office, a hospital, or a nursing home. As another example, a query may be performed that analyzes diagnosis codes and categorizes by diagnosis. This new categorization may allow a practice to see how many diabetic (or any other chronic condition) patients they are treating. Other queries may be performed that locate and correct null values in records, which may have "orphaned" the records.
  • the clean database 136 may be used to separate the data in the clean database 136 into smaller, related groups of data, herein referred to as datamarts 138.
  • the datamarts 138 may be created by separating the client data 120 according to requirements of the analytic definitions. For example, one datamart 138 may include financial information, while another datamart 138 may include scheduling information. By separating the client data 120 into datamarts 138, the datamarts 138 may be queried to provide concise, meaningful analyses to a client. These analyses may be performed using a standard set of data. However, customized analysis may be performed using a client's unique data or needs. For example, the datamarts 138 may include information relevant to revenue cycles, the flow of customers/patients of specific interest, and/or any other analysis desired by the client.
  • the Master Patient Registry (MPR) database 121 may be created using datamarts 138.
  • the MPR database 121 may utilize elements of claims data that have clinical value, such as patient demographic information (e.g., gender, age, ZIP code, etc), diagnoses (e.g., in the form of ICD-9 codes), and procedures (e.g., in the form of CPT codes).
  • the MPR database 121 may be created by analyzing each record in the datamarts 138 for combinations of data that match rules defined for Clinical Quality Measures which are stored in the Systems Management Database 432. When the data in a record within a datamart 138 matches the criteria defined in a Measure, the patient and service provider associated with that record is assigned to that Measure as a record in the MPR database 121.
  • Each Measure has Quality Codes associated with it, and the MPR database 121 may receive data indicating the presence of a Quality Code from the datamarts 138 or from the web application 422 defined in system 400.
  • the datamarts 138 may be processed into multidimensional databases called cubes 140.
  • the datamarts 138 may be processed into cubes 140 using an on-line analytical processing (OLAP) engine, such as Microsoft Analysis Services.
  • OLAP engines may perform multidimensional expression (MDX) analysis of data, including complex calculations, trend analysis, and modeling. Those skilled in the art are familiar with the operation of OLAP engines.
  • MDX multidimensional expression
  • the cubes 140 may be constructed to provide adequate capacity to analyze financial trends of the practice, payer contract assessment, patient volume and trends, physician-specific activity, clinical volume and trends, and patient population tracking and trends. These cube areas are listed below.
  • Financial Cube Financial trends of the practice a. Analysis of financial activity by dates of service and posting dates b. Aged accounts receivable c. Charge posting lag d. Payment lag from date of billing e. Payer mix and by-payer reimbursements f. Collection rates, contractual allowances, and denied charges g. Denial reasons h. RBRVS-benchmarked collections and payments i. Procedure coding j. Other drivers for practice revenues: place of service efficiencies, service mix by CPT, lab reimbursements and costs
  • Payer Cube Payer Contract Assessment a. Patient mix by payer b. By-payer collection results (charge-based and RBRVS), denials, payment lags, and total discount c. Payment variability between payer fee schedule and payment level
  • Patient Cube Patient volume and trends a. Zip code and demographic trends b. New visit growth trends c. Patient age groupings
  • Physician Cube Physician-Specific Activity a. Activities sorted by physician, location, CPT and CPT groupings b. By-physician and by-location charges, revenues, procedure coding c. Office appointment through-put by location and physician
  • Clinical Cube Clinical Volume and Trends a. E & M coding and procedural activity b. Patient listings for diagnoses of concern c. Referral source trends by type of cases and aggregated severity
  • EMR Electronic Medical Records
  • the cubes 140 may be stored.
  • the cubes 140 may be stored on the database server 104.
  • the cubes 140 may be stored at an offsite datacenter.
  • the cubes 140 may be transmitted to the client server 102 or another server via a network, such as network 122.
  • the cubes 140 may be transferred using an encryption/decryption utility, such as SSH.
  • the cubes 140 may be transferred to a datacenter by copying the cubes 140 onto a physical medium, such as a magnetic storage device or an optical storage device, and delivering the physical medium to the datacenter.
  • the database server 104 may be located behind a service firewall 142.
  • the service firewall 142 may prevent unauthorized entities attached to the network 122 from obtaining the client data 120, patient registry data 121, and/or converted data.
  • Fig. 3 is a flowchart of a method 300 for data extraction and conversion, according to an example. The method 300 is explained with reference to the system 100 depicted in Fig.
  • the method 300 may also include additional steps not depicted in Fig. 3.
  • client data 120 may be received by the database server 104.
  • the client data 120 may be in the form of a table.
  • the client data 120 may include the types of data depicted in Figs. 2A-2B.
  • a temporary staging database may be created.
  • the temporary staging database 134 may be a tabular or relational database that includes some or the entire client data 120.
  • client data 120 may be quantified and mapped.
  • the contents of the client data 120 may be quantified based on analytic definitions.
  • the analytic definitions are an identification of what questions a practice may ask to further understand their business and clinical operations, and to improve business performance and patient care.
  • the content of the data in the temporary staging database 134 may be analyzed to locate sets of information required by the analytic definitions.
  • the identification of tables and fields need for the analytic definitions may be performed manually or by using a database schema document. Inconsistencies, such as erroneous data types, may also be isolated and/or corrected while the client data 120 is in the temporary staging database 134.
  • a clean database 136 may be created.
  • the clean database 136 may be created by identifying the relevant sets of data in the temporary staging database 134 and disregarding the non-relevant data sets. The relevant sets of data are then copied to the clean database 136.
  • the clean database 136 may be used to further explore the contents of the client data 120.
  • datamarts 138 may be created.
  • the datamarts 138 may be created by separating data in the clean database 136 according to requirements of the analytic definitions. By separating the client data 120 into datamarts 138, the datamarts 138 may be queried to provide concise, meaningful analyses to a client.
  • the datamarts 138 may include information relevant to revenue cycles, the flow of customers/patients of specific interest, or any other analysis desired by the client.
  • cubes 140 may be created.
  • the datamarts 138 may be processed into cubes 140 using an OLAP engine.
  • the cubes 140 may be constructed to provide adequate capacity to analyze financial trends of the practice, payer contract assessment, patient volume and trends, physician-specific activity, clinical volume and trends, and patient population tracking and trends.
  • the MPR database 121 may be created by analyzing each record in the datamarts 138 for combinations of data that match rules defined for Clinical Quality Measures which are stored in the Systems Management Database 432.
  • the data in a record within a datamart 138 matches the criteria defined in a Measure, the patient and service provider associated with that record is assigned to that Measure as a record in the MPR database 121 Creation and Utilization of a Master Patient Registry (MPR) Database
  • Fig. 31 is a block diagram that shows how a patient registry database may be created and updated.
  • the analysis database is primarily sourced from claims data and is later supplemented with additional data generated as described below.
  • the analysis database may contain elements of claims data that have clinical value, such as patient demographic information (e.g., gender, age, ZIP code, etc), diagnoses (e.g., in the form of ICD-9 codes), and procedures (e.g., in the form of CPT codes).
  • the analysis database may use this information to develop a series of registries that correspond to patient populations under clinical quality review, based on diagnosis or procedure history or other factors such as age and gender.
  • the individual registries may overlap, but the MPR database may show unique patients with multiple registries listed.
  • Several methods can be used to attribute a provider to the patient and his/her registries. These registries can be further stratified through the import of additional data gathered outside the claims process as described as follows.
  • a query from the analysis database i.e., Analysis Database Feed
  • the information gathered here may include patient identification, last known participation status, last known status of all condition registries, date and nature of the last known registry trigger, last known date of service with that practice, and last known prompt responses. If any of the above information is not yet resident in the analysis database, default or null values may be used.
  • This query is triggered by an update of claims data in the analysis database.
  • an MPR Website is used by an authorized physician or their agent to log into the MPR database and update certain patient status information. The user can see and alter the status of the patient in the practice. For example, if a patient has died, moved away or has been dismissed, the user can select a checkbox to indicate that updated status. Similarly, the user can view all of the condition registries that the patient fits into and review that information.
  • the user may then select a checkbox if he/she feels that the patient has been erroneously included in that registry or if that particular condition is not being handled in the practice. Changes performed through the web interface may be immediately applied directly to the MPR database, and the MPR database may internally log when these changes occurred.
  • the MPR database may run a scheduled process to ensure that a patient's membership in the practice is up to date.
  • the Update Information process retrieves information on the patient from the Analysis Database Feed, such as last known date of service, last known place of service, last known attributed provider, and other elements.
  • the MPR database uses information pertaining to the last known visit to determine if the patient is still considered active in the practice. If the last known date of service is over twenty- four months earlier than the present date, then the MPR database may flag that patient as inactive.
  • the MPR database may run this process on a periodic basis, such as once a day.
  • the MPR may run a scheduled process to ensure that a patient's inclusion or exclusion in a condition registry is confirmed by the most recent claims data.
  • the Update Status process retrieves information on the patients from the Analysis Database Feed such as the dates and nature of the last known registry triggers. For example, if a patient has been considered erroneously included in a registry and recorded as such using the MPR web interface, the Update Status process searches for confirming information.
  • the trigger information in the Analysis Database Feed is older than the exclusion information in the MPR database, then the patient's status in that registry remains unchanged. However, if the Analysis Database Feed has information that again triggers a patient's membership in a registry, and is newer than the exclusion information in the MPR database, then the patient's status in that registry is updated in the MPR database.
  • the MPR database may run this process on a periodic basis, such as once a day.
  • a physician prompt is the physical representation of a set of questions to be answered by the provider at the point of care, usually a paper from positioned in the patient's medical record.
  • the physician prompt codes and uses are addressed later in detail.
  • the physician checks the applicable answers on the prompt form and these codes are then entered into the practice management system as procedure codes and modifiers to be ultimately collected by the analysis database.
  • the MPR database runs a scheduled process to generate a prompt if a patient is eligible to receive one.
  • the Prompt Generation process checks the Analysis Database Feed for a patient's status in a condition registry and whether that patient had received a prompt already.
  • the Prompt Generation process may create a prompt specifically for that patient given their specific combination of conditions.
  • the MPR database maintains a set of components that may be assembled dynamically for each patient when they become eligible for a prompt. That prompt can then be printed out and filed in the patient's medical record.
  • the MPR database may run this process on a periodic basis, such as once a day.
  • a patient communication letter may be generated by the MPR encouraging a course of action for the patient to take, for certain clinical conditions and agreements with some physicians. The letters are designed to appear as if they were generated by the practice, and bear the signatures of that practice's physicians.
  • the MPR database runs a scheduled process to generate a letter if a patient is eligible to receive one.
  • the Letter Generation process checks the Analysis Database Feed for the date of the most recent sent communication, if any. If a patient has not received a certain communication or letter and is eligible to receive one, then the Letter Generation process may create a letter specifically for that patient given their specific role in the practice's overall communication strategy.
  • the MPR database maintains a set of components that may be assembled dynamically for each patient when they become eligible for a letter. That letter can then be printed out and mailed to the address on file.
  • the MPR database may run this process on a periodic basis, such as once a day.
  • processes 3A-3E generate new information, the new information may be supplied to the MPR database at process 4.
  • the analysis database synchronizes itself with the latest information contained in the MPR database. Information that was updated via the web interface as well as tracking information regarding generated prompts and letters are sent back to the analysis database to enable reporting on claims data supplemented with quality and process information
  • Fig. 4 is a block diagram of a system 400 for client access to analytical data, according to an example.
  • the system 400 includes a client device 402, a web server 404, and a database server 406.
  • the system 400 may include additional entities not shown in Fig. 4.
  • the servers 404, 406 may be co-located and/or integrated.
  • the client device 402 may be a computing device or a terminal connected to a computing device.
  • the client device 402 includes a web browser 408, output devices 410, input devices 412, a processor 414, an encryption/decryption utility 416, and a transmit/receive device 418.
  • the client device 402 may include additional entities not depicted in Fig. 4.
  • the client device 402 may allow a user of the client device 402 to remotely access analytical data.
  • the web browser 408 may be an application that allows web pages to be viewed by the user of the client device 402.
  • the web browser 408 may fetch a web page that is requested by the user, interpret the text, format commands within the text, and then properly display the web page on a screen.
  • the web browser may be Mozilla Firefox or Microsoft Internet Explorer. Those skilled in the art are familiar with the operation of web browsers.
  • the processor 414 may be a microprocessor suitable for receiving input signals, executing machine language instructions, and providing output signals.
  • the processor 414 may receive inputs from entities within the client device 402 or from external sources via the input devices 412.
  • the input devices 412 may include any device that provides inputs to the client device 402, such as a keyboard, microphone, or mouse.
  • the processor 414 may be operable to execute commands from the web browser 408 and/or other applications on the client device 402.
  • the processor 414 may provide outputs to entities within the client device 402 or to external sources using the output devices 410.
  • the output devices 410 may be any device that provides an output to a user of the client device, such as a monitor or printer.
  • the encryption/decryption utility 416 may be used to ensure data security for both transmitted and received data.
  • the encryption/decryption utility 416 may be a
  • SSH utility may be used to allow the client device 402 to securely transmit and receive data over a network, such as a LAN, a WAN, intranet, and the Internet.
  • a network such as a LAN, a WAN, intranet, and the Internet.
  • the transmit/receive device 418 may allow data to be transmitted and received over a network.
  • the transmit/receive device 418 may be an Ethernet NIC.
  • the transmit/receive device 418 may allow a user of the client device 402 to request and receive analytical data.
  • a network 420 may provide a communication pathway between the client device 402 and the web server 404.
  • the network 420 may be a LAN, WAN, intranet, or
  • the web server 404 may be a computer connected to an intranet or the Internet that stores and displays documents and files.
  • the web server 404 may include a web application 422, an encryption/decryption utility 424, a first transmit/receive device 426, and a second transmit/receive device 428.
  • the web server 404 may include additional entities not depicted in Fig. 4.
  • the web application 422 may be a software application that is operable to select and display appropriate web pages on the client device 402.
  • the web application 422 may receive a request from the web browser 408 for a web page.
  • the web application 422 may respond to the request by verifying the user's authorization to have access to the web page, and if authorized, providing the requested web page to the web browser 408.
  • the web application 422 may receive the request for a web page and respond to the request using the encryption/decryption utility 424 and the first transmit/receive device 426.
  • the encryption/decryption utility 424 may be used to ensure data security for both transmitted and received data.
  • the encryption/decryption utility 424 may be a SSH utility.
  • other encryption/decryption methods may be used to allow the web server 404 to securely transmit and receive data over the network 420.
  • the first transmit/receive device 426 may allow data to be transmitted and received over the network 420.
  • the second transmit/receive device 428 may allow data to be transmitted and received over a network 430.
  • the first transmit/receive device 426 and the second transmit/receive device 428 may each be an Ethernet NIC.
  • the network 430 may provide a communication pathway between the web server 404 and the database server 406.
  • the network 430 is a LAN; however, the network 430 may be a WAN, intranet, or Internet.
  • the web server 404 and the database server 406 may be co-located and/or integrated and the network 430 may be unnecessary.
  • the database server 406 may be substantially the same as the database server 104 depicted in Fig. 1.
  • the database server 406 includes a system management database 432.
  • the system management database 432 may include client authorization data and Quality Measure and Registry definition information.
  • the client authorization data may include a database record associated with each authorized user that indicates which menus (lists and categories of views attributed to the specific user), views (OLAP queries, specifically MDX queries, already written and attributed to the user), databases, and overall content is available to the user with those credentials.
  • the Measure and Registry definition information may include the combinations of data required to assign a patient to a Measure or Registry.
  • the database record may include a query code associated with each client that specifies an initial web page to be displayed to the client upon successful credential verification or other user specific permissions.
  • the user may see patients that are displayed automatically into groups (Measures and Registries) based on a combination of diagnoses, clinical procedures, demographics and other factors, through the analysis of data within this system.
  • Fig. 5 is a flow chart of a method 500 of accessing analytical data using the system depicted in Fig. 4, according to an example. The method 500 is explained with reference to the system 400 depicted in Fig. 4. The method 500 may also include additional steps not depicted in Fig. 5.
  • the user may access a web page.
  • the user may use a universal resource locator (URL) to access the web page.
  • the web page may be associated with the database server 406.
  • the web server 404 may transmit the proper web page to the user.
  • URL universal resource locator
  • the user may click on publicly available links on the web page and the web server 404 may produce the selected pages to be displayed on the client device 402.
  • the user may request access to analytical data.
  • the user may click on a link to logon into the web application 422.
  • the web server 404 may transmit a page containing a logon form. This transmission may be encrypted by the web server 404 and decrypted by the web browser 408 on the client device 402.
  • the user may enter authorized logon credentials into the logon form and submit the form.
  • This transmission may be encrypted by the web browser 408 on the client device 402 and decrypted by the web server 404.
  • the web server 404 may verify the user's credentials.
  • the web server 404 may access the system management database 432 and compare the user's credentials with the system management database 432. If the user's credentials do not match those in the system management database 432, the web server 404 may re-transmit the logon form with an appropriate error message so the user may try again.
  • the web server 404 may determine the extent of the user's access to the analytical data. If the user's credentials match those of a record within the system management database 432, the web server 404 may determine what content the user has access to by reading from the database record associated with the user. The database record associated with the user may dictate which menus (lists and categories of views attributed to the specific user), views (OLAP queries, specifically MDX queries, already written and attributed to the user), databases, and overall content is available to the user with those credentials.
  • the web server 404 may display a web page with several links to components of the web application 422, depending on the records within the system management database 432.
  • the web server 404 may display links for, but not limited to, Quality Management, Data Capture Tools, and Analytical Tools.
  • the user may move the mouse cursor to a hyperlink for a component of web application 422 that manages Quality Measures and Registries, and click upon it.
  • the web server 404 opens the appropriate web page for the user.
  • the web server 404 may select from the system management database 432 the proper patients, measures and registries to generate the web page as seen by the user.
  • the web server 404 queries the MPR database 121 on the database server 406 with the information received from the system management server 432.
  • the database server 406 (or the offsite datacenter) may transmit the query results to the web server 404.
  • the web server 404 may send to the user's browser 408 a dynamically built web page containing the practices, providers, measures, registries and patients specifically assigned to that user. This transmission may be encrypted by the web server 404 and decrypted by the user's browser 408 on the client device 402.
  • the user may perform several actions within the web application 422 at this point.
  • the user may: a. Select a Practice from a drop-down box to repopulate the web page with data originating from a different practice.
  • b. Select a Provider from a drop-down box to repopulate the web page with data originating from a different provider.
  • c. Sort Measures by Category, Measure Name, the Patient Count, or the Completion percentage.
  • d View Measure-wide results and click on a Measure to view the results of individual patients.
  • f. Open the help page. g. Return to the previous web page.
  • the user may move the mouse cursor to a hyperlink for a component of web application 422 that manages Quality Code Data Capture Tools, and click upon it.
  • the web server 404 opens the appropriate web page for the user.
  • the web server 404 may select from the system management database 432 the proper patients, measures and registries to generate the web page as seen by the user.
  • the web server 404 queries the MPR database 121 on the database server 406 with the information received from the system management server 432.
  • the database server 406 (or the offsite datacenter) may transmit the query results to the web server 404.
  • the web server 404 may send to the user's browser 408 a dynamically built web page containing the practices, providers, measures, registries and patients specifically assigned to that user.
  • This transmission may be encrypted by the web server 404 and decrypted by the user's browser 408 on the client device 402.
  • the user may perform several actions within the web application 422 at this point. For example, the user may: a. Click on a hyperlink that begins the data capture tool generation process by broad categories of patients. b. Click on a hyperlink that begins the data capture tool generation process by individual patients. c. Open the help page. d. Return to the previous web page. e. Logout. f. Exit the application. The user may terminate the browser session by closing the application window.
  • the user may perform additional actions as well.
  • the user may move the mouse cursor to a hyperlink for a component of web application 422 that manages Analytical Tools, and click upon it.
  • the web server 404 opens the appropriate view for the user.
  • the web server 404 may select from the system management database 432 the query code that queries the proper cube 140 to generate the opening view as seen by the user.
  • the web server 404 queries the cube 140 on the database server 406 with the query code.
  • the database server 406 (or the offsite datacenter) may transmit the query results to the web server 404.
  • the web server 404 may send to the user's browser 408 a dynamically built web page containing the dropdown menus and initial/opening view specifically assigned to that user as well as a list of fields illustrating the contents of the cube being used by that view. This transmission may be encrypted by the web server 404 and decrypted by the user's browser 408 on the client device 402.
  • the user may perform several actions within the web application 422 at this point. For example, the user may: a. Select and open another pre-written view from the user menu. The user may move the mouse cursor to the menu categories and a predefined list of views may descend. The user may then click on the view title and the method 400 may be repeated except that the web page displayed on the user's client device may be based on the query associated with the view selected. b. Regenerate the current pre-written view. The user may move the mouse cursor to the "Restore" button and click on the Restore button to have the currently selected view regenerate to a default configuration. c. Display the query code that was used by the system to generate the view.
  • the user may move the mouse cursor to the "MDX” button and click on the MDX button to have the query code for the current view configuration appear in a separate application window.
  • d. Send the contents of the view to ExcelView.
  • the user may move the mouse cursor to the "Excel” button and click on the Excel button to have the contents of the current view configuration export into a web-based version of Microsoft Excel, where all the functions of that product may be utilized.
  • the user may move the mouse cursor to the "Fields” button and click on the Fields button to hide or unhide the Field List.
  • f. Modify the current view using Measures and Dimensions from the Field List.
  • the user may click on a folder in the Field List and add new Dimensions (fields) or Measures to the view in a "drag and drop" manner.
  • the web application 422 may dynamically create a new MDX query that is run against the cube 140.
  • the method 500 may be repeated except that the view that appears is based upon the results of the newly altered MDX query.
  • Save a modified view for later use The user may move the mouse cursor into the menu bar on the "My Views" heading and add the current view to the user menu by clicking "Add View.”
  • This process may add the MDX query code for the current view into the system management database 332 to be incorporated into the user's view menu.
  • h. Exit the application.
  • the user may terminate the browser session by closing the application window.
  • the user may perform additional actions as well.
  • Fig. 6A is a screen shot of a web page for entering user credentials, according to an example. This view may be used to explain how the user may perform the actions listed above with reference to block 506 within the web application 422.
  • the user may enter a user name by typing it in the Login Entry Space 601.
  • the user name is a part of the identification information used by the systems management database 432 in the determination of access.
  • the user may enter a password by typing it in the Password Entry Space 603.
  • the password is a part of the identification information used by the systems management database 432 in the determination of access.
  • the user may submit these credentials to the systems management database 432 by clicking on the Submit Button 605. If successful, the web application 422 will transmit a different web page to the web browser408. If not successful, the web application 422 will display an error message.
  • the user may exit the application by clicking on the Exit button 616 to close the application window.
  • Fig. 6B is a screen shot of a web page for selecting an application component, according to an example. This view may be used to explain how the user may perform the actions listed above with reference to blocks 514, 516, 518 and 524 within the web application 422.
  • the user may move the mouse cursor to a hyperlink 607 for a component of web application 422 that manages Quality Measures and Registries, and click upon it.
  • the user may move the mouse cursor to a hyperlink 609 for a component of web application 422 that manages Quality Code Data Capture Tools, and click upon it.
  • the user may move the mouse cursor to a hyperlink 611 for a component of web application 422 that manages Analytics, and click upon it.
  • the user may exit the application by clicking on the Exit button 616 to close the application window.
  • Fig. 6C is a screen shot of a web page for reviewing the status of all patients assigned to all measures for a physician, according to an example.
  • this web page When this web page is displayed, the user will see all Quality Measures that reflect the national consensus standards for patient care for the user's clinical specialty. Using this web page, the user may identify the status of compliance with accepted standards of quality for each clinical service, as reflected by the data in the database.
  • This view may be used to explain how the user may perform the actions listed above with reference to blocks 520 and 522 within the web application 422.
  • the user may select a practice from a drop-down box 651 to repopulate the web page with data originating from a different practice.
  • the user may select a provider from a dropdown box 652 to repopulate the web page with data originating from a different provider. In this manner, results on quality standards are displayed distinctly each provider in the organization.
  • the user may sort measures by category by clicking on the Category Column Heading 653.
  • the user may sort measures by measure name by clicking on the Measure Column Heading 654.
  • the user may sort measures by patient count by clicking on the Patients Column Heading 656.
  • the user may sort measures by completion percentage by clicking on the Status Column Heading 655. This allows the user to identify patients where the physician has not recorded the quality service or clinical value required to meet the quality standard, without viewing the entire list of patients. Additionally, this sorting allows providers to more easily validate patients' services by review of patient charts.
  • the user may View Measure -wide results and click on a Measure 657 to view the results of individual patients in the Patient Measure Window 658.
  • the user may sort the patients by Response Status by clicking on the Response Button
  • the user may sort the patients by Patient Name by clicking on the Patient Name Button
  • the user may sort the patients by Eligibility Criteria by clicking on the Eligibility Criteria Button 661.
  • the user may sort the patients by Effective Date by clicking on the Effective Date Button 662.
  • the user may sort the patients by Response Code Response by clicking on the Code Button 663.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may logout by clicking on the Logout Button 664.
  • the user may exit the application by clicking on the Exit button 616 to close the application window.
  • Fig. 6D is a screen shot of a web page for reviewing the status of a patient's clinical condition, the quality standards being tracked for a patient, as well as for the input of new information and the correction of erroneous information, according to an example.
  • This web page may be referred to as the Summary Window and is part of the web application 422.
  • the summary window contains clinical observations of patient conditions as revealed by the database, and additional clinical risks faced by the patient as a consequence of analysis of the data.
  • the patient's clinical observations may include an indication of diabetes mellitus, along with additional diagnoses related to complications of diabetes mellitus, revealing that the patient is higher risk.
  • the provider may use this information to review the clinical status of the patient at a glance.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may view the patient's last name under the Last Name Column Heading 669.
  • the user may view the patient's first name under the First Name Column Heading 670.
  • the user may view the patient's date of birth under the DOB Column Heading 671.
  • the user may view the patient's gender under the Gender Column Heading 672.
  • the user may view the patient's date of last visit under the Last Visit Column Heading 673.
  • the user may view the patient's status in the practice under the Status Column
  • Heading 674 The user may click on the value under this heading to select a new value provided by the system management database 432.
  • the user may enter a new value here to indicate that a patient is no longer active within the practice.
  • the entry of this information may influence the physician's quality scoring by maintaining or removing the patient from the measurement database. This step is critical to the validation of claims data that has been coded into the system, but where the physician may have mistakenly assigned incorrect diagnoses or other clinical conditions to the patient.
  • the user may view the patient's preferred language under the Language Column
  • Heading 675 The user may click on the value under this heading to select a new value provided by the system management database 432.
  • the user may enter a new value here to indicate the patient's preferred language for communications.
  • the language indicator may be used to direct communications from the physician to the patient with respect to quality of care and necessary clinical services.
  • the user may view the patient's consent for contact under the Contact Column Heading 676.
  • the user may click on the value under this heading to select a new value provided by the system management database 432.
  • the user may enter a new value here to indicate the whether the patient wishes to be contacted.
  • the user may view the patient's known email address under the Email Column
  • the user may click on the value under this heading to enter a new value.
  • the user may view the registries to which the patient belongs in the Observations Window 681.
  • the user may view summaries of where there missing data elements in the Action Items
  • the user may also view the data collected for Clinical Measures in the Patient Facts Window 683. Here the user views the list of Clinical Measures that are pertinent to the patient listed at the top of the screen.
  • the user may sort the Clinical Measures by name by clicking on the Clinical Measure Column Heading 684.
  • the user may sort the Clinical Measures by value by clicking on the Clinical Value Column Heading 685.
  • the user may sort the Clinical Measures by the date reported by clicking on the Date Reported Column Heading 686.
  • the user may sort the Clinical Measures by data source by clicking on the Source Column Heading 687.
  • the Clinical Measures may be used to identify serious issues in the provider's patient population and for the individual patient. These Clinical Measures and Values are later calculated as part of the physician's quality scorecard process.
  • the user may double click on a Record 667 in the Patient Facts Window 683 to launch a pop-up window 693 like those depicted in Fig. 6F and Fig. 6G.
  • the user may switch to view the Quality Reporting Window by clicking on the Quality Reporting Tab 679.
  • the Quality Reporting Window is described in Fig. 6E.
  • the user may switch to view the History Window by clicking on the History Tab 680.
  • the History Window is described in Fig. 6H.
  • the History Window contains relevant sequential clinical information about the patient that may assist the provider in comparing values of previous and current patient conditions.
  • Fig. 6E is a screen shot of a web page for reviewing the status of measures for a patient, as well as for the input of new information and the correction of erroneous information, according to an example.
  • This web page may be referred to as the Quality Reporting Window, and is part of the web application 422.
  • the Quality Reporting Window is used to record specific actions taken by the provider to deliver quality services to the patient, or to report the clinical status of a patient with respect to a particular quality standard.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may view the patient's last name under the Last Name Column Heading 669.
  • the user may view the patient's first name under the First Name Column Heading 670.
  • the user may view the patient's date of birth under the DOB Column Heading 671.
  • the user may view the patient's gender under the Gender Column Heading 672.
  • the user may view the patient's date of last visit under the Last Visit Column Heading 673.
  • the user may view the patient's status in the practice under the Status Column Heading 674.
  • the user may click on the value under this heading to select a new value provided by the system management database 432.
  • the user may enter a new value here to indicate that a patient is no longer active within the practice.
  • the user may view the patient's preferred language under the Language Column
  • Heading 675 The user may click on the value under this heading to select a new value provided by the system management database 432. The user may enter a new value here to indicate the patient's preferred language for communications.
  • the user may view the patient's consent for contact under the Contact Column
  • the user may click on the value under this heading to select a new value provided by the system management database 432.
  • the user may enter a new value here to indicate whether the patient wishes to be contacted.
  • the user may view the patient's known email address under the Email Column Heading 677.
  • the user may click on the value under this heading to enter a new value.
  • the user may double click on a Record 667 in the Quality Reporting Services
  • the user may sort measures by service provider by clicking on the Service Provider
  • Quality Measure Column Heading 654. The user may sort measures by measure status by clicking on the Patient Eligibility
  • Heading 690 and select a new status for that patient-measure combination the user may retain the default status of "Active," or change the status to one of a list of possibilities that explain why the patient-measure combination is invalid.
  • the user may sort measures by eligibility criteria by clicking on the Eligibility
  • Criteria Column Heading 691 The user may sort measures by clinical value by clicking on the Clinical Value Column Heading 685. The user may sort measures by quality code by clicking on the Quality Code Column Heading 692. The user may sort measures by date reported by clicking on the Date Reported Column Heading 686. The user may switch to the Summary Window by clicking on the Summary Tab 678.
  • the Summary Window is described in Fig. 6D.
  • the user may switch to view the History
  • Fig. 6F is a screen shot of a web page Pop-up Window 693 for entering quality codes in response to a measure which a patient has been included; according to an example and may be used to submit Quality Codes and Clinical Values in response to the assignments of patients to Measures. The user may select a single combination of a Clinical Value and a Quality Code by clicking on the Radio Button 695 that occupies the same line.
  • the coding options given to the user are limited by the MPR database 121 to the codes that are directly applicable to the Measure selected either when a Record 667 under the Clinical Value Column Heading 685 in the Quality Reporting Services Window 688 or when a Record 667 in the Patient Facts Window 683 is double-clicked.
  • the user may select a date to associate with the selected Quality Code or Clinical Value by clicking on Date Button 694 and clicking on the appropriate date.
  • the user may commit the Quality Code and Clinical Values selections made with Radio Button 695 and Date Button 694 by clicking on the Submit Button 696. Clicking the Submit Button 696 instructs the web application 422 to append the corresponding patient- provider-measure record in the MPR database 121 with the information selected.
  • the user may close the Pop-up Window 693 without committing any changes to the MPR database 121 by clicking the Cancel Button 697.
  • Fig. 6G is a screen shot of a web page Pop-up Window 693 for entering quality codes that pertain to specific clinical metrics in response to a measure which a patient has been included; according to an example; and may be used to submit Quality Codes in response to the assignments of patients to Quality Measures.
  • the user may select a single combination of a Clinical Value and a Quality Code by clicking on the Radio Button 695 that occupies the same line.
  • the coding options given to the user are limited by the MPR database 121 to the codes that are directly applicable to the
  • the user may select a date to associate with the selected Quality Code or Clinical Value by clicking on Date Button 694 and clicking on the appropriate date.
  • the user may commit the Quality Code and Clinical Values selections made with Radio Button 695 and Date Button 694 by clicking on the Submit Button 696. Clicking the Submit Button 696 instructs the web application 422 to append the corresponding patient- provider-measure record in the MPR database 121 with the information selected.
  • Fig. 6H is a screen shot of a web page for reviewing the data history for a patient as well as for the input of new information and the correction of erroneous information, according to an example. This web page may be referred to as the History Window, and is part of the web application 422.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may view the patient's last name under the Last Name Column Heading 669.
  • the user may view the patient's first name under the First Name Column Heading 670.
  • the user may view the patient's date of birth under the DOB Column Heading 671.
  • the user may view the patient's gender under the Gender Column Heading 672.
  • the user may view the patient's date of last visit under the Last Visit Column Heading 673.
  • the user may view the patient's status in the practice under the Status Column Heading 674.
  • the user may click on the value under this heading to select a new value provided by the system management database 432.
  • the user may enter a new value here to indicate that a patient is no longer active within the practice.
  • the user may view the patient's preferred language under the Language Column
  • Heading 675 The user may click on the value under this heading to select a new value provided by the system management database 432. The user may enter a new value here to indicate the patient's preferred language for communications.
  • the user may view the patient's consent for contact under the Contact Column Heading 676.
  • the user may click on the value under this heading to select a new value provided by the system management database 432.
  • the user may enter a new value here to indicate the whether the patient wishes to be contacted.
  • the user may view the patient's known email address under the Email Column Heading 677.
  • the user may click on the value under this heading to enter a new value.
  • the user may switch to view the Summary Window by clicking on the Summary Tab
  • the History Window is described in Fig. 6D.
  • the user may switch to view the Quality Reporting Window by clicking on the Quality Reporting Tab 679.
  • the Quality Reporting Window is described in Fig. 6E.
  • the user may view all the records from the datamarts 138 that were imported into the MPR database 121 in the Patient Services History Window 698 as they pertain to the patient named at the top of the web page.
  • the Patient Services History Window 698 may display to the user, among other information, Dates of Service, Patient Age, Diagnosis Codes, Procedure Codes, Procedure Modifier Codes, and Provider Names which can each be used by the user to sort the display order of the information.
  • the user may view all the records as they pertain to the patient named at the top of the web page submitted into the MPR database 121 via Pop-Up Window 693 after having double-clicking on a Record 667 in the Patient Facts Window 683.
  • the Patient Facts History Window 699 may display to the user, among other information, Dates of Service, Patient Age, Diagnosis Codes, Procedure Codes, Procedure Modifier Codes, and Provider Names which can each be used by the user to sort the display order of the information.
  • Fig. 61 is a screen shot of a web page for selecting one of two possible ways to generate data capture tools for quality management, according to an example. This web page may be within the web application 422.
  • the user may click on the hyperlink Batch Prompts 613. Doing so will load the web page described in Fig. 6 J.
  • the user may click on the hyperlink Pick Patients 615. Doing so will load the web page described in Fig. 6L.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may logout by clicking on the Logout Button 664.
  • Fig. 6 J is a screen shot of a web page for selecting groups of patients based on last visit date for the bulk creation of data capture tools for quality management, according to an example.
  • This web page may be within the web application 422.
  • the user may select the timeframe for patient last visits by clicking the Radio Button 617 next to the desired selection.
  • the user may submit to the web application 422 the timeframe selected by Radio Button 617 by clicking on the Continue Button 619. Doing so will load the web page described in Fig. 6K.
  • Fig. 6K is a screen shot of a web page for selecting groups of patients based on registry membership for the bulk creation of data capture tools for quality management, according to an example. This web page may be within the web application 422.
  • the user may select the registry the patients belong to by clicking the Radio Button 621 next to the desired selection.
  • the user may submit to the web application 422 the registry selected by Radio Button 621 and initiate data capture tool generation by clicking on the Generate Button 623. Doing so will assemble a document (a sample of which is depicted in Fig. Q) composed of graphics (a sample of which is depicted in Fig. P) and content specifically personalized to the individual patient, designed to aid the user in the submission of Quality Codes after a patient visit.
  • Fig. 6L is a screen shot of a web page for selecting groups of patients based on provider and last visit date for the bulk creation of data capture tools for quality management, according to an example according to an example. This web page may be within the web application 422.
  • the user may select the provider and the timeframe for patient last visits by clicking the Dropdown Box 617 then clicking the desired selection.
  • the user may submit to the web application 422 the timeframe selected by Dropdown Box 617 by clicking on the Continue Button 619. Doing so will load the web page described in Fig. 6M.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may logout by clicking on the Logout Button 664.
  • Fig. 6M is a screen shot of a web page for selecting groups of patients based on registry membership for the bulk creation of data capture tools for quality management, according to an example.
  • This web page may be within the web application 422. The user may select the registry the patients belong to by clicking the Radio Button
  • the user may submit to the web application 422 the registry selected by Radio Button 621 by clicking on the Continue Button 619. Doing so will load the web page described in Fig. 6N.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may logout by clicking on the Logout Button 664.
  • Fig. 6N is a screen shot of a web page for selecting groups of patients based on patient name for the creation of data capture tools for quality management, according to an example.
  • This web page may be within the web application 422.
  • the user may select the patients for whom the data capture tools are needed by clicking the Check Boxes 625 next to each appropriate patient.
  • the user may submit to the web application 422 the patients selected by Check Boxes 625 and initiate data capture tool generation by clicking on the Generate Button 623. Doing so will assemble a document (a sample of which is depicted in Fig. Q) composed of graphics (a sample of which is depicted in Fig. P) and content specifically personalized to the individual patient, designed to aid the user in the submission of Quality Codes after a patient visit.
  • the user may open the help page by clicking on the Help Button 666.
  • the user may return to the previous web page by clicking on the Iris List Button 665.
  • the user may logout by clicking on the Logout Button 664.
  • Fig. 6P is a sample of a component used in the dynamic construction of data capture tools for quality management according to an example.
  • Fig. 6Q is a sample of a fully constructed data capture tool, personalized for an individual patient's specific measure assignments, according to an example.
  • Fig. 6R is a screen shot of a sample view, according to an example. This view may be used to explain how the user may perform the actions listed above with reference to block 512 within the web application 422.
  • the user may select and open another pre-written view by selecting an analysis module 626 on the menu bar 602. For example, the user may select the physician module. A drop down menu of initial views 628 for that analysis module 626 may appear. The user may then select an initial view 628 as a starting point of an analysis.
  • the user may regenerate the current pre-written view by clicking the restore button 604. This feature may be useful if the user wishes to begin a new analysis or provide a known starting point.
  • the user may display the query code by clicking on the MDX button 606.
  • the user may review the query code to determine what query the system 300 is performing.
  • the user may send the contents of the view to Excel by clicking the Excel button 608. Once the data is exported to Excel, the user may use the features within Excel to perform data manipulations, such as creating graphs and charts.
  • the user may hide or expose a field list 634 by clicking the Fields button 610.
  • the fields list 634 may include measures 630 and dimensions 632, which may be selected by the user to modify the view. By hiding the field list 634, the application 422 may have more workable space.
  • the user may modify the current view by clicking on a folder in the field list 634 and dragging a new measure 630 or dimension 632 into a Columns Area 618, a Rows Area 620, or a Filter Area 622.
  • the measures 630 may be quantities generated from the data.
  • the measures 630 include counts (e.g., patients, visits, days) and currency (e.g., payments, charges, adjustments).
  • the measures 630 may be calculated and presented in accordance with the analytic definitions.
  • the dimensions 632 may be categories of data in which the measures 630 may be viewed.
  • the dimensions 632 may allow the user to group measures 630 in logical ways, which may provide the user with analytical information.
  • the dimensions 632 may be hierarchically designed to allow very fine granularity to distinguish data.
  • the dimensions 632 may be built to meet the requirements of the analytical definitions.
  • the user may save a modified view by selecting My View 614, and clicking on Add View from a drop down menu.
  • the user may exit the application by clicking on the Exit button 616 to close the application window Clinical Quality Management Example
  • Figs. 6A-6R visually represent the manner in which providers may review quality of care provided to patients as compared with national standards. It is difficult for physicians to identify problems of quality across the practice as a whole. For example, a physician may not realize that as many as 30% of his or her practice is diabetic, and that a significant portion of these have further diabetic complications. Because the nature of a physician practice is focused on problems that emerge on a patient-by-patient basis as they present with clinical issues, it is difficult to see quality trends across the practice. Also, the time constraints of a single visit make it likely that many services required by quality standards are missed. Web application 422 allows the provider to retrospectively review quality that has been delivered to patients in the aggregate, and allows corrective measures for individual patients.
  • the provider has selected a registry for Coronary Artery Disease, where patients should have been prescribed a particular beta-blocker medication following myocardial infarction. Failure to prescribe this medication has been linked to poor patient outcomes. Review of the patients in the registry indicate that many patients have not been reported as receiving prescriptions for this medication. If the values assigned to the patient represent unreported — as distinct from undelivered — care, Web Application 422 allows the provider to correct the patient record to indicate that the medication was prescribed. If the review of patients indicate that the patients did not receive the appropriate prescriptions, the results of this analysis will be part of the physician's quality scorecard.
  • Web Application 422 creates the basis for both review and scoring of physician quality. The results of individual patients are displayed for validation, updates, and corrections. This allows a measure of control for providers in their own quality scorecard.
  • Web Application 422 is important for review of clinical issues that must be addressed across an entire practice rather than individually. For example, knowledge that a high level of diabetic patients with unmanaged blood pressure exists in a practice serves to inform the physician that additional services should be organized for these patients as a group. The physician may wish to use the survey in Figure 34 to query patients on the reasons for poor blood pressure management, or the physician may wish to review other clinical inputs, such as prescribed medications, to resolve the issue for patients. Without Web Application 422, physicians do not have access to clinical information that is reflected in the whole of their practice.
  • Figs. 7-13 are screen shots of sample views of results using the system 400 depicted in Fig. 4. Lacking information on performance trends and not knowing where to find the information is one of many problems faced by practices today. For example, a practice may have difficulty determining the source, or even the existence, of declining practice revenues. As described below with reference to Figs. 7-13, the system 400 may provide a practice with the ability to track the source of revenue changes. It is understood that the data displayed in the screen shots is not actual data, but a representation of the type of data that may be used to analyze the problems encountered by practices.
  • Fig. 7 is a screen shot of practice revenues, according to an example.
  • This view may be created by dragging the Revenues Measure into the Columns Area, and the Month level of the Date Fiscal dimension into the Rows Area.
  • the result may be a view that answers the initial question of whether the revenues are in decline or not.
  • the numbers shown in Fig. 7 do indicate that the monthly revenues for this practice are down over 10% for the twelve month period shown.
  • a practice may now have the information that the practice has experienced a revenue decline. The practice may then want to know why there has been a revenue decline and what the practice do to change the trend, if anything.
  • the system 400 may be used to evaluate different factors to determine the cause of the revenue decline. For example, the system 400 may be used to determine if the revenue decline is a result of the practice treating fewer patients.
  • Fig. 8 is a screen shot of patient visits, according to an example. This view may be created by dragging the Revenues Measure out of the Columns Area and dragging the Patient Visits measure into the Columns Area. The resulting view depicted in Fig. 8 shows that the number of visits has been stable for the time period in question. Since the number of patient visits is stable, that factor may be ruled out as a contributor to the declining revenue. It may be helpful to determine if the practice is charging less overall for its services.
  • Fig. 9 is a screen shot of charges and revenues, according to an example. This view may be created by dragging the Patient Visits measure out of the Columns Area and dragging the Charges and Revenues measures into the Columns Area. The resulting view depicted in Fig.
  • Fig. 10 is a screen shot of charges by financial class, according to an example. This view may be created by dragging the Revenues measure out of the Column Area and dragging the Financial Class dimension into the Columns Area. The resulting view depicted in Fig. 10 shows charges for services across the various financial classes for the time period. Financial classes are convenient way to group similar types of insurance plans together. By expanding out the financial class members, the practice can see that the charges for the payers in the Insurance PPO category (circle added) have increased by 50% while charges for other categories have either remained stagnant or dropped sharply. This trend may indicate that payers in the Insurance PPO financial class have become a much more significant component of overall charges, starting at 37% of charges and growing to 55% of charges by the end of the period.
  • Fig. 11 is a screen shot of revenues by financial class, according to an example. This view may be created by dragging the Charges measure out of the Columns Area and dragging Revenues measure into the Columns Area. The resulting view depicted in Fig. 11 shows revenues across the various financial classes for the time period, and may be created to reveal any correlation with the charge trend. The charges had risen significantly for the payers in the Insurance PPO financial class, but the revenues are fairly stagnant and have increased by only 8%. Other financial classes show steep drops in revenues that match with the charges trend observed earlier.
  • the practice may question whether the revenue decline may be caused by factors related to payers in the Insurance PPO financial class.
  • the revenue decline may be caused by factors related to payers in the Insurance PPO financial class.
  • a problem may exist in processes at the billing service, affecting collections.
  • a problem may exist with the payers themselves.
  • the next step to identifying the source of the revenue decline may be to investigate the rate of collection, which may be a billing service responsibility.
  • Fig. 12 is a screen shot of collection rates, according to an example. This view may be created by rolling up the Date Fiscal dimension, dragging the Financial Class Name level of the Financial Class dimension into the rows area, and dragging the Charges and Collection Rate measures into the Columns Area. The time in the Date Fiscal dimension may be rolled up in order to cover the given time period as an aggregate. As a result, Fig. 12 depicts the collection rates received by payers by Financial Class.
  • Fig. 13 is a screen shot of collection rates by payer, according to an example. This view may be created by dragging the Financial Class Name level of the Financial Class dimension into the Filter Area and selecting Insurance PPO and by dragging the Payer Name level of the Payer dimension into the Rows Area. The resulting view depicted in Fig. 13 shows charges, payments, and collection rates for each Payer in the Insurance PPO category over the time period. Looking at the collection rates for each Payer, the practice may determine that the Payer called "Private Plans" is driving the revenue decline (circle added).
  • the practice may understand that if the Insurance PPO gains a greater share of the business, overall revenues of the practice may continue to decline. Knowing this information may allow the practice to address the problem effectively. For example, the practice may wish to renegotiate its contracts with the problem payer or entice more patients from more profitable sources.
  • a practice can use the system 400 to evaluate their business operations and improve business performance. While the example above depicts how a practice may use the analytical data from the cubes 140 to evaluate revenue declines, the practice may use the analytical data in a variety of other ways.
  • Fig. 14 is a screen shot of financial data, according to an example.
  • the system 400 may be used to help manage the business aspects of a physician practice in addition to patient care.
  • the view depicted in Fig. 14 shows the following analytical data for the calendar year 2001 :
  • Fig. 15 is a screen shot of data shown in Fig. 14 including percent charges of RBRVS, according to an example. This view may be created by dragging the % Charges of RBRVS into the Columns Area of the view. The resulting view depicted in Fig. 15 shows the following analytical data for the calendar year 2001 :
  • Fig. 16 is a screen shot of data shown in Fig. 15 by payer, according to an example. This view was created by clicking on All Payer dimension already in the view. Since All Payer was at the top of a hierarchy of members, clicking on it expands the list to show all members at the next level. The members below All Payer include the list of all payers that have had charges claimed against them for 2001, and for those individual payers the view shows:
  • Fig. 17 is a screen shot of data shown in Fig. 16 by a selected financial class, according to an example. This view may be created by dragging the Financial Class Name level of the Financial Class dimension into the Filter Area, and selecting to filter by Blue Cross. The resulting view depicted in Fig. 17 shows the list of all payers in the Blue Cross financial class that have charges claimed against them for 2001, and for those individual payers the view shows:
  • Fig. 18 is a screen shot of data shown in Fig. 17 including charges with adjudicated payments, denied charges, and payment lag, according to an example.
  • This view was created by dragging the Charges with Adjudicated Payments, Denied Charges, and Service to Payment Lag into the Columns Area.
  • the resulting view depicted in Fig. 18 shows the list of all payers in the Blue Cross financial class that have had charges claimed against them for 2001, and for those individual payers the view shows:
  • Fig. 19 is a screen shot of financial data, according to another example.
  • This initial view shows for year 2002 the Charges, number of procedures billed for, and the % of total charges for each financial class.
  • This view may be used to evaluate the relative amounts of business a practice has with the various types of payers. This type of information is typically not readily available to practice managers.
  • Fig. 20 is a screen shot of financial data, according to another example.
  • This is an initial view that shows the user how many days elapsed for charges to be entered into the billing system as reflected by different places of service.
  • This view may allow a practice administrator to identify potential bottlenecks in the billing process as reflected by the differing operational procedures in the different places of service.
  • Figs. 21-30 are screen shots of sample views of results using the system 400 depicted in Fig. 4. While the previous example demonstrated how a practice could use the system 400 to understand the financial nature of the practice's business, Figs. 21-30 demonstrate how a practice can use the system 400 to understand the clinical nature of the practice's business.
  • Fig. 21 is a screen shot of a number of diabetic patients and a number of visits these patients made to a practice in a given time, according to an example. While the example provides analytic data regarding diabetic patients, it is understood that the system 400 may analyze patient data for a variety of medical diagnosis. This view may be created by dragging the Patient Visit Count measure into the Columns Area. The resulting view depicted in Fig.
  • Figs. 22-30 show a progression of analyses as performed by the system 400.
  • Fig. 22 is a screen shot of data shown in Fig. 21 separated by age category, according to an example. This view may be created by dragging the Age Group level of the Age dimension into the Rows Area to show the distribution of the Diabetic patients by age group.
  • the age groups in the Age dimension may be fully customizable.
  • Fig. 23 is a screen shot of data shown in Fig. 22 separated by financial class, according to an example. This view may be created by dragging the Patient Visit Count measure out of the Columns Area, dragging the Financial Class Name level of the Financial Class dimension into the Columns Area, and moving the Age dimension to the Columns Area. The resulting view depicted in Fig. 23, may provide the practice information regarding how the diabetic patients are distributed among age groups as well as what type of insurance coverage they had during 2001.
  • Fig. 24 is a screen shot of a number of diabetic patients that also suffer from hypertension, according to an example.
  • This view may be created by dragging both the Financial Class and Age dimensions from the Columns Area and dragging the Provider dimension and the Study Hypertension dimension into the Filter Area of the view.
  • the Filter Area may allow users to select one or more members from a dimension to filter the query results accordingly.
  • the user has filtered the data to show the count of diabetic patients of a doctor (i.e., William Sykes) who also suffer from hypertension for 2001.
  • Fig. 25 is a screen shot listing diabetic patients that also suffer from hypertension and associated number of visits, according to an example.
  • This view may be created by dragging the Patient Name level of the Patient dimension into the Rows Area of the view, dragging the Visits Count measure into the Columns Area of the view, and dragging the Patient Count measure out of the Columns Area.
  • the resulting view depicted in Fig. 25 may allow the practice to receive data regarding individual patients.
  • This view shows the diabetic patients by name and how many visits each patient had during 2001. The names of diabetic- hypertensive patients who had no visits in 2001 are not be listed in the view depicted in Fig. 25 as the system 400 may discard results with empty data.
  • Fig. 26 is a screen shot listing place of service, according to an example. This view may be created by dragging the Place of Service Group level of the Place of Service dimension into the Columns Area of the view. The Place of Service dimension is created based on the CPT codes indicative of particular possible places of service used for the visit. The resulting view depicted in Fig. 26 shows the diabetic-hypertensive patients by name and how many visits they each had, and the type of facility in which the visit occurred in during 2001. Analyzing the place of service may be important in gauging workflow or operational issues of the practice.
  • Fig. 27 is a screen shot of data shown in Fig. 26 for patients that visited a practice in the last two quarters, according to an example. This view may be created by dragging the Quarter level of the Date of Last Visit dimension into the Filter Area, filtering for the time frame the two previous quarters to present in the view. The resulting view depicted in Fig. 27 shows the diabetic-hypertensive patients by name, how many visits they each had, and the type of facility in which the visit occurred, all for the previous two quarters. Patients with chronic conditions require specific regimens of care and knowing when a patient was last seen can allow physicians to better manage those patient populations.
  • Fig. 28 is a screen shot of data shown in Fig. 27 including date of visit, according to an example.
  • This view may be created by dragging the Date level of the Date of Service dimension into the Rows Area right of Patient.
  • the resulting view depicted in Fig. 28 shows the diabetic-hypertensive patients whose last visit was in the third quarter of 2001, by name, how many visits to the practice they each had, when they visited, and the type of facility in which the visit occurred.
  • Fig. 29 is a screen shot of data shown in Fig. 28 including primary diagnosis, according to an example. This view may be created by dragging the Diagnosis Name level of the Primary Diagnosis dimension into the Rows Area right of Date of Service. The resulting view depicted in Fig. 29 shows the diabetic-hypertensive patients whose last visit was in the third quarter of 2001, by name, how many visits they each had, what the primary diagnosis was, when they visited, and the type of facility in which the visit occurred.
  • Fig. 30 is a screen shot of data shown in Fig. 29, including charge to patient, according to an example. This view may be created by dragging the Charges measure into the Measures Area of the view. The resulting view depicted in Fig. 30 shows the diabetic- hypertensive patients whose last visit was in the third quarter of 2001 , by name, how many visits they each had, what the primary diagnosis was, when they visited, what the amount charged was, and the type of facility in which the visit occurred. As shown with reference to Figs. 21-30, a practice can use the system 400 to evaluate their clinical business operations and improve business performance. While the example above depicts how a practice may use the analytical data from the cubes 140 to evaluate diabetic patients, the practice may use the analytical data in a variety of other ways.
  • the system 100 may be used to calculate a score that provides an indication of physician performance.
  • the physician score is generally determined by analyzing data from multiple data sources. For example, data may be obtained from claims submitted by the physician's practice, either through a direct extraction from a practice management system or by collection from a third party, such as a hospital or a claims clearinghouse. The data may be used to identify an appropriate population of patients for measuring physician quality.
  • the patient population may be determined by analyzing the data to establish an initial registry of patients belonging to the conditions or patient populations being tracked (e.g., patients with diabetes, patients over the age of 65).
  • the patient registry may identify patients who have been diagnosed with the particular condition and track the number of patient visits to the physician practice, regardless of the reason for the visit. Filters may be applied to the patient registry to remove patients who should not be included in measuring the performance of the physician for a variety of reasons. For example, the patient may be deceased, dismissed from the practice, moved away, not have the condition managed by the physician, and so on.
  • FIG. 32 An example screen shot of a portion of a patient registry is depicted in Fig. 32.
  • This example depicts a portion of Dr. Angela Smith's patient registry who is a doctor in the Blooming Hills Internal Medicine practice.
  • two patients are active (i.e., Kirk and Klaus), while the other two patients (i.e., Lindberg and Lunch) are not active.
  • the data for inactive patients may be filtered out during the calculation of a physician score for Dr. Smith.
  • the active patients may be filtered based on particular condition. For example, if Dr. Smith's physician score is to be based on her treatment of diabetes and/or osteoporosis, data from both of the active patients may be used. However, if Dr.
  • a physician practice may review the patient registry using the system 400 or a secure web portal so that conditions, patient status, and management of the patient by the physician may be validated by the practice. Additionally or alternatively, a physician practice may use physician prompts to validate the patient registry.
  • a physician prompt may be a document or on-line form used to collect data for condition-specific clinical processes, patient outcomes, or other characteristics, which may not available from the practice management system. For example, physician prompts may be used to collect:
  • Stratification measures such as whether a patient is a current smoker, whether an asthmatic has mild intermittent asthma, or if a heart failure patient has an ejection fraction less than 40%.
  • the physician prompts may be placed in a patient's chart.
  • an electronic physician prompt similar to the paper-based one, may be included in the data capture process.
  • the physician prompts serve to capture clinical data in a retrievable format.
  • An example physician prompt for diabetes treatment is depicted in Fig. 33.
  • the physician prompts may be used to obtain "Control Measures" and "Clinical
  • the Control Measures may indicate the status of the patient's condition, and how well a condition is being controlled (e.g., in the case of diabetes whether the HgbAlC falls into one of three categories ⁇ 7%, 7-9%, or >9%).
  • the Control Measures may include measurements of blood sugar levels (HBAlC), blood pressure, and lipid levels.
  • HBAlC blood sugar levels
  • the Control Measures may include a measure of the successful outcome of the surgery and lack of complications.
  • the Clinical Process Measures may be used to determine whether the physician followed appropriate clinical procedure in the management of the specific condition, for example, by examining the receipt of any code for a quality measurement in the previous 12 months.
  • the physician's score may be increased.
  • Clinical Process Measures and Control Measures may be established for any condition and/or patient population being assessed for physician quality.
  • the physician score may be calculated using a subset of all services provided to the full patient population of a given physician.
  • the physician score may be determined by examining critical points of care to patients who represent a critical or measurable component of the physician's patient base.
  • the calculation of the Control Measures and the Clinical Process Measures may provide a partial foundation in which to evaluate a physician's quality.
  • a patient's status may be influenced by the care of the physician, but only if the patient adheres to prescribed treatment and lifestyle changes identified by the physician.
  • a Visit Adherence Index VAI
  • the Visit Adherence Index may be used to create a multiplier to be applied to the Clinical Process Measures and/or the Control Measures.
  • the Visit Adherence Index may be used to gauge the patient's likelihood of returning to the physician's office for management of a disease conditions (i.e., planned visits) needed for management of the disease condition by the physician.
  • the Visit Adherence Index may provide a comparison between practices regarding how likely the physician is able to manage the disease condition for the registry patients. To calculate the Visit Adherence Index, gaps between visits in the preceding twelve months and/or twenty-four months may be identified.
  • diabetic patients in the patient registry may be expected to visit their physician every three months (90 days), except for patients with very good control of the disease (e.g., a hemoglobin AlC less than 7, a systolic blood pressure less than 130 mmHg, a diastolic blood pressure less than 90 mmHg, and an LDL less than 100 mg/dl), and without other risk factors or complications of diabetes.
  • Variances of greater than 90 days may be identified and the days above 90 tabulated. Visits that are for minor acute problems and/or for which the condition (e.g., diabetes) is not listed in one of the diagnosis categories, may be excluded from the analysis, as well as inpatient visits.
  • Visit Adherence Index may be adjusted higher (e.g., doubled) for diabetic patients who have visited the office once and have not returned to the office within 90 days of the initial visit. Other adjustments may also be made to the Visit Adherence Index based on the likelihood of the patient adhering to the prescribed visit schedule.
  • adjustments may be made to the Clinical Process Measures and/or the Control Measures that reflect patient-controlled behaviors and refusal to participate in certain required tests. For example, adjustments may be made based on lifestyle choices, such as smoking status. Patients who choose to continue smoking have higher risk and poorer outcomes, in general. As another example, adjustments may be made based on income status. Patients in lower income levels have higher levels of chronic disease and poorer management levels of those conditions.
  • Patient assessment data may also be collected prior to determining the physician score.
  • a patient prompt may be used to collect patient- specific data that may be used to assess the effectiveness of the physician management. The patient prompt is meant to enhance patient-centered care and be closely linked with other data elements to assist in physician (or other health care provider) performance improvement and patients becoming more informed consumers.
  • An example patient prompt is depicted in Fig. 34.
  • the patient prompt may be designed by an analysis of the patient's specific conditions or procedures.
  • a patient prompt for a surgical case may request that the patient respond to whether the actual outcome of the surgery matched the patient's expectations (for example, as conveyed to the patient by the physician), whether the patient experienced any complications, and whether the patient had appropriate pre- surgical education.
  • a patient prompt for a patient with chronic disease may request the patient to respond to whether the patient believes that the physician's treatment will be effective, whether he or she is able to follow the required regimen, and whether the physician has adequately mentored the patient about the condition and the treatment.
  • the patient prompts may be designed to assure specific questions or issues have been addressed during the office visit as seen in Fig. 34.
  • This type of patient prompt which is referred to herein as a Type I patient prompt, queries patients about issues specific to the status of their care and may assist the physician in determining if certain factors may be creating a barrier to optimal outcomes.
  • the design of the Type I patient prompts may vary based on different clinical conditions and the appropriate Type I patient prompt may be provided to patients identified as having a particular clinical condition in the patient registry. For example, a diabetic patient with poor control of his/her blood pressure may be requested to answer questions about medication adherence.
  • the Type I patient prompts may be placed in a patient's chart.
  • an electronic Type I patient prompt similar to the paper-based one, may be included in the data capture process.
  • the Type I patient prompt is provided to the patient to complete and review with the physician.
  • the physician may note on the form that the questions were reviewed and provide the completed prompt to the front desk/office manager to include this occurrence on the patient registry. Alternately, the physician might enter a CPT code indicating form completion (this might be incorporated in the physician prompt process).
  • the Type I patient prompts may provide documentation of specific investigation of high-risk patients. In the case of patients with poor visit adherence or refusal of process measures, the Type I patient prompt may serve to confirm patient understanding and/or identify hidden reasons for poor patient involvement in self-management. Additionally or alternately, the Type I patient prompt may be used to secure patient commitment to action plans and/or goal setting for health management. The Type I patient prompt may also serve to alert patients to upcoming mailing from the physician and query about preferred means of out of office communication (e.g., will the patient accept email message, phone text messages, or must paper mail be used).
  • Additional patient prompts may also be used.
  • anonymous patient prompts may be used to obtain patient assessment of their physician and the care provided by the office.
  • This type of patient prompt which is referred to herein as a Type II patient prompt, is designed to capture patient feedback.
  • the Type II patient prompts may also vary based on different clinical conditions and the appropriate Type II patient prompt may be provided to patients identified as having a particular clinical condition in the patient registry.
  • the Type II patient prompt data may be collected at the office, subsequently entered by the patient securely online, or subsequently mailed to a third party for entry. The results may be scanned, entered into the database, and subsequently analyzed.
  • the content of the Type II patient prompt is very focused toward the physician's performance in the eyes of the patient.
  • the provision of and value of pre- and postoperative instructions may also be assessed.
  • the patient's assessment of complications and outcomes may be compared (e.g., on an aggregate basis) with the physician's assessment to determine discrepancies.
  • the patient prompts may be distinguished from standard patient satisfaction surveys in the following features: • They are produced from registry data and are specific to the care and problems the patient has. Even for Type II patient prompts, where the patient data may be collected anonymously, the specific issues and patient conditions are known and the resulting analysis is therefore specific to those patient populations and issues.
  • the language of the patient prompts (if other than English) may be varied based upon practice entry into the online patient registry.
  • the results of the patient prompts are integrated into the database for the physician and may serve to adjust and contribute to performance measurements for the individual physician.
  • Fig. 34 is an example physician score report.
  • the physician score may be reported both as an aggregate score and individual scores for each measurement set chosen by the physician.
  • the report may be designed in a variety of ways, including depicting only the aggregate score or only the individual scores.
  • the measurement set includes subcomponents, depending upon the measures.
  • the subcomponents may include Physician Clinical Performance, Patient Risk, and Patient Assessment. Table 1 below shows a description of each of these subcomponents.
  • the physician score is calculated by determining a Physician Clinical Performance index and adjusting this value downward and/or upward by the using Patient Risk, Efficiency Adjustment, and Patient Assessment.
  • the subcomponents may be combined to determine the physician score.
  • the physician score may be used by the physician to improve the quality of service at the physician's practice. Additionally, the physician score may be used by others for selecting a physician.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Medical Informatics (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Biomedical Technology (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Strategic Management (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

L'invention concerne un système et un procédé destinés à fournir des rapports et des analyses à des utilisateurs à distance en fonction de données utilisateur. Un tel rapport est un rapport de note de médecin qui comprend une note de médecin. La note de médecin est déterminée par l'analyse de données à partir de multiples sources de données. Un autre tel rapport affiche le statut de tous les patients attribué à toutes les mesures pour le médecin. Un utilisateur peut utiliser le rapport pour entrer des codes de qualité et des valeurs cliniques en réponse à une mesure dans laquelle un patient a été inclus.
PCT/US2008/054451 2007-02-20 2008-02-20 Système et procédé pour fournir aux utilisateurs à distance des rapports et des analyses en fonction de données utilisateur et de rapport adaptable ayant la capacité de modifier ou d'augmenter de tels rapports et analyses par l'intermédiaire d'une technologie web WO2008103749A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US89076607P 2007-02-20 2007-02-20
US60/890,766 2007-02-20

Publications (1)

Publication Number Publication Date
WO2008103749A1 true WO2008103749A1 (fr) 2008-08-28

Family

ID=39710478

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2008/054451 WO2008103749A1 (fr) 2007-02-20 2008-02-20 Système et procédé pour fournir aux utilisateurs à distance des rapports et des analyses en fonction de données utilisateur et de rapport adaptable ayant la capacité de modifier ou d'augmenter de tels rapports et analyses par l'intermédiaire d'une technologie web

Country Status (1)

Country Link
WO (1) WO2008103749A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8311854B1 (en) 2008-07-01 2012-11-13 Unicor Medical, Inc. Medical quality performance measurement reporting facilitator

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10198750A (ja) * 1996-09-30 1998-07-31 Smithkline Beecham Corp 病症管理方法とシステム
JP2001515620A (ja) * 1997-03-07 2001-09-18 インフォメディックス・インコーポレーテッド 患者の健康状態および医学的治療方式を実時間で監視し管理する方法、装置およびオペレーティング・システム
KR20010088639A (ko) * 2001-07-14 2001-09-28 박길준 네트워크를 이용한 원격 진료 시스템 및 그 방법
KR20020005888A (ko) * 2000-07-10 2002-01-18 황인택 원격 건강관리 서비스를 제공하는 방법 및 시스템
KR20030070871A (ko) * 2003-07-19 2003-09-02 서민식 인터넷을 기반으로 한 종합 건강관리 및 정보제공 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10198750A (ja) * 1996-09-30 1998-07-31 Smithkline Beecham Corp 病症管理方法とシステム
JP2001515620A (ja) * 1997-03-07 2001-09-18 インフォメディックス・インコーポレーテッド 患者の健康状態および医学的治療方式を実時間で監視し管理する方法、装置およびオペレーティング・システム
KR20020005888A (ko) * 2000-07-10 2002-01-18 황인택 원격 건강관리 서비스를 제공하는 방법 및 시스템
KR20010088639A (ko) * 2001-07-14 2001-09-28 박길준 네트워크를 이용한 원격 진료 시스템 및 그 방법
KR20030070871A (ko) * 2003-07-19 2003-09-02 서민식 인터넷을 기반으로 한 종합 건강관리 및 정보제공 방법

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8311854B1 (en) 2008-07-01 2012-11-13 Unicor Medical, Inc. Medical quality performance measurement reporting facilitator

Similar Documents

Publication Publication Date Title
US20080215370A1 (en) System and Method for Providing Remote Users with Reports and Analyses Based on User Data and Adaptable Reporting with the Ability to Alter, Modify or Augment Such Reports and Analyses through Web-Based Technology
US20080196108A1 (en) System and method for providing remote users with reports and analyses based on user data and adaptable reporting with the ability to alter, modify or augment such reports and analyses through web-based technology
US7532942B2 (en) Method and apparatus for generating a technologist quality assurance scorecard
US10922774B2 (en) Comprehensive medication advisor
US8438041B2 (en) System and method for tracking and reporting clinical events across a vast patient population
US10453574B2 (en) Systems and methods for mining aggregated clinical documentation using concept associations
US20090234674A1 (en) Method and system for administering anticoagulation therapy
US20200251216A1 (en) Systems and methods for determination of patient true state for personalized medicine
US20110119092A1 (en) Electronic health management system
US20060235280A1 (en) Health care management system and method
US20070198296A1 (en) Patient health management portal
US20080183508A1 (en) Methods for Real-Time Underwriting
US20050137910A1 (en) Systems and methods for automated extraction and processing of billing information in patient records
EP1573624A2 (fr) Systemes et procedes destines a l'extraction et au traitement automatique d'informations de facturation contenues dans des dossiers de patients
Baser et al. Use of open claims vs closed claims in health outcomes research
US20210280316A1 (en) Systems and methods for extraction of clinical knowledge with reimbursement potential
US20190051411A1 (en) Decision making platform
US8538777B1 (en) Systems and methods for providing patient medication history
US20010032102A1 (en) Psychiatric information systems, methods and computer program products that capture psychiatric information as discrete data elements
US20160357909A1 (en) Computerized system and method for presenting payer-based health record data to health care providers
WO2008103749A1 (fr) Système et procédé pour fournir aux utilisateurs à distance des rapports et des analyses en fonction de données utilisateur et de rapport adaptable ayant la capacité de modifier ou d'augmenter de tels rapports et analyses par l'intermédiaire d'une technologie web
US20090132396A1 (en) Revenue cycle charge capture system and method
US20200176091A1 (en) Method of administering a health care code reporting system
EP1497765A4 (fr) Systeme permettant a un utilisateur d'acceder a des informations liees a des soins de sante
MC GLYNN et al. Health information systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08743504

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08743504

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载