CN1603834A - System and method for processing related laboratory tests and results - Google Patents

Abstract

A system and method are provided that addresses the need for an improved microbiology validation system that monitors and validates clinical culture laboratory test results as they occur throughout the testing lifecycle of a clinical culture. Techniques are provided that consider the results of earlier performed tests when entering results for later performed tests so that inconsistent or wrong test results of a patient are not inadvertently released to a physician for review.

Description

System and method for processing related laboratory tests and results

This is a non-provisional application of Provisional Application Serial No. 60/455,934 filed March 19, 2003 by D. Brumbach et al.

technical field

The present invention relates to laboratory tests and more particularly to the consistent validation of test results throughout the test life cycle of clinical cultures in microbiological testing laboratories.

Background technique

Clinical laboratories are tasked with performing tests on clinical cultures to identify organisms that may be causing infections in patients. During normal operation, the microbiology laboratory department receives various patient samples collected by physicians. The microbiologist spreads the sample flat on the medium and incubates the medium. The flat-coated samples are commonly referred to in the art as "clinical cultures". After a certain period of time, organoids are grown on clinical cultures. It is the responsibility of the microbiology technologist to identify from clinical cultures any organisms (eg, bacteria, fungus, microbacteria, parasites, viruses) that may be causing an infection in the patient and to provide information that is applicable to therapeutic possibilities to the knowledge of the technologist. any antimicrobial information on the source of infection.

As traditionally, laboratory technicians analyze clinical cultures during what is often referred to as the "assay life cycle" of clinical cultures. Throughout the "assay life cycle" of a culture, as biochemical assays are performed, technicians periodically enter individual assay results into laboratory systems. These individual test results are typically released to technicians as they occur. Results entered in later stages of the life cycle should have expected consequences based on previous results. As an example, if a test performed earlier, such as the GramStain test, is reported as many Gram Negative Rods, then a test performed later, such as the Organism ID test A knowledgeable technician should expect Gram Negative Organism as a final test result.

It is incumbent on the technician to take the results of the earlier tests into account when entering the later results so that inconsistent or erroneous results are not released to the physician for review.

The downside of this process is its unpredictability and inconsistency. Specifically, the technician's ability to distinguish expected from unanticipated results depends in part on the technician's acquired and retained knowledge, which may vary from technician to technician, on his ability to refer to diagrams, manuals, and procedures for supervisory review.

Another disadvantage of the described process is that the validation of the culture samples is performed after the cultures are finalized, ie at the end of the assay life cycle. In most cases this is too late, as any unexpected intermediate results would have already been issued to physicians for review by the time they occurred. Instead verification should preferably be performed throughout the assay life cycle of the culture by continuously monitoring the assay results and comparing them with other culture results as they arise, and not at the final stage as is conventional.

Another disadvantage is that there is no messaging capability to inform the technician what additional steps to take when unexpected results occur.

Another disadvantage is that the quantity is not taken into account during verification, thus making the verification imprecise.

There is no existing system for processing information related to laboratory tests and results that overcomes the above mentioned disadvantages.

Contents of the invention

The present invention highlights the need for improved microbiological validation systems. During the "assay life cycle" of a culture in a clinical microbiology laboratory, several results are entered and issued over hours, days or weeks. The present invention improves on this process by providing a technique that takes into account the results of tests performed earlier when entering the results of tests performed later so that inconsistent or erroneous results are not issued to Technician for review.

According to one aspect of the present invention, a method for processing related laboratory tests and results includes: an interface processor that receives user-input data. The verification processor compares the laboratory test result to the expected test result and identifies a failure condition where the laboratory test result fails to match the expected test result. The result processor generates a warning message to the user, thereby notifying the user of the failure condition.

Description of drawings

Referring now to the drawings, wherein like reference numerals designate corresponding parts throughout, wherein:

Figure 1 illustrates an embodiment of a microbiological verification system for processing information about laboratory tests/results;

Figure 2 is an exemplary display image window illustrating a micro-verification user-defined template (UDT) for building a micro-verification definition;

Figure 3 is an exemplary list of those micro-authentication parameters included in the upper part of the UDT of Figure 2; and

4-10 are computer display image windows of various user interface screens in accordance with aspects of the present invention.

Detailed ways

The system of the present invention is suitable for use in pharmaceutical and radiology information systems and enables users to define simple or complex result verification procedures and messages. The system has particular application in hospital laboratory settings, enabling efficient and accurate analysis of cultures. Analysis of cultures may include reporting of various microbial types, which may include bacteria, fungi, parasites, and viruses. It is in this context that the invention is described. A processor as used herein is a device and/or a set of machine-readable instructions for performing tasks. A processor includes any one or combination of hardware, firmware, and/or software. A processor acts on information by manipulating, analyzing, modifying, converting, transmitting the information for use by executable programs, an information device, and/or sending the information to an output device. The processor may use the capabilities of the controller.

The system of the present invention offers several specific advantages over prior art systems, which include that the testing of cultures is performed by continuously monitoring test results throughout the life cycle of the culture and comparing them as they arise with previously obtained test results. verify. Another advantage provided by the present invention is the ability to monitor input test results throughout the life cycle of the culture. The invention also advantageously takes into account specific quantities when defining expected results and warning the user before releasing unexpected results to a technician for review. Another advantage allows users to define who can override validation failures and, in a related aspect, allows input of override comments directly from the validation failure window. In terms of messaging specifically, the present invention provides users with the ability to define user messages and allow users to customize the system to provide reminders to others. The present invention also includes a failure management report listing those tests that have been ignored by the laboratory technician. With regard to expected and actual test results, the present invention provides a verification failure window that displays both the expected test result value and the actual test result that caused the verification failure, and allows the user to define or construct the content of the composed expected result, Instead of defining exceptions for expected results.

The disclosed elements described herein may consist of hardware components (eg, discrete electronic circuits), software components (eg, computer programming), or any combination thereof. The system according to the invention can be implemented on any suitable computer running UNIX, Windows NT, Windows 2000 or Windows XP. Obviously, other computers and/or operating systems may be preferred in the future as technology changes. The systems disclosed herein can be implemented by a programmer using commercially available development tools.

One of ordinary skill in the art will recognize that the display image window illustrated in the figures of the embodiments of the present invention represents one possible setup, and that other setups may be used, including Several image windows of one image window, or conversely several image windows, or one image window of different image window settings.

The microbiology validation system is described in the non-limiting context of testing cultures within a clinical microbiology laboratory.

The present invention may be more fully understood with reference to FIG. 1 , which illustrates a microbiological verification system 100 according to one implementation of the present invention. The microbiological validation system 100 includes, for example, an interface processor 2 , a validation processor 4 , a result processor 6 and a microvalidation definition database 8 . The micro-validation definition database 8 stores micro-validation definitions defining the expected test results of those laboratory tests that need to be validated, as will be explained below.

In the exemplary embodiment, microbiology validation system 100 is comprised of one or more software modules integrated within an external computer system, such as a hospital laboratory information system (LIS).

The present invention operates in two phases, a preconfiguration phase and an operational phase. In the pre-configuration phase, the user makes a determination as to which of the plurality of tests to be performed for clinical training requires validation. As defined herein, verification involves finding unexpected inspection results based on predefined expected results supplied by the user. For those tests identified by user-required validations, the user creates one or more micro-validation definitions that define expected results. Once established, the micro-verification definitions are stored within the micro-verification definition database 8 for subsequent recall during the operational phase for comparison with actual verification results to determine the validity or invalidity of the verification requiring verification. The two phases of the process, provisioning and processing, are explained in more detail as follows:

In the pre-configuration phase, the user (customer) first decides which of those laboratory tests to perform a particular clinical culture require validation. In the illustrative examples that follow, reference is made to clinical cultures of blood. In the specific case of blood clinical cultures, one test typically performed on blood culture samples requiring validation is the GRAM test. In order to verify the GRAM test, the user completes the user-defined template (UDT) 200 of Figure 2, which includes data such as: expected GRAM test results, a number of preconditions, and one or more further defined tests and their expected results, The expected results of the further defined tests are supplied by the user, taking into account the earlier performed GRAM tests and their expected results.

By completing one or more user-defined templates (UDTs), such as the exemplary UDT shown in FIG. 2, the user defines the expected results of the user-identified tests that require verification.

FIG. 2 is an exemplary display image window of one embodiment of an example UDT template 200 . The UDT 200 template, once completed by the user, is stored as a micro-verification definition of the expected results of the particular inspection that requires verification. As determined by the user, micro-validation definitions are established for those tests that require validation.

As stated above, the establishment of a micro-verification definition for a test to be validated requires the user to identify the test to be validated together with its expected results, supply data including preconditions and allow for the test to be validated to identify any further tests and their the corresponding expected result. For any further inspection, the user has the option of requiring or not requiring that the actual inspection result match the expected inspection result. This option is provided by checking or unchecking "Req?"

An example of a precondition for UDT 200 is the "Incubation Time" field 230 shown in the upper portion of UDT 200. In this example, the user has entered the value "1", which represents 1 day in the "Incubation Time" field. The user has determined that the necessary precondition for validating the "GRAM" test 208 is an incubation time equal to or greater than one day.

Determining whether incubation time preconditions are met is performed by system 100 as follows. The verification processor 4 is configured to check the current date on which the test result was observed against the start date of the culture to determine if the incubation time is at least one day. If the incubation time is determined to be less than one day, the precondition is not met and the micro-verification of the "GRAM" test 208 is not performed.

Upon completion of the UDT 200 for a particular inspection to be verified, the micro-verification parameters provided by the user to fill out the UDT template 200 are stored as a single record in the micro-verification database 8. The record consists of various precondition parameter values and further defined tests and their associated expected values. Micro-verification records are then invoked at various times during the processing phase of performing verification verification.

The exemplary UDT 200 of FIG. 2 is shown divided into a top portion 202 and a bottom portion 204. Top section 202 includes fields such as Test Description, "Test" 208 identifying the laboratory test to be validated, Executive Agency "Perf Instn" 210, "result" 212, Organization Group Priority ("Org Grp Prio") 214, Activation ("Active") 216, "CultureTest" 218, "Source" 220, Validation Description ("Validation Desc.") 222, Validation Failure Message ("Validation Fail Msg") 224, "Validation Severity" ("Validation Severity ") 226, the required ignore comment ("Override Cmnt Req?") 228, and fields such as "Incubation Time" 230. From among the fields mentioned above, the fields defining preconditions include fields 208, 212, 214, 216, 218, 220, and 230 in FIG. 2 .

The bottom portion 204 of the UDT 200 includes several item lines 232a-h, which are used to allow the user to define further laboratory tests 234 and their associated expectations for the purpose of validating or voiding tests requiring validation (such as the GRAM test 208). Test result 236.

When the "Req?" item box 238 is checked, it requires that further laboratory tests, such as ORG ID 234, be considered as confirmatory tests when performing verification. In the case where two or more further laboratory tests 234 are used as confirmatory tests for the bottom portion 204 of the UDT 200, the failure condition occurs whenever the actual result of at least one confirmatory test fails to match its expected result. occur.

Table 1 of FIG. 3 illustrates the micro-authentication parameters exemplified in the top portion 202 of the UDT 200 in FIG. 2 . The first column 30 of Table 1 identifies various micro-authentication parameters 208-238. The second column 32 provides a concise description of the micro-authentication parameters 208-238 of the first column. For example, it is shown that for the micro-authentication parameter "validation severity" 226, the user has the option to select one of three messages to be displayed when an unexpected verification result, namely "INFO", "WARN" or "FAIL" occurs. The selection may be different for different micro-verification checks to be performed. The third column 34 illustrates how micro-validation parameters (micro-validation) may be stored in the micro-validation database 8 in one embodiment.

For laboratory tests requiring validation, one or more UDTs 200 per test to be validated are performed in the manner described above during the preprocessing phase. The pre-configuration phase is considered complete when the user completes the UDT 200 for those checks that require authentication.

The processing phase follows the preconfiguration phase and involves life-cycle testing of clinical cultures over hours, days or weeks. Processing of cultures begins when a physician determines that cultures need to be obtained from a patient. Cultures are obtained from patients and delivered to a microbiology laboratory. Upon determining that a culture is suitable for a body part, the laboratory registers this culture with a Laboratory Information System (LIS), as traditionally.

Throughout the processing phase, laboratory technicians perform assays and record results pertaining to the culture under consideration. In order to complete the necessary operations related to culture life cycle testing, technicians interface with the system of the present invention via a user interface, referred to herein as a "job card" for processing information related to laboratory tests and results.

FIG. 4 is a display image window of one embodiment of a so-called "job card" 400 that is invoked by a technician on a work screen at the beginning of a processing session.

As an example, microjob card 400 of FIG. 4 is shown to a technician in response to a technician calling a patient's blood culture. It will be appreciated that a job card of type "Blood Culture" (C BLD) 411 represents one of a wide range of culture types that the technician can choose to call. Other culture types callable by a technician may include, for example, wound cultures, saliva cultures, urine cultures, and the like.

The job card 400 is a display user interface used by the laboratory technician candidate throughout the test lifecycle of a culture, allowing the technician to enter, display, review, accept and reject test results as they occur.

The job card 400 is divided into three areas, the first (upper) area 402 includes the title field 411, "C BLD (PRELIM)" and various patient demographics, such as name 413 - "Dillow, Raliegh", gender 415 - "M ", age 417-"42", attending doctor 419-"UNKOWNDOCTOR". A header field 411, such as "C BLD (PRELIM)" identifies the job card 400 as the job card's blood culture type.

A second (middle) area 404 of the work card 400 is labeled "Direct Exam" and represents an area for displaying tests that can be performed directly on the specimen culture. In this example, item row 412 shows MEDIA under the heading "Test ID" and PERFORMED under the heading "Rslt." MEDIA tests are user-defined tests that are automatically part of the blood culture panel test. Note that some users do not define this test. Of the users who do define MEDIA inspections, the majority have inspections automatically have results with a status of "PERFORMED" for any number of reasons including audit, questionnaire, system and internal reasons. Alternatively, the user may manually enter the results of the MEDIA check. By seeing a result in the "Rslt" field, e.g. PERFORMED, combined with an entry in the overridden date/time field 418, e.g. "09/26/2003", it is provided to the lab technician that the blood culture has been incubated and the lifecycle testing has begun instructions. Also shown in the second area 404 is a "Culture Tech Note" field 421 for non-reporting information that may be shared among laboratory personnel through the use of the job card 400.

A third (lower) area 406 of the work card 400 is labeled "Culture Workshop" and represents the area of the work card 400 used to display the status of indirect tests performed on culture specimens. The "CULT RPT" test indicated at item line 423 is a standard test performed as part of the blood culture panel test. Item line 423 is automatically displayed whenever a blood culture type job card is brought up by the lab technician.

It is to be understood that the layout representation of job card 400 represents one embodiment of the conventional paper system from which the layout is derived. Other arrangements are within the contemplation of the invention.

Fig. 5a is a display image window of the work card 400 in Fig. 4 during the normal progress of preparing a blood culture. Figure 5a illustrates the same data shown in Figure 4 and additionally includes an item row 512 in the "Direct Exam" area 404 of the job card 400 indicating that the technician has performed a Gram stain test, i.e. "GRAM", and Its corresponding test result, "MANY GRAM NEGATIVE RODS", has been observed. Item line 512 further shows that the results have been entered into the system 100, see "ENT" 514 under the heading "Rslt Sts". The ENT status indicates results that have been entered into the system but have not yet been released to the physician for review.

As is well known to those skilled in the art of testing, the preparatory steps for performing Gram stains include incubating culture samples onto appropriate medium and microscopic slides, and placing the incubated medium on In the incubator for overnight incubation. After the incubation period, a technician performs a Gram Stain test and enters the test results into the system 100 .

The process of entering test results will now be described with reference to Figures 1 and 5 and Table II below.

Referring first to FIG. 1 , when a test, such as a Gram stain test, is performed, the results are input into the system 100 . The assay is input via an interface processor 2 configured to receive input data comprising assay result data at different time stages throughout the assay life cycle of the culture.

Table II illustrates various types of data that may be received by interface processor 2 in FIG. 1 . The first column is a description of the various data types and the second column is a description of specific examples of those data types used in the present invention.

Table II Generalized input exemplary input FIRST (First) Laboratory Test Identifier 5: Identifies a laboratory test requiring verification processing GRAM test EXPECTED (expected) first laboratory test results 7 GNRGRP - ie MANY GRAMNEGATIVE RODS ACTUAL (actual) first laboratory test results 9 GNRGRP - ie MANY GRAMNEGATIVE RODS*Note: Actual result 9 matches expected result 7 Identifier of FURTHER laboratory test 11: Identifies the further laboratory test used to verify the first laboratory test OGR ID EXPECTED FURHTER (expected further) laboratory test results 13 GNRGRP ACTUAL FURTHER (actual further) laboratory test results 15 Staphlococcus Aurues ^* Note: Actual further test results15 do not match expected further laboratory test results13

By comparing the actual laboratory test results 9 (row 3 of Table II) with the test that requires verification, such as the Gram test in Figure 2, and the test that is to be verified for verification or invalidation at a later stage, such as the Gram test 208 The verification processor 4 performs verification processing while comparing the expected verification results 7 (row 2 of Table II) of further performed verifications. For the purpose of verifying the Gram check 208 , a single further check that is performed is shown in FIG. 2 . The further performed test shown is the ORG ID test with its expected result, GNRGRP 236. A failure condition is flagged when the actual laboratory test result 9 (row 3 of Table II) of the test to be verified, such as the Gram test 208, fails to match its expected result 7 (row 2 of Table II). A failure condition is also identified when the further performed actual test result 15 (row 6 of Table II) fails to match its expected test result 13 (row 5 of Table II). In those cases where a failure condition occurs, the result processor 6 generates a warning message to the user.

Expected results can be expressed in several ways. Some common expression can be described by an indication, eg, that the culture is "resistant" to the test compound, or "susceptible" to the test compound. Test results can alternatively be expressed simply as having a "positive" or "negative" test result.

It should be understood that the expected result can also be expressed as a quantitative qualitative description, as in this example (GRNGRP=many gram negative rods (many gram negative rods)), wherein the predicate "many (many)" means Qualitative illustration of the number of "gram negative rods". Other qualitative descriptions used by the present invention include, but are not limited to, "few" ("several"), "resistant" ("resistant"), "sensitive" ("sensitive"), "positive" ("positive ”) and “negative” (“negative”).

Some examples of qualitative descriptions follow. If the test to be validated is, for example, the ORG ID test and its test result is "Klebsiella pnuemoniae" ("Klebsiella pneumoniae"), confirming that the test such as Ampicilli (AM) (ampicillin) is "resistant" expected outcome. If the ORG ID test result is "Staphylococcus aureus" ("Staphylococcus aureus"), the Vancomycin (VA) (vancomycin) confirmatory test has the expected result of "sensitivity". If the ORG ID test is "Staphylococcus" ("Staphylococcus"), the Catalase Confirmation Test (CAT) (Calase Confirmation Test) has the expected result of "Positive". If the ORG ID test result is "Streptococcus" ("Streptococcus"), the Catalase confirmatory test has the expected result of "negative".

Another example of the use of a qualitative quantity indicator would be in a situation where Sputum Culture (saliva culture) is used as a confirmatory test with an expected result of a "Many" Gram-negative stick (GNRGRP) (see Figure 2 218). Referring again to FIG. 5a, inputting a test identifier and its corresponding test to the system 100 of the present invention involves the action of clicking on the "Add Test" icon 516 of the job card 400 in FIG. 5a. In response, pop-up window 550 of Figure 5b is displayed to the technician. Area 580 of pop-up window 550 lists various tests that can be added by the technician for the blood culture instance. In this example, the technician will highlight the "GRAM" test and click on the "Add" icon 582, causing the popup window 550 to disappear and the item line 512 to appear on the job card 400 of Figure 5a.

The test results of the GRAM test, as viewed by the technician, are then entered into the system 100 by pressing the "Enter Result" icon 518 of the job card 400 in Figure 5a. In response, pop-up window 570 of Figure 5c is displayed to the technician. The pop-up window 570 includes a Quantity menu 590 listing a menu of measurement result quantities and a Description menu 592 listing a menu of test result descriptions. In this example, for the "many gram negative rods" result of the GRAMSTAIN test, the technician will select "MANY" from the Quantity menu 590 and "GNR" from the Description menu 592. When clicking on the "Add" icon 594, the encoded text result "MANY GRAM NEGA TIVERODS" is displayed within the encoded text results area 596 of the pop-up window 570, thereby providing the technician with a further opportunity to click on the "Apply" Click on icon 598 to modify the selections made before. After clicking on the "Apply" icon 598, the entered test result appears as "MANYGRAM NEGATIVE RODS" on line 512 of the job card 400 in Figure 5a.

Next, at a later stage during the normal course of examining a blood culture sample, the technician receives the blood culture sample with organic matter grown thereon. Several microbiological tests are performed and the results are entered into the system 100 via the job card 400 . In this example, a biochemical test performed on a blood culture sample resulted in a determination of "Many Staph Aurues". By clicking on the "Add/Edit Org" button 520 of the job card 400 in FIG. 5a to enter the organic matter test result and the organic matter identification, the technician enters the test result for the biochemical test performed later.

Figure 5d is a pop-up window 580 displayed to the technician in response to the technician clicking on the "Add/Edit Org" button 520 in Figure 5a. As results are entered, they appear in the upper right portion 606 of the pop-up window. Organism amount and identification are entered in field 604 and the results appear in the lower right field 608 of the pop-up window.

In the illustrative example, a technician performs two biochemical tests, a catalytic test "CAT" and a tube coagulase test "TUBE". Two test results were determined to be positive by the technician, resulting in a "Many Staphlococcus Aurues" ("many Staphlococcus aureus") organism designation. The technician clicks on the "Apply" icon 610 to accept the result.

Figure 6 is a display image window of the job card 400 in response to the technician clicking on the "Apply" icon 610 in Figure 5d. The display image window includes a new item row 416 in area 406, which indicates information about the biochemical tests performed and the identification of the organism. It is well known to those of ordinary skill in the art that the organic identification of "Many Staph Aurues" is not of the Gram Negative Rod type as expected. The expected result is "GNRGRP" 236 (see Figure 2). If an incorrect result is attempted to be issued to a doctor for review, it will cause the validation to fail.

It is beneficial at this point to illustrate the various methods whereby the results of the various methods may be released to the physician for review. In general, there are three status types: "Enter Status", "Review Status", and "Release Status". "Enter Status" defines the situation where the technician enters the test results into the system 100 but does not make the results available for the floor "Review Status" defines the situation where the supervisor reviews the test results just before allowing them to be entered on the floor , and "Release Status" defines the situation where results are both entered into the system 100 and released to physicians for review. The status conditions described above are implemented in the job card 400 via four icons.

Referring now to FIG. 6, four icons, namely "Comp/Save" 420, "Rel/Save" 422, "Rel/Fin/Save" 424 and "Comp/Fin/Save" 426 are shown on the lower left side of the job card 400 part. Various options are provided here to accommodate different laboratory policies and levels of expertise of technicians for review of results.

The "Comp/Save" icon 420 is used to save test results when they have been reviewed by a supervisor or laboratory technician with appropriate security credentials. The review can occur online or by using a printout of the job card 400 . Assume that additional tests are performed after saving the immediate results. In other words, the end of the culture inspection life cycle has not been reached. After the review, the test results are released to the physician for review.

The "Rel/Save" icon 422 is applied to situations where a laboratory technician does not possess the appropriate credentials and a supervisory review is delegated. Assume that additional tests are performed after saving immediate results. In other words, the end of the culture inspection life cycle has not been reached.

The "Comp/FinSave" icon 424 is applicable at the end of the same culture assay lifecycle and includes the above-described features of "Comp/Save". In addition to the features mentioned above, the “Comp/Fin/Save” icon 424 also saves any updated and/or unsaved data to the database 8 . From this point in time, the status of the culture changes from "Preliminary" ("preliminary") to "final" ("final") (see "C BLD (PRELIM)" 411 of FIG. 4).

However, the Rel/Fin/Save icon 426 can also be used to finalize a life cycle verification of the culture, in which case the technician needs to perform an additional step. Specifically, the technician is required to manually perform the REVIEW action (located under the job card 400 menu option).

In this example, a technician is attempting to issue laboratory test results for Organics Identification Test, ie, "ORG ID", ie, "Many Staph Aureus". In this case, the actual test result did not match the expected test result, "Gram Negative Rod". Therefore, attempts to publish actual laboratory test results resulted in validation failures.

Although for the purpose of illustrating aspects of the invention, under normal circumstances a technician will attempt not to issue a failed test, assume that by pressing the "Comp/Save" icon 420 or the "Rel/Save" icon 422 the technician releases the lab test results, Namely "Many Staph Aureus".

Figure 7a is a display image window of a failure verification screen 700 displayed to a technician when attempting to issue a failed result. The failure verification screen 700 provides an opportunity for the technician to review the detected failure and decide whether to ignore the failure and issue the result to the technician.

Independent of the system of the present invention, each technician is initially provided with a security access status that allows the technician to perform certain functions within the overall laboratory system, in accordance with pre-existing security measures incorporated into the laboratory information system. One aspect of this security access state allows the technician to ignore any authentication failure whose authentication security level status is determined to be "Informational" ("information") or "Warning" ("warning"). In the case where the verification security level status is "Failure", the technician may ignore the failure if the technician's security status is "validation". An authorization processor incorporated as part of the laboratory information system is used to determine the technician's security status and allow or deny the override. Referring to Figure 7a, when the technician's status is "validation", the technician can ignore the failure by pressing the "Yes" icon 716 .

The failed validation screen 700 is displayed to include several columns including a first column named "Validation Severity" ("Validation Severity") 702 for specifying the validation failure severity of the failed check. In the illustrated example, the validation severity is shown as "FAIL". As stated above, in the preprocessing stage, the severity level is set via UDT 200 verification. The validation severity can be set to one of "INFO", "WARN" or "FAIL".

The second column of the failed validation screen 700 is named "Validated TestID/Result" 704, which identifies the test to be validated and its expected result. In this example, "TestID/Result" is the GRAM STAIN test 208 (see Figure 2) and the expected result is many Gram negative bars "MANY FNR" 212 (see Figure 2).

The third column of the failed verification screen 700 is named "Failed TestID/Result" 706, which identifies the test performed at a later stage in the culture test life cycle and its observed (actual) result. In this example, the ORG ID check is performed at a later stage as a confirmation check for the ORG ID check performed earlier. As shown in 706, the actual test result for ORG ID is "MANY STAAUR". Recall that when building the micro-verification definition for the Gram verification 208, the ORG ID verification 234 of FIG. The expected result, GNRGP 236 of Figure 2, is also shown on the fifth column 710 of Figure 7a. When the ORG ID test was performed, its actual or observed result, "MANYSTAUUR" 706, differed from its expected test result GNRGRP 236, thereby invalidating the earlier performed GRAM STAIN test 208.

The fourth column of the failed verification screen 700 is named "User Message" 708, which provides an indication to the technician that in this case, the earlier performed test/result 704 to be verified differs from the actual test/result The result 706 does not match. The message shown includes a user prompt advising the technician to reconfirm tests that were performed earlier. Message prompts may also include, for example, prompts directing the technician to perform another predetermined laboratory test, prompts directing the technician to repeat the test, prompts to provide the user with predetermined messages, and prompts to identify actual and expected test results .

The fifth column of the failed verification screen 700 is named "Expected Result" 710, which identifies the last test performed and its associated expected result. In this example, the expected result of the "ORG ID" test performed later is "GNRGRP", the gram-negative rod.

The sixth column of the failed verification screen 700 is named "Requires Comment" 712 and displays "Y" (yes) or "N" (no) to provide a quick indication to the technician whether the verification requires it to be ignored in order for the verification to be ignored s reason. If the column shows "Y" and the technician presses the YES icon 716 (and there is no reason for ignoring entered, see 714), then a message to enter a reason for ignoring is displayed to the technician. This column can potentially save the technician time by showing the technician those instances where a reason is to be entered before verification ignores. In this example, a "N" (no) is shown at 712 , which indicates that no reason for ignoring is required, so the YES icon 716 can be pressed and verification ignored without entering a reason at 714 .

The seventh column of the failed verification screen 700 is named "Reason to Override" 714 and provides a display of any "reason for override" that may have been entered. Technicians have the opportunity to provide concise instructions for ignoring verification failures. The text for this ignore field can be entered by pressing the "Enter Reason For Override" icon 720 at the upper left portion of the FailureValidation Window in Figure 7a. "reason foroverride" is incorporated into the verification review log which can be reviewed by supervisors. The verification review record is defined in connection with Figure 10 below.

Figure 7b is a display image window of a pop-up window 750 that is shown to the technician in response to the technician pressing the "Enter Reason For Override" icon 720 in Figure 7a. Pop-up window 750 includes a text item field 752 for providing a reason for ignoring. When clicked on the "Add" icon 754, the text is included at the text field 714 of the validation window of Figure 7a.

The technician has the option to press the "Yes" icon 716 of FIG. Release test results to physician. Note that ignoring a verification failure by pressing the "Yes" icon 716 results in the ignoring being included in an administrative report that can be reviewed by a supervisor.

Figure 8 is a display image window shown on the technician's job card 400 in response to the technician pressing the "No" icon 718 at the failed verification screen in Figure 7a. When the technician presses the "No" icon 718 and chooses not to accept a test result that failed validation, the technician has several options including rereading the Gram stain again, entering a new result for the Gram stain, or returning to the original blood culture and start over. Selecting the "No" icon 718 prevents the test results from being released to the physician for review. Note that the item row 416 of FIG. 8 (shown scrolled to the right relative to the item row shown in FIG. 6 ) includes an ENT item 433 under the "Rslt Sts" heading. This indicates that the results were saved to the database 8 but not yet available for review by the doctor. Item row 416 further shows results 431 of biochemical tests performed on the organism and their associations. In the illustrated example, two biochemical tests, a CAT test and a TUBE test, performed on blood cultures are shown, both with positive P results. It should be understood that the two biochemical tests, CAT and TUBE, can also be validated in the manner described above if desired by the user. In other words, a check used to verify an earlier performed check may itself be verified by a later performed check. Note, however, that the UDT 200 is required to be populated during the preprocessing stage in order to validate any checks.

Figure 9 is a display image window shown on the technician's job card 400 in response to the technician pressing the "Yes" icon 716 at the failed verification screen in Figure 7a. Selecting the "Yes" icon 716 releases the test results to the physician. Note that the item row 416 of FIG. 8 (shown scrolled to the right relative to the same row shown in FIG. 6 ) includes the COMP item 417 under the "Rslt Sts" heading. The COMP item indicates that the results have been saved to the database and released to physicians for review.

In this example, the "ORG ID" test was performed as a final verification or confirmation test for the blood culture under consideration. Therefore, after performing the ORG ID test and recording the results, the technician presses the "Rel/Fin/Save" icon 424 to finalize the lifecycle test of the blood culture.

FIG. 10 is a display image window of the review verification window 1000 . Review verification window 1000 is available from a drop-down list on job card 400 of FIG. 9 . In the case where a culture has one or more ignored verifications, the supervisor has the ability to review the list of failed verifications that were ignored and has the option to continue the process of finalizing the culture by pressing the "Yes" icon 1002 or vice versa Decide not to finalize the process by pressing the "No" icon 1004 .

Although the invention has been described with reference to particular embodiments, it should be understood that many changes may be resorted to without departing from the spirit and scope of the invention as set forth in the appended claims. The technical description and drawings are to be regarded accordingly by way of illustration and not intended to limit the scope of the appended claims.

Claims (15)

1. A system for processing related laboratory tests and results, comprising: an interface processor for receiving data entered by a user identifying a patient's laboratory test result and for receiving data entered by a user identifying an expected result of the laboratory test; a verification processor for comparing the laboratory test result to the expected test result and for identifying a first failure condition in response to the laboratory test result failing to match the expected test result; and A result processor for initiating generation of a warning message to a user indicating said first failure condition. 2. The system of claim 1, wherein said interface processor further receives data entered by a user identifying at least one further laboratory test result of said patient and identifying said test result entered by a user. Data on at least one further expected laboratory test result of at least one further laboratory test; and wherein the verification processor compares the at least one further laboratory test result to the at least one further expected laboratory test result and responds to a failure to match the one further expected laboratory test result said at least one further laboratory test result identifies a second failure condition; and Wherein said result processor initiates generation of a warning message to a user indicating said second failure condition. 3. The system of claim 1, wherein said interface processor further receives user-entered data identifying a plurality of verification preconditions for verification of said laboratory test for said patient, wherein said verification processor identifies a third failure condition when at least one of said plurality of verification preconditions is not met, wherein said results processor initiates generation of a warning message to a user indicating said third failure condition and One of the plurality of validation preconditions corresponds to an elapsed period of time to wait before comparing the laboratory test result with the expected test result, the elapsed time period being The period of time after startup. 4. The system of claim 1, wherein The received user-entered data identifying the expected result of the laboratory test includes at least one of (a) an identifier indicating that the culture is resistant to the test compound, (b) an identifier indicating that the culture is resistant to the test compound. An identifier that is sensitive to the test compound, (c) an identifier indicating a positive test result and (d) an identifier indicating a negative test result. 5. The system of claim 1, wherein wherein said received user-entered data identifying expected results of said laboratory test includes a quantity identifier indicating the presence of an approximate number of microorganisms per unit area of culture, The number identifier identifies a qualitative range of the number of microorganisms per unit area, comprising at least one of (a) an identifier indicating "few" (several) and (b) indicating "many" (many) identifier for and The microorganisms include at least one of (a) bacteria, (b) fungi, (c) parasites and (d) viruses. 6. The system of claim 1, wherein The received user-entered data identifying expected results of the laboratory test identifies at least one of (a) counts of the number of microorganisms present per unit area of the culture, (b) microorganisms The color of the indicator, (c) the color change of the microbial indicator. 7. The system of claim 1, wherein The received user-entered data identifies a plurality of expected results of the laboratory test and the verification processor used to compare the plurality of laboratory test results to the plurality of expected results, and if at least one of said plurality of laboratory test results failing to match a corresponding one of said plurality of expected results identifying a failure condition in response to a predetermined condition, The interface processor receives data input by a user, the data identifying a plurality of expected results corresponding to a plurality of test results obtained at different time stages of a laboratory test, The verification processor compares a single result of the plurality of expected test results to a corresponding single laboratory test result of the plurality of test results, and responds to all results that fail to match the corresponding expected test result. Describe individual laboratory test results, identify failure conditions, and The results processor initiates generation of a warning message to a user indicating a failure condition of the single test performed at a particular time period of the different time periods. 8. The system of claim 1, wherein The results processor initiates generation of a warning message to the user in response to occurrence of the failure condition, the message performing at least one of (a) prompting the user to initiate another predetermined laboratory testing action, (b ) notifying the user of the potential cause of the failure condition, (c) prompting the user to repeat the lab test, (d) prompting the user with a user-predetermined message and (e) the expected and actual results of the lab test logo. 9. The system of claim 1, wherein said result processor initiates generation of a warning message to a user prompting the user for an ignore command indicating whether said failure condition is to be ignored, in response to the command being ignored by the user, the results processor initiates storage of a record indicating that the failure condition was ignored, and The record is at least one of the following, (a) is accessible by authorized persons, (b) provides an audit trail indicating who entered the ignore command and (c) is incorporated in a in the report. 10. The system according to claim 1, comprising An authorization processor for determining whether the user is authorized to override the failure condition and inhibiting the override in response to a determination that the user is not authorized. 11. A user interface system for processing information about laboratory tests and results, comprising: a display processor for initiating generation of at least one display image comprising display elements for: Enables a user to enter data identifying a patient's laboratory test results, as well as input data identifying expected results of said laboratory tests, and for displaying a warning message to a user indicating a failure condition originating from the laboratory test result by comparing the test result to the expected test result and by responding to the laboratory test result failing to match the expected test result Examine the results to determine failure conditions. 12. A user interface system according to claim 11, wherein The at least one display image includes display elements for enabling user input identifying an expected result of the laboratory test, including at least one of, (a) an indication that the culture is resistant to the test compound (b) an identifier indicating that the culture is sensitive to the test compound, (c) an identifier indicating a positive test result, (d) an identifier indicating a negative test result, and (e) an identifier indicating the culture's per unit area Quantity identifiers for the approximate number of microorganisms present on the The at least one display image includes a display element for displaying a warning message to a user prompting the user to enter an ignore command indicating whether the failure condition is to be ignored. 13. A system for processing information about laboratory tests and results, comprising: an interface processor for receiving data entered by a user identifying a plurality of expected results corresponding to a plurality of test results obtained at different time stages of the laboratory test; a validation processor for comparing the plurality of expected test results to a single laboratory test result corresponding to the plurality of test results, and responding to the failure to match the corresponding expected test result Individual laboratory test results, identifying failure conditions; and A result processor for initiating generation of a warning message to a user indicating a failure condition of said single test performed at a particular time period of said different time periods. 14. A method for processing information about laboratory tests and results comprising the following activities: receiving data entered by a user identifying a plurality of expected results corresponding to a plurality of test results obtained at different time periods in the laboratory test; comparing a single result of the plurality of expected test results with a corresponding single laboratory test result of the plurality of test results; identifying a failure condition in response to said single laboratory test result failing to match said corresponding expected test result; and Initiating generation of a warning message to a user indicating a failure condition of said single check performed at a particular time period of said different time periods. 15. A user interface system for processing information about laboratory tests and results, comprising: a display processor for initiating generation of at least one display image comprising display elements for, enabling a user to enter data identifying an expected laboratory test result, a laboratory test result, at least one further expected laboratory test result, at least one further laboratory test result; and for authenticating said first laboratory Multiple validation preconditions for the test, and for Display a warning message to the user to indicate the failure condition, the warning message originating from: comparing the expected laboratory test result to the laboratory test result, and identifying a first failure condition in response to the laboratory test result failing to match the expected laboratory test result; comparing the at least one further laboratory test result with the at least one further expected laboratory test result, and responding to the at least one further laboratory test result failing to match the at least one further expected laboratory test result laboratory test results identifying the first failure condition; and It is determined that at least one of the plurality of verification preconditions is not satisfied.

Images