Patent Application
20090119130
The present invention generally relates to methods and systems for analysis of medical data, including laboratory data, signs and symptoms, historical information about a patient, and so on. The present invention further relates to systems and methods for providing: 1) a differential diagnosis, i.e., a list of the most likely illnesses that match the known constellation of clinical data, and 2) a treatment plan or a best-practice workup, i.e., a list of next steps that should be taken, whether diagnostic or therapeutic.
Many conventional methods have been developed to provide a differential diagnosis based on a set of clinical data. Such conventional methods incorporate a variety of algorithms, including expert systems, neural networks, and Bayesian networks. A common failure of such methods is that they rank the differential diagnosis by a likelihood of occurrence, as opposed to the sequence in which hypotheses should be tackled. Another common failure of such methods is that they do not provide guidance regarding how to rule in, or rule out, any items listed within the differential diagnosis.
Several conventional methods have been developed to provide recommendations for a treatment plan or a best-practice workup, given a diagnosis in advance. Such conventional methods incorporate a wide variety of algorithms, making them difficult to categorize. A common failure of such methods is that they are problem-setting driven. This means that these conventional methods rely on a priori knowledge of a problem or a diagnosis (e.g., diabetes). This limits the applicability of these methods, and subsequent accuracy of treatment, to situations where the underlying problem itself has not yet been identified, or where multiple problems intersect at the same time. An example of such conventional systems and methods include a conventional system that provides best-practice recommendations for treating diabetes in the presence of renal failure, where this system cannot be invoked unless the system's user knows a priori that the patient has diabetes and renal failure. Another common failure of such conventional methods is that they require very particular and complete sets of data, resulting in failure if any portion of the required data is missing.
Some conventional methods are capable of determining a best-practice workup given only a set of clinical data. The results of these methods are typically fractured or incomplete and are not accompanied by an initial diagnosis. Such methods typically fail to keep up with the tremendous complexity of determining a best-practice workup, given the huge (and ever-changing) body of medical knowledge and the huge variety of concomitant clinical settings, signs, and symptoms. It is an object of the present invention to overcome these obstacles, describing a method to determine a best-practice workup, given only a set of clinical data (purely “data-driven”), with no assumptions as to completeness or prior diagnosis.
Conventional methods of automated interpretation of clinical data suffer from the following disadvantages, as they
Thus there is a need to provide a system and a method that can provide both a differential diagnosis and a best-practice workup given a set of clinical data, without any requirements as to completeness of the data, and without any need for a prior diagnosis.
Accordingly, it is an object of some embodiments of the present invention to provide a method and a system for providing a differential diagnosis and a best-practice workup given a set of clinical data, without any requirements as to completeness of the data, and without any need for a prior diagnosis.
It is an object of some embodiments of the present invention to provide a method and a system for providing, in its workup, both diagnostic and therapeutic recommendations.
It is an object of some embodiments of the present invention to provide a method and a system for dynamically adapting to input data, shifting recommendations to become more and more precise as more and more data is provided.
It is an object of some embodiments of the present invention to provide a method and a system for querying the user for additional relevant data that would assist in further refining the analysis.
It is an object of some embodiments of the present invention to provide a method and a system, which is highly extensible, so that additional knowledge may easily be added to the system.
It is an object of some embodiments of the present invention to provide a method and a system that runs efficiently, so that many patient records may be analyzed quickly in the background.
It is an object of some embodiments of the present invention to provide a method and a system that sends analyses directly into electronic medical records, when available.
It is an object of some of the embodiments of the present invention to provide a method and/or system which forwards medical orders or collections of orders directly into Computerized Physician Order Entry (CPOE) systems, when available.
It is an object of some of the embodiments of the present invention to provide a method and/or system which imports information directly from electronic medical record systems, electronic lab data systems, and other repositories of electronic clinical data.
It is an object of some embodiments of the present invention to provide a method and a system for an intuitive, compact user interface suitable for use by busy clinicians.
It is an object of some embodiments of the present invention to provide a method and a system that tailors output for multiple types of users, including insurers, clinicians, patients, and medical care facilities.
It is an object of some embodiments of the present invention to provide a method and a system that allows easy maintenance and updating over time, so that the knowledge encapsulated stays current.
In some embodiments, the present invention relates to a system for analyzing clinical data relating to a patient. The system includes a computing device having a memory, a plurality of tables configured to be stored and processed by the computing device, a plurality of modules configured to be executed by the computing device and further configured to interact with the plurality of tables. The modules are configured to process data obtained from a pool of data (wherein the pool of data includes raw clinical data relating to the patient), and generate derived data based on the processing. The modules are also configured to be executed using the derived data and/or raw data and to generate a result of such execution. The result of execution is provided to the plurality of tables. The plurality of tables is configured to store this result. The system further includes a collator configured to be executed by the computing device and further configured to generate output based on the result received from the plurality of tables.
In some embodiments, the present invention relates to a method for analyzing clinical data relating to a patient using a computing device having a memory for processing and storing a plurality of tables, and executing a plurality of modules configured to interact with the plurality of tables. The method includes processing data obtained from a pool of data, wherein the pool of data includes raw clinical data relating to the patient, generating derived data based on the processed data, executing at least one module to generate a result, providing the result to the plurality of tables, using the plurality of tables, storing the result, and generating output based on the result received from the plurality of tables.
In some embodiments, the present invention relates to a system for analyzing clinical data relating to a patient using a computing system having a memory, wherein the computing system processes and stores a plurality of tables, and executes a plurality of modules configured to interact with the plurality of tables. The system includes a means for processing data obtained from a pool of data, wherein the pool of data includes raw clinical data relating to the patient, a means for generating derived data based on the processing of data, a means for executing at least one module to generate a result, a means for providing the result to the plurality of tables, a means for storing the result in the plurality of tables, and a means for generating output based on the result received from the plurality of tables.
In some embodiments, the present invention relates to a computer program for analyzing clinical data relating to a patient, wherein the computer program is executable on a computing device having a memory. The computer program includes a plurality of tables and a plurality of modules configured to interact with the plurality of tables. The modules are configured to process data obtained from a pool of data—wherein the pool of data includes raw clinical data relating to the patient—and generate derived data based on the processing. The modules are executed using the derived data and/or raw data to generate a result and provide the result to the plurality of tables, wherein the plurality of tables are configured to store the result. The program further includes a collator configured to generate output based on the result received from the plurality of tables.
In some embodiments, the present invention relates to systems, methods, and computer programs for analyzing data, in particular clinical data relating to a patient, in order to determine a differential diagnosis (which can be a list of possible diagnoses) and treatment plan (or work-up) for the patient. More particularly, the present invention includes collections or classifications of modules that are capable of receiving raw clinical data, processing this data and/or subsets of such data, and generating derived data, and then, based on a combination of the clinical data (and/or its subsets) and derived data, determining a differential diagnosis and possible treatment plans or best-practice work-ups.
The present invention's systems, methods, and programs are configured to receive raw clinical data relating to a patient or an individual. For illustrative and non-limiting purposes, the term “raw” denotes clinical data, such as laboratory values, physical findings, prior medical history, test results, or other such data, that can be received from sources outside the present invention (such as medical laboratories, hospitals, physicians, other medical facilities, or any other sources). “Raw” data also includes certain types of data that may be built directly into the present invention—for example, ranges of normal laboratory values. In contrast, the term “derived” denotes data that is generated internally by the present invention by means of calculations, algorithms, or other processing; such processing can be performed on raw data, derived data, or both. As can be understood by one skilled in the art, the terms raw clinical data and derived data are not limited to the above definitions. Based on at least a portion of the raw data, derived data, and/or any combination thereof, a specific diagnosis and/or a treatment plan/work-up are generated for the patient.
The raw data 120 is supplied to the pool of data 102 that is used for supplying data to the collection of modules 106. The collection of tables 104 includes a plurality of tables, such as: a findings table 103a, a warnings table 103b, an orders table 103c, a data requests table 103d, and a recommendations table 103e. As can be understood by one skilled in the art, tables 103 are not limited to those illustrated in
The collection of tables 104 is configured to interact with a collection of modules 106. The modules 105(a, b, c) are configured to perform various calculations and functions, and to generate output and/or results. Such output/results can be fed back to the collection of tables 104 or data pool 102, provided to the publish/subscribe list 108, and/or provided to the trigger queue 110.
The collection of tables 104 also produce an output that is fed into the collator 112, which can perform post-processing of the output. The collator 112 is further configured to sort the output received from the collection of tables 104 and based on such sorting send the results out to the outside world. Additionally, the collator can format the output, eliminate redundancies, etc. Such results can include orders, findings, data requests, recommendations, and warnings. The results can be provided to the patient, medical professional, other automated programs, or any other individual, entity, program, etc. The results can be printed, displayed on the screen of a computer, or delivered in any form or shape desired. In some embodiments, these results can be broader than the eventual differential diagnosis generated by the system. An exemplary finding can be “this patient's clinical profile renders him/her ineligible for a clinical trial.”
As illustrated in
In some embodiments, the raw data items 202 can be subdivided into a plurality of categories, such as lab tests 302, medical history 304, hospital data 306, physical findings 308, medicolegal data 310, demographic data 312, and genomic data 314. The information/data 302-314 relates to a particular patient for which a diagnosis and a proposed treatment plan are being sought. The following are illustrative examples. The lab tests data 302 can include information that the patient's creatinine=1.6. The medical history data 304 can indicate that the patient has a history of diabetes. The hospital data 306 can indicate that the patient is currently on Keflex for bacterial infection. The physical findings data 308 can indicate that the patient's blood pressure is 140/90. The medicolegal data 310 can indicate that the patient has signed a do-not-resuscitate (“DNR”) consent form. The demographic data 312 can indicate that the patient is a 20-year-old white female. The genomic/proteomic data 314 can indicate that the patient is HER-2/neu positive. As can be understood by one skilled in the art, the present invention is not limited to the categories and/or information illustrated in
The orders table 103b is configured to present and/or output specific orders for a treatment of the patient. For example, the orders table 103b can be configured to present an order that the patient should begin a specific treatment course.
The recommendations table 103c can be configured to present recommendations for courses of action to be taken with regard to the particular patient. The recommendations table 103c can be configured to perform a recommendation function based on the clinical data or at least one subset of the clinical data, derived data, or any combination thereof. For example, the recommendations table 103c can be configured to issue a recommendation stating: “Prescribe a beta blocker,” for a particular patient.
The warnings table 103d can be configured to issue alerts regarding errors or unusual program execution by the present invention. In some embodiments, the warnings table 103d can be configured to provide an indication to the user of the present invention's system 100 that the system 100 has obtained an abnormal result (e.g., assumption of a default value, or other out-of-the-ordinary signals).
The data requests table 103e can be configured to request additional data that can be sent to the user (e.g., patient, medical professional, etc.) for manual entry and/or to an information exchange system for automated entry. The data requests table 103e can be configured to request a specific additional data, such as raw clinical data 502 (or a subset of such clinical data), a derived data, or any combination thereof. For example, the data requests table 103e can be configured to issue a request for an albumin measurement in order to produce useful findings or recommendations. Such a request can be issued to the user of the system 100. Such a user can be a patient, a physician, a medical healthcare professional, or any other individual/system using the system 100. Alternately, such a request can be issued electronically to another electronic system; for example, an Electronic Medical Record (EMR), or Health Information Exchange (HIE) system. In some embodiments, the data request classification of code modules can generate a pop-up dialog on the user's computer screen, or an entry in an electronic medical record.
Referring back to
The module 105 is configured to include a core 704 for processing input data and generating a trigger (or a plurality of triggers) 706 and output items 708. The output items 708 can include derived data items and table items, as discussed above with regard to
The module 105 can be configured to send alerts to the publish/subscribe list 108 upon receipt of the input items from the pool of data 102 and/or table(s) 103. Such alerts can indicate that the module 105 has requested specific data, information, and other. This way, other modules 105 are made aware of the fact that this particular module 105 has requested information. If such information is not immediately available (e.g., needs to be provided by other module 105), other modules 105 can work to provide and/or request the information from other modules, the user, etc.
The core 704 can be configured to include a block of codes configured to be executed by a computer. Such computer can include a central processing unit (“CPU”), a memory, a hard drive, a RAM, and any other requisite components for execution of functions, which are provided to the Core 704. An exemplary Core 704 of the module 105 is illustrated in
In some embodiments, the Core 1900, based on the input data, can perform various manipulations indicated by the IF-THEN statements in the block showing the Core 1900. As a result of the manipulations performed by the Core 1900, derived data 1912 indicates that the patient has a primary acid-base disorder. Additionally, the Core 1900 can be configured to generate a warning 1914. As can be understood by one skilled in the art, the Core 1900 is not limited to the illustrated embodiments shown in
Referring back to
The output of the core 704 is configured to be added to the pool of data 102 in the form of derived data. The output of the core 704 can also be added as table items 702 to any of the tables 103.
Further, the module 105 can be further configured to place alerts to the publish/subscribe list 108 of the system 100. A “subscription” alert can be added to the publish/subscribe list 108 indicating that a particular input datum and/or data was requested by the module 105 but was unavailable when the module 105 executed. This way, other modules 105 can be made aware that a particular module 105 has requested specific input data, which can include raw clinical data, derived data, or any other information. Alternately, a “publication” alert can be added to the publish/subscribe list 108 indicating that a particular input datum and/or data was provided by the module 105. Such an alert tells other modules 105 that there are new information/data now available. Publish/subscribe schemes are common in the computer science literature and variations on the above will be familiar to one conversant in the art. In some embodiments, the publish and subscribe lists can be separated into two lists, rather than being combined into a single list as described herein.
In step 804, data items identified in step 802 are obtained from the pool of data 102 and table items identified in step 802 are obtained from the tables 104. The method then proceeds to decision step 806.
In step 806, the method 800 determines whether all items have been obtained, which are needed for execution of a particular module 105. If not, the method proceeds to step 808, wherein for each input item, the method 800 adds zero or more subscription alerts for the input item to the publish/subscribe list 108. Additionally, in some embodiments, the method 800 can also add zero or more warnings for the input items to the warnings table. Then, the method 800 proceeds to the decision step 812, where the method determines whether items obtained in step 804 are sufficient for the module(s) 105 and specifically the core to execute. If not, then the method 800 terminates.
If the method 800 determines that there is sufficient number of input items needed by module 105 to execute, the method 800 then proceeds to step 810, where module's core 704 executes based on the obtained input items.
If, in step 806, all items were obtained then the method 800 proceeds to step 810, wherein the module's core executes based on the obtained input items. The processing then proceeds to the decision step 814.
In step 814, the method 800 checks whether the core of the module 105 has generated derived data items. If so, then the processing proceeds to step 820. In step 820, each derived data item is added to the pool of data 102. Additionally, for each derived data item, an alert may be added to the publish/subscribe list 108 of the system 100. The alert indicates to other modules that the newly derived data is now available for use by the module(s) 105. The processing then proceeds to step 816.
If the core 704 did not generate derived data items (step 814), then the method proceeds to step 816, where the method 800 determines whether the module's core 704 generated new table items 602.
If, in step 816, the method 800 determines that the new table items were generated by the module's core 704, then the processing proceeds to step 818. In step 818, each new table item 602 is added to the respective table 103 (for example, recommendations table, data requests table, etc.). In some embodiments, an alert is also added to the publish/subscribe list 108. Such alert indicates that newly added item to the table(s) 103 is now available for use by the module(s) 105. The processing then proceeds to the decision step 822.
If, in step 816, it is determined that the module's core 704 did not generate any new table items 602, the processing proceeds to the decision step 822. In step 822, the method 800 determines whether or not the module's core generated triggers. If not, then the method 800 terminates.
If, in step 822, it is determined that the method 800 generated triggers, then the method proceeds to step 824. In step 824, for each newly-created trigger, its target module (e.g., calculation of osmolal gap (see
Referring to
As stated above, the modules 105 can be configured to “subscribe” to the publish/subscribe list 108. This means that the modules 105 can be alerted or executed, when particular data become available or when certain conditions become satisfied. By requesting information from the list 108, i.e., based on the “subscription” alert(s) and/or “publication” alert(s), the modules 105 request and have such information provided to them by other modules 105, data pool, table items, or any other sources. By adding items to the list 108 (i.e., publication and/or subscription alert(s)), the modules 105 are configured to add an entry and/or pointer to the list 108 that indicates the location and/or availability of information or data that is either requested or provided by modules 105 as a result of execution. The requested information may be obtained by a requesting module 105 by accessing the entry on the list 108 and communicating with the source of that information. The entries on the list 108 can also serve to notify modules 105 that have requested specific information/data that such information/data has become available and can be readily accessed. The list 108 can also provide information about events that can trigger the execution of particular modules. Examples of such triggering events include the determination of specific findings or the execution of specific modules. Some examples of triggering events are discussed below. The information in the list 108 may include data items, table items, or information about subscribing (information-requesting) and/or publishing (information-posting) modules 105. The list may also include alerts, flag(s), and/or any other information.
The data in each entry 902 is configured to include a name or an identifier 904 of a data item or a table item that is desired by the subscribing module 105 as well as a name or an identifier 906 of the subscribing module 105. As such, each entry 902 can be configured to include identifiers with which other modules 105 can locate necessary requested information. In some embodiments, the entry 902 can also be configured to include flag(s) and/or additional information in the structure 908.
The data in each entry 1002 is configured to include a name or identifier 1004 of a module 105 that is to be triggered (or which core is executed). As stated above, such triggering can be immediate or postponed. In some embodiments, the entry 1002 can also include flags, alerts or other information 1006 that can be passed to specifically selected modules 105 during their execution. Further, the entry 1002 can include information about conditions 1008 for triggering execution of a module and/or generating a trigger. As stated above, when a module 105 is triggered, specific information may be provided to the module pursuant to the module's execution. Similarly, for a module to generate a trigger, e.g., a request for a particular information, the module can determine that certain information required for its execution is missing and must be provided, thereby causing it to generate a trigger.
Referring back to
In step 1104, the collator 112 is configured to perform final processing (“post-processing”) on the information in the tables 104, and then present the results of the post-processing to the user (e.g., patient, medical professional, or any other authorized individual) and/or to another automated system. Such post-processing may include formatting, elimination of duplicates, language localization, and/or a variety of other functions. As can be understood by one skilled in the art, various methods of presenting information to users/automated systems are possible. Such results can be displayed in a spreadsheet, presentation, shown on a computer screen, transmitted electronically, etc.
In step 1202, the method 1200 populates the pool of data 102 with a raw clinical data 120. This means that the raw clinical data 120 is configured to serve as an input to the system 100 and, in particular, to the pool of data 102.
Then, in step 1204, a trigger is added to the trigger queue 108, where the trigger corresponds to at least one module 105 in the collection of modules 104. This means that the trigger can be configured to identify at least one module 105 that is to be executed either immediately or at a later stage. As can be understood by one skilled in the art, more than one module 105 can correspond to the trigger placed in the trigger queue 108.
In step 1206, a specific entry in the trigger queue 108 is selected. This means that a particular module 105, corresponding to the selected entry, will be executed. The entry in the trigger queue 108 is removed and the module 105 that is identified in the entry is executed, as shown in step 1208.
The method 1200 then determines whether the trigger queue 108 is empty, i.e., whether all trigger entries have been selected and corresponding modules 105 have been executed. (See step 1210). If not, then the method 1200 proceeds back to step 1206 and repeats the procedure of selecting an entry from the trigger queue 108. Once the trigger queue 108 is empty, the method 1200 proceeds to step 1212, where the collator 112 is executed and the results are provided to the user.
The following discussion of execution of the modules 105 of the present invention is provided for illustrative, exemplary, and non-limiting purposes. This discussion is further provided to aid one skilled in the art in a better understanding of the present invention.
As shown in
Although particular embodiments have been disclosed herein in detail, this has been done by way of example for purposes of illustration only, and is not intended to be limiting with respect to the scope of the appended claims, which follow. In particular, it is contemplated that various substitutions, alterations, and modifications may be made without departing from the spirit and scope of the invention as defined by the claims. Other aspects, advantages, and modifications are considered to be within the scope of the following claims. The claims presented are representative of the inventions disclosed herein. Other, unclaimed inventions are also contemplated. The applicant reserves the right to pursue such inventions in later claims.
