Patient data mining, presentation, exploration, and verification

This application claims the benefit of U.S. Provisional Application Serial No. 60/335,542, filed on Nov. 2, 2001, which is incorporated by reference herein in its entirety.

The present invention relates to organization and review of data, and, more particularly to a graphical user interface for presentation, exploration and verification of patient information.

The information environment faced by physicians has undergone significant changes. There is much more information available, in more formats than ever before, competing for the limited time of physicians. Although the information age is slowly transforming this landscape, it has not yet delivered tools that can alleviate the information overload faced by physicians.

Currently, many health care organizations have started to migrate toward environments where most aspects of patient care management are automated. However, health care organizations with such information management systems have tended to maintain information in a myriad of unstructured and structured data sources. It may still be necessary to access numerous different data sources, each with its own peculiar format.

In view of the above, it would be desirable and highly advantageous to provide new graphical tools for presentation, exploration and verification of patient information.

The present invention provides a graphical user interface for presentation, exploration and verification of patient information.

In various embodiments of the present invention, a method is provided for browsing mined patient information. The method includes selecting patient information to view, at least some of the patient information being probabilistic, presenting the selected patient information on a screen, the selected patient information including links to related information. The selected patient information may include raw information extracted from various data sources for the patient (hereinafter referred to as ‘elements’) or conclusions drawn therefrom. This information may be derived from various data sources.

The selected patient information may include an element linked to unstructured information. For example, an element linked to a note with highlighted information may be presented. The highlighted information may refer to information used to derive the element. Additionally, the unstructured information may include medical images and waveform information.

The selected patient information may also be derived from structured data sources, such as a database table.

The selected patient information may include a document with links to elements associated with the document.

The selected patient information may include patient summary information.

The patient information presented to a particular user may depend on the identity or role of the user. For instance, a physician may be interested only in a high-level view of the disease (at least initially) and be presented with the most relevant conclusions drawn from the entire patient record.

Another option is to display all the patient information (every element and derived conclusion) but to sort this list in order of decreasing relevance to the disease.

These and other aspects, features and advantages of the present invention will become apparent from the following detailed description of preferred embodiments, which is to be read in connection with the accompanying drawings.

FIG. 1 shows an exemplary data mining framework for mining structured clinical information;

FIG. 2 shows an exemplary main browser screen;

FIG. 3 shows an exemplary options screen;

FIG. 4 shows an exemplary summary frame screen;

FIGS. 5 and 6 show exemplary verification screens;

FIGS. 7 and 8 show exemplary exploration screens;

FIGS. 9 and 10 show exemplary results of extraction from a structured data source; and

FIGS. 11 to 13 show exemplary presentation of patient summary information.

FIG. 1 illustrates an exemplary data mining framework as disclosed in “Patient Data Mining,” by Rao et al., copending U.S. patent application Ser. No. 10/287,055, published as 2003-012045, filed herewith, which is incorporated by reference herein in its entirety.

Detailed knowledge regarding the domain of interest, such as, for example, a disease of interest is used. This domain knowledge base can come in two forms. It can be encoded as an input to the system, or as programs that produce information that can be understood by the system. The part of the domain knowledge base that is input to the present form of the system may also be learned from data.

Domain-specific knowledge for mining the data sources may include institution-specific domain knowledge. For example, this may include information about the data available at a particular hospital, document structures at a hospital, policies of a hospital, guidelines of a hospital, and any variations of a hospital.

The domain-specific knowledge may also include disease-specific domain knowledge. For example, the disease-specific domain knowledge may include various factors that influence risk of a disease, disease progression information, complications information, outcomes and variables related to a disease, measurements related to a disease, and policies and guidelines established by medical bodies.

An extraction component takes information from a computerized patient record (CPR) to produce probabilistic assertions (elements) about the patient that are relevant to an instant in time or time period. This process is carried out with the guidance of the domain knowledge that is contained in the domain knowledge base. The domain knowledge required for extraction is generally specific to each source.

Extraction from a text source may be carried out by phrase spotting, which requires a list of rules that specify the phrases of interest and the inferences that can be drawn therefrom. For example, if there is a statement in a doctor's note with the words “There is evidence of metastatic cancer in the liver,” then, in order to infer from this sentence that the patient has cancer, a rule is needed that directs the system to look for the phrase “metastatic cancer,” and, if it is found, to assert that the patient has cancer with a high degree of confidence (which, in the present embodiment, translates to generate an element with name “Cancer”, value “True” and confidence 0.9).

The data sources include structured and unstructured information. Structured information may be converted into standardized units, where appropriate. Unstructured information may include ASCII text strings, image information in DICOM (Digital Imaging and Communication in Medicine) format, and text documents partitioned based on domain knowledge. Information that is likely to be incorrect or missing may be noted, so that action may be taken. For example, the mined information may include corrected information, including corrected ICD-9 diagnosis codes.

Extraction from a database source may be carried out by querying a table in the source, in which case, the domain knowledge needs to encode what information is present in which fields in the database. On the other hand, the extraction process may involve computing a complicated function of the information contained in the database, in which case, the domain knowledge may be provided in the form of a program that performs this computation whose output may be fed to the rest of the system.

Extraction from images, waveforms, etc., may be carried out by image processing or feature extraction programs that are provided to the system.

Combination includes the process of producing a unified view of each variable at a given point in time from potentially conflicting assertions from the same/different sources. In various embodiments of the present invention, this is performed using domain knowledge regarding the statistics of the variables represented by the elements (“prior probabilities”).

Inference is the process of taking all the factoids that are available about a patient and producing a composite view of the patient's progress through disease states, treatment protocols, laboratory tests, etc. Essentially, a patient's current state can be influenced by a previous state and any new composite observations.

As illustrates in FIG. 1 , an exemplary data mining framework for mining high-quality structured clinical information includes a data miner 150 that mines information from a computerized patient record (CPR) 110 using domain-specific knowledge contained in a knowledge base ( 130 ). The data miner 150 includes components for extracting information from the CPR 152 , combining all available evidence in a principled fashion over time 154 , and drawing inferences from this combination process 156 . The mined information may be stored in a structured CPR 180 .

The extraction component 152 deals with gleaning small pieces of information from each data source regarding a patient, which are represented as probabilistic assertions about the patient at a particular time. These probabilistic assertions are called elements. The combination component 154 combines all the elements that refer to the same variable at the same time period to form one unified probabilistic assertion regarding that variable. These unified probabilistic assertions are called factoids. The inference component 156 deals with the combination of these factoids, at the same point in time and/or at different points in time, to produce a coherent and concise picture of the progression of the patient's state over time. This progression of the patient's state is called a state sequence.

FIG. 2 illustrates an exemplary main browser screen 200 for browsing mined patient information. The exemplary main browser screen 200 includes a run state selector 202 , a patient selector 204 , and an enter button 206 .

In operation, a user interacting with the main browser screen 200 enters a patient identifier using the patient selector 204 and a data mining run state using the run state selector 202 . The user then clicks on the enter button 206 to cause the selected patient identifier and run state to be input.

The data mining run state can include a particular run cycle (e.g., run date, time) that patient medical records were mined. When information is retrieved, it can include only information current as of that point.

Referring to FIG. 3 , an exemplary options screen 300 is illustrated. The options screen 300 may include a plurality of input buttons, each input button for displaying a level of information. For example, the user may click on an input button to select summary information. FIG. 4 illustrates the result of selecting summary information from the options screen 300 . As shown in FIG. 4 , a summary of a particular patient information is presented. This summary includes all elements, documents, and tests for the patient relating to glycemic control, which is the view of the patient record presented to the particular user.

Advantageously, the patient information presented to a particular user may depend on the identity or role of the user. For example, a cardiologist may be presented with a different view of the data than an oncologist. Similarly, a physician may be presented with information different from that of a nurse or administrative employee. By presenting different views of the patient information, the user can more effectively make use of information that he or she is interested in.

Another option is to display all the patient information (every element and derived conclusion) but to sort this list in order of decreasing relevance to the disease. For instance, one patient's most relevant item may be his abnormal test results, while another patient whose test results are normal may have his family history of cancer be the most relevant item.

Referring to FIG. 5 , an exemplary verification screen is illustrated. This screen allows a user to drill down an element to its underlying source. In this case, the element “STTAbn; Value: true, 0.8” has been selected, causing a physician note to be displayed in the right-hand portion of the screen. The highlighted portion of the physician note indicates the data from which the element was derived. In this case, it was concluded that there is an 80% probability that the patient's ECG showed ST-T wave abnormalities. FIG. 6 illustrates drilling down of another element, “STTabn; Value: false, 0.7”, that contradicts the element shown in FIG. 5 . In this case, it was concluded that there is an 70% probability that the patient's ECG showed ST-T wave abnormalities. A user may use the verification screen to verify the conclusions inferred from the underlying data sources.

Although FIGS. 5 and 6 show that the underlying data sources are physician notes, it should be appreciated that the data sources could take other forms. For example, the elements may be derived from (and linked to) medical images, waveforms, and structured information (e.g., information contained in a database).

Referring to FIG. 7 , documents may be displayed to the user. In this case, the user selected a physician note written by Emergency Room (ER) personnel. Two separate elements were derived from information contained in this document. FIG. 8 shows another document displayed on the exploration screen. As illustrated, this document includes fourteen elements in six categories.

FIGS. 9 and 10 illustrate patient information extracted from structured data sources. In particular, FIG. 9 shows lab results for a particular patient. As depicted, the lab results include a date, time, test name, and measurement value. FIG. 10 shows various medications administered to the patient. This information includes a drug name, date, dosage, and price information. The information obtained from structured data sources may have been converted into standardized units, where appropriate.

FIGS. 11 to 13 illustrate exemplary patient summary screens. FIG. 11 shows summary results for ‘BGLUT’ (blood glucose level). As shown, various summary information is presented to the user. Likewise, FIG. 12 shows summary results for “TCPL”. As shown in FIG. 13 , patient summary information related to various facets of glycemic control is presented.

While the exemplary screens use several selection menus and buttons, it should be appreciated that the selection of various parameters such as the patient identifier, miner run state, documents, elements, categories, etc., can be accommodated using a variety of devices, such as a number of graphical user interface selection widgets, check boxes, buttons, list boxes, pop-up or drop-down marks, text entry boxes and the like, or any known or later developed interfaces that an operator can access. It should be appreciated that the various exemplary screens illustrated herein can also, or alternatively, include any device capable of presentation, exploration, and verification of mined patient information.

Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope or spirit of the invention.