Patent Application
20090024414
1. Field
This invention relates generally to the field of computerized medical records management systems, and in particular to methods for facilitating analysis of clinical information in a medical records database.
2. Description of Related Art
In the medical arena, hand written patient record keeping systems have evolved through many years of careful refinement and enhancement into systems which maintain a detailed manual record of medical information concerning each patient. To meet the needs of different hospital entities (such as doctors, nurses, pharmacy, accounting, laboratory, etc.) a manual record keeping system often requires that one piece of information be entered into multiple records. In addition it often requires that the same information that has not changed from visit to visit (such as family/social history, allergies, immunization status) be re-asked of the patient and re-documented in the current record. In certain instances, such as in the Emergency Department (ED), this information may be asked and recorded as many as three separate times (on the Triage Note; the main ED record; and MD documentation) leaving the patient to wonder if there is any communication between healthcare providers and frustrating those healthcare providers who must fill out more and more paperwork. If the patient is admitted, this same information is then asked and recorded again by the admitting nurse and attending physician.
In a typical manual patient record keeping system a patient chart, usually in the form of a notebook, is maintained at the nursing station for each patient. The notebook is divided into a plurality of individual tabbed sections, such as Physicians Orders, Nursing Care Plan, Nursing Assessment, and Laboratory.
Each of the above sections is further subdivided into a number of forms. The forms are those which are appropriate to the individual patient and/or such patient's physician. For example, within the Laboratory section there may appear forms for chemistry, hematology, blood gas, and microbiology.
In addition, a “flowsheet” chart is usually kept at the patient's bedside, particularly in a critical care environment. On the “flowsheet” chart there are individual areas for medication records, vital signs, intake/output, laboratory results, and other categories which are dependent upon the patient's affliction, such as intravenous (IV) drips.
Referring in particular to nursing functions, annotations to charts and/or nursing progress notes are made manually. Typically, brief notations are jotted down in various places through-out a shift. Sometime during the shift, typically at the end, the nurse makes a full notation into the nursing progress notes based on the brief notations or remembered items. This process can be very inefficient since notations may be forgotten or not copied appropriately. In particular, documentation and entry of physician orders, prescriptions and other activity has been viewed as two separate activities or steps, one step completing the documentation and a second step of entry of the order or prescription in the medical records of the patient.
The need for more efficiency of workflow and coordination between multiple departments and healthcare providers in a hospital environment has led to the advent of computerized medical records applications and related systems. Medical records management systems are known in the art and include the systems disclosed in the following U.S. Pat. Nos.: 5,325,478; 5,247,611; 5,077,666; 5,072,383 and 5,253,362 all assigned to the assignee of this invention, and have been commercialized by the Assignee of this invention and others.
The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent to those of skill in the art upon a reading of the specification and a study of the drawings.
In a first aspect, a medical records information apparatus is provided which facilitates analysis of clinical data (e.g., patient or patient care information) stored in a clinical database. The apparatus is in the form of a software application comprising a set of machine readable code stored on a machine readable medium and executable on a computing platform. The application is referred to herein as an analytics module.
The application includes a process extracting clinical data from the clinical database and loading the extracted data into an analytics database. The analytics database is separate from the clinical database. A separate analytics database is used in order such that the use of the analytics database (e.g., by hospital medial personnel or administrators) does not adversely impact the ongoing use and updating of the clinical database. The application further configures the analytics database in accordance with a data model that is optimized for business intelligence reporting tools, such as commercially available software reporting applications providing display of multidimensional data e.g., in the form of multidimensional data cubes. The application further includes procedures (e.g., SQL procedures) for applying clinically-related logical rules to the clinical data and storing flags associated with the logical rules in the analytics database.
In one possible arrangement of the analytics database, the data model by which the analytics database is structured includes a plurality of fact tables storing clinical data and the flags associated with the logical rules. In another possible arrangement, the data model further includes a plurality of dimension tables. A commercially available database software tool such as MICROSOFT SQL SERVER ANALYSIS SERVICES™ operates on the fact and dimension tables to create multidimensional on-line analytics processing (OLAP) cubes, which are a suitable format for commercially available business intelligence reporting tools. The data can also be organized into data marts including at least one of an orders data mart, a quality measures data mart, a clinical decision support datamart, and an inpatient admission data mart.
As noted, the analytics database is ideally separate from the clinical database. In a typical implementation, e.g., in a hospital environment, the clinical database is continually updated with new patient admissions, new tests results for patients, new orders being prescribed, and other events in the episode of patient care for a multitude of patients served by the hospital. The analytics module application further includes an update process by which clinical information in the analytics database is periodically updated from information in the clinical database. This update process could run on a daily basis, a weekly basis, or on some other periodic interval.
The logical rules setting the clinically-related flags can be tailored by the system administrator of the application. The flags can be used to create additional meaning and context to information in the clinical database. For example, the flags may include one or more flags designed to profile a patient for a chronic illness, e.g., based on the occurrence (or non-occurrence) of a set of events in the episode of patient care. As another example, the flags may include one or more flags designed to profile compliance with quality measures for care of a patient, such as quality measures set by an industry or governmental organization.
Another aspect of the invention relates to a method of facilitating analysis of clinically relevant information contained in a clinical database. The method includes the steps of: performing a backup step including creating a backup to the clinical database to thereby provide a source database for a data extraction program; performing an extract step including executing the data extraction program and responsively creating a set of metadata tables and extracted source tables; performing a load step including executing a plurality of procedures to move data from the extracted source tables into a plurality of tables of an analytics database; and wherein the procedures further include procedures applying clinically related logical rules to the data in the extracted source tables and storing flags associated with the logical rules in one or more of the plurality of tables of the analytics database. The method of this aspect of the invention can be coded as a set of software instructions and provided to a health care enterprise as a separate analytics software product for use with a pre-existing medical records information application maintaining the clinical database.
In one embodiment, the plurality of tables includes a plurality of fact tables which store among other things the flags and a plurality of so-called dimension tables. The fact tables include at least one of a patient visits table, an orders table, a clinical decision support table, and a cardiology-related table. The dimension tables store time-related data, or clinical data organized by time period, such as on a yearly, monthly, weekly or shift.
In another embodiment, the method includes providing a facility by which an organization practicing the method may customize the clinically related logical rules. The facility may consist of a user interface to the analytics module which allows an administrator to program the logical rules and add new rules to an existing set of rules.
In yet another aspect of the invention, a system for medical records management is disclosed comprising a computer system including a computing platform executing a medical records information application maintaining a clinical database. The system further includes software (program instructions) stored on a machine readable medium accessible to the computing platform which creates an analytics database separate from the clinical database. The analytics database is configured in accordance with a data model optimized for business intelligence reporting tools. The analytics database further includes a plurality of flags set by the application of clinically-related logical rules to the clinical data.
In one embodiment the data model includes a plurality of fact tables storing clinical data and the flags associated with the logical rules. In another embodiment the data model includes a plurality of dimension tables. The database can also be configured into one or more OLAP multi-dimensional data cubes.
In addition to the exemplary aspects and embodiments described above, further aspects and embodiments will become apparent by reference to the drawings and by study of the following detailed descriptions. Moreover, the exemplary embodiment will be described in conjunction with representative and non-limiting examples of user interfaces by which information in the analytics database is presented to the user. Persons skilled in the art will recognize that variation from the specifics of the disclosed embodiments and user interface design is possible without departure from the teachings herein.
Exemplary embodiments are illustrated in referenced figures of the drawings. It is intended that the embodiments and figures disclosed herein are to be considered illustrative rather than restrictive.
Overview
This invention relates to a method and system for providing health care practitioners, clinical researchers, as well as health care administrators and support staff, access to clinically relevant information stored in a clinical database, such as a database of medical records of patients that have been admitted to a hospital over some period of years. The methods of this disclosure allow all the relevant information in a clinical database to accessed and utilized to meet substantially all of their data manipulation and reporting needs, using commercially available business intelligence (BI) report writer or presentation tools such as PROCLARITY™ or MICROSOFT SEQUEL REPORTS™, both available from Microsoft Corporation of Redmond, Wash. Unlike the situation in the past, however, the methods of this invention allow the aggregation and communication of massive amounts of data without impacting the performance of the clinical database, e.g., slowing it down. Additionally, the methods of this invention allows for simplified access to clinical data. It features a full replication of the relevant clinical data into a separate analytics environment (analytics database) as well as the creation of OLAP data cubes for use with business intelligence tools for effective report writing.
A motivation behind the development of this invention is to offer medical enterprises, such as hospitals and other health care organizations, with a tool to reorganize and make accessible the data they collect in their main clinical database. The data is reorganized by copying it from the main clinical database into an analytics database, and in the process transforming or configuring it into a data model which is optimized for Business Intelligence (BI) reporting tools, such as the two products mentioned above. One significant part of this transformation of the data is the use or setting of clinically-related flags and storing such flags in the analytics database. Accessibility to the analytics database is offered to users of the systems through the creation of reports such as “briefing books” derived from the cubes, again using commercially available software tools.
The use of clinically related-flags will be explained in more detail below, but in essence the flags provide a methodology by which the administrator or user of the system to set values related to clinically relevant data. The flags are imported into and made a part of the data structures of the analytics database (for example, entries in the fact tables as explained below) and thus are accessible to the BI reporting tools. Consider the typical situation where many transactions related to a patient occur over an episode of care, from admission, test results, orders, diagnoses, discharge, follow up care, and so forth. The method applies a test to particular information in the episode of care that determines the presence or absence of a specific event (e.g., a particular meaningful lab test value), either at any time or at a specific point in time of an episode of care. If the test criteria for the event (e.g., medical data, lab result, order, etc.) is met, then the method sets a flag (e.g., a discrete piece of data, such as a “1”), which means that the event occurred. If the test criteria is not met, it sends another type of flag or discrete set of data, e.g., a “0”.
For example, consider the situation where a patient is admitted to the hospital for pneumonia and stays seven days. One of the events that can be flagged was whether an appropriate antibiotic was ordered for the patient within four hours after admission. The software of this system examines all the orders for the patient (such orders being data contained in the clinical database) and looks for any one of the appropriately tagged antibiotics that is ordered within four hours of admission. It may find none, one, two, three, or more antibiotics tagged for pneumonia that have been ordered within four hours. If it finds at least one, it sets a flag of “1” and includes the flag in the Orders fact table which is stored in the analytics database. If it finds the correct antibiotic but it was not ordered within four hours, it sets a flag of “0” and the “0” is reflected in the Orders fact table. The flag is part of the Orders OLAP cube and thus presented to the user when they view an Orders briefing book on their workstation.
Obviously, this is just one example of the many different types of flags can be established when establishing the analytics database. The user of the system is allowed to define the flags, and can define any arbitrary number of them.
As another example, the analytics product could profile a patient for chronic illness by setting flags of “0” or “1” relating to codes or indicia that would indicate a certain type of illness, e.g., whether the patient is a smoker, whether they tested positive in some type of test, e.g., presence of HIV virus, whether they have certain medical conditions, etc. For example, there could exist up to twenty codes that indicate whether a patient has a history of diabetes. The analytics program applies a test to episode of care information relating to all 20 codes, and then returns a flag of either “0” or “1” for history of diabetes, and stores the flags in the analytics database.
Thus, the flags may include one or more flags designed to profile a patient for a chronic illness, e.g., based on the occurrence (or non-occurrence) of a set of events in the episode of patient care. As another example, the flags may include one or more flags designed to profile compliance with quality measures for care of a patient, such as quality measures set by an industry or governmental organization, e.g., whether an appropriate antibiotic was prescribed for a patient diagnosed with pneumonia within four hours of admission. This processing provides a strategy which is well suited to transform electronic medical record information in a clinical database to a format of information that is suitable to be transformed into data cubes, and suitable for interpretation by commercially available business intelligence objects or reporting tools.
To summarize, the methodology and software products described in this disclosure provide for extracting electronic medical records (electronic health records) in a clinical database and configuring the data into a new format in an analytics database suitable for use by business intelligence reporting tools. The methodology is flexible and configurable so that the organization implementing the methods and software can have flexibility over the criteria to apply to the medical information when setting the flags during the data extraction process—basically, the organization can specify any criteria it wants to. The analytics application is totally configurable in order to allow the organization to identify both the subject area in the clinical data, and the flag-setting test to be applied to particular clinical data. Thus, the organization can configure the meaning of the information contained in the electronic health records that is transferred to the analytics database.
The methods of this disclosure have a variety of uses in the medical setting. For example, it facilitates in-depth analysis of patient visits, orders given to patients, and clinical decision support, by health care researchers, practitioners, and hospital administrators. It further facilitates in-depth analysis of a hospital's compliance with quality measurements for hospital care and ambulatory care, such as those required by the Joint Commission on Accreditation of Hospitals (JCAHO), standards of the Centers for Medicare and Medicaid (CMS) for management of patients in Medicare and Medicaid programs, and health care standards mandated by health insurance companies, employers, or other payers of health care.
With the above overview in mind, this disclosure will initially present a description of one representative example of an environment in which the invention can be practiced, namely a hospital environment in which a clinical database of electronic patient records is created and maintained by a principal medical records application used throughout the hospital. The discussion will proceed to explain the analytics software which interacts with the medical records application, including the process of creation of the analytics database, and the features of the database, including fact tables, dimension tables and the clinically-related flags which are set and stored in the fact tables. The following sections will also explain what is being done to the extracted clinical data from the clinical database in order to present it as compiled information in the analytics database. The compilation process includes a series of logical rules, coded as SQL procedures, which set the clinically-related flags. The discussion will then turn to the business intelligence reporting tools by which information in the analytics database may be presented to the user.
System Overview and Creation of Clinical Database 18
Referring now to
The medical records system 10 includes a plurality of distributed workstations or client computers 14, a central database server 16 and a clinical database 18 containing electronic patient records. The workstations 14 could be for example general purpose computers with a processing unit and graphical display unit. The workstations 14 could also be hand-held computers. The workstations 14 include a memory storing an interactive, client-server based patient documentation application that is executed by the processor in the workstation. The application provides user interface tools in the form of graphical screen displays which allow the user access the electronic patient records stored in the clinical database and add clinical documentation regarding a patient being treated at the facility 12.
As shown in
The network 32 may include a router (not shown) providing a connection to an internet service provider (ISP) 40 providing access to an external wide area Internet Protocol network 42 such as the Internet 42. A workstation 14A may be coupled to the enterprise network 32 via the ISP 40 whereby a clinician authorized to access patient records in the database 12 may do so via the Internet 42, ISP 40 network access server and local area network 32. Thus, a workstation 14, 14A creating patient documentation need not necessarily physically reside on the network 32 or be physically located within or at the enterprise 12.
Thus, the medical records system 10 that is installed in the medical facility 12 allows clinicians to access patient records in a clinical database 18. The system 10 may take the form of a hospital medical records information system, and such systems are generally known in the art and commercially available from Eclipsys Corporation, Siemens, and others. The preferred embodiment of such a system provides clinicians information they need, when and where they need it—at the point of care (e.g., in the ER or at the nursing stations 26), in the offices 28, even at home via a computer 14A and the Internet 42.
A schematic representation of the clinical database 18 is shown in
A second field 56 contains orders for the patient. The orders are determined by health care personnel treating the patient. Each row in the orders field 56 may constitute a specific order, and the various columns in the row devoted to different aspects of the order, such as the entering physician's name, the type of order, the date it was placed, etc.
A third field 58 is directed to documents (i.e., documentation) entered by a physician or nurse. Each row may represent specific instances of documentation created by a user.
A fourth field 60 contains prescription medications ordered for the patient. A fifth field 62 contains data of all the patient's allergies. Other fields 64 are also present, and may include fields devoted to significant events, health issues, care providers and others. The name of the categories in the electronic patient record, and the number of categories is not particularly important and may vary depending on the environment and the choices made by a system administrator.
Analytics Module 80 (
In one aspect of this disclosure, a medical records information apparatus is provided which facilitates analysis of clinical data (e.g., patient or patient care information) stored in the clinical database 18 (
In particular, the application includes a process 82 extracting clinical data from the clinical database 18 and loading the extracted data into an analytics database 18A shown in
The main elements of the analytics module 80 is shown in
The analytics module 80 includes an extract process 82 which operates to extract clinically relevant information from the clinical database 18. The analytics module 80 further includes a load process 84 which loads data, including the flags discussed herein, into the analytics database 18A in a format or configuration optimized for business intelligence reporting tools. The analytics module 80 further includes stored SQL procedures 86 which include procedures in the form of logic statements or rules which are applied to extracted clinical data and are used to set flags of 0 or 1 for user-defined events in the episode of patient care. Other procedures 86 will be identified below. The load process 84 loads the data extracted from the clinical database into the analytics database 18A in the form of fact tables and dimension tables, as explained in further detail below. The analytics database (shown in more detail in
As indicated by the arrows connecting the workstations 14 and the analytics module 80, the purpose of the analytics module is to facilitate user access and analysis of the clinical information in the analytics database 19. Thus, the workstations include a business intelligence tool (software) 100 which interfaces with the analytics database 18A and provides to the user the information the user desires, in the form of briefing books, reports or other format 102 supported by the business intelligence software 100. The reports and briefing books can be presented on the display of the workstation, printed out, assimilated into other documents, etc. in known fashion.
The inpatient admission datamart 110A contains a subset of the clinical data relating to inpatient admissions. When a visit is created with a visit type of “Inpatient” it means that the patient is admitted to the hospital with the standard definition of an inpatient according to CMS rules. The quality measures created by CMS apply to that visit type. The visit usually lasts greater than 24 hours and generally for several days. There are other visit types that are not inpatient, such as emergency department and ambulatory. These visit types may be open for several hours but usually less than 24 hours. The patient information in these visit types are not extracted into the inpatient admission datamart.
The quality measures datamart 110B basically contains a subset of the clinical data relating to performance of the hospital and its employees relating to quality measures such required by the Joint Commission on Accreditation of Hospitals (JCAHO), standards of the Centers for Medicare and Medicaid (CMS) for management of patients in Medicare and Medicaid programs, and/or health care standards mandated by health insurance companies, employers, or other payers of health care. The focus is on quality measure reporting for the in-patient. Examples of the data in the quality measures datamart 110B could include: identification of patients with named conditions by reviewing authorities, report elements relating to orders, analysis of clinical decision support, medication administration timing in relations to ED admission and or hospital admission, elements of nursing care and education, analysis of standard JCAHO quality related measures, elements contained in orders and documentation, and Prescriptions, in-hospital immunization standards, length of stay, chronic disease profile, adverse metabolic events, discharge location, drug usage patterns, falls, decubitii related information, in-hospital fractures or other injuries, and code related information.
The orders datamart 110C contains a subset of the data relating to orders given to patients. All orders created for an inpatient admission are extracted into the Orders datamart. This data mart includes the essential information that defines the order such as name, type, and priority, timing, order clinician and in the case of medication orders, additional information about dose, units, frequency. The ordering pattern of clinicians and outcomes such as transfers to critical care, discharged alive and length of stay by principle diagnosis can be evaluated.
The clinical decision support datamart 110D contains all of the safety messages that are created for a patient, many of which pop up on the workstation display to the user. The user response to the patient safety alert messages is captured. The average response of the clinicians to these alerts can be measured and compared. The usefulness of these alerts can be measured. The information in the clinical decision datamart 110 contains the data captured by the medical logic modules (MLM) running in the clinical manager application.
The database 18A further includes a plurality of multidimensional OLAP cubes 92, including a visit discharges cube 92A, a patients cube 92B, a visit health issues cube 92C, a visit observations cube 92D, an orders cube 92E, clinical decision support cube 92F, and a quality measures cube 92G. Additional OLAP cubes may also be created and stored within the analytics database. The OLAP cubes 92 are described greater detail below. The OLAP cubes are created from the fact tables by a database application such as Microsoft SQL Server 2000 Analysis Services and serve to organize or arrange the data in a format compatible with the business intelligence reporting tool (100,
The database 18A includes metadata tables 112. The metadata tables 112 are described in further detail below in conjunction with
The database 18A further includes extracted source tables 114. These tables are described below in conjunction with the explanation of
The database 18A further includes supporting list tables 116. These tables are described in further detail below in conjunction with
The database 18A further includes “fact tables” 118, which are described below in conjunction with
The database 18A further includes dimension tables 120. The dimension tables are shown in
The database 18A further includes a clinical data warehouse 122 providing a reporting database for use in generation of reports.
The database further includes one or more reports 90. The reports 90 (
Creation of Analytics Database 18A
The process of creating the analytics database 18A of
The process backup process 200 is shown as consisting of four sub-steps 202, 204, 206 and 208. In essence, in this process 202 a backup of the clinical database 18 is created and restored on a server 16 in the computer system 10 of
The extract process 82 consists of substeps 302, 304, 306, 308 and 310 shown in
The result of extract process is shown on the right hand side of
Updating Analytics Database 18A
As noted previously, the analytics database 18A is created from the clinical database 18 and the clinical database is constantly being updated by the clinical manager application in real time as new patients are admitted, new orders or test results are entered into the database, etc. There is therefore a need to update the analytics database 18A on an ongoing basis. Therefore, the process of
Analytics Database Tables (
The analytics database 18A stores extracted information from the clinical database 18 in two types of tables, “fact tables” 118 (
Fact tables are tables of measurements, such as outcomes of tests, and dimension tables are tables of values of variables. Sometimes the same information may be a measurement in a fact table whereas it may be a dimension in another context. A typical dimension is the time or day, or hospital location, in which a particular event is being measured. The time dimension may be a time such as 10:30 am, or it may be an identification of one of the three work shifts such as 7 am-3 pm, 3 pm-11 pm and 11 pm-7 am. The fact of measurement may be an absolute value, such as blood pressure measurement, or it may be a flag that is set as described above. For example, a flag may be set indicating that less than 4 hours elapsed from the time of a medication order until the time of the first administration.
As an example of a fact in a fact table: The patient was given aspirin within 24 hours of admission to the hospital (a flag indicating it did or did not happen). The dimension related to this fact is the variable Principal Diagnosis for admission. In the fact table would be a measurement for the Principle diagnosis of dimension of acute myocardial infarction. As another example, the dimension may be the names of the admitting physicians, and the fact of the aspirin administration within 24 hours can be measured against the dimension of the attending physicians.
As another example of a fact: The measurement is eye examination within the past year (a flag indicating yes or no). The dimension is diagnosis of diabetes (another yes or no flag). Additional dimensions might include the age, race, gender and primary language of the patient.
As another example of a fact: a flag indicating whether or not the patient has had a hemoglobin A1c of >7.5 at any time in the past 12 months. The dimensions may be the flag for a diagnosis of diabetes and the primary care provider.
Dimensions are known variables that might change the number of times that a measurement is true or false or below or above a particular number or was or was not performed. For example, the question may be asked of the system as to how many patients were discharged to the hospital with evidence of counseling to discontinue smoking (flag measurement in the fact table) who had a principle diagnosis of acute myocardial infarction (dimension is principle diagnosis), and who had smoked tobacco products within the past one year (dimension is Smoker (a flag for yes or no) and did not die in the hospital stay (a dimension of discharge disposition)). In this case the counseled patients with these criteria is the numerator and the total number of these patients whether counseled or not is the denominator.
As will be appreciated from the above discussion, any given set of data relating to a patient will include data in both the fact tables and the dimension tables. To relate these tables together, the fact tables and dimension tables will include pointers to each other to reference the fields of the tables (e.g., row and column) that identify the facts and dimensions (variables) that, together, comprise the patient information. Hence, as shown in
Fact Tables 118 (
SANCardioNote 118A (FIG. 5)—this fact table is derived from a clinical document that employs a template to collect the answers to questions about possible AMI (cardiac) patients. It further offers JCAHO related data points about care delivered to AMI patients. This fact table provides source data for the “JCAHO Quality Measures” OLAP cube. The entries in the table are listed in
SANClinDecSupport 118B (FIG. 6)—this fact table derived from MLM (Medical Logic Modules) and Alert data extracted from the clinical database. This fact table supports the “Clinical Decision Support” OLAP cube. This fact table also includes pointers to the Visit and Order fact tables 118C and 118D as shown in
SANOrder 118D (FIG. 7)—this table is derived from extracted order data from the clinical database for the same inpatient discharged visits found in the SANVisit table (see below). The Order fact table 118D supports the “Order” OLAP cube.
SANVisit 118C (FIG. 8)—this table is derived from the inpatient discharged visit data extracted from the clinical database. This fact table supports two OLPA cubes: “Visit” and “Visit Patients”. As an example of the storage of the flags, the elements of the SANVisit fact table 118C “Has Critical Potassium” would contain a 1 or a 0, depending on the result of application of a logical statement to the extracted data from the clinical database relating to potassium level measurements of a given patient.
Dimension Tables 120
The dimension tables 120 of
SANActivityStatusDim 120A—this table list of possible discharge instructions given to patients regarding their options for strenuous activity. This dimension table is used with the SANCardioNote table to construct the “JCAHO Quality Measures” OLAP cube.
SANAgeDim 120B—list of ages used in reporting. Age can be represented as a year, as a month (as in 23 months old) or both. This table is used with the SANVisit table to construct the two Visit OLAP cubes. SANAgeRangeSet—defines various “sets” or age range categories. Examples include the default “Decile” set which groups ages by decades. SANAgeRangeItem—defines the groupings of ages for the various sets. SANAgeRangePart—defines the relationship between the age range items defined in the SANAgeRangeItem table and the ages recorded in the SANAgeDim table. It associates the individual ages recorded in SANAgeDim with the item groupings defined in the SANAgeRangeItem table.
SANCareLevelDim 120C—defines the departments or areas of care in the facility. This table is used with the SANVisit table to construct the two Visit OLAP cubes.
SANDateDim 120D—defines a calendar of days over a period of years. This table is used by all the fact tables and in the construction of all cubes. The dates start with Jan. 1, 1980 through Dec. 31, 2020 plus 1 row as a default for any dates encountered outside this time 40 year period.
SANDiagDim 120E—list of diagnosis codes used with the SANVisit table to construct the two Visit OLAP cubes.
SANDietDim 120F—a list of dietary categories assigned to patients. This table is used with the SANCardioNote table to construct the “JCAHO Quality Measures” OLAP cube.
SANDischargeSvcDim 120G—list of discharge services performed by the facility. This table is used with the SANCardioNote table to construct the “JCAHO Quality Measures” OLAP cube.
SANLanguageDim 120H—list of languages spoken by patients. This table is used with the SANVisit table to construct the two Visit OLAP cubes.
SANLocationDim 120I—list of locations in the facility. This table is used with the SANVisit table to construct the two Visit OLAP cubes.
SANNurseDim 120J—list of nurses delivering care at the facility. This table is used with the SANCardioNote table to construct the “JCAHO Quality Measures” OLAP cube.
SANPatDriveDim 120K—list of instructions for patients with regard to their driving of automobiles after discharge. This table is used with the SANCardioNote table to construct the “JCAHO Quality Measures” OLAP cube.
SANPostalCodeDim 120L—list of postal zip codes identifying where patients live. This table is used with the SANVisit table to construct the two Visit OLAP cubes.
SANPriorityDim 120M—list of order priorities used by the facility. This table is used with the SANOrder table to construct the Order OLAP cubes.
SANProviderDim 120N—is the list of provider practicing at the facility. This table is used by all the fact tables and in the construction of all cubes.
SANRaceDim 120O—list of patient racial characteristics. This table is used with the SANVisit table to construct the SAN Visit Patients cube.
SANReligionDim 120P—list of patient religious affiliations. This table is used with the SANVisit table to construct the SAN Visit Patients cube.
SANReturnToWorkDim 120Q—list of instructions for patients with regard to their return to work after discharge. This table is used with the SANCardioNote table to construct the “JCAHO Quality Measures” OLAP cube.
SANServiceDim 120R—list of the service categories defined by the facility. This table is used with the SANVisit table to construct the “SAN Visit Discharge” OLAP cubes.
SANShiftDim 120S—lists the work shifts defined by the facility. This table is used with both the SANVisit and SANOrder tables to construct the “SAN Visit” and “SAN Orders” OLAP cubes.
Metadata Tables 112 (
SANMDProcess 112A—a single row table of parameters for the clinical database extract process. It contains the parameters that define when to run the extract, the name of the server 16 and the clinical database 18A and the name of the Analytics database 18A. This is also the location of the semaphore flag which is used to prevent the data extraction service from processing a table that is being used by the data population process.
SANMDTable 112B—the list of the clinical database tables from which data is extracted and facts related to the last extract of data from the given table.
SANMDLocation 112C—the name of the clinical database and the server where it can be found.
SANMDOLAPObject 112D—the list of dimensions and cubes that are to be processed with each update of the SAN database. The load process includes a procedure that executes two SQL Server Data Transformation Services (DTS) scripts to refresh the dimensions and then the cubes.
SANMDLog 112E—Execution history
Supporting List Tables 116 (
1. SANMDCCUList 116A—list of critical care units in the facility.
2. SANMDFlagList 116B—list of medical attribute flags found in the various fact tables. An example would be the IsDiabetic flag found in the SANVisit table. It is used to indicate whether the patient receiving care during the visit was a diabetic.
OLAP Cubes 92
A database application such as MICROSOFT SQL SERVER 2000 ANALYSIS SERVICES (or other suitable application) is used to create and update the following OLAP cubes 92 (
1. SAN Visit Discharges 92A
2. SAN Visit Patients 92B
3. SAN Visit Health Issue 92C
4. SAN Visit Observation 92D
5. SAN Order 92E
6. Clinical Decision Support 92F
7. JCAHO Quality Measures 92G
Reporting Using Business Intelligence Tools
A commercially available business intelligence reporting application such as PROCLARITY™ from Microsoft Corporation is used to create a set of reports, called Briefing Books, that allow users to view the OLAP cube data and to refine the presentation. For each briefing book, a screen shot is shown in the appended Figures which illustrates the list of reports in the frame on the left hand side of the screen, the list of measures and dimensions in the frame on the middle, left hand side of the screen that can be moved into and out of the given report in order to refine presented information, and the presented report in the major frame on the screen. It will be apparent to persons skilled in the art that there are a variety of formats that can be used to display the details of the reports and the screen shots of
1. Visit Discharge and Patient Information briefing book (
Cube: SAN Visit Patients
Cube: SAN Visit Discharges
Reports: Discharged Visits by
Cube: SAN Visit Health Issue
Cube: SAN Visit Observation
Reports: Discharged Visits by
Cube: SAN Order
Reports: Orders by
Cube: Clinical Decision Support
Reports:
Cube: JCAHO Quality Measure
Reports: Orders by
Terminology
As used herein, the term “datamart” refers to repository of data which contains a subset of organizational data (in this instance, medical related or clinical data) which helps a health care enterprise to analyze medical related information, e.g., on the basis of past trends and experiences. The creation of a data mart is predicated on a specific, predefined need for a certain grouping and configuration of select data. A data mart configuration emphasizes easy access to relevant information.
The term “OLAP (On-Line Analytical Processing) cube” refers to an array of data into a multidimensional format, referred to as a “cube”. The arrangement of data into cubes avoids a limitation of relational databases which are not well suited for near instantaneous analysis of large amounts of data. Relational databases are better suited for creating records from a series of transactions (known as OLTP or on-line transaction processing). OLAP cubes can be thought of as extensions to the two-dimensional array of a spreadsheet. For example, a hospital might wish to analyze some clinical data by time-period, by doctor, by facility, by type of revenue and cost, and by comparing actual data with some standard. These additional methods or parameters of analysing the data are known as dimensions.
While a number of exemplary aspects and embodiments have been discussed above, those of skill in the art will recognize certain modifications, permutations, additions and sub-combinations thereof may be made to the specifics of the preceding disclosure. It is therefore intended that the following appended claims, and claims hereafter introduced, are interpreted to include all such modifications, permutations, additions and sub-combinations as are within their true spirit and scope.
Examples of reports 90 (
Other types of reports can include general demographics reports, such as breakdown in the patient population by items such as
1. Gender
2. Race
3. Language
4. Religion
5. Postal Code
6. Age distribution
As another example, the analytics module can create complex reports, such as
Admit Reason and LOS with the variables of Diabetes, COPD, CHF, Smoker, CAD, MI, Probable Kidney Disease, Probable Liver Disease, Admit reason and Admitting Provider.
The analytics module can also prepare reports 90 concerning orders placed, such as for example
1. Orders by Provider
2. Orders by Provider by Priority (Stat, Routine, Now, Time Critical)
3. Provider Orders by Shift
The analytics module can also prepare discharge reports 90, such as reports
1. for acute MI (myocardial infarction) patients:
2. for Heart Failure Patients
3. Community Acquired Pneumonia
The table that follows lists the “flags” set during the process of moving data from the clinical database 18 to the analytics database 18A. Some of the flags indicate whether or not a specific event occurred and others whether or not the patient has the medically relevant characteristic. The basic specifications are retained in a table called SANMDFlagList. Its definition is provided below.
From the SANMDFlagList table the list of flags ([FlagColumn]), the source table ([FlagTable]) and the criteria ([WhereCriteria]) have been extracted and recorded in the next table seen below.
The first column in the table identifies the “flag” that the user will see in the reports. The second column identifies the clinical database tables that provided the relevant data clues. The third column lists the actual criteria that have to be met to set the flag to ‘true’ or ‘positive’. The default is ‘false’ or ‘negative’.
In this table each listed flag is followed by the SQL UPDATE statement that is generated by a SQL Server Stored Procedure that queries the table to construct and submit the UPDATE statement for processing.
It is contemplated that additional software modules can be incorporated into the analytics module 80 and used to generate additional reports or other collections of data.
Research 602
A research module can create case report forms data marts (602A), perform general outcome research (using multivariate analysis) (602B), and reports of persistent patient registries for studies (602C).
The outcomes research module (602B) monitors for adverse events over time for chronic diseases, such as
Medical Education Monitoring 608
A module creates reports useful for medical education, including a case mix for students (608A), a case mix for residents (608B), and procedure note analysis (608C).
Ambulatory/HEDIS Module 610
This module prepares reports relating to ambulatory patient. The module also can also prepare HEDIS reports. HEDIS (Health Plan Employer and Data Information Set) is a set of standardized performance measures designed to ensure that purchasers and consumers have the information they need to reliably compare the performance of managed health care plans. Examples of such reports can include reports which:
1. Identify patients with Chronic illness
2. Survey for preventive therapy (Vaccines)
3. Survey for Preventive Medicine test
4. Monitor goals for DIABETES:
5. Vascular Disease
6. Congestive Heart Failure
7. Prescription Medication Utilization
8. Additional HEDIS Measures
An Emergency Department (ED) Module 612
This module creates report analyzing data pertinent to performance of an emergency department, such as reports which summarize such factors as:
1. Admission Rate
2. Length of Stay before Admission
3. Time to invasive procedure for MI
4. Time to Thombolysis for stroke
5. Code Outcomes
6. Acuity Case Mix
7. Shift variation in acuity and volume
8. Length of stay by acuity
9. Imaging utilization
10. Order set utilization
11. Order utilization
Critical Care Module 614
1. JCAHO ICU Core Measures Reporting
2. Death in Unit
3. Survival, long term
4. Discharge Disposition
5. Multivariate analysis related to survival
6. Sepsis
7. Procedure and complications
8. LOS
9. Ventilator Associated Pneumonia
10. MRSA Infections
11. VRE Infections
12. C.Difficile Infections
13. Drug usage
14. Drug days
15. Central Line Location
16. Central Line Days
17. Infections per Central Line Days
A Revenue Cycle Module (616)
This module analyzes financial performance of the enterprise using the analytics module and generates reports such as
1. Receivable Analysis, including days to collect
2. Cost to collect
3. Revenue sources
4. Admissions/discharge statistics
Enterprise Scheduling Module 618
Resource Utilization 620
This module analyzes data relating to the utilization and allocation of enterprise resources, both physical and personnel, and generates reports, such as reports of service levels, the ability to fulfill a scheduling request, wait time (point of schedule to appointment), office throughput, and waiting room times.
