Patent Publication Number: US-11640852-B2

Title: System for laboratory values automated analysis and risk notification in intensive care unit

Description:
CROSS-REFERENCE TO PRIOR APPLICATIONS 
     This application is the U.S. National Phase application under 35 U.S.C. § 371 of International Application No. PCT/M2016/051494, filed on Mar. 17, 2016, which claims the benefit of U.S. Provisional Application Ser. No. 62/144,374, filed Apr. 8, 2015. These applications are hereby incorporated by reference herein, for all purposes. 
    
    
     FIELD 
     The following relates generally to the critical medical care arts, medical laboratory testing arts, and related arts. 
     BACKGROUND 
     Laboratory test results are performed on tissue samples (e.g. blood, urine, et cetera) to generate clinically useful results such as blood gas levels (PaO 2 , PaCO 2 , . . . ), a complete blood count panel (white cells, red cells, hemoglobin, hematocrit, platelets, . . . ), measurements of various electrolytes, creatinine, kinase isoenzymes, or so forth. In an ICU setting, specimens are drawn from the patient at intervals and tested, and the results are written on the patient chart. More recently, electronic data recordation and transfer has been standardized, e.g. using the HL7® ANSI-accredited exchange standard, so that such data can be automatically recorded in the patient&#39;s Electronic Health or Medical Record (EHR or EMR) and electronically distributed to the doctor, nurse, or other authorized persons or entities (in accord with HIPAA or other applicable privacy standards). 
     However, these improvements in data recordation and exchange have not necessarily translated into more effective leveraging of laboratory tests for patient monitoring/treatment, and numerous limitations remain. Physicians have a tendency to consider individual laboratory results in isolation, and may fail to recognize clinically probative patterns in diverse laboratory results, especially if the clinically probative pattern pertains to a clinical condition that is outside of a physician&#39;s area of specialization. This tendency is amplified by the discrete nature of laboratory tests: different laboratory results, even if electronically recorded and distributed, generally become available to the physician at different times due to discrete/semi-manual specimen collection and processing. A Physician attends to many patients, and laboratory tests are usually outsourced to a testing laboratory, which in some cases may not even be located in the hospital (e.g., an outside contract laboratory). Such factors may make it difficult for a physician to collate different laboratory test results into a useful pattern. Still further, if a pattern is identified which is made up of laboratory test results acquired over an extended period of time, it may be difficult to assign a meaningful date to a medical conclusion drawn from the pattern. 
     The following discloses a new and improved systems and methods that address the above referenced issues, and others. 
     SUMMARY 
     In one disclosed aspect, a computer is programmed to perform a risk level assessment method for a plurality of clinical conditions as follows. A set of laboratory test results with time stamps for a patient including at least one hematology test result and at least one arterial blood gas (ABG) test result are stored on a non-transitory storage medium. For each clinical condition, a risk level is determined for the clinical condition based on a clinical condition-specific sub-set of the stored set of laboratory test results. This determination is made conditional on the stored clinical condition-specific sub-set of laboratory test results being sufficient to determine the risk level. A time stamp is assigned to each determined risk level based on the time stamps for the laboratory test results of the clinical condition-specific sub-set of laboratory test results. A display device is caused to display the determined risk level and the assigned time stamp for each clinical condition whose determined risk level satisfies a display criterion. 
     In another disclosed aspect, a non-transitory storage medium stores instructions readable and executable by an electronic data processing device to perform a risk level assessment method for a plurality of clinical conditions. The risk level assessment method includes the following operations. For each clinical condition, it is determined whether sufficient laboratory test results are stored in a laboratory test results data structure to perform risk level assessment for the clinical condition. If sufficient laboratory test results are available, a risk level is determined for the clinical condition based on a clinical condition-specific sub-set of the set of laboratory test results, and a time stamp is assigned to the determined risk level based on the time stamps for the laboratory test results of the sub-set of laboratory test results. A display device is caused to display the determined risk levels of clinical conditions for which the risk level satisfies a display criterion and to display the assigned time stamp for each displayed risk level. 
     In another disclosed aspect, a method comprises: storing a set of laboratory test results including at least one hematology test result and at least one arterial blood gas (ABG) test result using a computer-readable non-transitory storage medium; determining a risk level for a clinical condition based on a clinical condition-specific sub-set of the set of laboratory test results; assigning a time stamp to the determined risk level based on the time stamps for the laboratory test results of the sub-set of laboratory test results; and displaying, on a display device, the determined risk level and the assigned time stamp. 
     One advantage resides in providing automated detection of clinically probative patterns in diverse laboratory test results. 
     Another advantage resides in providing automated time stamping for a clinically probative pattern of laboratory test results. 
     Another advantage resides in providing automatic identification and notification of quantitative risks of various clinical conditions based on combinations of laboratory test results. 
     Another advantage resides in providing guidance as to scheduling of laboratory tests to provide synergistic information about the patient. 
     A given embodiment may provide none, one, two, more, or all of the foregoing advantages, and/or may provide other advantages as will become apparent to one of ordinary skill in the art upon reading and understanding the present disclosure. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention may take form in various components and arrangements of components, and in various steps and arrangements of steps. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. 
         FIG.  1    diagrammatically illustrates a system for automatic identification and notification of quantitative risks of various clinical conditions based on combinations of laboratory test results. 
         FIG.  2    diagrammatically illustrates processing suitably performed by one of the clinical condition risk inference engines of the system of  FIG.  1   . 
         FIGS.  3  and  4    diagrammatically show two illustrative approaches for assigning a time stamp to an clinical condition risk assessed based on four laboratory test results respectively designated “T 1 ”, “T 2 ”, “T 3 ”, and “T 4 ”. 
         FIG.  5    diagrammatically illustrates a suitable embodiment of the risk notification component of the system of  FIG.  1   . 
     
    
    
     DETAILED DESCRIPTION 
     With reference to  FIG.  1   , a system is disclosed for automatic identification and notification of quantitative risks pertaining to various clinical conditions based on combinations of laboratory test results. The system includes three main components: a data collector  8 , a data analyzer  10 , and a risk notification component  12 . These components  8 ,  10 ,  12  are suitably implemented on an illustrative server computer  14  or other electronic data processing device (e.g. desktop computer, electronic patient monitor device, or so forth; or various aggregations of devices, e.g. a cloud computing network, server cluster, or so forth). It will also be appreciated that the disclosed approaches for automatic identification and notification of quantitative risks pertaining to various clinical conditions based on combinations of laboratory test results may also be embodied as a non-transitory storage medium storing instructions readable and executable by the computer  14  or by another electronic data processing device to perform the disclosed methods. The non-transitory storage medium may, by way of illustration, include: a hard disk drive or other magnetic storage medium; an optical disk or other optical storage medium; a flash memory or other electronic storage medium; various combinations thereof; and so forth. 
     The data collector  8  is operatively connected with various data sources, such as various medical laboratories, diagrammatically indicated in  FIG.  1    by an illustrative hematology laboratory  20 , an illustrative histopathology laboratory  22 , and an illustrative arterial blood gas (ABG) laboratory  24 . The hematology laboratory  20  provides laboratory test results such as a complete blood count panel (white cells, red cells, hemoglobin, hematocrit, platelets, . . . ) or portions thereof as requested by the patient&#39;s physician, and blood serum values such as measurements of various electrolytes, creatinine, kinase isoenzymes, albumin, bilirubin, ammonia, alkaline phosphatase, lactic acid, glucose, cholesterol, iron, or so forth, in the blood. The histopathology laboratory  22  performs microscopic inspection of extracted tissue samples as requested by the physician. The ABG laboratory  24  measures various blood gas levels (PaO 2 , PaCO 2 , pH, HCO 3 , . . . ) in an arterial blood sample. It will be appreciated that fewer, additional, and/or other laboratories may provide laboratory test results to the data collector  8 , and moreover the illustrative laboratories may be variously combined, e.g. the hematology laboratory may also perform ABG analysis. The data collector  8  is also operatively connected with an Electronic Health (or Medical) Record (EHR/EMR)  26  or other patient data source in order to obtain patient data such as demographic data (age, sex, ethnicity, et cetera), chronic health conditions such as a heart condition or Chronic Obstructive Pulmonary Disorder (COPD), or other medical history information (e.g. information on any recent surgery), patient habits (smoker or non-smoker, et cetera), current medications, or so forth. Laboratory test result data and patient data may be delivered to the data collector  8  automatically, for example via an HL7® ANSI-accredited exchange standard-compliant electronic network for patient data recordation and transfer provided by the hospital or other medical setting, and optionally also connected with contract laboratories if such are employed by the hospital. Additionally or alternatively, some or all laboratory test results and/or some or all patient data may be entered manually using an electronic data entry terminal or computer  28 . 
     Each laboratory test result collected by the data collector  8  is time stamped appropriately, usually using a time stamp assigned to the test result by the laboratory  20 ,  22 ,  24  that performed the laboratory test. For example, the time stamp for a laboratory test result obtained from an extracted blood or tissue sample may be appropriately set to the date/time that the tested blood or tissue sample was extracted. The term “time stamp” as used herein includes any chosen temporal designation, e.g. a time stamp may specify the calendar date of the test result, or may specify more particularly (i.e. with greater temporal resolution) both a calendar date and time-of-day of the test result (with various optional specifications, e.g. with or without the seconds, and/or with a time zone offset, or so forth). Patient data may also be assigned a time stamp as appropriate. 
     The data analyzer  10  performs analysis, such as probative pattern detection, on the laboratory test results in light of any relevant patient data. To this end, the data analyzer maintains a patient profile  30  (also referred to herein as a “P1-profile”) which is a table or other data structure containing patient data (e.g. demographic and clinical information such as age, gender, medical history, current diagnosis, medications, and so forth). The data analyzer also maintains a patient laboratory test results table  32  (also referred to herein as a “P2-profile”) which is a table or other data structure containing laboratory tests results, optionally organized by test class or other organizational criteria. The patient profile  30  and the patient laboratory test results table or other data structure  32  are suitably stored using a non-transitory storage medium  34  which may, by way of illustration, include: a hard disk drive or other magnetic storage medium; an optical disk or other optical storage medium; a flash memory or other electronic storage medium; various combinations thereof; and so forth. 
     The data analyzer  10  may optionally perform certain “per-test” analyses (not illustrated). For example, the current value of each laboratory test result may be compared against a normal range for that test result, and a preliminary risk level assigned for a clinical condition based on P1-profile data. For example, PaO 2  may be compared against a normal range for PaO 2  where the “normal range” depends on various patient data such as age and whether the patient has COPD. Along with current time values the test results table  32  may record dynamic information such as the change of each lab test result when compared with the previous test run, and positive and negative trends identified for a given time-window. 
     The data analyzer also processes the laboratory test results stored in the table  32  to detect patterns of laboratory test results that may be probative of a clinical condition such as a deteriorating organ or organ system or the onset of a serious medical condition such as sepsis, hypoxia, or so forth. To this end, the data analyzer  10  implements various clinical condition risk inference engines  40 , designated in illustrative  FIG.  1    as clinical condition #1 risk inference engine  40   1 , clinical condition #2 risk inference engine  40   2 , and so on through clinical condition #N risk inference engine  40   N . (The number of different clinical condition risk inference engines is designated here as “N” without loss of generality). Each risk inference engine  40  may be implemented as an empirically trained classifier, a codified inference rule (or set of rules), a mathematical model of organ function, or other inference algorithm which is applied to a set of patient laboratory test results (which set is a sub-set of the test results contained in the table  32 ) along with any relevant patient data from the table  30  assign a risk level for the corresponding clinical condition. Each computed risk level is assigned a corresponding time stamp  42  based on the time stamps of the laboratory test results of the set of test results upon which the risk inference engine operates. Thus, the risk level for clinical condition #1 has a corresponding time stamp  42   1 , the risk level for clinical condition #2 has a corresponding time stamp  42   2 , and so on through the risk level for clinical condition #N which has corresponding time stamp  42   N . 
     In one approach, a clinical condition risk inference engine  40  is constructed empirically as follows. Various sub-groups of laboratory values and their trends (e.g., {Albumin, Bicarbonate, pH, Lactic acid, Hg}, {Creatinine, BUN, BUN/Creatinine}, {Glucose, WBC}) are identified as probable indicators of the clinical condition based on information drawn from the medical literature and/or identified in consultation with medical experts. These sub-groups of medical test results may optionally be combined with other possibly relevant patient data, again based on the medical literature and/or expert knowledge. The resulting set of parameters form a set of features on which to train the clinical condition risk inference engine, which may for example be implemented as a machine learned linear regression model, logistic regression model, neural network, or other model or parameterized inference algorithm. Training data are drawn from labeled past patient examples (both positive examples of patients labeled as having had the clinical condition whose risk is to be inferred, and negative examples labeled as not having had the condition). An ensemble learning algorithm or other machine learning technique appropriate for learning the weights or other parameters of the model or inference algorithm is then applied to train the clinical condition risk inference engine  40  to generate a risk score given an input data set of values for the parameters such that the clinical condition inference engine  40  effectively distinguishes between the positive and negative examples of the training set. The summed or otherwise aggregated error between the labels of the training data and the inference engine output for the training data is minimized during the training. The machine learning may optionally also include a feature reduction component (incorporated into the learning or performed prior to the learning) to identify and discard features (i.e. laboratory tests) that are empirically found to have minimal impact on the machine learned clinical condition risk inference, so as to provide a smaller probative set of test results for the risk assessment performed by the clinical condition risk inference engine  40 . 
     An advantage of the foregoing machine learning approach is that it provides a discovery mechanism for identifying and refining probative patterns of laboratory test results for use in assessing risk of (onset of) a particular clinical condition. On the other hand, if a pattern of laboratory test results is known to be indicative of (onset of) a particular clinical condition a priori, for example because a set of rules has been published in the medical literature via which a physician may infer the clinical condition is present or incipient, then this a priori-known set of rules can be codified to construct the inference engine. As yet another example, an inference engine can be constructed using a mathematical model of organ function that is suitably characterized by results of a set of laboratory tests. Various hybrids are also contemplated, e.g. a semi-empirical model of the organ function having weights or other parameters that are optimized by machine learning. 
     The output of each clinical condition risk inference engine  40   1 , . . . ,  40   N  is a risk level for the respective clinical condition #1, . . . , #N. These risk levels are input from the data analyzer  10  to the risk notification component  12 , which outputs information pertaining to the risks to a physician, nurse, or other medical personnel via a suitable user interfacing device such as a patient monitor  44 , a wireless mobile device  46  such as a cellular telephone (cell phone), medical pager, or the like running an application program (“app”) interfacing with the computer  14  (and more particularly with the risk notification component  12 ) via a 3G, WiFi, or other wireless network, a nurses station computer, or so forth. In some illustrative embodiments described herein, the risk notification component  12  performs ranking, filtering, or other processing of the risk levels so that only the most critical risk(s) (if any) are reported to medical personnel. Optionally, the risk notification component  12  logs all risk values in patient record for the patient being monitored in the EHR/EMR database  26 . 
     In applying any of the clinical condition risk inference engines  40   1 , . . . ,  40   N  two difficulties may arise. First, some of the input patient data for assessing risk of the clinical condition may be missing, either because a laboratory test was not (or has not yet been) performed or because the available test result is “stale”, i.e. too old to be relied upon. Second, it is not readily apparent what time stamp  42  should be assigned to the inferred risk level when the various input laboratory test results have different individual time stamps. This latter difficulty could lead to misinterpretation of the risk level if, for example, the physician assumes the risk level is current as of the most recent laboratory test ordered by the physician to assess the clinical condition when in fact the clinical condition risk inference engine relied upon a set of input data that also includes laboratory test results that are significantly older than this last-obtained test result. 
     With reference to  FIG.  2   , an illustrative inference process  50  suitably performed by the data analyzer  10  in applying one of the clinical condition risk inference engines  40  is described. In  FIG.  2   , reference is made to a clinical condition #k, where without loss of generality #k denotes one of the clinical conditions #1, . . . , #N and is assessed using the clinical condition risk inference engine  40  k which is one of the clinical condition risk inference engines  40  of  FIG.  1   . In an operation  52 , an input set of patient laboratory test results for assessing clinical condition #k is acquired from the patient laboratory test results table  32 . This set of laboratory test results is a sub-set of the complete table of test results  32 , and was defined during the training of the clinical condition risk inference engine  40  k (or, alternatively was defined by the set of codified literature rules, mathematical organ model, or other source from which the clinical condition risk inference engine  40  k was generated). In an operation  54 , it is determined whether the set of patient laboratory test results read from the patient laboratory test results table  32  is missing any essential laboratory test results. By “essential” it is meant that the clinical condition risk inference engine  40  k is not considered to produce a reliable result without that essential laboratory test result. Some laboratory test results, while being used by the clinical condition risk inference engine  40  k, may be considered non-essential because they have a relatively weak impact on the risk level output by the clinical condition risk inference engine  40  k—in such cases, the missing non-essential test result can be filled in with a default “typical” value for the laboratory test. In some cases, the clinical condition risk inference engine  40  k may be constructed to operate either with or without the non-essential test result (for example, by being constructed to employ a default value if the test result is unavailable, or by applying a different trained classifier that does not rely upon the non-essential test result if it is unavailable). In determining whether an essential laboratory test result is missing, the operation  54  may take into account the time stamp of the test result, so that for example a test result that is available but is too old (i.e. stale) is deemed to be missing as the stale essential test result cannot be relied upon in applying the clinical condition risk inference engine  40  k. 
     If the operation  54  determines that a laboratory test result that is essential for applying the clinical condition risk inference engine  40   k  is missing, then flow passes to an error handler  56  which takes remedial action. This remedial action, at a minimum, preferably includes providing some indication that the risk level for clinical condition #k is not available. This may be done by setting a suitable binary flag associated with clinical condition #k to indicate unavailability, and/or by setting the time stamp for the risk level for clinical condition #k to a value such as −1 so as to indicate unavailability, or so forth. The error handler  56  may optionally also provide medical personnel with a recommendation (e.g. displayed on the display device  44 ,  46 ) that the laboratory test that produces the missing laboratory test result should be performed in order to assess the risk for clinical condition #k. If the test has been performed but is stale, the displayed message may indicate the existing test result is stale and should not be relied upon. 
     With continuing reference to  FIG.  2    and with brief reference to  FIGS.  3  and  4   , if all essential laboratory test results are determined to be available in the operation  54 , then flow passes to an operation  60  in which the time stamp for the risk level associated with condition #k is determined based on the time stamps of the laboratory test results of the input set of test results retrieved in the read operation  52 . Various approaches can be used to choose the time stamp for the risk level for clinical condition #k, two of which are diagrammatically shown in respective  FIGS.  3  and  4   . The approach diagrammatically shown in  FIG.  3    assigns the risk level the time stamp of the oldest time stamp of any of the input test results. Thus, in illustrative  FIG.  3    the clinical condition risk inference engine  40   k  uses four laboratory test results designated as “T 1 ”, “T 2 ”, “T 3 ”, and “T 4 ”, which were acquired (i.e. have time stamps) in the order “T 3 ”, “T 1 ”, “T 4 ”, “T 2 ” as shown in  FIG.  3   . In the approach of  FIG.  3   , the time stamp for the risk level of clinical condition #k is then assigned the time stamp of the oldest laboratory test result, here being the time stamp for test result “T 3 ”. 
     The approach of  FIG.  3    does not take into account the time frame over which a laboratory test result may be relied upon. For example, if the physiological feature measured by a test is slowly varying, then the test result may be reliable for a significant time period after the test is performed, and similarly it is reasonable to assume that the test result is representative over comparable time period before the test was performed. By contrast, if the physiological feature measured by the test tends to fluctuate rapidly over time, then the window over which the test result is reasonably relied upon is substantially shorter. The illustrative approach of  FIG.  4    applies a time window for each test result, as diagrammatically indicated by a box-type range associated with each of “T 1 ”, “T 2 ”, “T 3 ”, “T 4 ”. Since the illustrative risk level for clinical condition #k relies upon the combination of “T 1 ”, “T 2 ”, “T 3 ”, “T 4 ”, the overlap or intersection of all four time windows for “T 1 ”, “T 2 ”, “T 3 ”, “T 4 ”, i.e. Δt=W(T 1 )∩W(T 2 )∩W(T 3 )∩W(T 4 ) where W( . . . ) is the time window and “∩” is the binary intersection operator. The time stamp for the risk level computed for clinical condition #k is then suitably set to the most recent end of overlap time interval Δt. Note that if all time windows extend to the present time, then the time stamp for the risk level could reasonably be set to the present time so as to indicate the risk level is current. On the other hand, if there is no mutual overlap between all windows W(T 1 ), W(T 2 ), W(T 3 ), and W(T 4 ) (that is, Δt=0) then the risk level cannot be reliably computed, and flow may suitably transfer to the error handler  56  to (for example) recommend ordering one or more new laboratory tests. 
     With continuing reference to  FIG.  2   , in read operation  62  any relevant patient data (i.e. patient data used by the clinical condition #k risk inference engine  40   k ) is read from the patient profile  30 . At a decision operation  64 , it is determined whether any essential patient data are missing. “Essential” patient data is defined analogously to “essential” laboratory test results—essential patient data are patient data without which a reliable risk level for clinical condition #k cannot be estimated using the clinical condition #k risk inference engine  40   k . If a missing patient datum is non-essential, then the clinical condition #k risk inference engine  40   k  can still be applied, for example by inserting a default value for the missing patient datum. If at the decision operation  64  any essential patient data are identified as missing, then the error handler  56  is invoked to take remedial action, such as requesting that the missing patient data be entered into the EHR/EMR  26  in order to be transferred to the data collector  8  (or entered directly into the data collector  8 ). 
     If at the decision  64  it is determined that all essential patient data are available (and since earlier decision  54  determined that all essential laboratory test results are available), then flow passes to the clinical condition #k risk inference engine  40   k  where the risk score is computed for clinical condition #k, with the time stamp assigned in operation  60 . Optionally, further processing  66  is performed, for example to apply a threshold or quantization to the risk score to generate the risk level as a more readily perceived risk assessment. For example, a threshold may be applied so that the final output is: “significant risk of clinical condition #k” or “no significant risk of clinical condition #k”. In another example, a quantizer is applied to the score to form the final output as one of a series of levels, such as: “red”=“high risk of clinical condition #k”, “yellow”=“moderate risk of clinical condition #k”, or “green”=“low risk of clinical condition #k”. 
     The illustrative process flow of  FIG.  2    and illustrative risk level time stamping algorithms of  FIGS.  3  and  4    are to be understood as non-limiting examples. The process flow may be variously adjusted, for example the time stamp may be assigned after computing the risk level, patient data may be read before test results, the time stamp may be set to the middle of the time interval Δt rather than its end, or as another illustrative example the time stamp for the risk level may be set to the time stamp of one particular “most critical” test result, or so forth. 
     With reference to  FIG.  5   , an illustrative embodiment of the risk notification component  12  is described. The illustrative risk notification component  12  receives as input a set of risk levels  70 . Optionally, the risk notification component  12  records these “raw” risk levels (or scores) in the EHR/EMR  26 , as diagrammatically indicated in  FIG.  5    by flow indicate  72 . These recorded raw risk levels may then be reviewed with the patient&#39;s physician at the patient&#39;s next physical examination. For purposes of providing a rapid risk assessment in a critical care unit setting (e.g. an intensive care unit, ICU, or a cardiac care unit, CCU), the risk levels are optionally adjusted by criticality weights  74 . These weights  74  may be fixed values, or may be adjusted based on patient-specific factors such as any chronic conditions  76  the patient may have (e.g. a risk of hypoxia may be enhanced by a higher weighting in the case of a patient with COPD) or any patient-specific instructions  78  provided by the patient&#39;s physician (e.g., if the patient&#39;s physician is concerned based on the physician&#39;s medical expertise about the possibility that the patient may develop sepsis, the physician may assign a higher weighting for the sepsis risk score). Risk summarization logic  80  then generates a risk assessment for the patient. For example, the risk summarization logic  80  may cause display of the top-M risk levels (where M is some integer, e.g. if M=3 then the three clinical conditions with the highest (weighted) risk level are displayed on the display device(s)  44 ,  46 ). In another example, the risk summarization logic  80  displays the risk level(s) of any clinical condition whose (weighted) risk level exceeds a reporting threshold. Use of filtering (e.g. top-M or reporting threshold) reduces the amount of information presented to medical personnel in a critical care setting by presenting only risk information for those clinical conditions for which the patient is at highest risk. 
     It will be appreciated that the system updates the risk levels on a real-time basis. In one approach, a table is provided which lists the input laboratory test results for each clinical condition risk inference engine  40   1 , . . . ,  40   N , and when a new test result comes in via the data collector  8  this table is consulted by the data analyzer  10  to identify which clinical conditions should be updated and the appropriate clinical condition risk inference engines are applied with the new test result. In some embodiments (not shown in  FIG.  5   ), the risk notification component also tracks risk level over time for a clinical condition, and reports a warning if the risk level has been rising over the last two (or more) laboratory test cycles. 
     The invention has been described with reference to the preferred embodiments. Modifications and alterations may occur to others upon reading and understanding the preceding detailed description. It is intended that the invention be construed as including all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.