WO2008115882A1

WO2008115882A1 - Block verification of medical tests

Info

Publication number: WO2008115882A1
Application number: PCT/US2008/057258
Authority: WO
Inventors: Mary O'donnell; Jon White; Douglas Davidson
Original assignee: Beckman Coulter, Inc.
Priority date: 2007-03-16
Filing date: 2008-03-17
Publication date: 2008-09-25
Also published as: WO2008115882B1

Abstract

The efficient and accurate auto-validation of results from medical diagnostic tests ordered on a biological sample are provided. Test results are received once an instrument completes that test. Upon receiving a test result, a computer system analyzes the received test results to determine if that test is initially valid. Once a test is known to be initially invalid, the computer system contains validation rules that know if the final validity of a first test is dependent on the results of a different test. Accordingly, the initial validation of only some of the tests may need to be performed for the validation rules to confidently validate the first test. Thus, the first test can advantageously be released for diagnosis of the patient before all of the ordered tests are completed.

Description

BLOCK VERIFICATION OF MEDICAL TESTS

CLAIM OR PRIORITY

[0001] This application claims priority to U.S. Provisional Patent Application No. 60/895,315 " Block Verification of Medical Tests" by O'Donnell et al. (attorney docket number 021594-001300US), filed on March 16, 2007, the disclosure of which is incorporated by reference in its entirety.

BACKGROUND

[0002] The present invention relates generally to the analysis of medical diagnostic tests as might be performed in the course of treatment of a patient at a hospital, and more specifically to the efficient auto-validation of these results by a computer system.

[0003] In the course of patient care, medical tests are run to determine possible ailments of a patient. These tests may be of many types, including chemistry/immunochemistry type tests that test blood, saliva, urine or other probes of the patient. These different tests may involve a multitude of different diagnostic machinery to perform each test. The organization and timely analysis of such results is crucial to timely and effective patient care. An organization and timely analysis of the test result is performed by a Laboratory Information System (LIS) and/or by a separate computer system, which may communicate with the LIS.

[0004] Many of these diagnostic tests are typically ordered at the same time. Also, these tests typically use a single sample. The use of single sample is partly due to hospital initiatives to reduce the total amount of blood drawn from a patient and due to the use of single platform instruments (or automation connected instruments) capable of performing many tests.

[0005] When many tests use a same sample, the risk of obtaining inaccurate (invalid) results from a contaminated sample increases since all of the tests use the sample. Hospital initiatives to reduce patient contact, resulting in personnel other than phlebotomist drawing the blood, have caused more contaminated samples. In a contaminated sample, some tests may be invalid while other tests are valid.

[0006] The increase in contamination of samples has made laboratory technicians extra sensitive to releasing results, which may be inaccurate. In particular, since the introduction of the tests have been completed. Such conduct ensures that no contamination of the sample has led to inaccurate results.

[0007] However, such conduct can cause certain test results to be released slower than those tests previously had been released. For example, the BMP test which has typically been a very short test can now take a long time to be reported out. This problem is highlighted when some of the test results may be completed fast while other tests are slower. The test results that are completed fast are still linked to the slowest test ordered. Patient care can thus suffer since test results are not being made available in a timely fashion.

[0008] It is therefore desirable for methods and systems to validate test results and allow releasing of accurate results in a timely fashion.

BRIEF SUMMARY

[0009] Embodiments of present invention provide systems and methods for efficiently and accurately auto-validating results from medical diagnostic tests. For example, test results are received once an instrument completes that test. Upon receiving a test result, a computer system analyzes the received test results to determine if that test is initially valid. The initial validation can be done in an expedited manner. Once a test is known to be initially valid, the computer system contains validation rules that know if the final validity of a first test is dependent on the results of a different test. A test is required if the first test is dependent on that test.

[0010] Accordingly, the initial validation of only some of the tests may need to be performed for the validation rules to confidently validate the first test. Thus, the first test can advantageously be released for diagnosis of the patient before all of the tests are completed. In one aspect, a deadlock from two tests being interdependent can be prevented since an initial validity is used to determine a final validity.

[0011] According to one exemplary embodiment, a method for auto-validating medical diagnostic tests using a computer system is provided. The tests are performed on a biological sample by one or more instruments. The computer system receives a first test result and one or more second test results from the instruments. The computer system (e.g. running a parameter rule) determines whether each one of the first test results and the second test results satisfy one or more initial validation criteria. A test result is initially invalid when that test result does not satisfy the initial validation criteria. The computer system (e.g. running a test result. The first test is invalidated when at least one of the required second test result is initially invalid.

[0012] According to another exemplary embodiment, requested tests are grouped into blocks containing tests that take a similar amount of time for results. Also, an invalid result of a test in one block causes the other tests to be invalid in that block. This block validation (verification) advantageously allows a block to be released quickly, for example, when all of the tests of that block are completed. Note that a block may also be dependent on another block and/or the initial validity of particular tests. In some embodiments, block verification uses counters to monitor the number of tests ordered and resulted. Reverse validation logic and auto comments can mark results as invalid.

[0013] Other embodiments of the invention are directed to systems, apparatus, and computer readable media associated with methods described herein.

[0014] As used herein, the term "biological sample" refers to any blood, urine, fecal, or other biological material obtained from an organism (e.g. a human). For example, a blood sample is obtained in a time period and placed into a single container. As used herein, the term "a rule" is any logic in hardware or software that is used to perform an action on a computer system. The action may be based, for example, on criteria or a condition.

[0015] A better understanding of the nature and advantages of the present invention may be gained with reference to the following detailed description and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIG. 1 illustrates a system for efficiently producing validated results of medical diagnostic tests according to an embodiment of the present invention.

[0017] FIG. 2 is a flowchart illustrating a method 200 for auto-validating medical diagnostic tests using a computer system according to an embodiment of the present invention.

[0018] FIG. 3 illustrates an organization of a set of tests into blocks according to an embodiment of the present invention.

[0019] FIG. 4 is a flowchart illustrating a method for providing validated results in an efficient manner according to an embodiment of the present invention. embodiment of the present invention.

[0021] FIG. 6A illustrates a screen snapshot of an interface for defining an initialization rule for a download counter according to an embodiment of the present invention.

[0022] FIG. 6B illustrates a screen snapshot of an interface for defining an incrementing rule for a download counter according to an embodiment of the present invention.

[0023] FIG.6C illustrates a screen snapshot of an interface for defining a incrementing rule for a result counter according to an embodiment of the present invention.

[0024] FIG. 7 is a flowchart of a method illustrating an initial analysis of the set of tests that are ordered according to an embodiment of the present invention.

[0025] FIG. 8A is a screen shot of a download rule for creating download and result counters when one of the tests of a block are encountered according to an embodiment of the present invention.

[0026] FIG. 8B is a screen shot of a list of download rules according to an embodiment of the present invention.

[0027] FIG. 9 is a flowchart illustrating a method for analyzing an upload of test results according to an embodiment of the present invention.

[0028] FIG. 1OA is a screen snapshot of a rule for incrementing the download counter of a particular block according to an embodiment of the present invention.

[0029] FIG. 1OB is a screen snapshot of a rule for incrementing the result counter of a particular block according to an embodiment of the present invention.

[0030] FIG. 1OC is a screen snapshot of a validation rule for a test result according to an embodiment of the present invention.

[0031] FIG. 11 is a flowchart illustrating a method of validating test results according to an embodiment of the present invention.

[0032] FIG. 12A is a screen snapshot of an upload rule according to an embodiment of the present invention.

[0033] FIG. 12B is a screen snapshot for displaying the results of a set of test according to an embodiment of the present invention. embodiment of the present invention.

[0035] FIG. 13 shows a block diagram of components of a computer system according to an embodiment of the present invention.

DETAILED DESCRIPTION

[0036] Embodiments of present invention provide systems and methods for efficiently releasing accurate results from medical diagnostic test. The inventors have recognized that multiple tests are being performed from a single sample; that many of the samples may be contaminated, thus providing inaccurate results; and that lab technicians typically hold results until all of the tests are done so that inaccurate results are not released, but which causes a slowdown in the release of some tests. Accordingly, embodiments provide validated results in a more expedited fashion so that certain tests can be released and used for diagnosis faster.

[0037] FIG.1 illustrates a system 100 for efficiently producing validated results of medical diagnostic tests according to an embodiment of the present invention. Such a system may be a Library Information System (LIS), a middleware computer system, which communicates with the LIS, or a standalone computer system. The term "computer system" includes any of these systems.

[0038] In one embodiment, the system 100 includes one or more computers 150 and may also include inputs 160 and outputs 170 for the computers. The inputs 160 and outputs 170 may be part of another system that is coupled to the system 100 through an interface. The system 100 may also include one or more instruments (e.g. 110-130) and interfaces for communicating between the computers and the instruments.

[0039] By way of example, system 100 is used to analyze a biological sample 160 (e.g. a blood sample) of a patient, as may occur at a hospital. As is typical these days, more than one test is usually performed on the sample. These multiple tests may be part of an annual (or other time period) visit in order to check of possible conditions. The multiple tests may also be needed in order to investigate different causes of symptoms that a patient is feeling. In system 100, the instruments 110-130 perform diagnostic tests on the sample 140. Such diagnostic tests can include a measure of sodium (Na) in a blood sample and a measure of the Thyroid-stimulating hormone (TSH) in a blood sample. sodium 110, potassium 120, or Thyroid-stimulating hormone (TSH) 130, as shown in FIG. 1. In another embodiment, one or more instruments may also be able to provide results of many different tests. The DXC800 made by Beckman Coulter is an example of an instrument that can provide multiple results.

[0041] For treatment of the patient, a doctor, nurse, technician, or other person requests a list or set of tests. These tests may be entered into a computer system 150 through input 160, such as a keyboard CD, DVD, stylus, or another suitable means. The computer system 150 then prepares a download file of the requested tests to be performed by any number of instruments. The computer 150 sends instructions to the instruments to perform the requested tests. By of example, Fig. 1 shows the instructions being sent from the computer to the instrument A I lO. Similar instructions would also be sent to other instruments needed for the current list of tests. The instructions may also be entered locally at each instrument, e.g., by hand.

[0042] After an instrument has performed a test, a result is sent to the computer 150. In an embodiment where an instrument performs multiple tests, the tests may be sent to the computer 150 when each test is finished. Different instruments may send their respective tests results at different times, for example, because the different tests take different time periods too complete.

[0043] The computer 150 then analyzes the test results. Part of the analysis is an auto-validation step (also termed a verification), which determines whether or not a test result is accurate (valid). If a test result is not accurate, it should not be relied upon for diagnosis, as such an error can cause a misdiagnosis that could result in harm to the patient. Embodiments of the invention provide efficient and flexible methods and system that perform the auto-validation.

[0044] After the analysis is completed, the computer 150 can then upload test results and the validation results to an output 170, such as a display, memory medium, or other device for conveying or storing data. Although, the output 170 is shown separate from the computer 150, the output 170 may be part of the computer 150, as may be input 160.

[0045] FIG. 2 is a flowchart illustrating a method 200 for auto-validating medical diagnostic tests using a computer system according to an embodiment of the present instruments (e.g. 110-130).

[0046] In step 210, an input of the computer system (e.g. system 100) receives a request for performing a plurality of tests on the biological sample. The request may be received through a network interface or any input device described herein. In one embodiment, a technician places the biological sample in a position so that the instruments may draw a portion of the sample for the testing. In another embodiment, a technician draws different portions of the sample and places each of the portions into a position to be used by the respective instruments. These placements may be done before or after the request for the tests is made. Alternatively, the requests may be made to each instrument individually.

[0047] In step 220, the computer system sends instructions to one or more of the instruments to perform the respective tests. Each test uses at least a portion of the biological sample. The instruction may be a simple start command. The instruction may also include operational specifications to be used by the instrument in performing the test. Alternatively, the instructions may be entered locally at each instrument.

[0048] In step 230, the computer system receives a first test result and one or more second test results from at least a portion (e.g. at least one) of the instruments. The computer system may receive the test results through a single port or through multiple ports. Note that not all of the test results may be received at this point. In other words, the test results may be received in multiple batches, each batch being received at different times. The computer system may also poll the instruments to see if a particular test is done.

[0049] In one embodiment, the computer system has the port open and receives the test result. An identifier of which test the result corresponds may also be received in the test result or encapsulating message. Which sample that test result corresponds may also be identified. The test result includes a value associated with the test. For example, the test result may be a particular score for the TSH. If a test returns more than one value, then each value may be viewed as a different test. Different tests may use a same portion of the sample. A test may also be a combination of other tests. For example, a test may combine multiple test results to produce a new test result. A formula may be used that has the test results as inputs and that outputs the new test result.

[0050] In step 240, a parameter rule running on a processor of the computer system determines whether each one of the first test results and the second test results satisfy one or result value is within a specified range; and whether the value differs by too much from a corresponding result value of a previous test using a different sample. Note that the specified range is not what values are healthy, but is a range of what values would or could occur in a patient, even though those values show an unhealthy value.

[0051] In one embodiment, the initial validation criteria only pertain to a value of the test result being evaluated for initial validity. In another embodiment, the initial validation criteria may pertain to a result of an accuracy test. For example, a hemolysis test determines whether the red blood cells have broken open and released hemoglobin into the surrounding fluid. If hemolysis occurs then the results of other tests may be inaccurate and thus invalid. Such an accuracy test may also provide diagnosable results. In one aspect, an accuracy test is not dependent on another test to determine its validity, but its result may determine the initial validity of other tests

[0052] In step 250, each one of the first and second test results may be respectively marked as either initially valid or invalid based on whether or not that test result satisfies a respective initial validation criteria. In one embodiment, the marking is done by adding a comment of invalidity to the test result. In another embodiment, a binary-field may be used where one value marks a valid test result and the other marks a non-valid test result.

[0053] In step 260, a validation rule (also termed an upload rule) running on the computer system identifies at least a portion (e.g. at least one) of the second test results as being required to determine a final validity of the first test result. The requirement is because an invalid result of one test may cause or signify that another test result is invalid. In this embodiment, the validity of the first test result is dependent on the initial validity of the required second test results. In other words, the first test result is not valid if one of the required second test results is also not initially valid. Note that other test results besides those received as the second test results may be required for the first test result. These other required test results can then be identified later. The validation rules may be written so that test results that are long to perform are not required for tests that are short to perform.

[0054] In one aspect, the required second test results are known beforehand. Thus, a validation rule may be written that provides a list of the required test results that are to be checked for a given test result. For example, a Na test may be required to be initially valid in order for a K test to be valid. second test result is marked as initially invalid. Each of the second test results that are required for the first test result are checked. In one aspect, only after all of the required second test results are identified as being initially valid and the first test is initially valid, then the first test result is found to be valid. Note that the final validity could be dependent on other conditions not mentioned herein. The validation result for the first test may then be output, written to memory, or other steps described herein. The above method may be repeated for each test result.

[0056] This dependency of validity could normally cause a deadlock when two tests are interdependent. This deadlock may be solved by not providing the dependency in the auto- validation rules and allow a technician to determine the final validation. However, the human validation is labor intensive and can result in all of the tests being finally validated only after all of the tests are done. This slowdown prevents a doctor from viewing faster test earlier, which produces unwanted delay and causes inefficiencies. In this embodiment, since the final validity is dependent on initial validity, which occurs at an earlier stage, a deadlock does not occur.

[0057] After the output, the validation result can be reported out (released) to the doctor or other care provider. The test result can advantageously be provided as soon as it is validated, thus potentially saving valuable time in terms of cost and ability to provide care to the patient. Also, the first test result is known to be accurate since other required test results are first checked. The amount of human labor is also advantageously kept to a minimum without sacrificing accuracy and a deadlock is prevented.

[0058] Since not all of the test results are received at the same time, the computer system may keep track of the number of the other test results required for a particular test result to make sure that all of them are checked. Counters may be used to keep track of whether all of the required test results for a particular test result have been checked. As a default, the computer system may also assume that all required tests have been ordered, although this usually would not be the case.

[0059] In one embodiment, certain tests are all interdependent with one another. Consider the basic metabolic panel (BMP) which includes test for Glucose, Calcium, Sodium,

Potassium, CO2 (carbon dioxide, bicarbonate), Chloride, BUN (blood urea nitrogen), and Creatinine. Each of the tests of the BMP may be made be required to be initially valid for identified as blocks. A block may also be made up of only one test. Other blocks can include the Comprehensive Metabolic Panel (CMP), TSH, enzyme tests, or any other test as might be performed on a biological sample.

[0060] FIG.3 illustrates an organization of a set of tests into blocks according to an embodiment of the present invention. A biological sample 310 is requested to undergo a set 315 of 15 different tests A-M. These tests are organized into blocks based on an interdependency of an initial validity of the tests of a block on each other for determining a subsequent validation. Note that a test may belong to more than one block.

[0061] A first block 320 of five tests A-E are organized into a block 1 because an initially invalid test result of any one of tests A-E mean that the other tests are also invalid. This rule may be set or written, for example, by a worker handling the particular computer system that the test results are being run on, by a person who installs the computer system, or by a download of firmware, or may be fixed in hardware or software. Similarly, a second block 330 of two test F-G and a third block 340 of six tests are created with a rule stating that an initially invalid result for one test of a respective block means that all the tests for that block are invalid.

[0062] In one aspect, the validity of one block (e.g. block 320) can be independent (i.e. not dependent) from the validity of other blocks (e.g. blocks 330, 340). As a corollary, the tests of blocks 330, 340 are not required for block 320. In another aspect, the validity of one block (e.g. 330) can be dependent on the final validity of another block (e.g. 340). However, block 340 would not be dependent on the final validity of block 330 as that would cause a deadlock. In yet another aspect, block 340 could be dependent on the initial validity of tests in block 330 though, which would not cause a deadlock. For example, the CMP is dependent on the BMP block, but the BMP block can be validated even if some results are not valid in the CMP.

[0063] In one embodiment, all of the block are independent from each other. In another embodiment, some of the blocks are dependent on other blocks, and some blocks are independent of the other blocks. In an extreme embodiment, only one block is independent of the other blocks. This block would be the first block to be validated, and then one or more of other blocks would check the validity of that first block. As no block can be validated before all the tests of a required block, the dependencies naturally are only upstream. In other does not have to happen first). This may be taken into account when writing the rules so that the required blocks for a first block generally include tests that are performed faster that the tests of that block.

[0064] To decrease the turnaround time (TAT), it is useful to block tests together according to times that the tests might take to perform. For example, a Troponin result may not be included in a block, or alternatively be in an independent block unto itself since it is desirable to keep the Troponin TAT within 1 hour. Accordingly, in one embodiment, in order to get validated results for certain groups or blocks of tests as soon as possible, blocks are composed of tests that take similar times to finish.

[0065] Examples for the definition of which test belong to which blocks and the rules for dependencies of tests are provided below. In embodiments where blocks are not used, the dependency rules may still be used, but each test would have its own list of required tests.

[0066] FIG. 4 is a flowchart illustrating a method 400 for providing validated results in an efficient manner according to an embodiment of the present invention. The step 410 may be performed, for example, by the computer system when turned on, installed, or generally configured. The computer system performs the rest of the steps for a particular list of tests requested to be performed on a sample.

[0067] In step 410, tests, blocks, and rules may be defined as an initial step for each list of tests or done previously, for example, as a setup or firmware upgrade of the computer system. The results of a test can be defined as having certain units, given a name, or otherwise described. Herein, a test is defined to provide one result. If another test result is obtained, then it is from a different test. However, different tests may use a same portion of the sample.

[0068] The organization of the tests can be defined. This may be done, for example, with a graphical user interface for selecting a test and dropping that test into a block or via text with a list structure. Also, rules are defined for the validation of a test, e.g., the dependency rules mentioned above. These rules may be implemented, for example, as IF-THEN statements. Other rules may keep track of the progress and state of tests for a block. For example, counters and their function may be defined to keep track that all tests of a block that have been ordered also have finished with a result being received. The blocks may be defined at this point so that the blocks are dynamic and based on the actual tests requested. If the blocks are pre-defined, then not all of the tests of a pre-defined block may be requested. In one embodiment, the list of requested tests are viewed one at a time and then associated with one or more blocks. For example, a test may be grouped into a larger structure that defines a block, or a tag may be attached to the test signifying which blocks that test belongs.

[0070] The blocks may also be initialized. For example, the number of requested tests for a block may be recorded. In one embodiment, counters are incremented when a test is added to a block to keep track of the number of tests for that block. Counters may also be used in embodiments not using blocks. For example, the required tests for each test may be tracked with a counter.

[0071] In step 430, the test results from tests requested from the instruments are analyzed. In one embodiment, a counter for a block is updated when a test result is received. For example, the counter previously initialized may be decremented when a test for that block is received. Also, the initial validity of each received test result is determined.

[0072] In step 440, the received results are analyzed to determine whether or not a block is valid. In one aspect, a block may not be validated or analyzed for validation until all of the tests of that block are received. Accordingly, with multiple instruments reporting partial results, the validation rule can be applied when the system knows all ordered tests of a block have been resulted. A block may also not be validated until all of the blocks required for a particular block also have each of their tests received.

[0073] FIG. 5 illustrates a screen snapshot of an interface for defining a test according to an embodiment of the present invention. A test can have a parameter for its result and parameters for initializing and keeping track of the test (such as counters). As may be defined in step 410, sample test parameter characteristics are: (1) Parameter Name; (2) Parameter Code; (3) Unit; (4) Decimal Place; (5) Sample Nature; and (6) Sample Type.

[0074] The parameter name may be the name given to the test by normal parlance in a hospital or lab. The parameter code may be used internal to the computer system to track the test. The units and decimal place determine the accuracy and absolute value of the parameter (test result). The sample nature may be used to define the physical properties of the sample, which may signify the sample requires pretreatment before the test is performed. The sample needing a pretreatment of a calculation, e.g., obtaining the other test results. The sample type is used define whether the sample is from blood, urine, or other type of sample. This information may be used to determine the initial validity for the test since different values will result from different types of samples.

[0075] Once the tests have been given names and characteristics, the blocks may be defined. Some natural blocks could be: BMP, General Cartridge Chemistries, Urine Chemistries, Spinal Fluid Chemistries, Drugs of Abuse, Therapeutic Drugs, and Immuno Chemistries.

[0076] In one embodiment, to validate a block one or more counters may be used, e.g., to ensure that results for all of the tests of a block have been received. In one embodiment, counters are used when tests from multiple instruments are requested. For example, chemistry/immunochemistry results can be received from multiple instruments, with results being received by the computer system in multiple sends.

[0077] The rules may be defined for a particular parameter by clicking on the rules tab 510. The definition of the rules (e.g. for validation, download, and counter tracking) for the counter may also be performed at step 410, but could also be done at step 420. In practicality, typically it would be more efficient for the definitions to be performed before tests are ordered and downloaded.

[0078] FIGs. 6A-6C are screen snapshots illustrating the creation of counters and defining rules for the initializing and incrementing the counters according to embodiments of the present invention. These screenshots involve definitions that may be performed during step 410 of method 400.

[0079] FIG. 6 A illustrates a screen snapshot 610 of an interface for defining an initialization rule for a download counter of a block according to an embodiment of the present invention. In one embodiment, this initialization may be done for each test when a test is requested. In another embodiment, the initialization is done only once for a block when a test of that block is first encountered. Download test counters may also be used to keep track of the required tests for a particular test. Such download test counters may be needed when not all of the required tests for a particular test have been ordered. download counter is set to 0 and can be marked as valid. A condition could be that the initialization has already been done. The initialization may be done when any test in a block is encountered, and thus the initialization would not need to be done when another test in a block is encountered. A (NOCONDITION) value may be used for the IF statement to automatically set the counter to zero. In one aspect, each rule includes 2 sections: the condition and the action. The condition, which if true, triggers an action. In the rule of screen 610, the NOCONDITION always triggers the action requested and the counter is set to zero. In one embodiment, the counters will not increment without this rule.

[0081] FIG. 6B illustrates a screen snapshot 620 of an interface for defining an incrementing rule for a download counter of a block according to an embodiment of the present invention. If a test exists in the list (set) of tests that are ordered, then the download counter, for the block in which that test belongs, is incremented, e.g. by 1.

[0082] In one embodiment, such an incrementing rule is established as a parameter rule and is run when a first test of a block is received. In another embodiment, the incrementing rule is performed prior to receiving any tests, e.g., when the requested tests are first received.

[0083] The initialization and incrementing rules for the result counter may also be done similarly. For example, if there is no condition previously set for the result counter of a block, then the result counter can be set to 0 and can be marked as valid.

[0084] As for the incrementing rule, FIG.6C illustrates a screen snapshot 630 of an interface for defining a rule for incrementing a result counter according to an embodiment of the present invention. If a test exists (Exist(NA)) in an upload of results from one of the instruments, then the download counter, for the block in which that test belongs, is incremented, e.g. by 1. In one aspect, the counter is only incremented if the value of the result for that test is not null. For example, it may test whether some value has been placed into the result variable for that test, and not simply that the variable has been returned.

[0085] Results counters may also be used to keep track of the required tests for a particular test. Validation rules may also be defined for each test, and/or validation rules may be defined for each block. analyzes the tests, and performs some initialization steps. For example, the initialization may use the rule defined in screen 610 and also the population of a block with tests can occur.

[0087] FIG. 7 is a flowchart of a method 700 illustrating an initial analysis of the set of tests that are ordered according to an embodiment of the present invention. In step 710, a list of the tests that are ordered is received. The list may be received in any manner as mentioned herein. The list may be complete before the rest of the steps are started, or the method 700 may start when the first test is received. In step 720, a first test is evaluated. The evaluation may include identifying the test name, a code for that test, and any parameters associated with that test.

[0088] In step 730, it is determined whether the test belongs to a new block that has not been encountered before in this current download. In another embodiment, control could be focused on a particular block, and then in step 720, it would be determined whether a test belongs to that block. In this embodiment, the tests could be analyzed multiple times as more than one block would need the analysis. If the test belongs to a block in which a test has already been encountered, then control passes to back to step 720 to evaluate the next test.

[0089] If the test belongs to a block that has not been encountered before, then control is sent to step 740 where the download counter and results counter for the new clock are created and may be set to zero. The creation and initialization may be performed by calling rules that were previously defined for a test or block. In one embodiment, the download counter is added to the list of tests when the list is received.

[0090] FIG. 8A is a screen shot 800 of a download rule for creating download and result counters when one of the tests of a block are encountered according to an embodiment of the present invention. The IF line 810 determines if at least one of the tests of the download belongs to a specific block. If so, the counters are added (created) in the THEN 820. Once the counters are created, then a rule (e.g. as shown in screen 610) may be called to initialize the block counter.

[0091] In another embodiment, an initialization rule may be called so that when no condition is present then the counters are created and set to zero. In this embodiment, step 730 may not be required since if a condition is already present the counters will not be created again when a second test of block is encountered. Thus, a determination of whether a new block is encountered is not necessary. In yet another embodiment, the incrementing counter is created and set to a default value, e.g. 0, the download counter could be incremented for each test of a block (e.g. via a rule similar to screen 620).

[0092] In step 750, it is determined if more tests exist in the download. If no more tests exist, then the download analysis process completes at step 770. FIG. 8B is a screen shot of a list of download rules according to an embodiment of the present invention. In some instances, only some of the download rules 840 may pertain to the block download rules. In one embodiment, download rules are repeated until all tests in the block can be counted and all blocks have been completed.

[0093] The results of the tests are desired as soon as possible, but with a requirement of accuracy. Thus, the results of each test may be uploaded back to the computer system 150 when a particular instrument has finished the particular test. Accordingly, after one or more of the tests have been run, the results are uploaded to the computer system 150. There may be a subset of the tests since more than one instrument may finish at the same time and thus both results will be uploaded as a single group, or a single instrument may finish multiple tests at the same time.

[0094] FIG. 9 is a flowchart illustrating a method 900 for analyzing an upload of test results according to an embodiment of the present invention. In step 910, at least a partial upload of test results are received. As the method 900 is running additional results may be received as is discussed above. A purpose of method 900 is determine whether each received test result is initially valid and to count the number of received test results.

[0095] In step 920, certain or all parameter rules are run. For example, only parameter rules that correspond to tests that have been ordered may need to be run. The parameter rules perform the steps 930-970. In one embodiment, no commands of validity of a test are issued in the parameter rules except in a QC rule. The QC is a standard rule used to pass on a quality control result to the computer system. It is validated automatically based on the format of the control ID.

[0096] In step 930, it is determined whether a test of the partial upload is in a block. If the test is not in a block, then the next test is evaluated in step 940. If the current test is in a block then the process continues. Note that a single test may be defined as its own block, thus causing the rest of the steps to always be performed for each test. incremented based on the appropriate rule(s). Also, if this is the first time that a test in that block has a test result received, then the result block counter may be first set to zero and then incremented. In one embodiment, the result counter is incremented only if the value of the test result is not equal to null, or that it has some value.

[0098] In step 960, it is determined whether the test result value is initially valid or invalid. In one embodiment, a range for the test result is required to be within a particular range for the test result to be valid. For instance, a rule for a particular test might state that a sodium test must have values within a specified range in order for it to be considered valid.

[0099] In another embodiment, a delta check is used to compare the current result to a previous result. In one embodiment, if the difference is to large the result will not be validated, and a comment can be added as well. The auto comments can be chosen carefully before the validation rules are written. Example comments are: INV - Invalid; IMM - Immuno; BMP - BMP ; and IND-Indices. In one aspect, the comments indicate something in the block is bad, a critical results for example.

[0100] At this stage, the initial validity of a test result may also be checked based on another test result that has no dependencies. Such a test may be hemolysis. This test result also may not be part of any block, or a block unto itself. Once a test is found to be initially invalid for whatever reason, other evaluations of that test may be prevented from occurring, for example, to save resources.

[0101] Such prevention may be implemented with a stop rule, which prevents another rule from being run based on some type of condition. For example, a stop rule might recite If the result of the Hemolysis was >= 3 then stop. In one aspect, the rule is placed above the validation rule for any test affected by Hemolysis. In one embodiment, with block verify, the hemolysis is looked at by itself for its validity. Hemolysis may also be included in the BMP or Chemistry block. Note that hemolysis may also be treated as a test that is part of a block with other tests. Then, the hemolysis could be marked as initially invalid if its value lies outside of a range.

[0102] In one embodiment, when the result value is outside of the range, a result counter is still incremented, but a comment as to the validity of that test is associated with that test. The comment can be used later in the validation rules. Once the comment is generated, that comment may remain in the comment field for the life of that sample test id, unless the one may have to manually validate that set of results.

[0103] In other aspects, linearity range rules are evaluated. Linearity rules can result from a test not having the accuracy to recite a specific value, but only a range of values. Thus, the test result may be an alphanumeric result of "<1". For example, if the result is less than (<) the linear range, the result is an alpha numeric result, i.e. <0.1. However, some embodiments can require the test result to a purely numeric value in order to be initially validated.

[0104] In one embodiment, when such a case is encountered, the validate command may be removed from the Then statement. The rule could read If the Result < X then Modify the Result <0.1. If the test is part of a block, the test result may not be able to be initially validated in the parameter rule, thus the validate command may be removed. The stop rule can be inserted if the result is actually initially valid to stop the validation rule from running. If the result is initially invalid then the stop rule is not inserted, allowing the validation rule to run which will invalidate the block. In other words, if the modified value is initially valid then the modify rule adds a STOP command. If the modified result is not initially valid, then the result is left to be evaluated by the validation rule. Validation rules may also be deleted.

[0105] Referring back to FIG. 9, in step 970, it is determined whether any more test results appear in the partial upload. If there are more tests, then control moves to evaluating the next test result at 940. If all of the test results for this partial upload have been evaluated, then the process of evaluating this partial upload is complete. Note that this analysis of received test results is an ongoing application that can be run each time an batch (upload) of test results is received. Once at least one partial upload of the results of a set of tests has been processed, a validation process may begin. Note that certain steps may be done in any order, and particularly that steps 950 and 960 may be done simultaneously or in reversed order.

[0106] FIG. 1OA is a screen snapshot 1000 of a parameter rule for incrementing the download counter of a particular block according to an embodiment of the present invention. In line 1010, the test CHMD32, which is in the chemistry download block, is identified as being in that block, and the IF THEN statements determines if the download counter exists then increment the counter. Thus, in one embodiment, the download counter rules checks the results received from the instruments; and if this is the first result for a block, then the download counter is incremented for each test ordered. This calculation of the total number download process.

[0107] In one embodiment, as mentioned above the parameter rule of screen 1000 is run when a first test of that block (to which the counter counts for) is received. At this point the order (download) counter will count all the tests ordered but the result counter will only count the tests completed. In another embodiment, this rule is run prior to receiving a test, for example, when the requested tests are received.

[0108] FIG. 1OB is a screen snapshot of a rule for incrementing the result counter of a particular block according to an embodiment of the present invention. The result counter verifies that a result has been sent from the instrument. In one aspect, no decision is made on the quality of the result by this rule and at this particular step. These rules are run every time any result is received from the instrument s).

[0109] FIG. 1OC is a screen snapshot of a validation rule for a test result according to an embodiment of the present invention. In this embodiment, the IF line 1060 examines whether the value LD is within a particular range. This rule evaluates the LD result for the delta check and the validation range.

[0110] FIG. 11 is a flowchart illustrating a method 1100 of validating test results according to an embodiment of the present invention. Once tests are validated, which may be done in blocks, then those validated tests may be, e.g., sent to a database storing the patient's chart, displayed to a care provider, or printed out. These validated tests can then be used for diagnosis.

[0111] In step 1110, validation rules are run to determine whether tests are validated. In one embodiment, the validation rules are the final rules processed by the system before results are sent to the computer system. The following criteria may be used to evaluate and validate the tests of a block: (1) the download and result counter must have a value; (2) the value of the download counter and upload counter must be equal, and (3) the auto comment field cannot contain the group code for invalid.

[0112] FIG. 12A is a screen snapshot of a validation rule according to an embodiment of the present invention. The block Chem has an IF line 1210 that determines if the above three criteria are met. The THEN line 1220 marks all of the tests of that block as valid. runs. Each run may be validated and then a separate command may be used to validate across all runs.

[0114] In step 1115, it is determined whether the current test is within a block. If not, the next test is evaluated at step 1120. If the test is not in any block, no counters will be added and the test will be validated in the parameters rules, e.g. aTnl. In step 1125, the download and result counters of the block of the current test result are examined to determine if they are equal. If they are not equal, then the block is not valid at this point 1130 and the next test result is evaluated at step 1120. A reason for the counters not being equal is that not all of the tests have finished and their results uploaded or a test result has returned a NULL value. In step 1135, the counters are examined to see if they are not equal to zero and/or NULL. The counters may be 0 or NULL when a type of error, possibly unforeseen, has occurred.

[0115] In step 1145, it determined whether any of the tests of a block contain a comment, e.g., an invalidity comment. If one test in the block is not valid then none of the tests will be validated, thus requiring manual validation by a technologist. This review will protect the laboratory from releasing contaminated or invalid specimens while allowing validated partial results to release.

[0116] If a test of the block does have a comment, then the block is marked as invalid in a step 1130 and the results are displayed at step 1140. FIG. 12B is a screen snapshot for displaying the results of a set of test according to an embodiment of the present invention. In this manner, any comments reported by the system can be reviewed in the middle section of the result section. In one embodiment, the system maintains the color coded abnormal and critical range display so that the technologist can visually pick out the results which caused the failure.

[0117] If the block does not contain a comment, then the block is validated at step 1155. Thus, after each result is evaluated and all of the validation criteria is met, the system will apply a V, for system validation, to the validated results. The result is then uploaded 1160 with the process for that block being completed at step 1165.

[0118] In one embodiment, the computer system will allow the customers to select only validated and partial result reporting from the setup screen. FIG. 12C is a screen snapshot showing the reporting options according to an embodiment of the present invention. components or any subset of such components may be present in the computer system 150 shown in FIG. 1. The subsystems shown in FIG. 13 are interconnected via a system bus 1375. Additional subsystems such as a printer 1374, keyboard 1378, fixed disk 1379, monitor 1376, which is coupled to display adapter 1382, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller 1371, can be connected to the computer system by any number of means known in the art, such as serial port 1377. For example, serial port 1377 or external interface 1381 can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus 1375 allows the central processor 1373 to communicate with each subsystem and to control the execution of instructions from system memory 1372 or the fixed disk 1379, as well as the exchange of information between subsystems. The system memory 1372 and/or the fixed disk 1379 may embody a computer readable medium. Any of the rules, software, and logic mentioned herein may be running on one or more central processors 1373 of a computer system.

[0120] The specific details of the specific aspects of the present invention may be combined in any suitable manner without departing from the spirit and scope of embodiments of the invention. However, other embodiments of the invention may be directed to specific embodiments relating to each individual aspects, or specific combinations of these individual aspects.

[0121] It should be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software

[0122] Any of the software components or functions described in this application, may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C++ or Perl using, for example, conventional or object- oriented techniques. Computer programs incorporating features of the present invention may be encoded on various computer readable media for storage and/or transmission; suitable media include magnetic disk or tape, optical storage media such as compact disk (CD) or be any combination of such storage or transmission devices.

[0123] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer program product (e.g. a hard drive or an entire computer system), and may be present on or within different computer program products within a system or network.

[0124] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0125] A recitation of "a", "an" or "the" is intended to mean "one or more" unless specifically indicated to the contrary.

Claims

L A method for auto-validating medical diagnostic tests using a computer system running rules, wherein the tests are performed on a biological sample by one or more instruments, the method comprising: receiving, at a computer system from at least one of the instruments, a first test result and one or more second test results; determining, using a parameter rule, whether each of the one or more second test results satisfy one or more initial validation criteria, wherein a test result is initially invalid when that test result does not satisfy an initial validation criteria; identifying, using a validation rule, at least one of the one or more second test results as being required for the first test result; and invalidating the first test when a required second test result is initially invalid.

2. The method of claim 1, further comprising: prior to a third test result being received at the computer system, releasing the first test result as invalid when a required second test result is initially invalid, wherein the third test result is for a test that is performed by at least one of the instruments on the biological sample.

3. The method of claim 1, further comprising prior to receiving the test results: receiving, at an input of the computer system, a request for performing a plurality of tests on the biological sample, the plurality of tests including a first test associated with the first test result and one or more second tests associated with the one or more second test results; and sending, from the computer system, instructions to the instruments to perform the respective tests, wherein a test uses at least a portion of the biological sample.

4. The method of claim 3, further comprising: associating at least two of the requested tests with one or more predetermined test blocks, at least one test block being associated with two or more tests; and invalidating every test of a test block when a test result of at least one of the tests of that test block is initially invalid.

5. ine metnoα ot claim 4, wnerein me tests associateα witn a given test block have similar processing times.

6. The method of claim 4, wherein identifying at least one of the one or more second test results as being required includes identifying results from tests that are associated with the same test block as the first test is associated.

7. The method of claim 4, wherein the validity of the first test block is dependent on the validity of another test block.

8. The method of claim 4, wherein the validity of the first test block is dependent on the initial validity of only some of the tests from another test block.

9. The method of claim 4, further comprising: for each test block of the one or more predetermined test blocks: determining a requested number of tests associated with that test block; and tracking a number of received test results associated with that test block.

10. The method of claim 9, further comprising: determining whether the requested number of tests for a test block equals a number of received test results for that test block; and if the requested number equals the received number, proceeding with a validation rule for the tests for that test block.

11. The method of claim 9 further comprising: for each test block of the one or more predetermined test blocks: creating and initializing a download counter to track the requested number of tests associated with that test block; incrementing the download counter for each requested test of that test block; and creating and initializing a result counter to track the number of received test results associated with that test block; and corresponding block, wherein determining whether the requested number of tests for a test block equals a number of received test results for that test block includes calculating whether the download counter equals the result counter for that test block.

12. The method of claim 11 wherein the corresponding result counter is incremented only if the received test value is not NULL.

13. The method of claim 11 wherein the download counter and the result counter are checked to determine if their values are NULL or zero before proceeding with a validation rule.

14. The method of claim 1, wherein an initial validation criteria includes at least one of a specific range that a value of the test result is required to satisfy, a delta value that the test result can differ from a previous test result for the same test, and a result of an accuracy test.

15. The method of claim 1, further comprising validating the first test result when: (a) all of the required tests results for the first test result have been received; (b) all of the required test results for the first test result are initially valid; and (c) the first test result is initially valid.

16. The method of claim 1, further comprising: prior to a third test result being received at the computer system, releasing the first test result as valid when (a), (b), and (c) are satisfied, wherein the third test result is for a test that is performed by at least one of the instruments on the biological sample.

17. The method of claim 1, wherein the initial validation criteria for one test result is different from the initial validation criteria for another test result.

18. The method of claim 1, further comprising adding a comment to a test result when the test result is initially invalid.

19. A computer program product comprising a computer readable medium encoded with a plurality of instructions for controlling a computing system to perform a method for auto-validating medical diagnostic tests using a computer system running rules, method comprising: receiving, at a computer system from at least one of the instruments, a first test result and one or more second test results; determining, using a parameter rule, whether each of the one or more second test results satisfy one or more initial validation criteria, wherein a test result is initially invalid when that test result does not satisfy an initial validation criteria; identifying, using a validation rule, at least one of the one or more second test results as being required for the first test result; and invalidating the first test when a required second test result is initially invalid.

20. The computer program product of claim 19, wherein the method further comprises: prior to receiving the test results: receiving, at an input of the computer system, a request for performing a plurality of tests on the biological sample, the plurality of tests including a first test associated with the first test result and one or more second tests associated with the one or more second test results; and sending, from the computer system, instructions to the instruments to perform the respective tests, wherein a test uses at least a portion of the biological sample; associating at least two of the requested tests with one or more predetermined test blocks, at least one test block being associated with two or more tests; and invalidating every test of a test block when a test result of at least one of the tests of that test block is initially invalid.

21. A system for auto-validating medical diagnostic tests, wherein the tests are performed on a biological sample by one or more instruments, the system comprising: a computer system for receiving the test results from the instruments and analyzing test results, wherein the computer system is configured to: receive, from at least one of the instruments, a first test result and one or more second test results; second test results satisfy one or more initial validation criteria, wherein a test result is initially invalid when that test result does not satisfy an initial validation criteria; identify, using a validation rule, at least one of the one or more second test results as being required for the first test result; and invalidate the first test when a required second test result is initially invalid.

22. The system of claim 21, wherein the computer system is further configured to: prior to receiving the test results: receive, at an input of the computer system, a request for performing a plurality of tests on the biological sample, the plurality of tests including a first test associated with the first test result and one or more second tests associated with the one or more second test results; send, from the computer system, instructions to the instruments to perform the respective tests, wherein a test uses at least a portion of the biological sample; associate at least two of the requested tests with one or more predetermined test blocks, at least one test block being associated with two or more tests; and invalidate every test of a test block when a test result of at least one of the tests of that test block is initially invalid.