Method of evaluating performance of a hematology analyzer

[0002] This invention relates to a method of comparative analysis between historical group data and current analytical data for the purpose of validating the operating accuracy of an instrument. In particular, the invention relates to a method of verifying the operating accuracy of hematology analyzers by comparing current data generated by testing a control substance with historical data collected from a group of similar analyzers testing the same control substance.

[0003] Quality control data is generated in the clinical laboratory by causing an analyzer to test known specimens (controls). Such data is typically gathered from a number of instruments all testing the same control substance. The data is then normally subjected to statistical analysis to determine if a particular analyzer is functioning properly, or “in control,” prior to testing patient specimens. In many instances, United States federal law mandates daily testing of the analytical system prior to testing specimens from humans. Even when not required by law, daily evaluations of the analytical systems is considered to be proper laboratory practice.

[0004] One common method of statistical analysis is based on the mean and standard deviation of the data over time. If new data differs from historical data by a pre-determined statistical variation (e.g., three standard deviations from the mean), the analyzer may be malfunctioning.

[0005] Various rules have been developed for conducting a statistical analysis of the data. The so-called Westgard rules normally compare new data from an instrument in a particular laboratory against historical data from that same laboratory. However, analyzing only the data from the same instrument within the same laboratory, rather than from a comparable peer group working with different instruments in different laboratories, can cause a test to suggest an instrument is malfunctioning, when in fact it is not.

[0006] Under the Clinical Laboratory Improvement Act of 1988, laboratories testing certain analytes on human specimens are required to participate in a testing program in which a designated agency distributes blind samples to a group of participating laboratories. The results are tabulated and analyzed according to rules specified by government regulation. For example, the grading limits for glucose state that a participant laboratory must have a result falling within 6 mg/dL from the mean of the group or +−10% of the mean of the group, whichever is greatest. The grading limits under the federal regulations are generally more liberal than the Westgard rules because they are based to some degree on clinical significance of allowable error. In addition, the historical data used for comparative analysis is collected from a peer group of different analyzers in different laboratories, which is believed to be more reliable information than that selected from a single analyzer.

[0007] An inter-laboratory quality assurance program is disclosed in U.S. Pat. No. 4,858,154, which is incorporated herein by reference. Prior art systems for doing comparative analysis on inter-laboratory data have relied upon electronic data input from a number of laboratories to a central computer where the data is analyzed and a report is sent to the participating laboratory in either electronic or hard-copy form. The shortcomings of these prior art systems include the fact that there is normally a delay of anywhere from several days to weeks to obtain a report from the data processing center. By the time the report is received and there is an indication of malfunction of a particular analyzer, hundreds or thousands of specimens may have already been processed. Heretofore, there has been no procedure for a participating laboratory to input data and then synchronize their data with the historical data prior to analysis. It has also heretofore not been possible to obtain real time analysis to permit the laboratory to make an immediate determination of the reliability of a particular instrument.

[0008] A further shortcoming of the prior art has been that the participating laboratory which is coupled with a central data repository to select the most appropriate category of data for comparative analysis. For example, in some instances it may be preferable to make a comparative analysis with instruments in a particular geographic region, while in other instances it may be desirable to do the comparative analysis based upon a particular instrument model.

[0009] It is therefore an object of the present invention to allow analysis of an instrument based on the federal regulations or the Westgard Rules for evaluating the data on an on-demand, rather than a periodic, basis.

[0010] It is therefore an object of the present invention to provide a method of evaluating the performance of an instrument by comparing operating data with historical data whereby the current data can be input to a global database prior to making the comparative analysis.

[0011] Another objective of this invention is to provide a method for evaluating the performance of an instrument by comparing operating data with historical data whereby the historical data may be accessed and retrieved prior to conducting the comparative analysis.

[0012] Another very important object of the invention is to provide a procedure for evaluating instrument performance by comparing operating data with historical data whereby the historical data is grouped into categories for comparative analysis and the evaluation procedure may include selecting a particular group of data for comparative analysis purposes.

[0013] Another one of the aims of the present invention is to provide a procedure for evaluating the performance of an instrument, particularly a hematology analyzer, wherein all of the procedural features set forth in the foregoing objectives are available instantaneously in real time by any participating laboratory.

[0014] Still another one of the objects of the invention is to provide a method of evaluating the performance of an instrument as set forth in the aims and objects preceding wherein each participating laboratory may communicate directly with the repository so that the historical database is continuously updated.

[0015] To accomplish these and other objectives, a user preferably begins by conducting an operation on a desired instrument and obtaining individual data from this operation. The user then stores the individual data in a client database on a client computer, such as a PC. The user also preferably stores in the client database rules for analyzing the data and a report capability to display the results of such analysis. The client computer is provided with a capability for transferring data, such as a modem providing access to the Internet, to exchange data with a global database on a server computer. Alternatively, such data transfer between the client database and the global database could occur via a diskette. The global database contains data generated by conducting a substantially identical operation on a group of like instruments.

[0016] The user selects desired attributes and the desired group data and then synchronizes to a desired extent the data in the client database with the data obtained from the global database. During synchronization, the data from the operation is transferred to a global database. Similarly, the local database can accept data from the global database corresponding to the user's selected instrument(s).

[0017] After synchronization, the local client database contains current statistical data concerning the peer-groups in which the laboratory is participating and other peer-groups of interest to the user. Using the client database, the user can then immediately perform desired statistical analyses, among other reasons, to set the group mean for analysis of the daily that data in accordance with federal regulations.

[0018] In the accompanying drawings, which form a part of the specification and are to be read in conjunction therewith and in which like reference numerals are used to indicate like parts in the various views:

[0019] FIG. 1 is a flowchart overview of the invention showing a single client computer and client database.

[0020] FIG. 2 is a flowchart of the invention illustrating multiple client computers in communication with the global database.

[0021] FIG. 3 is a detailed block diagram illustrative of the Quality Control network and system of the present invention;

[0022] FIG. 4 is a flowchart illustrative of a software program for adding laboratory data to a webhosted database.

[0023] FIG. 5 is a flowchart illustrative of a software program for adding laboratory data to a local client database.

[0024] FIG. 6 is a flowchart illustrative of a software program for modifying data acquired at a webhosted database.

[0025] FIG. 7 is a flowchart illustrative of a software program for modifying data at a local client database.

[0026] FIG. 8 is a flowchart illustrative of a software program for synchronizing data at a local client database with data at a webhosted database; and

[0027] FIG. 9 is a flowchart illustrative of a software program for synchronizing data at a webhosted database with data at a local client database.

[0028] The invention is preferably carried out in a data processing environment comprising a client computer containing a client database, a server computer containing a global database and a capability for data transfer between the client computer and the server computer. The client computer is preferably a personal computer (PC) or similar unit. The client database is preferably programmed using a commercially available database software, such as Microsoft Access, although other software having a data management capability could be used. As will be understood by those skilled in the art, the client database is preferably programmed to allow a user to easily carry out the necessary data management, such as inputting data, and statistical operations. Such programming could be achieved using Borland's Delphi 4 language, the C++ language or the Java language.

[0029] The global computer is preferably a Unix web server class computer containing the global database, which is preferably implemented using the Microsoft SQL or the Oracle database program. The global database preferably is stored on an Internet web server having an application server software, such as Oracle Application Server, Windows DNA or Netscape Application Server. An important requirement of the global server is that it have a relational database software and a Web connection software.

[0030] The data transfer capability is preferably a communication link implemented using a high-speed Internet connection, although standard analog telephone Internet connections can suffice. Alternatively, the global server and client computer are capable of exchanging data stored by using a standard diskette.

[0031] With reference initially to FIG. 1, a flow diagram illustrative of the present invention is illustrated generally by the reference numeral 10. As illustrated, this embodiment of the present invention necessitates a client data base 12 and a global data base 14 connectable via a communications network, indicated by reference numeral 16. The local client database 12 maintains QC (Quality Control) data that has originated from the lab, peer-group data that has been transmitted from the webhost, rules on how to analyze the QC data, the necessary auxiliary records for maintaining the system (i.e. instrument, test, and unit records, access times, etc.) and has the ability to produce various statistical summaries of groupings of data dynamically; i.e., the QC data mean for a set of analytes for a defined time range.

[0032] The global database 14 (or webhost) maintains the QC data from the local clients and has the ability to produce various statistical summaries of groupings of the data dynamically; i.e., the mean of all clients from a definable geographical region for a set of analytes for a defined time range.

[0033] The Local QC Network Client has the ability to import local QC data from the LIS and can synchronize with the Global QC Network database on demand. Upon synchronization, the global system receives any new or modified data from the client system since the last synchronization. The global system then updates its group statistical summaries and transmits the summarized group data to the requesting client along with any new or modified auxiliary records for system maintenance information that need to be distributed. This propagates the global QC database to the client each time synchronization occurs.

[0034] After synchronization, the local client database contains current statistical summaries of the peer-groups that the laboratory is participating in and other peer-groups that the laboratory has expressed an interested in. These statistical summaries may then be used, among other things, to set the group mean for analysis of the daily QC data with the CLIA '88 rules.

[0035] The local client system has extensive data analysis capabilities. It allows the user to define two statistical blocks of data (stat block A and stat block B) to be analyzed where a statistical block has the following selection criterion:

[0036] Identity: either an instrument in this laboratory or a group of instruments in this laboratory, the laboratories in a user definable specific peer-group, the laboratories in a country, or all the laboratories in the world.

[0037] Time Frame: a specification can be made of the time frame over which to look at the data.

[0038] Shift: when the identity is an instrument in the client laboratory or a group of instruments, a specification can be made to select work shift or combine the data derived from all work shifts.

[0039] Peer-Group Type: data can be combined with:

[0040] a specific instrument, test, method, and reagent,

[0041] a specific instrument and test without regard to method and reagent,

[0042] a specific instrument, test and method without regard to reagent,

[0043] a test and method without regard to instrument or reagent,

[0044] a test and reagent without regard to instrument or method,

[0045] a test without regard to instrument, method or reagent.

[0046] In each instance of instrument, the user may specify a class of instruments, which behave in a similar fashion.

[0047] Once the statistical blocks are defined, the system can produce a statistical analysis of the selected data including: number of points in the data set, mean of the data set, median of the data set, standard deviation of the data set, coefficient of variation of the data set, the standard deviation index of 1 statistical block in reference to the other, the coefficient of variation index of 1 statistical block in reference to the other.

[0048] The data can also be plotted using Levey-Jennings plots, Youden Plots, or Yundt Plots, with the frame of reference being able to be changed from stat block A to stat block B.

[0049] Accordingly, this approach embodies the following aspects of the invention:

[0050] 1) The group data is available in a local database for manipulation and analysis

[0051] 2) The group data is collected electronically from the participant laboratories through the synchronization process

[0052] 3) The group data can be refreshed upon demand

[0053] 4) The group data can be used in the analysis of daily QC for bias and relative imprecision

[0054] 5) The daily QC data can be plotted against the group data dynamically in a variety of ways (against a given time-frame, with different types of plots).

[0055] 6) The ability to compare to group data in real time gives the laboratorian the only means of knowing he/she is in compliance with the regulatory requirements of CLIA at any time the instrument is operational.

[0056] 7) The group which is defined by the user can be modified dynamically.

[0057] With reference now to FIG. 2, a schematic representation of an overall system according to the present invention is illustrated. In particular, a plurality of client data bases 12 are connected to global data base 14. As will be understood and appreciated, statistical analyses are performed based upon input from each of the plurality of client data bases 12.

[0058] With reference to FIG. 3, a more detailed block diagram indicative of the present invention and, particularly, indicative of the distributed quality control at work functionality principles of the present invention, local client functions are indicated generally within box 18. As illustrated, these functions include a “Client Add Lab Data” function which permits the client to add data to the local client data base, as indicated at reference numeral 20, a “Client Modified Data” function, indicated by reference numeral 22, which permits the local client to modify data in the local client data base, a synchronize with webhost function, indicated at reference numeral 24, which permits data in the local client data base 12 to be synchronized with data in the webhost global data base 14, and a query data function, indicated at step 26, permitting the local client to query data in the local data base.

[0059] As also illustrated, those functions within the box 28 are carried out at the host server for the global data base 14. In particular, web host functions include a “Webhost Add Lab Data” function, indicated by reference numeral 30, a “Webhost Modify Data” function indicated by reference numeral 32, a “Synchronize With Clients” function indicated by reference numeral 34, and a “Query Data” function indicated by reference numeral 36.

[0060] With reference now to FIGS. 4-9, each of the functions indicated by reference numerals 20, 22, 24, and 30, 32 and 34 are illustrated and described in detail.

[0061] In particular, with reference to FIG. 4, the “Webhost Add Lab Data” function 30 is illustrated and described. As indicated generally by reference numeral 38, lab data to be added to the webhosted global data base 14 is acquired. Acquisition of this data may be made in a number of ways, such as entering the data into the website through a keypad, as indicated at reference numeral 38a, loading the data from a formatted file onto the website, as indicated by reference numeral 38b, loading the data directly from the local client database utilizing client synchronization as indicated at reference numeral 38c, loading the data from an e-mail transmission, as indicated at step 38d, or loading the data from an FTP transmission, as indicated at step 38e.

[0062] Regardless of how the data is acquired, it is processed in the same way. In particular, as indicated at step 40, records necessary for processing the acquired data are located or, if non-existent, created. As indicated at step 42, any data that significantly differs from the group or the assay, based upon a comparison performed at the web host server, is outliered. Then, as indicated at step 44, new lab data records, based upon the acquired data, are written. Lab monthly statistics are then updated, as indicated at step 46. Group monthly statistics are then updated as indicated at step 48, and last touch fields are updated as indicated at step 50. It will be understood and appreciated that the time period other than monthly may be programmed.

[0063] As illustrated in FIG. 5, the “Client Add Lab Data” function 20 is illustrated and described. As illustrated at step 52, data is acquired. Data may be acquired by keying the data into the client data base 12, as indicated at step 52a, or may be loaded from a formatted file into the client, as indicated at step 52b. It will be understood and appreciated that various ways of acquiring data are contemplated and within the scope of the present invention. Regardless of how the data is acquired, it is processed in the same way. In particular, as indicated at step 54, those records necessary for processing the data are located or, if non-existent, created. The new lab data records are then written, as indicated at step 56, the monthly statistics (e.g., lab and group) are updated based upon the added data as indicated at steps 58 and 60, respectively, and the last touch fields are updated as indicated at step 62.

[0064] With reference now to FIG. 6, the “Webhost Modify Data” 32 is illustrated and described. In particular, the server at the webhost determines whether the data is data from a lab, as indicated at reference numeral 64. In the event the data is not lab data, a corresponding record is modified as indicated at step 66, and the last touch fields are updated as indicated at step 68. However, when the webhost server determines that the lab data is lab data, at step 64, processing advances to step 70, where the necessary records are located or created. Processing then advances through steps 72, 74, 76 and 78 where, correspondingly, any data that significantly differs from the group or the assay is outliered, and the lab data records, lab monthly statistics, and group monthly statistics are updated. Processing then advances to step 68 where the last touch fields are updated.

[0065] With reference now to FIG. 7, the “Client Modify Data” function 22 is illustrated and described. In particular, the local client server determines at step 80 whether the data is lab data. When it is determined that the data is not lab data, a corresponding record is modified, as indicated at step 82, and the last touch fields are then updated as indicated at step 84. However, when it is determined at step 80 that the data is lab data, processing advances to step 86, at which the necessary records are retrieved or created. Processing then advances to step 88, at which lab data records are updated, to step 90, at which group monthly statistics are updated, and to step 92, at which lab monthly statistics are updated. Processing then advances to step 84 where the last touch fields are updated.

[0066] With reference now to FIG. 8, the “Client Synchronize Webhost” function 24 is illustrated and described. In particular, utilizing an input, a user selects data at the local client database 12 to synchronize, as indicated at step 94. At step 96, transaction records are written. At step 98, an RT file is created. At step 100, a determination is made whether local client server is synchronized via an Internet connection with the processor hosting the global database 14. In the event there is no such Internet synchronization, processing advances to step 102, so that the RT file may be sent via a disk through the mail to the processing center. Processing then advances at step 104, at which the processing center returns a group response RT file on the disk (including the processed data updates) to the local client.

[0067] When, however, it is determined at step 100 that an Internet synchronization is in place, processing advances to step 106 so that the RT file may be transmitted to the global data base 14 via an Internet protocol. Processing then advances to step 108 at which the web host processing center returns a transaction key to the local client. At step 110, the client sends a post transaction key back to the website to check for a group response RT file. This check is continued periodically until the group response RT file is located, or until the user aborts the process. Assuming the process is not aborted by the user, once the group response RT file is located, the webhost processing center returns the group RT file to the local client, as indicated at step 112. Following step 104 or step 112, as the case may be, processing advances to step 114, at which any lab statistics recorded in the transaction records are factored out of the group statistics. Processing then advances to step 116, at which group statistics are updated with current laboratory statistics.

[0068] With reference now to FIG. 9, the “Webhost Synchronize With Client” function 34 is illustrated and described. In particular, at step 118, the webhost processing center receives the client RT file. The webhost server then validates the client RT file as indicated at step 120. The transaction key, described in FIG. 8, is generated as indicated at step 122. At step 124, a determination is made whether there is an Internet synchronization between the webhost processor and the processor at the local client. In the event there is such an Internet synchronization, the transaction key is returned to a client via an Internet protocol, as indicated at step 126. If not, the transaction key must be turned in a more traditional manner. As indicated at step 128, the webhost server processes the client RT file. At step 130, the webhost server generates a response RT file. As indicated at steps 132,134, and 136, in the event there is an Internet synchronization between the webhost server and the local client processor, the response file is returned to the client when the client presents the transaction key via an Internet communication. When, however, there is no such Internet synchronization, the response file is to the client via mail on a diskette.

[0069] The following software code corresponds to the previously described function blocks 20, 22, and 24, and 30, 32, and 34, as indicated by the various headings throughout the code.

[0070] From the foregoing it will be seen that this invention is one well adapted to attain all ends and objects hereinabove set forth together with the other advantages which are obvious and which are inherent to the structure.

[0071] It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations. This is contemplated by and is within the scope of the claims.

[0072] Since many possible embodiments may be made of the invention without departing from the scope thereof, it is to be understood that all matter herein set forth or shown in the accompanying drawings is to be interpreted as illustrative, and not in a limiting sense.