BACKGROUND OF THE INVENTION

This patent application relates to a system for instrument quality assessment.

Instruments used for conducting various tests need to be verified before use by being tested to ensure that the results they produce are valid and then periodically tested for quality assessment.

The present invention provides a system and method to address this. SUMMARY OF THE INVENTION

According to a first aspect of the invention there is provided a system for instrument quality assessment, the system comprising: a communications module for receiving via a communications network a results data file and an identification code, the results data file including the results of a test conducted on a sample using the instrument being quality assessed and the identification code including at least an identification of the sample tested and an identification of the instrument; a validation module to access the results data file and compare the received results with results stored in a memory to determine if the instrument tested obtained the correct results or not; and a corrective action module responsive to the validation module in the case of the received results being incorrect to determine if a corrective action can be instructed to the user and if so to pass this information to the communications module for transmission back to the user. in an example embodiment, the identification code includes information read from a barcode.

The validation module further may use the identification of the sample tested to access the memory to retrieve a previously stored test result on the same sample type.

According to another aspect of the invention there is provided a method of instrument quality assessment, the method comprising: receiving via a communications network a results data file and an identification code, the results data file including the results of a test conducted on a sample using the instrument being quality assessed and the identification code including at least an identification of the sample tested and an identification of the instrument; accessing the results data file and comparing the received results with results stored in a memory to determine if the instrument tested obtained the correct results or not; and determining, in responsive to the validation module in the case of the received results being incorrect, if a corrective action can be instructed to the user and if so to transmit this back to the user.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a schematic drawing of a system in accordance with an example embodiment; and

Figure 2 shows a flow diagram of a method in accordance with an example embodiment.

DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of an embodiment of the present disclosure. It will be evident, however, to one skilled in the art that the present disclosure may be practiced without these specific details.

Referring to the accompanying Figures an example system for instrument quality assessment is described. It will be appreciated that the instrument to be quality assessed could be any type of instrument. For purposes of illustration only the instrument wilt be described herein as an instrument for detecting tuberculosis.

Also for purposes of illustration, the present system and method will be described in conjunction with using the method of culturing, inactivation and quantification of rifampicin sensitive tuberculosis cells as described in published patent application no WO 2011/138765, the contents of which are incorporated herein by reference.

It will be appreciated that the system could be for alternative Cepheid assays e.g. MRSA, H!V Virai Load, MTB/RIF, Flu etc.

Once an instrument has been installed, a test sample is sent to the machine to be validated by a test performed by the operator. At future periods, the instrument will need to be checked to ensure it is performing properly.

In either of these cases, the operator runs a test on a sample provided and a data file containing the results of the test is produced by the instrument.

This results data file is transmitted to a central server 10 for analysis and subsequent verification. In one example embodiment, the results data file is in Comma Separated Value (CSV) format.

Each sample is provided to the instrument tester with a barcode containing information thereon identifying the sample.

The barcode structure allows a sample provider to identify a number of fields which are captured in the barcode structure. In one example embodiment these include:

Sample Type - Verification sample (V); External Quality Assessment (EQA) sample (E); Re-test sample (R) Year (YY)

EQA Provider

EQA Cycle

Batch ID's for panel constituents

Four digit sample type identifier for the four supported sample types which are explained in more detail below.

In the prototype embodiment, four different sample types where prepared for testing the instrument:

- MTB positive, RIF sensitive

MTB positive, RIF resistant

- NTM (Non-tuberculous mycobacteria)

Negative

In order for an external QA provider to have their material compatible for processing and analysis with the instrument platform, they are able to request the server 10 to generate barcodes for the different material types to be used as the sample.

In this regard, the communications module 14 will receive, via a communications network, a communication request from the external QA provider. This is passed to the barcode module 16 that generates the barcode number and sends this via the communications module 14 back to the external QA provider for printing. The external QA provider can specify the barcode format, for example 1 D or 2D.

In any event, the user of the instrument will also read the barcode using a barcode reader. This will typically be done at the beginning of the QA sample testing process.

The tester will transmit, via a communications network, the results data file together with an identification code to the communications module 14 of the central server, the identification code including at least an identification of the sample tested and an identification of the instrument used to do the testing.

In the described example, the identification code includes the information read from the barcode which identifies the sample tested.

It will be appreciated that the transmission could be done in a number of ways. For example, the barcode data read with the results data could be transmitted as an attachment to an e-mail or could be transferred using a fife transfer protocol (FTP).

!n one example embodiment the barcode data read with the results data could be transmitted by a communications network to the server 10. The results are transmitted back from the server 10 via the same communications network. In one example, the results file needs a password to be viewed and this password is transmitted to the user by SMS.

In another example embodiment, the tester accesses an Internet website using a computer and uploads the data files to the website.

In this example embodiment, the tester will typically be given a user name and password to log into the website to upload the test files.

It will be appreciated that the use of the barcodes enables any material to be analysed in a standard reporting way independent of the material provider. The analysis is barcode dependent and sample-type independent.

This approach allows any material from any external provider to be analyzed in the same format, on the same platform as described above.

In any event, the server 10 includes a number of modules which will be described below in more detail. In this regard, "module" in the context of the specification will be understood to include an identifiable portion of code, computational or executable instructions, data, or computational object to achieve a particular function, operation, processing, or procedure. It follows that a module need not be implemented in software; a module may be implemented in software, hardware, or a combination of software and hardware. Further, the modules need not necessarily be consolidated into one device but may be spread across a plurality of devices.

A communications module 14 of the central server 10 will receive the results data file and the associated barcode data read and store these in a memory 12.

It will be appreciated that the results received must include an identification of the instrument on which the test was conducted.

A barcode module 6 will access the barcode data and retrieve information relating to the individual sample types sent for testing.

The inclusion of the barcode structure allows the barcode module 16 to reject all non-compliant QA samples which may potentially be a patient sample which has been uploaded in error.

Once the barcode module 16 has verified the sample, a validation module 18 accesses the results data file and compares the results received from the instrument with the expected results based on the sample used to test the instrument.

The validation module makes use of a simple mathematical algorithm to identify the sample type from the barcode and compares this to the individual sample result transmitted in the results file.

The expected results are stored in memory 12 and retrieved by the validation module 18 using the identification of the sample tested to access the memory to retrieve a previously stored test result on the sample. If the test results are correct, the instrument is verified and the communications module 14 transmits a verification message back to the user of the instrument. It will be appreciated that this verification could be on installation or at a later time during the life of the instrument to confirm that the instrument is still operating correctly. if the results are not correct, the instrument is not verified and the communications module 14 transmits a non-verification message back to the user of the machine.

A corrective action module 22, in the instance where the test results are not correct, assesses where the results are not correct and ascertains that a corrective action is required by the user of the instrument to correct the instrument verification.

The corrective action suggestion is transmitted back to the user via communications module 14.

The instrument user is able to capture the corrective action process immediately and submit the corrective action report for review before further patient specimen testing is performed. This does not mean that bidirectional communication is used to lock the instrument.

The corrective action module 22 also notifies an administrator to review the report.

In an example of the present invention, if the results are correct they are automatically released back to the tester in real-time whilst if the results are incorrect they are referred to the administrator before the tester is notified.

Any notifications to the tester are implemented by the communications module 14. it will be appreciated that this could take any one of a number of forms including by way of e-mail and/or by way of notification whilst logged into the website as described above and/or by way of a report that is avaiiable for download from the website and/or by means of a mobile communications protocol such as SMS.

In one example embodiment, an EQA provider is registered on the server 10 and is able to control and view only their data for instruments which have been enrolled in their program. This allows different EQA providers to administer their own programs on the same platform independently of each other.

This is implemented preferably through the provider interacting with the server 10 via the Internet whereby the provider logs into the server supplying a user name and password and is then given access to only the data stored in the memory 12 pertaining to tests done on instruments using the providers EQA samples.

Each provider can also configure whether the developed online corrective action form is required to be completed with any EQA results which do not pass. in one example embodiment a verification scoring system is applied to automated results which differentiate between types of errors being either user-based or instrument based and scored accordingly. An example of this is as follows:

2 - Correct result;

1 - Cartridge/instrument error;

2 - User related error; and

0 - Incorrect result.

The scoring system is based on the results of the EQA material.

The system may or may not differentiate between user-based and instrument cartridge based errors. If the separation of user and non-user based errors is implemented this would be to ensure that no prejudice is present in the system with a user being incorrectly penalised in the reporting process for an unavoidable error based on the instrument or cartridge which are beyond the user's control. tn one example, the recommended format for the EQA panel is to include an additional re-test sample which would allow a user to re-run a failed sample. In one example embodiment the extra sample is only included for verification when the instrument is being set-up but is not included for later testing.

Currently the EQA programme supports four samples per EQA panel, meaning the maximum score a laboratory can achieve is 8 and the lowest, with all values incorrect is 0. The score of the lab per phase of the EQA will be plotted on a graph so that a lab manager and administrator can review each laboratories performance in the enrolled EQA program throughout the EQA year.

In any event, by sending substantially uniform samples to instruments to be verified in different geographic regions, important geographic information can be gleaned from the results received back from the samples.

In this regard, a geographic module 20 retrieves from the received results data file, a geographic location in which the instrument was tested, and compares this with other instruments tested in the same and different geographic locations for patterns of data.

In addition to the above, the server 10 stores in the memory 12 the date of the last test of a particuiar instrument and when a predetermined period of time has passed, generates a reminder for the tester to retest the instrument. The reminder is transmitted to the user via the communications module 14 in any one of the means as described above. Certain instruments are made up of various modules which each perform the same test on the sample. This allows a number of samples to be tested simultaneously.

The system in such a case is able to track the modules tested on the instrument to ensure maximum coverage across the instrument in a given year of EGA testing. This is done as typically not all modules are tested at the same time to save costs. in the prototype of the invention, since the EQA panels only consist of 4 samples - and the instrument often has more than 4 modules, the system stipulates which modules are required for testing in each EQA phase to ensure that modules previously tested in an EQA cycle are not retested in the subsequent cycles. This helps to ensure that the maximum number of unique modules is tested across the instrument each year. The results data referred to above now needs to include an identification of the module used to test the sample.

The above described system gives the following advantages.

Real time corrective action is issued upon automated verification of the results generated. Previously, corrective action is a much slower process as laboratories have to wait extended periods to receive their results before corrective actions can commence or they are provided with unblended EQA and manage their own corrective actions. The real-time reporting of results allows for real-time corrective action performance. Corrective action issued covers stages from pre-analytical to post-analytical. This is made possible by having the barcodes linked to the verification result as the barcodes include information that a corrective action is necessary - the system and the user would not know this was required otherwise.

The barcode system rejects any non-compliant test material (incorrect format type) and only valid verification and EQA samples are accepted and analysed by the system ensuring patient confidentiality since no patient results could be uploaded and stored online. The barcodes also render the sample provider-neutral which is a novel approach for EQA,

In addition, the system provides for lot to lot verification capacity. This means that where an instrument uses a number of modules, the correct operation of modules distributed across a number of sites can be done by checking to see the correct operation of the modules once the test results are received back.

The system makes the verification results electronically available on a rolling basis instantaneously for administrators. it will be appreciated that the above described system also provides these results very rapidly.