* * * *

The present invention relates to a laboratory automation system with integration of data from a laboratory automation apparatus and a middleware.

In the field of automation apparatus for handling specimens of biological material in analysis laboratories, the presence of an application is known, which deals with the joint and coordinated management of the whole set of equipment (pre- or post-assay modules, in turn interfaced with the actual assay modules) which concur to forming the laboratory automation apparatus as a whole in order to manage over time the flow of operations for each specimen present, and in relation to each equipment.

Therefore, the application substantially serves as global control unit of the whole automation apparatus; the control of the current status of each of the pre- or post-assay modules in terms of number of specimens currently processed and/or to be processed, and with this any possibility to reallocate the resources of the automation apparatus by changing the addressing order of the specimens themselves, is done through a graphical user interface (GUI). It is located close to the automation apparatus and is connected to a central computer of a dedicated manual specimen input/output module; observing such a Graphical User Interface, an operator in charge controls the module status and can actively act thereon to change, in case of extreme necessity, the addressing of the specimens, disable and/or re-enable some modules, and in general also visually check the implementation of such changes by the modules.

It is advantageously a practical touchscreen type graphical user interface.

In any case, the subject application only deals with managing per se the addressing of the assay modules and the processing of biological specimens along the various pre- and post-assay modules present in the automation apparatus. In other words, this aims to keep track of the position and operations to which every single specimen is subjected as long as it is on the automation apparatus, i.e. while it interfaces with the corresponding pre- or post-assay modules located along the path thereof. On the other hand, when the specimen is picked by one of the actual assay instruments, the management of the specimen itself then becomes a prerogative of the analyzer itself, and only once such an assay has ended and once the specimen has been reintroduced along the automation apparatus, it is once again managed by the above management application.

In laboratory facilities for assaying biological material from different patients, the presence of an application for the collection and management of data generated from assays carried out on specimens by the various modules connected to the automation apparatus is also known.

Therefore, unlike the above-mentioned application, the latter is merely dedicated to managing the assay results and thus it does not deal in any way with managing the addressing of specimens but only with what is downstream, i.e. the collection of data from the specimens handled (and tested thereafter) along the automation. In this meaning, it is often referred to as a middleware, or a database which can provide an overview of the results of assays carried out by the various forms and on various specimens within an automation apparatus.

Typically, the subject application already has, for each type of test made, a range of allowed values, in order to distinguish non-matching values in relation to a particular specimen exhibiting them.

In turn, the data collection application (middleware) interfaces with the Laboratory Information System (LIS), which is the computer system used in the health field, to manage specimen testing orders and process and store the information generated by all the assay modules connected to the laboratory, by sending the results collected to the LIS itself; in this way, there is a possibility, by a doctor who examines the results directly from the LIS, to optionally order the repetition of some assays if the results thereof are abnormal or unsatisfactory.

Therefore, there are two distinct applications.

The most striking expression of the separation into two distinct applications is given by the presence of two separate graphical user interfaces (GUI) deeply different from each other, one for managing the handling of specimens and the other for subsequently managing the assay results. Accordingly, it may happen that the information (whatever they are) available to one may not be shared with the other.

A laboratory technician in charge of reading and correctly interpreting the data by either application must therefore primarily be an expert in both, and in any case the possible presence of different information at the level of two different graphical user interfaces forces the same technician to monitor two physically separate screens, each with its own information. This is particularly inconvenient because while the middleware GUI can also be viewed remotely via a browser (by typing a specific IP address), conversely the GUI of the application that manages the specimens, being as said connected to the central computer of the specimen input/output module, is inevitably located in the laboratory, adjacent to the automation apparatus. Therefore, to simultaneously observe the information from two different GUIs, in the known solutions it is preferred to entrust the two tasks to two distinct technicians, one of them being typically located on site at the laboratory (to act appropriately on the specimen management application) while the other can act remotely on the middleware application.

Each of the two is an expert in one of the two interfaces but it is clear that, in case there is any problem and this must therefore be investigated, the two technicians must continuously communicate with each other, exchanging information displayed on his/her own interface, with consequent waste of time and resources. Moreover, a number of other problems occur related to the presence of the two distinct graphical user interfaces (GUI) associated with the two different applications.

By way of example, a situation can often occur where a tube is circulating along the automation apparatus for which, due to a problem that can be of various nature (e.g. a delay in the communication protocol), no order has arrived from the LIS as to the type of tests which such a tube requires, and therefore the automation apparatus does not know to which assay modules in the laboratory it should be addressed. In other words, in this case, a suitable worklist referred to the specimen and containing the information about which assay modules should take it over has not been passed correctly to the automation apparatus.

An abnormal situation thus occurs if the tube remains in circulation along the automation, potentially indefinitely or sooner or later being set aside in an area dedicated to unprocessed ("incomplete") specimens or in a refrigerated specimen storage area; this happens based on the configuration of the automation apparatus in reference to specimens missingorders (i.e., programming). The monitoring of the GUI of the automation apparatus is unquestionably needed by the operator to have the information on where the specimen is once shelved, but does not allow the same operator to find out that the reason for the above-mentioned "end" of the specimen is, in this case, the non-receipt of orders from the LIS. In the practice, it is not possible to make a proper investigation of the problem related to the specimen itself which, long in circulation along the automation, is then set aside. The inherent lack of communication between the two applications prevents the two technicians, while in touch with each other, to get to the bottom of the problem and understand why the specimen was for a certain period of time circulating along the automation without being taken over by any assay module, and then it was shelved without producing any result.

Another aspect is related to the fact that a single automation apparatus can certainly be managed either by the graphical user interface (GUI) present on site close to the automation ("central computer" of the specimen input/output module) or by other graphical user interfaces which can be connected remotely to the automation apparatus after obtaining the appropriate access rights to the laboratory network (and advantageously viewable on the screens of standard PCs connected to such a network). However, it is necessary to proceed, at such clients external to the automation apparatus, i.e. of such personal computers on which the above graphical user interface needs to be displayed, with an installation using a compact disc or other application medium (of the client type) that allows the remote viewing of the automation apparatus GUI. This is particularly difficult in a domain like that of analysis laboratories, where the use of strict restriction policies on the installation of applications on personal computers that need to manage the information from the same laboratory is frequent.

A further problem is related to the fact that, for any type of assay that is to be made along the automation apparatus by one or more of the modules forming part of the apparatus itself, it is still necessary to separately configure both applications, thus setting appropriate rules and/or parameters (different case by case, i.e. for each type of assay) on either GUI.

Moreover, the management of information that relate to the two different components, i.e. LAS (Laboratory Automation System, automation end) and LIS (Laboratory Information System, data collection and management end) certainly already allows a validation of the clinical data to the previously known solutions: in particular, upon the analysis carried out by a module along the automation and which has produced a certain value of a given parameter, the result management application in the known solutions can already determine whether or not this value is within a certain admissibility threshold (in this sense, it is precisely called data "validation"). However, the above information management always remains distinct and separate between the two components, and therefore there remains the risk that abnormal situations arise.

An example of this can be represented by the situation in which a specimen, properly addressed to an assay module, is ignored by the latter due to the incorrect placement of the label on the tube, which prevents a proper reading of the barcode by the reader and thus the identification of the specimen by the assay module, despite the automation apparatus upstream has correctly identified it. As said, the specimen is then ignored and reentered along the automation apparatus but without any error message relating to the failed assay. It is then stored to an appropriate specimen collection area, as if it was duly tested, when in fact it is untrue as it lacks the results for the assay module that has ignored it.

There is no way to detect the error: in fact, on the one hand, the automation end does not handle the results of the analytical process, and therefore cannot notice the missing results on the assay skipped, and on the other hand the data management end can only passively accept the results that come from the various assay modules (and only afterwards it can examine the results themselves), so there is no possibility to notice that a particular assay was not performed (due to missed reading of the barcode) and thus that the results are lacking. In the practice, as can be understood, this second example brings out, as above, a further aspect related to the impossibility to perform a proper investigation when there is a problem of lack of analytical results. This happens, as seen, whatever is the cause (in the two examples above, first the non-communication of appropriate orders from the LIS, and now the non-processing of the specimen by the assay module due to a label positioned incorrectly), and is the result of the lack of integration between the two applications.

EP-2450711 describes a laboratory automation plant adapted to manage the handling of biological specimens and the processes of a plurality of analyzers of such specimens.

It is the object of the present invention to implement a laboratory automation plant adapted to manage both the application that deals with the management of the equipment of a laboratory automation apparatus and the consequent addressing of specimens, and that which collects and manages the results from the assays made on such specimens. This is to allow a single operator, expert in both applications, to control any type of information from the components involved (automation apparatus and middleware).

It is a further object to implement a laboratory automation plant adapted to reduce the time dedicated to the investigation regarding any problem that may arise, and to ensure with certainty the possibility to find out where the problem actually is, for those cases in which (see the examples above) due to inconsistency or lack of data, such an investigation would be almost impossible according to the known solutions.

It is yet another object to implement a laboratory automation plant in which an appropriate management of each process in progress is ensured, through a continuous exchange of information (and its related control) between the LIS end and the LAS end, also so as to carry out, if necessary, a suitable immediate self-recovery activity, preventing situations that lead to an erroneous allocation of a specimen considered to be processed (but which actually is not, because the results of some assays therefrom are lacking) and thus, indirectly, to a delay in issuing a medical report.

According to the invention, said objects are achieved by a laboratory automation plant as described in claim 1.

Advantageously, the plant according to the invention is web-based, i.e. is also accessible remotely by simply typing, on any web browser, an IP address associated with the single automation apparatus (and so that the change, if any, in the IP address corresponds to the access to a different automation apparatus and to a different middleware). Accordingly, it is not necessary to proceed with installation of a specific application for each of the clients that access the information provided by such a unified interface: certainly, a "centralized" installation of an application at the specimen input/output module along the automation apparatus is still necessary, but all the clients that want to connect thereto, through the unified interface, as mentioned, only need a common web browser, thus obviating the restrictive policies of each laboratory on installing applications on the local network.

Advantageously, it is easier to configure each type of assay (test) to be carried out on the specimens, making any settings (rules, parameters) for that test be entered to a single user interface screen, which is now unified.

These and other features of the present invention will become more apparent from the following detailed description of an embodiment thereof, made by way of a non-limiting example with reference to the accompanying drawings, in which:

figure 1 shows a block diagram of a laboratory automation plant according to a known solution;

figure 2 shows a block diagram of a laboratory automation plant according to the invention.

A known laboratory automation plant 1 (figure 1) comprises an automation apparatus 2 which according to the needs sorts the biological specimens contained in test tubes to the pre- and post-assay equipment as well as to the various assay modules 3 which interface with the automation apparatus 2 itself. In the following description, the pre- and post-assay equipment is deemed to be included in the automation apparatus 2. For convenience, a single block is shown in the figures to represent the plurality of assay modules 3 optionally present.

A manual specimen input/output module 4 is provided between the pre-assay modules. In the case of very bulky automation apparatus 2, and therefore located in large laboratories, more than one specimen input/output modules 4 may also be provided.

The specimen input/output module 4 in turn comprises a personal computer running a specimen addressing application 5 for the "centralized" management, jointly and coordinated, of all the equipment forming the automation apparatus 2, or all the operations relating to each of such equipment; the whole is intended to ensure at each time the appropriate addressing of the specimens along the whole automation apparatus 2, and therefore to the appropriate pre- or post-assay modules as well. Application 5 is managed by an operator through a practical graphical user interface 6 of the touchscreen type which allows the operator to view the current status of each equipment.

The access to the same controls provided on the graphical user interface 6 just mentioned is also possible through other clients 7, located in different positions in the laboratory and yet connected to the local network of the laboratory itself. Such clients 7 advantageously are personal computers installed with a specific application, which is client-only type, and therefore different from application 5 installed only in the input/output module 4. In any case, each client application has a corresponding graphic user interface 8, which can be managed or not in touchscreen mode depending on whether the screen with which it is associated supports this mode or not (otherwise, for example in the case of a standard notebook, it can be managed via a mouse), and which allows the operator to act on the automation apparatus 2 in the same manner as the "centralized" graphical user interface 6.

Plant 1 is also provided with a middleware 9 for managing data from the assays made by the various modules 3 along the automation apparatus 2. In essence, middleware 9 is a web-server and is also provided with a graphical user interface 10 which is accessed by different clients 11 provided with the appropriate access rights to application 9. The access of clients 11 (typically, as above, the personal computers) to the information contained in middleware 9 is done remotely by typing a specific IP address of the subject middleware 9 in a common web browser.

A Laboratory Information System (LIS) 12 is also provided, which exchanges data directly with middleware 9. A laboratory automation system 100 according to the invention (figure 2), on the other hand, provides for the use of an integrated software user interface 13 used to control both the equipment management application 5 and the data management application (middleware) 9. The implementation of an integrated user interface 13 is made possible by the use of a driver 14 for communication between the above applications 5, 9. In particular, the communication driver 14 is a portion of a software application designed for the communication according to a specific protocol.

Again, clients77 are provided, or personal computers, each of which, provided with the appropriate access rights to middleware 9, connects to middleware 9 itself through its web browser, as already seen with reference to the prior art in figure 1.

Obviously, the connections of the middleware 9 to the assay modules 3 and to the Laboratory Information System 12 remain, according to what is already known.

The novelty which characterizes the new embodiment described in figure 2 is that due to the integrated user interface 13, and in particular to the communication driver 14, each client 77 accesses middleware 9 remotely through the browser, but by means of the latter, it also accesses the equipment management application 5, which conversely in the known solutions can only be managed via personal computer directly residing in the laboratory, thereby preventing a remote management of the handling of tubes along the automation apparatus 2.

Compared to known solutions, it remains the presence of two separate applications 5 and 9, independent of each other in the management of the respective operations.

The decision to keep the use of two separate applications is dictated by reasons of greater safety and higher performance by each of the two, given the complexity of the overall management. In other words, thereby the two applications are installed on two separate personal computers (obviously, application 5 is usually installed on the PC of the input/output module 4) and a possible malfunction of one of the two PCs thus prevents the use of the corresponding application but is not going to affect the use and functionality of the other application.

On the other hand, the lower computational effort required from each of the two PCs (because each is provided with only one of the two applications) enhances the performance of both applications, while reducing the probability of failure or malfunction of the corresponding PCs.

For the practical usage purposes only by the laboratory technician expert in both applications, the use of an integrated user interface 13 in the new solution, made possible by the use of the communication driver 14 between the two applications, allows the end user of such an integrated user interface 13 to remotely be in front of an integrated management system of two different components (equipment management application 5 and middleware 9), such as to be perceived as if they were one, and thus without a doubt manageable with greater immediacy by the technician himself/herself.

In the practice, it has been seen that the plant thus described can achieve the intended objects while ensuring, within the scope of a laboratory automation apparatus and the management of data from the assay modules connected to the apparatus, the appropriate integration between the end which manages the addressing of the specimens along the apparatus and that of management of the results from the assays made by the various modules. The above integration, resulting from the use of a specific communication driver between two separate applications, is expressed in particular in the use of a single integrated user interface to manage the above two applications, when instead the known solutions require two separate user interfaces.

Accordingly, it is sufficient to use a single technician, suitably skilled in both applications. He/she must monitor, typically remotely, only one interface in which in a few steps he/she is able to find all the information needed about the exact location of each specimen located along the automation apparatus and about the results of the assays made on each specimen. In the known solutions, the two different sets of information reside on two separate user interfaces, and it is therefore necessary to continuously cross the data from the two user interfaces; this means checking two separate screens, which moreover are not physically adjacent, because the result management interface can be consulted remotely while that for managing the handling of the specimens must reside on a personal computer directly connected to the automation; based on this, the known solutions cannot in the practice avoid the presence of two distinct technicians, each engaged in the monitoring of one of the two interfaces, and who exchange information as necessary (for example by telephone) in case problems arise, with consequent waste of time.

The integrated user interface instead implies a significant reduction in the time for investigating a problem that may arise at any level (therefore both on the automation end and on that of result management), since it can be monitored by only one technician who can also decide what to do in every situation in total autonomy.

Moreover, since the new interface is completely web-based, it has been seen that an installation of an application for each client (personal computer) that access the system is not needed anymore since, after granting the appropriate access rights to the local network of the laboratory, in order to gain access to the integrated user interface it is sufficient for each client to have a standard web browser to type a specific IP address referred to the network itself of the analysis laboratory.

Still, it is clear that it is sufficient to configure each individual assay test only on the middleware end, without having to configure parameters on the two separate applications due to the use of two separate interfaces.

Moreover, the system described by the invention allows a more profitable management and control of the process in all of its steps ("General Event Manager"), due to a continuous exchange of information and control thereof between the automation end and the results end; this is also due to the feature of the middleware to act now as a "rule builder", through the ability to automatically set the performance of certain actions (by the automation apparatus) in response to the occurrence of certain conditions or at certain values of some parameters.

This latter feature is certainly already present in the known middleware which, however, only exhibit it in the context of validation of a clinical data (therefore, a result already ready) but not in an area which requires, further upstream, an interaction or an exchange of information with an automation apparatus.

Therefore, the above feature allows a self-recovery in the event of problems.

We can go back to the example mentioned above of an assay module that is unable to read the barcode of a label on a test tube, because the label is applied incorrectly; in known solutions, as already mentioned, the tube is ignored by the assay module, but this is not accompanied by an actual error message and therefore, at the end of its cycle along the automation apparatus and when it is stored (typically in a refrigerated warehouse suitable for storing specimens), some assays actually missing are deemed as made, and this inevitably delays the issuance of a report by the doctor, as essential data may be missing.

With the solution of the present patent, instead, the middleware, which now communicates with the automation and is no longer an entity separate therefrom, check in real time whether a query has been received from the assay module to which the automation apparatus has addressed the specimen (and such a query only arrives if the barcode is readable by the assay module itself) and is therefore able to notice if such a query has not arrived (or if the barcode is unreadable) and, therefore, to infer that it is precisely a consequence of this that the expected results from the module itself are missing. The middleware at this point, due to its feature of "rule builder", may take a decision ("General Event Manager"), ordering the automation apparatus to immediately return the specimen to the assay module (before it is incorrectly stored in the refrigerated warehouse without the appropriate assay and therefore the appropriate results). It is clear that as long as the problem of wrong application of the label is not solved, the specimen is continually rejected by the assay module; after a (configurable) number "n" of consecutive rejects, the specimen is then parked in a special dedicated area ("rack of errors") where an operator can then advantageously manually re-apply a second label correctly. It is well understood that the dismissal of the specimen recognized as "wrong" (illegible) is functional to prevent the specimen, if rejected by the assay module, from being stored as "successfully processed " with the risk, upon the issuing of the medical report, of having some assays on the specimen that are missing, when it is sometimes too late to redirect to the sample back to the assay module.

In this regard, the system subject of the invention is capable of providing a greater safety for clinical data and of making up for all the weaknesses of the process, protecting the laboratory from the possibility of incurring in errors to a greater extent as compared to the known solutions.

Several changes and variations may be made to the invention thus conceived, all falling within the scope of the inventive concept.

In the practice, the materials used as well as shapes and sizes, may be any, according to the requirements.