This invention relates to the field of monitoring and controlling laboratory information and/or laboratory instruments. The word laboratory may be taken to encompass many different types of establishment, from a single room containing one or two scientific instruments to a building housing hundreds of scientists and pieces of equipment; from a place of academic research to the process control room of a brewery, food manufacturing plant, oil refinery, chemical or pharmaceutical facility etc.

What most laboratories have in common is their function of performing scientific tests or experiments and their product, laboratory information. In a modern laboratory, there may be hundreds of samples, in respect of each of which hundreds of items of data must be known such as the sample's origin, its amount, its likely constituents, the chain of custody of the sample, any tests it has undergone (and their results) etc.

There will also be information regarding any tests that the sample should undergo in the future and instructions as to the carrying out of these tests, amongst many other types of information and instructions.

The task of handling and managing these data and instructions for even a small laboratory can be vast, and for this purpose different types of Laboratory Information Management System (LIMS) have been proposed. LIMS are software-based systems using databases to store, retrieve, manipulate and report laboratory data, to provide information about work

being and to be undertaken and/or to control laboratory instruments. The LIMS may provide spreadsheet, word processor, statistical and quality control functions in addition to other functions which may be specific to certain types of laboratory -for example a commercial research laboratory may require an automatic billing function. The LIMS may also directly control a number of scientific instruments. Since the needs of each laboratory are different, a typical LIMS package may not fulfil all a laboratory's requirements"out of the box", but will require some customisation, either by the vendor or by the customer. Such customisation may require many weeks of expensive coding, with or without the aid of regulated business models, in order that the LIMS system can operate according to a particular laboratory's exact requirements. Should these requirements change at a future date, for example with the introduction of new statutory requirements, further expensive coding will be necessary. The amount of effort required to customise the base software can often be the major financial and time cost of a LIMS installation. The flow of events happening to a sample in a typical prior art LIMS is shown in Figure 1. Before running any samples, the system is configured by defining various static data tables and entering data therein. This information will typically be about the laboratory environment, the types of analyses which can be performed, the test schedules and the types of samples to be analyzed. In Figure 1 these steps are shown as boxes 1,2,3 and 4 respectively.

Once this data is entered, samples may be run. A sample is logged in as shown in box 5 and a

worksheet is generated (box 6) giving a list of tests to be carried out on the sample. This worksheet may for example be printed out on paper as a series of instructions for a human operator, as a bar code to be read by a bar code reader or automatically sent to an instrument or series of instruments for automatic handling of a sample. The results of these tests are then entered into the system (again either manually or automatically)- this is shown as box 7. The results may then be outputted in report form (box 8), and/or checked against nominal values to check the quality of the product from which the sample was drawn (box 9).

Once the results have been authorised (box 10) the data can be archived.

In a typical LIMS the sequence of work is broadly fixed, although each individual step may be modified by the user. Changing the sequence of events, or adding further logical branches (e. g. IF.

. THEN... ELSE nodes) to the sequence usually requires the development of custom code, generally in the programming language of the LIMS, which may be a proprietary language unique to that LIMS. Such customisation is not only complex and expensive but it can lead to problems for the customer in terms of upgrading and validating their LIMS. For example, the business process of a particular laboratory may require that each time a sample arrives from a particular client, a receipt should be generated and sent to that client. In a traditional LIMS, the services of an experienced analyst would be required to design and code a custom mechanism for this scenario.

The object of the present invention is to provide a LIMS which obviates the need for such customisation.

In particular, the object of the present invention is to provide a LIMS which allows the user readily to generate and modify the sequence of event to be undergone by a sample or samples. Another object of the present invention is to provide a LIMS which is easy to use and modify. A further object of the invention is to provide means for monitoring and/or controlling laboratory information and/or instrumentation which is easily configured and used by the user. These and other objects are realized by the invention as described below.

According to a first aspect of the present invention, there is provided a system for managing laboratory data, comprising: an electronic storage device, arranged to store an array of static laboratory data and an array of dynamic laboratory data; a graphical user interface providing an array of symbols each of which represents a task to be performed; and a processor in communication with the electronic storage device and the graphical user interface, the processor, in use, executing the associated task represented by the corresponding symbol selected by a user from amongst the array of symbols upon the graphical user interface by using data selected from at least some of the array of static laboratory data and/or at least some of the array of dynamic laboratory date; whereby a user defined sequence of tasks may be generated by linking at least two of the array of symbols upon the graphical user interface such that each task represented by an individual one of the array of symbols selected by the said user from amongst the array of symbols is executed by the processor in turn.

There are a number of advantages to the system of the invention over the prior art. Firstly, the use of

graphical symbols or objects'allows straightforward set up of a complex sequence of tasks (hereafter referred to as a workflow') without the need for a skilled programmer. Secondly, the overall amount of code that needs to be written is dramatically reduced with the present invention. Each symbol or object' requires a finite amount of code to be written to allow the task function to be fully specified, as well as to allow connection or linkage to other tasks.

For example, to define a suitable number of different sequences or workflows to address most eventualities in a laboratory information management system may require several tens of different symbols in the array of symbols, requiring several tens of thousands of lines of codes. However, to write separate bespoke programs to address the many different test procedures in a large laboratory (as frequently occurred in the prior art) may require several million lines of code.

The term static laboratory data'will be understood by those skilled in the art to refer to the body of information held by the laboratory, in a database for example, and which relates to procedures which tend not to change with time. By way of example only, static laboratory data may include the types of samples to be analysed and the types of analyses to be performed.

Likewise, the term'dynamic laboratory data'will be understood by the skilled reader to refer to the body of information held by the laboratory, again in a database for example, and which usually relates to procedures specific to each particular experiment.

For example, dynamic laboratory data may include the identification of a specific sample to be analysed, or the results of such analysis.

In one preferred embodiment, at least some of the array of symbols represent a single associated task to be executed by the processor. Alternatively, at least some of the array of symbols represent a multiplicity of associated tasks to be executed by the processor.

The symbols may be arrangeable in a plurality of different ways corresponding to different sequences of tasks. Therefore, whether each symbol represents a single task or a multiplicity of tasks, it will be appreciated that an extremely large number of different work flows may be defined by a user using a relatively small number of symbols.

For example, using only twenty different symbols, theoretically more than 1018 different workflows may be constructed. Of course, not all combinations of symbols define meaningful task sequences, but even if only 10% of such combinations are meaningful, this is still a very large number of combinations.

Preferably, the system is arranged to present the array of symbols in a first window, individual ones of the array of symbols being selectable for entry into a second window, the selected symbols being linkable within that second window. For example, the selected symbols within the second window may be linkable in a hierarchical tree structure such that a first selected symbol located at the root of the said tree structure and a second selected symbol located upon a branch of that tree structure causes the processor to execute a first associated task represented by the first selected symbol before execution of a second associated task represented by the second selected symbol.

In that case, the electronic storage device may be further arranged to store a set of rules defining one or more sequences of tasks which are disallowed,

the graphical user interface being in communication with the electronic storage device via the processor such that a user is prevented from linking symbols upon the graphical user interface so as to define a sequence of tasks which is defined by the set of rules to be disallowed.

The set of rules may be held in a database, for example, which operates behind'the graphical user interface. By referring to this set of rules, the system can prevent a user from building up meaningless sequences (such as carrying out a task upon an aliquot of a sample before the sample has been divided into aliquots). This utility thus further assists users who are unfamiliar with programming techniques.

In a preferred embodiment, at least one of the array of symbols may represent an associated task to be executed by a device external to the system, the processor executing the associated task when selected by a user by using data obtained from the said device external to the system.

Although the system of the preferred embodiment is particularly suitable for data processing and handling, it is convenient to permit the system to allow data collection from an external device such as for example a sample pH detector. Thus, one of the symbols may define the task of triggering such a detector and then downloading the results of the test (which will represent dynamic laboratory data) into a database.

At least some of the array of symbols may represent fixed, predefined tasks to be performed.

Likewise, at least one of the array of symbols may represent a task to be performed, which task may be defined by a user of the system.

By providing a palette'of predefined tasks, as

previously mentioned, a vast number of different workflows may be defined. Even so, there will of course be times when none of the predefined symbols are suitable to define the procedure to be carried out. For this reason, it is preferable to provide the user-definable task. A user may then write custom code to carry out a specific task.

According to a second aspect of the present invention, there is provided a method of managing laboratory data, comprising: (a) storing an array of static laboratory data and an array of dynamic laboratory data; (b) providing an array of symbols upon a graphical user interface, each symbol representing a task to be performed; (c) selecting at least two symbols from amongst the array of symbols upon the graphical user interface; and (d) executing the associated task represented by the corresponding symbol thus selected, by using data selected from at least some of the array of static laboratory data and/or at least some of the array of dynamic laboratory data; whereby a user defined sequence of tasks may be generated by linking the at least two symbols upon the graphical user interface such that each task represented by an individual selected one of the symbols is executed in turn.

In that case, the static laboratory data may preferably be stored prior to the step (d) of executing the associated task.

Additionally or alternatively, the dynamic laboratory data may be stored during the step (d) of executing the associated task in response to a prompt displayed by the graphical user interface.

The invention also extends to a computer program product directly loadable into the internal memory of a digital computer and comprising software code

portions for carrying out the steps of this method, when the product is run on a computer.

In a further aspect of the present invention, there is provided a computer program product stored on a computer readable medium, the product being adapted for control of a computer comprising electronic storage means for storing an array of static laboratory data and an array of dynamic laboratory data, a graphical user interface providing an array of symbols each of which represents a task to be performed, and a processor in communication with the electronic storage means and the graphical user interface, the product comprising: computer readable program means for causing the processor to execute an associated task represented by the corresponding symbol selected by a user of the computer from amongst the array of symbols upon the graphical user interface; computer readable program means for causing the processor to carry out the said execution by using data selected from at least some of the array of static laboratory data and/or at least some of the array of dynamic laboratory data; and computer readable program means for linking at least two of the array of symbols upon the graphical user interface such that the processor is caused to execute each task represented by an individual one of the array of symbols selected by the said user from amongst the array of symbols in turn.

According to another aspect of the invention, there is provided means for managing laboratory sample data including means for storing static data, at least regarding the types of samples to be handled and types of tests to be performed; means for inputting dynamic data regarding at least sample identification and test results and storage means for storing said dynamic

data; means for defining a list of tasks to be performed with relation to said samples, said tasks using information selected from among the static. and dynamic data; and means for carrying out the tasks detailed on the said task list; characterised in that the task list defining means comprises a graphical interface, whereby graphical tools are provided in the form of symbols representing tasks which may be selected by the user to form part of the list of tasks, each said symbol representing an event or sequence of events to be carried out, the user being able to combine various different symbols to form a user-defined sequence of tasks.

Preferably, each symbol represents an integral task or series of tasks, the symbols being arrangeable in a plurality of different ways corresponding to different sequences of tasks.

Advantageously, the means for carrying out the tasks is controlled automatically, relevant instrumentation being provided which responds to the instructions detailed on the task list.

Preferably, the graphical interface is presented in the form of several windows, the user being able to select a window to appear in the foreground of the display, each window presenting various tools to the user, so that the user can select from the various tools in the appropriate window as required.

According to yet another aspect, the invention provides a method for managing laboratory sample data including the steps of storing static data, at least regarding the types of samples to be handled and types of tests to be performed; inputting dynamic data regarding at least sample identification and test results and storage means for storing said dynamic data; defining a list of tasks to be performed with

relation to said samples, said tasks using information selected from among the static and dynamic data; and carrying out the tasks detailed on the said task list; characterised in that the step of defining a task list includes providing a graphical interface, whereby graphical tools are provided in the form of symbols representing tasks which may be selected by the user to form part of the list of tasks, each said symbol representing an event or sequence of events to be carried out, the user being able to combine various different symbols to form a user-defined sequence of tasks.

An example of the invention will now be described in greater detail with reference to the accompanying drawings, in which: Figure 1 shows the flow of events in a typical prior art LIMS; Figure 2 shows examples of typical graphical symbols available to the user; Figure 3 shows an example of how the display would appear in a particular aspect of the current invention; Figure 4 shows an example of the use of a Choice node; Figure 5 shows an example of the use of a Selection node; Figure 6 shows an example of a User Defined Event; and Figure 7 shows an example of the use of a subtree.

The operation of the invention relies on the concept of the workflow. A workflow in this context is a model of the laboratory process which defines the events be carried out on a sample or samples. The workflow may include the steps of defining a sample and/or sample group, splitting off and defining aliquots of samples, specifying decisions to be taken, tests to be applied and reports to be printed. The

user can build a macroscopic workflow using graphical tools which correspond to workflow nodes. In this way, often complex laboratory processes can be modelled using a structured task list made up of a series of workflow nodes selected by the user. The workflow can be structured to incorporate specific event nodes which allow status changes or report processing, for example, to be triggered as a response to the outcome of a particular test. In summary, a workflow defines the business rules for events to be carried out on a sample. As the structure of a workflow is hierarchical, it is necessary to define workflows for results, tests, aliquots and samples before a sample workflow can be used for sample login. Details about particular steps in the workflow may be specified in associated templates, which may be pre-defined or defined by the user himself.

A workflow can therefore be used by the user to model internal business practices, obviating the need for custom coding. To show an example of one realisation of the invention, see Figure 3 (the symbols used being detailed in Figure 2), which shows how the screen would look when the user has set up the system to handle a sample with its corresponding aliquot, complete with a single test and a set of results. The report beneath the event node will run when the sample completes. Each symbol selected by the user corresponds to a type of workflow node, as shown in Figure 2. Each type of workflow node has a series of corresponding workflow tables which define the properties of each node. There may be many predefined node types, some examples of which are shown in Figure 2. As discussed, the workflow is a hierarchical structure, and the relevant table will define which node types may appear beneath the current node type.

As an example, it is valid for ALIQUOT nodes to appear beneath SAMPLE nodes, however the converse is not true. The data within this table is queried within the workflow screen, when a user clicks on a node in the tree, so that the user will not be allowed to position a node in a position disallowed in the table.

Certain workflow nodes may support events, for example"Completed"or"Schedule Item". All events which may be associated with each node type may be stored in a table associated with each node. Events may be pre-defined or user-defined-for example if the user's business process requires an aliquot to be archived and a certain type of report to be printed each time the sample fails a particular quality control test, the user may define this as an event. A user event can be triggered by some part of the workflow or can be run manually by the user.

When the workflow is processed, the system reads the relevant table, instantiates objects internally, and then processes those objects. For each workflow node processed, the system looks up the relevant table, and creates an object of the type specified within it. In the case of a sample node, for example, this forces a new sample to be logged into the system.

The sample workflow node has a link to the sample template to be used at login, so the user is presented with the fields on that template within the login screen. The sample record maintains a link back to the workflow node used to generate it. When the sample status changes, a database trigger on the server is run, and that looks up the associated workflow nodes.

A search is then made for any event nodes directly below the sample node in the workflow, and if found, a further check is then made on the nodes in the workflow to see if the event corresponds to that

occurring within the database. If the event matches one within the workflow, an entry is then made on the background queue, which contains enough information for a background process to perform the subsequent nodes within the workflow. A workflow can automate the complex processes within a laboratory through the use of decisions. The business process may state that every time a sample arrives from a particular client, an e-mail receipt should be generated and sent to that client. In a traditional LIMS, the services of an experienced analyst would be required to design and code a custom mechanism for this scenario. Decisions of this nature are common, and with the current invention are supported by the system"out of the box". Two types of decisions are supported-choices and selections. A choice permits the selection of one of two alternatives, whereas a selection permits a choice between more than two possible outcomes.

Figures 4 and 5 show examples of the use of these nodes respectively. In the example shown in Figure 4, the Test BARBEL will only be assigned if the amount in the aliquot is sufficient, otherwise the HPLC-B test will be assigned. The selection node extends the If-Then-Else processing capability of the choice node-it permits multiple comparisons to be made, with a corresponding list of multiple outcomes. The example shown in Figure 5 performs an action based on the conclusion of the aliquot. Figure 6 shows an example of the display as seen by the user. Different windows may be selected using the tabs at the top of the screen. The user may select symbols from the drop-down lists at the right hand side of the screen and place them in the relevant position in the workflow in the left-hand window. Depending on the symbol selected (each symbol corresponding to a type of

workflow node) a dialogue box may appear requesting further information from the user, or a selection screen permitting the user to select between options, as appropriate. Using the workflow model, decisions may be nested to any depth, and are extremely powerful as the data used for the decision may be retrieved from any dynamic node up the tree. Some database fields only occur on the aliquot, such as the amount of substance available within the aliquot. It is therefore possible to make decisions on splitting aliquots, such as"If I have more than 100ml, split into two test tubes and send one to MicroBiology and store the other in a freezer. If less, omit the split and send the vial directly to MicroBiology".

Workflows may be combined, building a large and possibly very complex set of decisions and data definitions from predefined simpler workflows. A Subtree node is used to link one workflow to another.

Figure 7 shows an example, in which the workflow links to predefined aliquot and test workflows. Saving workflows in this manner permits complex workflows to be generated from reusable objects. The shortcut indicator (see Figure 2) denotes a subtree. Aliquots are commonly split in the laboratory, so that vials of the same sample can be tested individually by different chemists. A Split node can be used within the workflow to automatically generate these subsequent aliquots, and the system maintains a link between any aliquot and its children, so that a hierarchy of aliquots can be generated. To support extensions to the system, a User Defined node is included, which when run calls user-supplied code. The user creates an object and the appropriate code is called by the system when the user object is encountered within the workflow. The User Choice node

is similar to the User Defined node, but permits the user to supply code that can evaluate the choice.

Again the appropriate (user-supplied) code will be called.

A Message Box node is used to display a message to the user, and would commonly be incorporated into a user event workflow. The text defined within the workflow is presented in the form of a dialogue box.

Information may also be provided on various factors such as client factors, container factors, product factors and instrument factors. Factors are used to supply arguments to calculations, and look up numeric values stored in associated database tables. For instance, different clients may be charged according to different fee scales, this information being stored in a table as appropriate. Using workflow nodes, a user can select between various symbols, such as those shown in Figure 2, to build up a workflow which is then actuated by the system. Instrumentation may be directly controlled by the workflow so that tests are performed automatically, or instructions may be made available to human operators to perform tests. Many other types of workflow node may be defined and made available as appropriate.

The manner in which the workflow nodes actually link to the databases, for example, will be familiar to those skilled in the art and will not be described in detail.

Furthermore, the nature of the database itself is not critical to the operation of the invention in its various embodiments. By way of example, the Oracle'"" database system may be employed to store static and dynamic laboratory information. However, the static and dynamic data could equally be stored in Extensible Mark-up Language (XML). Many other systems, such as SQL/DS, may be equally suitable depending upon the specific tasks to be carried out.