The invention relates generally to the field of task management. In particular, the invention relates to an integrated system and method for orchestrating the testing of samples.
Testing of samples, especially chemical testing for screening compounds that satisfy certain properties, often requires a large number of tests. Often, a large number of samples are involved. Each sample may require several tests or assays to be conducted thereon. Test results in one test sometimes may determine whether subsequent tests will be required. For example, as is often the case, only a small number of screened compounds can meet the selection criteria. Current laboratory processes are not ideally suited for such screening processes. Some of these reasons are as follows:
1) Large number of assays: Typically the screening process requires a number of assays to be run on candidate compounds, to test for various properties.
2) Time consuming assays/tests: Many assays such as liquid chromatography mass spectrometer etc. typically require extensive time for processing samples and acquiring data and are therefore rate limiting steps.
3) Data Quality: The results from the tests need to be of high quality in order to allow for well-informed decisions. The analytical confidence in prior art methods may be low because of discontinuous steps in experimentation, and because data was obtained by different groups.
4) Capital Intensive Equipment: The equipment necessary to perform certain assays is very capital intensive. Many large organizations have numerous labs in one or more locations. As such, the requirement for multiple equipment or instrumentation further increases these costs.
In addition to the above issues, it is known to run the various assays in parallel as opposed to a serial manner. In the serial approach, the assays are linked successively with a pre-set selection criteria. Thus, a particular test will be conducted if a prior test result provides an acceptable result. The parallel approach comprises running multiple assays simultaneously. Although the latter approach may save time, it results in additional expense since tests are conducted on various compounds that may have been withdrawn from consideration for other reasons (i.e. due to failure of another assay etc.).
The foregoing creates challenges and constraints for a method and system for screening drugs. It is an object of the present invention to mitigate or obviate at least one of the above mentioned disadvantages.
The invention provides a system and method for testing samples and, in one embodiment, a system for directing and coordinating the operations of hardware components and performance of tasks of laboratory personnel. The system includes a user interface for receiving requests from one or more users. Each request comprises a list of one or more samples to be tested and specifies one or more tests to be conducted on each sample. The system also includes a sample preparation station for maintaining a library of all received samples and creating a sublibrary of samples based on the test(s) to be conducted. The system directs hardware components and laboratory personnel (collectively, laboratory resources) to conduct the requested tests and reports test results to the user(s) who have requested the test(s).
Optionally, the user can specify, in the request, a test strategy to conduct tests in parallel, in series, or a combination thereof. The test strategy can also include branching conditions to specify the parameters for promoting a sample on to subsequent tests or which subsequent tests to conduct depending on the results of prior tests. The system may generate an order for conducting the tests based on the test strategy and/or branching conditions specified and direct laboratory resources to conduct each requested test following the order generated.
In another feature, the system permits dynamic preparation of sublibraries. For example, upon completion of a given test on a given sample, the system may direct the sample preparation station to create a further sublibrary, including such sample, for a subsequent test. In this way, sublibraries are created including only those samples that are promoted for further testing. In one aspect, the creation of the further sublibrary can be started as soon as one sample from the previous sublibrary is ready to be promoted. In this way, sublibraries can be generated dynamically in response to test results of individual samples without waiting for all samples or a sublibrary to be tested.
In other aspects the invention provides various combinations and subsets of the aspects described above.
For the purposes of description, but not of limitation, the foregoing and other aspects of invention are explained in greater detail with reference to the accompanying drawings, in which:
The description which follows and the embodiments described therein are provided by way of illustration of an example, or examples, of particular embodiments of the principles of the present invention. These examples are provided for the purposes of explanation, and not limitation, of those principles and of the invention. In the description which follows, like parts are marked throughout the specification and the drawings with the same respective reference numerals.
In one aspect, the present invention relates to a system and method for the orchestration of testing samples. Although the example of chemical or drug testing is used to illustrate the invention, it will be understood that the invention is not limited to such application and may be equally used for any other purposes such as stress testing or nondestructive testing of finished products in a quality control procedure. In general, the invention can be adapted to coordinate or orchestrate any testing protocol.
In the embodiment of the invention described herein, examples of chemical testing are provided wherein chemical samples are deposited tested using commonly known microtitre plates. Such plates are transported to the test or assay station, which includes the required equipment, apparatus or personnel for conducting the desired test or assay.
By way of example,
The communication components include a data processing module 114 for processing and analyzing data obtained from the various tests and coordinating the flow of data through the system as will be described in greater detail below. The user communication subsystem 116 provides services allowing a user to interact with the system. Users of the system may be scientists, laboratory technicians, facility staff or other department or institution personnel. In general, a user may be anyone that interfaces with the system to conduct tests on samples or access test data. This will assume that the users have any required security clearances to access the system. The user communication subsystem 116 may also include a display terminal 118 for providing system status information, such as availability of hardware resources, status of experiments, test results or other relevant information to a user. The system may also include an administration workstation 120, allowing a user to interact with the system, so that the user may, for example, control the operation of the system, the workflow executed by the system, or monitor the progress of various experiments performed by the hardware resources. In addition, the system may also provide remote access to a user in the form of an information portal 122. The information portal 122 provides the remote display of a user interface that provides a user with status and other information and allows a user to access the system using the user's own computer resources. User's own computer resources may include a computer workstation, a terminal, or a handheld computer, among others, which may or may not have the same operating system used by the user communication subsystem 116.
The software components 104 include a process integration server 124, which coordinates and orchestrates the operation of laboratory resources including hardware components and/or laboratory personnel. The software components may also include various instrument automation components. For each hardware component, there can be provided a corresponding software component for the automation and control thereof. There can also be a corresponding data acquisition module for each of the hardware components for acquiring data for the test conducted and coordinating the data flow.
As will be described below, the software components 104 also may include a scheduler (not shown in
Generally, when requesting testing of a sample, the user provides the sample to a laboratory, for conducting planned tests. Samples provided by users are maintained in a sample library. Sublibraries of samples are then prepared, based on the tests to be conducted. That is, one or more samples on which a given test is to be conducted are grouped into a sublibrary. In a preferred embodiment, each sublibrary may comprise samples on one or more microtitre plates as known in the art. The wells of such plates contain a volume of the desired samples. As will be appreciated by persons skilled in the art, microtitre plates are designed with an array of wells (each adapted to receive a small volume of sample). In the result, the location of each sample on the plate can be specifically assigned, or mapped, to a particular well. This facilitates the tracking of a sample as it passes through required testing steps. This is further described below.
The reformatter 108 shown in
The plates used in the system are uniquely identified so that the location and status of each plates can be determined, preferably in real time. To accomplish this, each plate may be provided with an identification device such as a bar code label or RF (radio frequency) chip etc. Various other devices will be known too. In conjunction with such identification devices. The various stations of the system (including reformatter etc.) may include a reader to read the identification device and to identify, the plates. Such readers can also be connected to the process integration server so that the location and/or status of each plate can be tracked and monitored. As mentioned above, each sample well on a plate can be specifically mapped. Thus, by tracking each plate, specific information concerning such sample may be tracked.
Assay station 110 is preferably enclosed for safety, reliability and protection from the external environment.
An analyzer station 112 may be provided for analyzing the test results and collecting experimental data. For example, analyzer station 112 may be a high throughput liquid chromatography mass spectrometry (LC-MS) workstation. Such a workstation enables its users to automatically analyze a large number of microtitre plate samples at high speed with LC-MS technology. Samples from microtitre plates may be injected at random into an LC-MS at high speeds. Instruments such as an automated incubator (controlled environment) can also be used to supply these plates at random with high speed to an auto-sampler (not shown) that will inject samples into an LC-MS workstation. A data acquisition unit (not shown) connected to analyzer station 112 captures data generated by, analyzer station 112, such as a high throughput LC-MS workstation, and transmits the captured data to process integration server 124 for further processing.
The software system 400 has a number of components to provide its functionality. The process integration server 124 provides the function of orchestration. Other components may include network messaging module 402, data warehouse 404, information services module 406, process scheduler 408, instrument cell subsystem 410 for each of the reformatter 108, assay station 110 and analyzer station 112, decision module 420, workflow interface subsystem 422 and analytics module 424.
In general, messages are generated and exchanged for establishing communication between and among the process integration server 124 and various data processing and logic process units. For example, the network messaging module 402 exchanges messages with various hardware subsystems to control start, stop, operations of the hardware, data collection, and to monitor hardware subsystems. The network messaging module 402 also exchanges messages with user communication subsystem 116 for receiving inputs from and communicating output to users. These messages may be in the form of any network messages conforming to a suitable protocol or protocols, such as web service messages in http (hypertext transfer protocol) format, or electronic control signals if a hardware unit is directly controllable by software system 400.
Data warehouse 404 is a data depository Data warehouse 404 may consist of one database or several integrated databases, stored on one storage medium, or several different storage media, or any suitable storage or memory means. Data warehouse 404 stores data as acquired from each workcell during experiments or upon completion of experiments. A complete audit trail of each experiment may be collected at each hardware unit and archived in data warehouse 404. Such audit data may include, for example, the location of a sample and the time the sample stayed at that location, the test conditions of an experiment conducted on a sample at a workstation, status information of a hardware unit when conducting an experiment, among others. Processed data, i.e., data generated from a data analysis operation on raw data, are also stored in data warehouse 404. For easy storage and retrieval as well as for access control, the database may be a secure SQL database. A laboratory information management system (LIMS) may also be provided with the database to provide further integration and unification of data acquired in any given screening campaign or in multiple screening campaigns. Alternatively, there may be provided an interface for exchanging data with an external LIMS.
Information services module 406 is a subsystem that provides software services allowing the communication between users and the system 400. Users of the orchestrated laboratory system 100 and the software system 400 may include researchers, scientists, laboratory personnel, facility staff and facility managers. Information services module 406 is responsible for providing a user interface, such as a graphical user interface, to allow users to communicate with the system. The user interface may be accessible remotely, no matter where a user is located. Such user interfaces may be provided, for example, by Web-browser-based software applications, software applications resident on either a fixed or wireless mobile networked computing device, or a display terminal directly controlled by information services module 406. Input can be entered by a user through the user interface. Information services module 406 can request data from data warehouse 404 and present the data in a suitable format for user review. Status information, such as progress of experiments, can be sent to users as system messages or may be communicated to users on display terminal 118 or information portal 122. Information services module 406 may further distinguish the types of data and their respective intended user and present the data differently so as to tailor the portal presentation specific to users' particular roles within a laboratory. For example, information regarding status of various instruments, including assays being run on instruments or workstations, may be delivered to users by network messaging module 402 on information portal 122, without any restriction. On the other hand, test plans and modifications thereof may be delivered to scientists in a trusted fashion, requiring user authentication.
The entry form 500 shown in
Although
Through similar user interfaces, a user can also define or specify a test strategy for testing the compounds specified. This can be achieved through specifying interdependencies of the assays to be conducted. For example, the user can specify a sequence or order to perform the assays, as shown in
Referring to an embodiment of the invention as shown in
The software portion, namely, instrument cell subsystem 410, controls and monitors the operation of the corresponding hardware unit and is responsible for the automated operation, or “walk-away” operation, of each hardware unit. An experiment is set up by supplying the required samples and the requisite instructions on experimental procedures to be carried out. This allows instructions to be sent to the required laboratory resource to start a test procedure. Once a procedure is started, the instrument cell subsystem 410 is responsible for directing the corresponding hardware instrument to carry out the steps without human intervention.
Acquisition of experiment data can be automated. A hardware instrument may be provided with its own dedicated detection units and data acquisition software. The software application may be executing on a processor physically located in the vicinity of the hardware unit, or may be executing on a processor remote from the hardware unit, such as a central computer located in a control room. The hardware unit may also be serviced by a generic software application that is designed for servicing all hardware units operated by a laboratory. Instrument cell subsystem 410 may also be responsible for capturing data from the experiment or samples, if the hardware instrument is not equipped with its data acquisition software.
Instrument cell subsystems for other instrument cells may have a similar structure, although it will be appreciated that the function of each instrument cell subsystem will vary. For other types of workcells, other software modules may be required. For example, for an analyzer station 112, there will be a data acquisition module. If the analyzer station 112 has its own dedicated data acquisition software application, the data acquisition module will only be responsible for interfacing the dedicated data acquisition software application with process integration server 124; otherwise, the data acquisition module will also be responsible for interacting with data acquisition devices of the analyzer station 112 to capture data and transmit the captured data to integration server 124.
Process scheduler 408 is a software service subsystem that applies laboratory experiment rules to the construction of a laboratory workflow strategy. A scientist or researcher submits a user request to the system 400 through a user interface provided by the system 400. The user request generally includes a test plan, which includes a list of one or more samples to be tested as well as an indication of one or more assays or analyses (i.e., tests) to be conducted on each sample. The test plan may also include a test strategy. The user can specify a test strategy to conduct tests in parallel, in serial, or in a combination thereof. Branching conditions can also be specified. The scheduler 408 analyzes the test plan and determines an order of running all assays in the specified set of assays. An example of a test strategy is provided in
Alternatively, test strategy may be implicitly specified through interdependencies and priorities of the assays. For example, for a process screening for desirable pharmaceutical components, it may be desirable to run all toxic assays first. Any compound that fails a toxic assay may be rejected immediately. The process scheduler 408 may schedule to run all toxic assays in parallel and as the first step in a series of tests.
Running one assay may require a series of steps such as reformatting samples, conducting experiments on the samples, and analyzing experimental results to capture data. Laboratory resources required for each step of an assay as well as time required are generally known in advance. This information may be stored in a memory means accessible to scheduler 408 or in a permanent storage device, such as a hard disk. Based on the assays requested by a user, the scheduler 408 may also develop a list of required instrument units, as well as the required laboratory personnel, for performing the tests.
Decision module 420 is a software service subsystem that examines information obtained from laboratory instrument subsystems, by way of their software service components or instrument cell subsystem 410 provided by process integration server 124. Decision module 420 applies heuristics to the determination of adjustments to subsequent laboratory process flows orchestrated with the process integration server 124.
For example, a user can specify a test acceptance criteria, or “hurdle property”, for “promoting” a sample to the next scheduled assay. Failing a single test acceptance criteria may eliminate a compound immediately, without the need of continuing with other assays. Other heuristic methods can be used, such as passing control samples (such as test markers or “canaries”) through to subsequent tests, or basing the hurdle rate on the capacity of the downstream devices. A test acceptance criteria may also be cumulative in that only after failing a number of similar hurdle properties will the compound be eliminated. The decision module 420 can make the decision automatically to determine whether to permit the compound to proceed (or, to be “promoted”) to the next assay. This allows the automatic running of all assays once the samples are provided to the system 100. Alternatively, the researcher can choose to be advised on the status of each test so that a decision can be made on the hurdle property while the results are being reported (as described further below).
Workflow interface subsystem 422 is a subsystem that provides software services allowing laboratory personnel and research scientists to interact with the system, monitor the process of each experiment, monitor the status of the laboratory instruments, and initiate, modify or execute laboratory processes. To the extent that some elements of the orchestrated laboratory flow process are performed by laboratory personnel, and not laboratory instrument subsystems, inherent in such a configuration is the communication with such personnel by the orchestration components and the process integration server, during the course of initiating, adjusting, and executing the laboratory process. The communication may be in the form of e-mail messages, notification messages on a computer display, status indication displayed in a message window, an audio message or any other suitable form.
Once an assay is completed for a compound, the decision module 420 of the software system 400 makes a decision as to whether the compound should be promoted. A message is then sent to the laboratory resources scheduled for the next step. The next step may be further compound detection, other experiments, or sample preparation, for example. If the hardware resource for the next step is completely automated, the message may be in the form of a control signal to commence operation of the hardware unit. If the hardware resource for the next step is not completely automated, the message may be an e-mail message sent to a laboratory technician or a test facility staff responsible for the hardware unit so that that person may take the necessary steps to commence the operation of the hardware unit to start the next step. In case where the compound is not promoted, there may not be any further steps to be performed on the compound. This helps to reduce the number of unnecessary testing and thereby speed up the screening process.
Results analysis module 424 provides the necessary data analysis services and is part of the data processing module 114. Data generated by hardware units and acquired by their associated data acquisition software applications are analyzed by the results analysis module 424. Results analysis module 424 typically has a statistics component for extracting statistical information from raw data. It may also have graphing components for visually presenting data. Data may be analyzed as the experiment is being conducted, for example, by periodically polling the hardware instrument for new data, or upon completion of the experiment. Results analysis module 424 may also process data in real-time and provide feed-back to the hardware unit for optimizing compound detection and data acquisition. For example, results analysis module 424 may analyze data streams from a LC-MS workstation, locate signal peaks, and provide feed-back to the LC-MS workstation so the detection parameters may be optimized in real-time. Results analysis module 424 may be custom programmed for those specific experiments conducted in a laboratory, or may be adapted from commercially available data analysis software. Results analysis module 424 may also make experiment results available to users, laboratory personnel, or others for viewing and process decision-making.
In another embodiment, orchestration software system 400 interconnects experiment instruments to support an orchestrated testing environment 600 as illustrated in
Each self-contained, automated laboratory instrument, such as the reformatter, work cell etc., constitutes an individual laboratory service process. Laboratory instruments 604 interacts with each other and other elements in the orchestrated testing environment 600 through interchange hub 602. For example, laboratory personnel 606 interact with process integration server 124 through interchange hub 602 in the form of e-mail messages and data entry forms. Network messaging module 402 enables the initiation and completion of test procedures conducted by workcells, such as sample transfer 608, sample preparation and testing 610 and sample analysis 612. Communication may be in the form of web messages delivered to interchange hub 602, which messages are then processed by process integration server 124 and delivered to their respective destinations for further processing. A web portal 614 (or a display terminal, not shown in
Orchestration software system 400 interconnects the individual laboratory instruments to provide an integrated laboratory environment 600. The laboratory process flow is determined and adjusted by the process integration server 124 according to data received from individual laboratory instrument systems. These data are obtained as these systems perform their assigned test procedures following the process flow.
The environment 600 may be supported by custom software. Conveniently, commercially available software also may be used, with only necessary custom programming to integrate the commercially available software. For example, BizTalk™ commercially available from Microsoft Corporation may be used to perform some of the functions required by process integration server 124 or workflow interface subsystem 422.
At the step of sending and receiving assay request 702, a laboratory staff member, for example, starts the workflow by sending an operation request. The request may also be sent automatically by the system. For example, when samples are delivered to a workcell, such as an LC-MS workstation for purity assay, upon checking in of the samples using a barcode reader, an XML form is sent from the LC-MS workstation and received by process integration server 124. The process integration server 124 uses the message to identify the compound to be tested at the step of identifying compound 704 and the assay requested in order to schedule and instruct the appropriate workcell for performing the assay. At the step of commencing assay 706, a message (for example, in XML format) is sent to an appropriate hardware unit, such as assay station 110 to commence the requested assay. Data is captured during the performance of the assay at the step of capturing data 708 where possible. Certain data may only be collected upon completion of experiment. When all data are collected, assay results are returned from the hardware units to process integration server at a step of returning assay results 710. The returned assay results are assigned to the compound, namely associated with the compound, at the assigning assay results 712 step. The assay results, associated with the compound, are next stored in data warehouse 404 for later retrieval or further processing. Once such a generic workflow is defined, it may be repeatedly executed by the hardware and software components of the orchestrated laboratory system 100.
Referring to
In operation, a user submits a user request for running a number of assays on a list of compounds to the system 100 through a user interface. Optionally, the scheduler 408 analyzes the user request to generate an order to run these assays on each of the compounds. Upon confirmation or notification that compound samples are arrived at the laboratory, instructions are sent to the reformatter 108 to reformat plates, namely, to create a sublibrary from the library of samples, for conducting the first assay. The status of the laboratory resources and each sample as well as the data generated from the tests are monitored and stored. At the completion of each assay conducted on each sample, the decision module 420 may compare test results with a test acceptance criterion, if one is supplied by the user. If the test results are within acceptable range as compared with the test acceptance criterion, the compound being tested is to be “promoted”, i.e., to be further tested. If so, instructions are sent to reformatter to reformat the compound for the next assay. Otherwise, a message may be sent to the user so the user can determine whether the compound is to be to promoted. These steps are repeated until all compounds specified in the user requests are tested.
Referring to
The process has the following steps: obtaining test plan 1002, obtaining samples 1004, initiating sample preparation 1006, initiating experiment procedures 1008, data acquisition 1010, performing data analysis 1012, optionally presenting test results 1014 to a user of the system, deciding compounds promotion 1016, making subsequent assay decision 1018, and process termination 1020.
The process starts by obtaining a test plan related to the screening campaign at an obtaining test plan 1002 step. The test plan may be one entered by a user in the user request, or modified from a previous test plan. As described earlier, a test plan identifies a list of samples or compounds, a set of assays for each compound and optionally a test strategy. The test strategy may request that the assays be run in parallel, in serial, in a combination of parallel or serial, or including branching conditions. Test procedures and experiment protocols may also be defined or specified. The test plan is retrieved at the obtaining test plan 1002 step.
When determining next the samples of compounds required, the scheduler 408 analyses the test plan (or test plans if there are more than one user request outstanding), and determines an order to conduct the assays. As will be appreciated, if a sequential order is provided in the test plan, the integration server 124 simply follows the order in scheduling the assays. Once an assay to be performed is determined, the required compounds or samples can also be determined by identifying all samples for the assay from the test plan or plans. In general, if a decision tree is specified, the decision tree provides an order to conduct the assays. If no order is specified, or if at one stage, parallel testing is requested, then these assays can be performed in parallel, namely, performed in any time sequence. If not sufficient hardware units are available for testing all samples, a round robin order, or any other suitable order, may be selected by the system for parallel testing. In any case, the system will first select an assay for testing, based on the test strategy, or decision tree, provided in the user request, namely the test plan. If a priority is specified, assays having the same priority are scheduled together, starting from the highest priority. Optionally, the system may also poll the required hardware units or examine the schedule information of the required hardware unit to determine whether all these hardware units required for conducting the chosen assay will be available. If any of them will not be available when required, the system may attempt to schedule next assay until an assay can be scheduled. As described above, once the chosen assay is determined, samples are selected and provided to reformatter 108.
Referring to
Upon confirmation that samples are in reformatter 108, process integration server 124 sends a web service message to the instrument cell subsystem 410 responsible for reformatter 108. The instrument cell subsystem 410 instructs reformatter 108 or a laboratory technician to start the reformatter 108 to prepare sample plates for the requested assays at an initiating sample preparation 1006 step. Reformatter 108, through its instrument cell subsystem 410, informs process integration server 124 when sample preparation is completed. In a semi-automated system, process integration server 124 sends an e-mail message to laboratory personnel, updates the status information presented in information portal 122, or otherwise notifies the laboratory technician of the completion of sample preparation so that the laboratory technician may transport the prepared samples to assay station 110 for testing. If barcode or other labeling technology is used, a bar code reader may be employed to check in and check out the samples. Process integration server 124 may then record the location of each sample, thus providing location tracking of each of the samples as they move from hardware unit to hardware unit. In an automated system, process integration server 124 directs a transport system to move the prepared samples from reformatter 108 to assay station 110 and records the movement and location of each sample.
Experiments are conducted at assay station 110. An instrument cell subsystem 410 responsible for assay station 110 is instructed by process integration server 124 to start the experiments at an initiating experiment procedures 1008 step. Experiment procedures specified in the test plan or steps in the protocol selected for the test plan are followed by instruments and devices of assay station 110, such as robotic devices and liquid handling devices, in an automated fashion. Upon completion of all procedures, the instrument cell subsystem 410 notifies process integration server 124 by sending a notification message, for example. Again, in a semi-automated system, process integration server 124 may notify a laboratory technician or a researcher of the completion of the experiment by sending an e-mail message, updating the status information presented in information portal 122, or by employing some other suitable means. The e-mail message may simply provide status information. It may also include an experiment report to provide more detailed information about the assay or experiment completed. Any other suitable audio or visual means may be utilized to provide the notification.
As described earlier, dedicated software or instrument cell subsystem 410 responsible for a workcell captures experiment results and transmits the captured data to process integration server 124 for saving to data warehouse 404. Data acquisition 1010 is performed either when the experiment procedures are being conducted or at the conclusion of the experiment procedures, depending on the nature of assay and the experiment procedures. Once the results are captured, they are stored in data warehouse 404.
Next, process integration server 124 waits for results from analytics module 424. The results analysis module 424 polls the hardware units periodically for new data. Once a hardware unit has new data available, in a data analysis 1012 step, the results analysis module 424 processes the raw data and extracts information from the data. Data analysis operations may include statistical analysis of the data, formatting data, i.e., manipulating for sharing with other components of the system or other users, as well as preparing data for visualization. Results of data analysis 1012 are also stored in data warehouse 404 as the data are processed.
At the step of presenting test results 1014, these results are communicated to users, such as researchers and laboratory personnel. The results may be “pushed” to the users by updating a status screen display constantly as results of each assay become available; they may also be “pulled” by users as a response to request for data or assay results. As will be appreciated, because the test results are communicated back to the integration server 124 in real time, or at least during each assay, what are available to users and therefore can be communicated to users are not limited to test results. As the test results are stored for each sample at least during each assay, the storing of test results therefore enables the system to provide status information to the user in real time. Along with the test result, test conditions of each experiment, such as temperature or agitation rate, can be stored. The status information therefore may include the assays already conducted on the sample and assays still left to be conducted, the test results of conducted assays, and test conditions of the conducted assays, among others.
At this step, status information can be communicated to a user as requested, or constantly communicated to the user as the information is updated. Because of the potentially large quantity of information associated with such a screening process, the information can be organized and presented in a summary form, and in a graphical format. For example, the results and status of the tests can be shown in a flow chart format, corresponding to the decision tree specified by the user, as that shown in
At compounds promotion 1016 step, process integration server 124 retrieves the results of the assay and forward the results to its decision module 420. At least the relevant test acceptance criteria for the assay is also forwarded to or made available to decision module 420. The decision module 420 compares the assay results with the test acceptance criteria to determine whether to advance all, some or none of the compounds. A sample is to advance if its test results pass the associated test acceptance criteria. An advanced compound will have further assays performed thereon until all assays requested by the user have been completed.
If the test results fail the test acceptance criteria, the sample may be eliminated from further testing. In general, a sample is eliminated from further testing if it fails a specified set of tests. A special case is for the sample to fail a single test. As discussed earlier, in general, the decision to eliminate a sample is made accumulatively on the failure of several tests. The controlling factor may be the number of failed tests in the specified set of tests or the failure of all tests in a more confined group. How the accumulative decision is to be made is specified by a user, such as a scientist, when submitting a job request entry form. If a sample is not to be promoted, no further tests will be performed on the failed sample. The sample can be removed from the schedule for further testing. If so, none of the hardware components that are scheduled to perform further tests on the failed sample will be requested to perform the cancelled tests. Alternatively, a message may be sent to all such hardware components to explicitly cancel further testing, or to all staff members who would otherwise test the failed sample as scheduled. This tends to reduce the wasted time and resources spent unnecessarily on samples that are already known to be unsuitable.
Whatever the decision is rendered by the software system 400, the decision may be reviewed and modified by a user. For example, when screening for compounds, a user may review the results of current assay or all assays performed thus far and then decide whether to fail a compound. Test results as well as test acceptance criteria may be reviewed along with the machine-made decision. The results may be provided through a user interface, such as an information portal 122. The user may confirm the automatically rendered decision. The user may also use his or her own judgment to decide whether to modify, namely manually override, the automatically rendered decision. A user can make these modifications through, for example, a user screen shown in
In case a further assay is to be performed, the process returns to the step of obtaining samples 1004 step. Namely, process integration server 124 instructs reformatter 108 to prepare the requisite plates for the next assay, without including any compounds that are already eliminated, and the process will be repeated from there.
As can be seen, according to this process, each assay is scheduled for a compound only if necessary. The scheduling of the assay is dynamic in that the process integration server 124 determines the next step and directs the laboratory resources to start the next assay only when test results of the current assay are known. Because test results are communicated back to the process integration server 124 in real time, the next assay can be scheduled in real time as well, upon the completion of the current assay.
Further, the scheduling can incorporate availability of laboratory resources, including hardware resources and laboratory personnel. In general, it tends to be more difficult to predict when a laboratory resource may become unavailable at the beginning of the testing process, which may last for several days. But, it may be more predictable whether a laboratory resource may become unavailable when the next assay is to be conducted, which may be only several hours in the future. In addition, should a hardware resource becomes unavailable during an assay, dynamic scheduling also allows the screening process to be re-scheduled, instead of suspending the process until the failed hardware resource becomes available again. For example, suppose during a purity assay, an LC-MS workstation breaks down, the integration server 124 can dynamically schedule and start the next assay to be carried out if the next assay does not require an LC-MS workstation, instead of waiting for the current assay to finish. Of course, it is understood that the next assay does not depend on the result of the current assay, though it is also possible to program the integration server 124 to ignore the results of the current assay, if the estimated time for restoring the failed hardware resource exceeds certain limit. Although this example makes reference to hardware failure, it is understood that the same principle can be applied to unavailability of laboratory personnel as well.
At the end of the screening process, the network messaging module 402 may generate a message to notify the user of the termination of the process. As will be understood, the process may terminate either when all requested assays are conducted or when there are no further assays to be conducted. Of course, a user may also decide to terminate the process at any time. The notification may simply inform the user that the process is now terminated so that the user can request a final test report. The system 400 may also generate a test report at the end of the process, without being requested by the user, and send the test report to the user, along with the notification message. The test report may include summary information relating to the screening process, such as number of compounds that pass all test criteria and the test conditions of each assay. Further drill-down on each assay or each compound may also be provided in the test report, for the user to explore further the test results.
As can be seen in
In one embodiment, a process alternative to that shown in
The steps are as follows. First, at step 1302, the compounds from a library to be screened are delivered to the orchestrated laboratory system 100, in a set of formatted microtitre plates, together with the data corresponding to each of the compounds. Next, at step 1304, reformatter 108 reformats these samples into the appropriate microtitre plates to form a sublibrary of samples. At step 1306, reformatted samples are transported to the appropriate workcell or workstations for performing the assay, either by a robotic transport device or moved by a laboratory technician.
The purity assay commences at step 1308. As purity data is being obtained, decisions will start to be made on whether a compound passes the property hurdle or not at step 1310. As described, the system 400 can decide whether to advance a compound for further testing by comparing assay results against the associated test acceptance criteria. Scientists can review the system decision to advance or eliminate a compound, and to confirm or override the decision, or vary the hurdle rates, or choose other heuristics to indirectly decide whether to pass compounds to the next stage.
If at least one compound passes the property hurdle, the system 400 at step 1310 automatically starts passing information on to the reformatter 108, through the process integration server 124, in order to start reformatting microtitre plates for the subsequent assay. The reformatter 108 reformats all the passed compounds into new microtitre plates as directed. If the next assay is not immediately performed upon creation of the sublibrary, the plates are stored in standard format container temporarily, waiting to be tested.
Various embodiments of the invention have now been described in detail. Those skilled in the art will appreciate that numerous modifications, adaptations and variations may be made to the embodiments without departing from the scope of the invention. Since changes in and or additions to the above-described best mode may be made without departing from the nature, spirit or scope of the invention, the invention is not to be limited to those details but only by the appended claims.
Number | Date | Country | Kind |
---|---|---|---|
PCT CA2005 000567 | Apr 2005 | US | national |
This is a continuation-in-part application of International Application No. PCT/CA2005/000567, filed Apr. 15, 2004, which claims priority from U.S. Provisional Application No. 60/562,851 and U.S. Provisional Application No. 60/648,225, each of which is incorporated herein by reference in its entirety.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/CA2006/000122 | 2/1/2006 | WO | 00 | 3/24/2010 |