CN111406292B

CN111406292B - System and method for efficiently performing bioassays

Info

Publication number: CN111406292B
Application number: CN201880077205.6A
Authority: CN
Inventors: 克拉克·鲍尔斯; 威廉·霍华德·加里森; 迈克尔·T·范西克勒; 迈克尔·芬斯克
Original assignee: Becton Dickinson and Co
Current assignee: Becton Dickinson and Co
Priority date: 2017-12-07
Filing date: 2018-12-06
Publication date: 2024-04-05
Anticipated expiration: 2038-12-06
Also published as: EP3721377A4; US20200303066A1; CA3084402A1; US11581089B2; JP2023113651A; CN111406292A; JP2021505848A; EP3721377A1; JP7279041B2; US20240105291A1; US20230253080A1; CN118112271A; US11887703B2; WO2019113296A1

Abstract

An automated laboratory system for processing biological samples in a batch-type manner is disclosed. In one embodiment, the system may receive assay instructions for biological sample processing between a plurality of devices. The apparatus may include an analytical instrument and one or more analytical systems. The system may include a flow orchestration core application for determining an order of execution for assays for sample ordering.

Description

System and method for efficiently performing bioassays

RELATED APPLICATIONS

The present application claims priority from 35 u.s.c. ≡119 (e) for the following applications: U.S. provisional application No.62/596,052 filed on 7 of 12 th 2017, U.S. provisional application No.62/596,032 filed on 7 of 12 th 2017, and U.S. provisional application No.62/626,581 filed on 5 of 2 nd 2018. The contents of each of these related applications are incorporated by reference herein in their entirety.

Technical Field

The present disclosure relates generally to the field of diagnostic automation, and more particularly to automated flow orchestration of biometrics.

Background

Diagnostic testing of biological samples helps the healthcare industry to diagnose and treat diseases quickly and effectively. With the increasing demand, clinical laboratories performing such diagnostic tests receive hundreds or thousands of samples per day. Automation of sample analysis may help address challenges presented by managing such large numbers of samples. Automated sample analysis is typically performed by automated analytical instruments, which are typically independent systems that perform multi-step processing of biological samples to obtain diagnostic results.

Automated clinical analysis instruments provide a user with a series of automated tests that can be performed on a provided sample. However, when samples arrive at the laboratory, they are typically not directly available for analysis. To prepare a sample for testing with an automated analytical instrument, laboratory technicians typically transfer an aliquot of the sample from a primary container or primary tube received by the laboratory into a secondary container or secondary tube suitable for the analytical instrument. In addition, the skilled artisan typically needs to know what test is to be performed on the sample so that the skilled artisan can select a test-specific reagent or diluent to be paired with the sample. This is time consuming and can cause operator error and exposure to infectious disease.

The pre-analytical instrument is intended to assist in preparing the sample for analysis and further to eliminate technician intervention from the laboratory in the flow schedule between the receipt of the sample and the appearance of the analytical instrument test results. However, many of these instruments still require significant technician involvement, such as before loading the sample into the pre-analytical instrument, after the sample has been prepared by the pre-analytical instrument, and after the analysis instrument has completed analysis.

For example, some pre-analytical instruments may automatically transfer an aliquot of a sample from a first container to a second container. However, such systems typically require a technician to manually pair the identification codes of the first and second containers to load the first and second containers into the system, which is time consuming and error prone.

Furthermore, many of these systems cannot be integrated with one or more analytical instruments. In this regard, after the analysis is completed, the technician is required to manually transfer the sample from the pre-analysis instrument to the analysis instrument and from the analysis instrument to the storage location. This can divert the attention of the technician to tedious work and can cause interference because the technician must pay attention to the advance of the sample in the pre-analytical instrument and the analytical instrument all the time so that the technician is ready to transfer the sample when it is prepared, thereby minimizing downtime.

In addition, current pre-analytical and analytical instruments typically process samples in a continuous flow as they are introduced into the system. Thus, such systems process samples in a predefined order, typically set by a user. In this regard, existing pre-analytical instruments typically do not take into account information other than user-provided information in determining the next sample to be prepared in the sequence. Furthermore, pre-analytical instruments typically prepare samples at a different rate than analytical instruments, which further complicates the integration between the pre-analytical instrument and the analytical instrument. In this regard, a technician is required to continuously track samples prepared by the pre-analytical instrument until the accumulation of samples for all batches is complete for manual transfer to the analytical instrument. Alternatively, the technician may transfer portions of the batch to the analytical instrument, which may reduce the productivity of the analytical instrument.

Disclosure of Invention

Disclosed herein are systems and methods for performing assays on biological samples and high throughput automated bioassays. In one embodiment, the system comprises: a memory storing instructions; and a processor programmed by the instructions to perform a method comprising: receiving a plurality of assay instructions for a plurality of biological samples; and determining a plurality of assays to be performed for each of the plurality of biological samples based on the assay instructions; determining available assay resources for performing a plurality of assays; determining an order for performing each of the plurality of assays based on available assay resources so as to maximize efficiency of performing the plurality of assays; and instructing one or more analytical instruments to perform a plurality of assays based on the determined order.

In one embodiment, the method comprises: receiving a plurality of assay instructions for a plurality of biological samples; determining a plurality of assays to be performed for each of a plurality of biological samples based on the assay instructions; determining available assay resources for performing a plurality of assays; determining an order for performing each of the plurality of assays based on available assay resources so as to maximize efficiency of performing the plurality of assays; and instructing one or more analytical instruments to perform a plurality of assays based on the determined order.

In one embodiment, the system comprises: a memory storing instructions; and a processor programmed by instructions to perform a method comprising: receiving a plurality of assay instructions for a plurality of biological samples from a plurality of analysis systems; determining a plurality of assays to be performed for each of a plurality of biological samples based on the assay instructions; identifying an available analysis system for running each of the plurality of assays; determining available assay resources within the identified analysis system for performing a plurality of assays; determining an order for performing each of the plurality of assays based on available assay resources so as to maximize efficiency of performing the plurality of assays; and instructing the one or more analysis systems to perform a particular assay of the plurality of assays based on the determined order.

In one embodiment, the system comprises: a first automation module configured to prepare a biological sample for at least one molecular assay; at least one second automation module for receiving the biological sample prepared by the first automation module and performing molecular assays on the received biological sample, wherein the first and second automation modules each comprise: at least one automated instrument; and a process orchestration core computing device in communication with the first automation module, the second automation module, and the laboratory information system, wherein the process orchestration core computing device receives instructions from the analysis system for processing biological samples and manages processing resources of the first automation device and the second automation device, wherein the process orchestration core computing device comprises at least four processing layers: a first layer (service level object layer) in communication with the analysis system, a flow orchestration layer, an instrument module control layer, and an instrument module layer, wherein the instrument module layer is in communication with the automated instruments in the first and second automated devices, and wherein the status of the automated instruments is transferred to the flow orchestration layer, and based on the current status of the analysis system, the flow orchestration core computing device groups two or more biological samples into batches, and transfers instructions to the instrument module layer to batch the samples.

Drawings

FIG. 1 is a perspective view of an analysis system according to one embodiment described herein.

FIG. 2A is a block diagram of a distributed analysis system in communication with a laboratory information system, according to one embodiment described herein.

FIG. 2B is a block diagram of a centralized analysis system in communication with a laboratory information system, according to one embodiment described herein.

FIG. 3A is a block diagram of a flow orchestration core computing device architecture according to one embodiment described herein.

FIG. 3B is a block diagram of a flow orchestration core computing device architecture according to another embodiment described herein.

FIG. 4 is a block diagram of components of a flow orchestration core application according to one embodiment described herein.

FIG. 5A is a block diagram of a flow orchestration core application and a flow orchestration sub-application according to one embodiment described herein.

FIG. 5B is a block diagram of a flow orchestration core application and a flow orchestration sub-application according to another embodiment described herein.

FIG. 6 illustrates one embodiment of a flow orchestration core application described herein.

Fig. 7 is a block diagram illustrating various instrument states for an analysis system.

Fig. 8 is a block diagram illustrating various instrument states for an analysis system.

FIG. 9 is a block diagram illustrating an exemplary assay state for an analysis system.

FIG. 10 is a flow chart of one exemplary method of determining an order of measurement or execution of measurement steps for a sample to maximize performance of an analysis system.

FIG. 11 is a block diagram of one example of determining an order of execution of assay steps for a sample to maximize performance of an analysis system.

FIG. 12 is a flow chart of an exemplary method of determining an order of execution of an update of a measurement or measurement step after receiving a new measurement instruction in an analysis system.

FIG. 13 is a flow chart of an exemplary method of determining an order of execution of an assay or assay steps and an updated order of execution to maximize a performance metric.

FIG. 14 is a flow chart of another exemplary method of determining an order of execution of an assay or assay steps and an updated order of execution to maximize a performance metric.

FIG. 15 is a block diagram of a flow orchestration core application in communication with a hospital and laboratory information system and analysis system over a network.

FIG. 16 is a schematic diagram of a cloud server-based orchestration core application in communication with a orchestration laboratory application to coordinate automated sample processing and analysis.

Detailed Description

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, like numerals generally identify like components unless context indicates otherwise. The illustrative embodiments described in the detailed description, drawings, and claims are not meant to be limiting. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented herein. It is readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and contemplated in a variety of different configurations, all of which are explicitly contemplated and made part of the disclosure herein.

SUMMARY

The present disclosure describes devices, systems, and methods for performing processing and analysis on biological samples. In particular, a system architecture is described that coordinates automated sample processing among multiple analysis devices or systems with a high degree of automation. A flow orchestration computing device receives input from the laboratory information system, coordinates the operation of one or more analyzers and pre-analytical instruments for processing samples in an information transparent and efficient manner, thereby improving the overall efficiency of running assays on multiple analysis systems and analysis instruments (also referred to as analyzers and assay devices). Various discrete inputs to the flow orchestration computing device are contemplated, the sum of which enables efficient and rapid sample processing with minimal operator input and intervention.

Sample processing and analysis system

FIG. 1 depicts an exemplary analysis system 100. The analysis system 100 may be or include an in vitro diagnostic system. As shown, such a system includes a pre-analytical instrument 104, a first analytical instrument 108a, and a second analytical instrument 108b. The pre-analysis instrument 104 may include a user interface 112 for receiving user input and an input window 116 for receiving samples. Each of these units 104, 108a and 108b is modular. Accordingly, the pre-analytical instrument 104 may be coupled to one or more analytical instruments. Furthermore, each analytical instrument in communication with the pre-analytical instrument 104 (in terms of exchanging information and samples for processing) may perform the same or different operations. For example, the first analytical instrument 108a may perform viral assays, such as human papilloma virus ("HPV") assays, while the second analytical instrument 108B may perform bacterial and parasitic assays, such as those used to detect chlamydia trachomatis, neisseria gonorrhoeae, trichomonas vaginalis, group B streptococcus, enterobacteria, and enteroparasites. However, in some embodiments, the analysis system 100 may be configured such that the first and second analysis instruments 108a, 108b are similar and capable of performing the same or similar assays. This instrument modularity allows the clinical laboratory to customize the analysis system 100 to its particular needs. The analysis system 100 is referred to herein as an electronic system.

The pre-analytical instrument 104 and the analytical instruments 108a, 108b each have hardware components that allow them to perform specified operations. For example, in one embodiment, the pre-analytical instrument 104 may be configured to pre-process biological samples in order to prepare the samples for analysis by the analytical instruments 108a, 108 b. In this regard, the pre-analytical instrument 104 may have a tray/shuttle handling robot capable of transporting sample containers from one location to another location within the instrument and to an adjacent analytical instrument, a sample container handling robot capable of transporting and/or uncapping individual sample containers, a pipette robot capable of drawing samples from one container into another container, a diluent applicator for diluting the samples, a vortex for swirling the samples, a heating plate for heating the samples, and a cooling unit for cooling the samples. The analysis instruments 108a, 108b may also have robots capable of moving containers within their individual instruments, moving containers from the pre-analysis instrument 104, and moving containers back to the pre-analysis instrument 104. The analytical instruments 108a, 108b may also include a pipette robot, a sample container handling robot, a magnetic extractor (for providing a magnetic field to a sample container (together with paramagnetic particles added to the sample) for sample purification), and any other hardware components required to perform instrument operations.

In addition to hardware components, the pre-analysis instrument 104 includes a staging or accumulation area. These areas are locations where the sample containers and other consumables are stored before they are designated for input into the workflow. These accumulation areas communicate with the flow orchestration core application so that the flow orchestration core application can assign processing information to the samples so that the instrument can process the samples according to instructions of the flow orchestration control application, as described further below.

FIG. 2A is a block diagram of an analysis system in communication with a laboratory information system, according to one embodiment described herein. In one embodiment, the analysis system 100 may include at least one pre-analysis instrument 104 and one or more automated analysis instruments 108. The pre-analytical instrument 104 may process the sample for analysis in the analytical instrument 104. The analysis instrument 108 may be configured to perform an assay on a biological sample, while the pre-analysis instrument 104 may be configured to prepare the sample for analysis by the analysis instrument 108. For example, the pre-analytical instrument 104 may transfer a biological sample from one container to another container suitable for use by the analytical instrument 108, and may also swirl, preheat, and cool the sample depending on the assay to be performed. Such an analysis instrument 108 and pre-analysis instrument 104 may each be modular, independent units with robots capable of transferring biological samples back and forth between the individual units when coupled together.

The analysis system 100 may communicate with the laboratory information system 204 over a network 208. Laboratory information system 204 may be an existing information system operated by a medical institution or a stand-alone clinical laboratory. Such a laboratory information system may provide information to the analysis system regarding the sample measurement instructions 212, the requirements 216 of ordered measurements, and patient information. In some embodiments, the analysis system 100 may receive patient information from a hospital information system.

Analysis system 100 may include a flowline core application 220 executed by a flowline core computing device 224, where the flowline core computing device 224 communicates with analysis instrumentation 108 and pre-analysis instrumentation 104 across an instrumentation interface 228, and with laboratory information system 204 over network 208. The analysis system 100 may be located behind a firewall or may be connected to the network 208 through another computing system to isolate the analysis system 100 and protect it from any inadvertent or malware that may interfere with or alter the performance of the analysis system 100.

The flow orchestration core application 220 may coordinate processes and manage resources between one or more analysis instruments 108 and the pre-analysis instrument 104 to achieve efficient utilization of available resources and to maintain activity of those resources at or above a predetermined threshold level. The performance of the analysis system 100 may be determined based on the performance metrics. For example, the performance index may be a maximum percentage of usage of processing resources available for processing demand at a given point in time. In addition, the flow orchestration core application 220 utilizes the information received from the laboratory information system 204, the analysis instrument 108, and the pre-analysis instrument 104 to reduce, significantly reduce, and even eliminate operator involvement, and make high-level decisions on activities to be performed in each instrument based on changing conditions.

In one embodiment, computing devices 232, 236 of pre-analytical instrument 104 and analytical instrument 108 execute flow orchestration sub-applications 240, 244. Such a flowsheet sub-application 240, 244 is linked to the flowsheet core application 220 for implementing the instructions provided by the flowsheet core application 224. In this regard, decisions and instructions for implementing such decisions are passed down from the flow orchestration core application 220 to the specific hardware components that perform the indicated actions. These instructions become more specific as they move down the chain from the flow orchestration core application to the individual hardware devices. Information is also passed up from the various hardware devices to the flow orchestration core application, such that the flow orchestration core application frequently receives status updates that inform the decision making process.

The flow orchestration core application 220 and the flow orchestration sub-applications 240, 244 may comprise state machines that operate on their own threads. In this regard, the core application 220 and the sub-applications 240, 244 may have a locked state for making decisions such that changes in state do not interfere with the decision making process.

The flow orchestration core application 220 and flow orchestration sub-applications 240, 244 operate to efficiently utilize the analysis instrumentation 108 and the pre-analysis instrumentation 104. Because the idle time of system resources can reduce overall performance, the goal is to achieve the desired hardware resource utilization within such an instrument.

The flow orchestration core application 220 makes decisions about biological samples to be processed and evaluated by the pre-analysis instrument 104 and the analysis instrument 108, respectively, based on information from the laboratory information system 204. The flow orchestration core application 220 organizes individual biological samples into multiple batches in the pre-analysis instrument 104, which helps to maximize the overall throughput. Samples are placed into a lot based on an identification of processing conditions (e.g., thermal cycling conditions) of the samples in the lot. Each sample in a batch is exposed to the same processing conditions (e.g., temperature, light frequency) as much as possible. However, process uniformity is not required. For example, if the samples or control (control) containers in a batch have been preheated, then the samples will not be subjected to a preheating step. Thus, the flow orchestration core application 220 "tracks" not only information about individual samples, but also information about batches in which individual samples are processed. In other words, there is a "one-to-many" relationship between the lot and the sample. Some information is sample-specific and other information is fully applicable to each sample in the batch.

In addition to performing batch processing on samples, the flowline core application 220 may also obtain a large amount of information input from various sources while controlling and coordinating the processing resources 248, 252 of the pre-analysis instrument 104 and the analysis instrument 108. Such information includes an inventory of consumables 256, 260 of the instrument, an allocation of the inventory for the processes in the queue, an operational status of the instrument hardware, a measurement of orders to be performed on the samples, availability of the samples; batch already in process, sample age, availability of the pre-analytical instrument 104 and analytical instrument 108, availability of the instrument devices 264, 268 of the pre-analytical instrument 104 and analytical instrument 108, biochemical stability of the samples and reagents 272, 276, and business or compliance practices of a particular laboratory. The pre-analytical instrument 104 and the analytical instrument 108 are also referred to herein as instrument devices. In one embodiment, the analysis system 100 includes redundant hardware and consumables such that the analysis system 100 can remain operational while the hardware is replaced and consumables are replenished.

The flow orchestration core application 220 receives the metering instructions from various external systems (e.g., laboratory information system 204, hospital information system, and another analysis system). In some embodiments, when a sample arrives in the pre-analysis instrument 104, the pre-analysis instrument 104 knows exactly what process is to be performed on the sample. The decisions about the actual processing can be largely made in advance. That is, when a sample arrives at the pre-analysis instrument, all decisions required regarding batch, timing, metering, and consumable resources will be incorporated into the flow orchestration core application 220.

The flow orchestration core application 220 may include three components: a flow orchestration state component, a flow orchestration decision maker component, and a flow orchestration engine component. Each component has a different assigned role in managing resources and controlling the operation of the pre-analytical instrument 264 and the analytical instrument 268. The process orchestration state component stores state information. The flow orchestration state component is configured to receive the operational state of the system hardware and instrumentation devices 264, 268. Thus, each instrument and the sub-modules in each instrument are configured to output information about their status, and this status information can be directly used but more commonly passed to the flow orchestration status module by the logic of the applicable instrument. The flow orchestration decision maker component makes decisions using the state information. The flow orchestration engine component performs the decisions and prevents the flow orchestration state component from being updated when the decisions are made.

In this regard, the flow orchestration core application 220 tracks consumable inventory. It is also configured to determine how much consumable quantity is allocated to the batch being processed. Using this information, the flow orchestration core application 220 is configured to determine a net consumable inventory and make process flow determinations based on the net inventory to ensure that no consumable is available to process the sample. In addition, the flow orchestration core application 220 is configured to inform the user that certain consumables need to be replenished in the instrument. Such consumables 256, 260 may include diluents, reagents, assay control samples, pipette tips, empty sample containers, extraction containers, and PCR plates, to name a few. Various sensors may be implemented to track such consumables 256, 260, such as a level sensor for bulk diluent. Moreover, the flow orchestration core application 220 can track the initial consumable inventory, how many consumables 256, 260 have been used from the initial consumable inventory to determine the net worth.

The coordination core application 220 also tracks the operational status of the analytical instrument 108 and the analytical instrument 104 itself. Based on this information, the flow orchestration core application 220 decides which samples can be processed and when processing should begin. The instrumentation 264, 268 may include physical hardware components, such as motor encoders, integrated circuits, solenoids, etc., that help the flow orchestration core application 220 track the operational state of the hardware in each instrument. An aspect of the operational state is whether there is a fault or error in the operation of a particular component. In this case, the flow orchestration core application 220 is aware of redundant devices in the system and coordinates or activates such redundant devices in the event of component operational errors or faults. In this regard, the flow orchestration core application 220 has a predetermined error protocol that it will execute in the event of component operation errors or faults. Another function performed by the flow orchestration core application 220 is to know both the instrumentation, equipment, and various components required to process a given lot, and whether hardware components, pre-analysis instrumentation, and analysis instrumentation are currently participating in or assigned to a process.

The flow orchestration core application 220 communicates with one or more information systems to obtain sample metering instructions 212. Such systems may include a hospital information system, a laboratory information system 204, an informatics system, and another assay system. The flow orchestration core application 220 is configured to obtain this information as early as possible in order to make decisions about sample processing before actually scanning the sample into the pre-analysis instrument 104. In this regard, laboratory technicians are not required to obtain sample metering order information, thereby reducing user error and freeing up time for the technician to undertake other tasks.

The flow orchestration core application 220 is also configured to track the bio/chemical/mechanical lifetime of consumable inventory and samples (e.g., assay controls and reagents), as well as the biological samples themselves in various states of execution of the assay protocol. Exceeding the limit of the useful life of the sample and the consumable can adversely affect the authenticity of the assay. This lifetime decreases with time and the biochemical properties of the reagent or sample may change if the age of the reagent or sample exceeds a certain threshold. The flow orchestration core application 220 may prioritize samples in a way that ensures that the assay protocol steps are completed before the samples or reagents exceed their lifetime.

The flowsheet core application 220 may also be configured to receive information from the pre-analysis system 104 and the analysis system 108, which will allow tracking of samples throughout sample processing. This includes tracking the acquisition of sample aliquots that are applied to different containers for sample processing, as well as sample transport from one instrument to another, e.g., sample transport from pre-analytical instrument 104 to analytical instrument 108 (and vice versa). This enables laboratory technicians to query the system and instrument for sample locations and their progress in determining. If multiple assays are ordered for a single patient sample, the flow orchestration core application 220 coordinates and tracks the execution of the multiple assays for a single sample without user intervention, thereby maximizing or at least increasing the overall efficiency of executing the assays.

Fig. 2B is a block diagram of a centralized analysis system 100B in communication with a laboratory information system, according to one embodiment described herein. The analysis system 100B in fig. 2B is similar to the analysis system 100 described with reference to fig. 2A. As described in further detail below, the analysis system 100B in fig. 2B is a centralized system having the functionality of the orchestration sub-applications 240B, 244B executed by the orchestration core computing device 224B.

In one embodiment, the analysis system 100b may include at least one pre-analysis instrument 104b and one or more automated analysis instruments 108b. The pre-analytical instrument 104b may process the sample for analysis in the analytical instrument 104 b. The analysis instrument 108b may be configured to perform an assay on a biological sample, while the pre-analysis instrument 104b may be configured to prepare the sample for analysis by the analysis instrument 108b. Analysis system 100b may communicate with laboratory information system 204b over network 208 b. Analysis system 100b may include a orchestration core application 220b executed by a orchestration core computing device 224b, where the orchestration core computing device 224b communicates with analysis instrument 108b and pre-analysis instrument 104b through interface 228b (e.g., across an instrument interface, an inter-device interface, or an intra-device interface). Analysis system 100b may communicate with laboratory information system 204b over network 208 b. The flow orchestration core application 220b may coordinate the process and manage resources between one or more analysis instruments 108b and the pre-analysis instrument 104b to achieve efficient utilization of available resources and to maintain activity of those resources at a predetermined threshold level or higher.

The orchestration core computing device 224b executes the orchestration sub-applications 240b, 244b. Such a flowline sub-application 240b, 244b links to the flowline core application 220b to implement instructions provided by the flowline core application 220 b. In this regard, decisions and instructions for implementing such decisions are passed down from the orchestration core application 220b to the orchestration sub-applications 240b, 244b, and then to the specific hardware components that perform the indicated actions. These instructions become more specific as the instructions move down the chain from the orchestration core application 220b to the orchestration sub-applications 240b, 244b to the various hardware devices. Information is also passed up from the various hardware devices to the flowline core sub-applications 240b, 244b and to the flowline core application 220b so that the flowline core application 224b and sub-applications 240b, 244b frequently receive status updates that inform the decision making process.

The flow orchestration core application 220b and flow orchestration sub-applications 240b, 244b operate to efficiently use the analysis instrument 108b and the pre-analysis instrument 104b. The flow orchestration core application 220b makes decisions about biological samples to be processed and evaluated by the pre-analysis instrument 104b and the analysis instrument 108b, respectively, based on information from the laboratory information system 204 b. In addition to performing batch processing on samples, the flowline core application 220b also obtains a large number of information inputs from various sources in controlling and coordinating the processing resources 248b, 252b of the pre-analysis 104b and analysis 108b instruments. The flow orchestration core application 220b receives the metering instructions from various external systems (e.g., laboratory information system 204b, hospital information system, and another analysis system).

The flow orchestration core application 220b may include three components: a flow orchestration state component, a flow orchestration decision maker component, and a flow orchestration engine component. The flow orchestration core application 220b may track consumable inventory. The flow orchestration core application 220b also tracks the operational status of the analysis instrument 108b and the pre-analysis instrument 104b itself. The flow orchestration core application 220b is also configured to track the bio/chemical/mechanical lifetime of consumable inventory and samples (e.g., assay controls and reagents), as well as the biological samples themselves in various states of execution of the assay protocol. The flowsheet core application 220b may also be configured to receive information from the pre-analysis system 104b and the analysis system 108b via the flowsheet sub-applications 240b, 244b, which will allow tracking of samples throughout sample processing.

In the embodiment shown in FIG. 2B, the orchestration core application 220B, the orchestration sub-application 240B, and the orchestration sub-application 244B are shown as three components of the orchestration core computing device 224B. However, this is merely illustrative and is not intended to be limiting. In another embodiment, the orchestration core computing device 224b may implement the orchestration core application 220b, and may perform the functions of the orchestration sub-applications 240b, 244 b. In one embodiment, the orchestration core computing device 224b includes one orchestration sub-application linked to the orchestration core application 220b to implement instructions provided by the orchestration core application 220 b.

Flow arrangement core system architecture

Fig. 3A depicts a flow orchestration core computing device architecture 300 that supports an analysis system 100 (e.g., the analysis system 100 described with reference to fig. 2A) according to an embodiment of the present disclosure. The architecture generally includes a flow orchestration core computing device 224 having a user interface, such as user interface 112, to allow a user to communicate therewith. The flow orchestration core computing device 224 may include one or more code scanners 304 for reading sample identifiers (e.g., bar codes, QR codes) on sample containers or sample racks. The flow orchestration core computing device 224 communicates with a pre-analyzer computer control device 232 of the pre-analyzer 104 and one or more analyzer computer control devices 236a1, 236a2 of the analyzers 108a, 108b (here shown as two such control devices; one for each analyzer). As shown, the flow orchestration core computing device 224 is connected to the network 208, and the network 208 is also connected to the laboratory information system 204 ("LIS"). LIS204 may be an existing generic or custom system associated with a diagnostic laboratory or medical facility that stores and maintains patient records, doctor ordered measurements, and the like. Network 208 allows for flow orchestration computer core computing device 224 to be communicatively coupled with LIS204 and to share information between them. The flow orchestration core computing device 224 is also communicatively coupled to instrument control devices 232, 236a1, and 236a2 of the instruments 104, 108a, and 108b via the cross-instrument interface 228. However, other interconnection mechanisms between computer control devices 232, 236a1, and 236a2 and flow orchestration core computing device 224 that allow these devices to share information with the system are also contemplated.

In addition to being connected to cross-instrument interface 228, pre-analytical instrument computer control device 232 is also connected to module interface 308, module interface 308 being connected to pre-analytical instrument device 264 of system 100, allowing computer control device 232 to communicate with pre-analytical instrument device 264. The pre-analytical instrument computing device 232 includes an application stored in its memory that provides instructions to its processor that relate to the control of physical operations used in the preparation and pre-processing of samples in the system 100. In this regard, the application facilitates control of each instrument/device within the pre-analysis instrument module/device 264 via the processor of the pre-analysis instrument computer control device 232.

The analyzer computer devices 236a1, 236a2 may also each include a processor and memory. In addition to being connected to cross-instrument interface 228, analyzer computing device 236a1 is also connected to module interface 312a1, module interface 312a1 being connected to analyzer instrument A ₁ Allowing analyzer computer device 236a1 to communicate therewith. The analyzer computer device 236a1 includes an application stored on its memory that provides instructions to its processor related to the pair provided to the analyzer instrument a via the system 100 ₁ Is controlled by the physical manipulation utilized in the analysis of the sample. In this regard, the analyzer computing device 236a1 facilitates control of the analyzer instrument a via a processor of the analyzer computing device 236a1 ₁ Is provided. The analyzer computing device 236a2 is similarly configured for its respective analyzer instrument.

Thus, as shown in FIG. 3A, the flow orchestration core computing device 224 receives information from multiple inputs and distributes the information as needed. This allows the system 100 to be fully integrated with one or more analytical instruments and an information sharing network, which allows the system 100 to be able to intelligently perform preparation and pre-processing of a plurality of different samples contained in a plurality of different containers.

In another embodiment of architecture 300, pre-analyzer computer device 232 or analyzer computing devices 236a1, 236a2 may also function as a flow orchestration core computing device 224.

Each of the devices 232, 236a1, 236a2 and the flow orchestration core computing device 224 and LIS 204 are at different nodes of the network 208 and are capable of communicating directly and indirectly with each other. However, as shown, the flow orchestration core computing device 224 generally serves as a control interface between the LIS 204 and the computing devices 232, 236a1, 236a2 of the analytical instruments 108a, 108b and the pre-analytical instrument 104. Various protocols and systems may be used to interconnect computing devices 232, 236a1, 236a2 and the flow orchestration core computing device 224 and LIS within the network 208. The network 208 may utilize standard communication protocols (e.g., ethernet and Wi-Fi) as well as protocols proprietary to one or more companies, as well as various combinations of the foregoing. Communication between laboratory information system 204 and analysis system 100 may be via a communication protocol, such as the hypertext transfer protocol (HTTP). Although certain advantages are obtained in transmitting or receiving information as described above, the systems described herein are not limited to any particular communication protocol.

FIG. 3B is a block diagram of a orchestration core computing device architecture 300B according to the embodiment described with reference to FIG. 2B. Architecture 300B of the orchestration core computing device in fig. 3B is similar to architecture 300B of the orchestration core computing device described with reference to fig. 3A. Because the analysis system 100B in fig. 2B is a distributed system having the functionality of the flow orchestration sub-applications 240B, 244B executed by the flow orchestration core computing device 224B, rather than the pre-analysis instrumentation 104B and the analysis instrumentation 108B, the flow orchestration core computing device 224B communicates with the pre-analysis instrumentation 264B and analysis instrumentation 268B1, 268B2 and/or controls the pre-analysis instrumentation 264B and analysis instrumentation 268B1, 268B2 through the interface 228B (e.g., across an instrumentation interface, inter-device interface, or intra-device interface).

Flow orchestration core application and sub-application states

FIG. 4 illustrates the state of a flow orchestration core application or sub-application. Fig. 4 shows a plurality of communication interfaces 404 a-404 c in bi-directional communication with cross instrument interface 228. Each of these communication interfaces has a processor. These interfaces 404 a-404 c are processors by which the core computing device 224 coordinates operations in each of the analysis systems 236a1, 236a2 and the pre-analysis system 232 with the flow orchestration. Each of the communication interfaces 404a to 404c is for an analyzer computing device 236a1, 236a2 or for a pre-analysis computer control device 232. In this regard, each of the computing devices 404 a-404 c includes one or more processors, memory, and other components typically found in general purpose computing devices.

The communication interfaces 404 a-404 c forward information regarding the analysis instrumentation and state changes in the pre-analysis instrumentation to a flow orchestration state component 408, the flow orchestration state component 408 being part of one of the pre-analysis instrumentation computing devices 232 or the analyzer computing devices 236a1 or 236a 2. The orchestration state component 408 communicates the state change to the orchestration engine component 412 of one of the pre-analyzer computing devices 232 or analyzer computing devices 236a1 or 236a 2. The orchestration engine component 412 is in bi-directional communication with the orchestration decision maker component 416 of one of the pre-analyzer computing device 232 or the analyzer computing device 236a1 or 236a 2. In response to a request from the orchestration engine component 412, the orchestration decision component 416 determines whether the orchestration engine component 412 is to dispatch instructions to the analysis device 108 and the pre-analysis device 104.

The memory of each of the communication interfaces 404 a-404 c may store information accessible to one or more processors, including instructions executable by the one or more processors. The above-described flow orchestration engine threads will execute on any available processor core in the communication interfaces 404 a-404 c. As described above, the orchestration engine component 412 requests decisions from the orchestration decision maker component 416. If a decision is returned, the flow orchestration engine component 412 assigns actions to the appropriate communication interfaces 404 a-404 c. When the communication interfaces 404 a-404 c receive a message relating to a state, they obtain the state from the orchestration engine component 412 and update the orchestration state component 408 with their new state. The new flow orchestration state in flow orchestration state component 408 then triggers flow orchestration engine component 412 to run.

The memory includes data that can be retrieved, manipulated, or stored by the processor. The memory may be of any non-transitory type capable of storing information accessible to the processor, such as a hard disk drive, memory card, ROM, RAM, DVD, CD-ROM, write-capable memory, and read-only memory.

The instructions may be any set of instructions (e.g., machine code) that is directly executed by one or more processors, or any set of instructions (e.g., scripts) that is indirectly executed by one or more processors. In this regard, the terms "instruction," "application," "step," and "program" are used interchangeably herein. The instructions may be stored in object code format for direct processing by a processor or in any other computing device language, including scripts or collections of independent source code modules that are interpreted or precompiled as needed. The functions, methods and routines of the instructions will be described in more detail below.

One or more processors may retrieve, store, or modify data according to instructions. For example, although the subject matter described herein is not limited by any particular data structure, the data may be stored in a computer register, in a relational database, as a table or XML document having many different fields and records. The data may also be formatted in any computing device readable format, such as, but not limited to, binary values, ASCII, or Unicode. Further, the data may include any information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary codes, pointers, references to data stored in other memory (e.g., at other network locations), or may include information used by a function for calculating the relevant data.

The one or more processors implemented by each of the communication interfaces 232, 236a1, and 236a2 may be any conventional processor, such as a commercially available CPU. In the alternative, the processor may be a dedicated component, such as an application specific integrated circuit ("ASIC") or other hardware-based processor.

In some embodiments, a processor or memory may actually comprise multiple processors and/or memories that may or may not be stored within the same physical housing. For example, the memory may be a hard disk drive or other storage medium located in a different housing than the processor. Thus, references to a processor, computing device, or memory will be understood to include references to a collection of processors, computing devices, or memory that may or may not operate in parallel.

In the embodiment shown in fig. 2A, the analyzer computing devices 236a1, 236a2 and the pre-analysis computing device 232 are located within their respective instruments. The location of the flow orchestration core computing device 224 is largely dependent on design choices. As shown, the flow orchestration core computing device 224 may also be in communication with the user interface 112 of the code scanner 304 and the pre-analysis instrument 104 (fig. 2A). The code scanner 304 is located within the input window 116 of the pre-analysis instrument 104. In one embodiment, the user interface 112 is a touch screen device mounted to a housing of the pre-analytical instrument 104 (shown in FIG. 2A). However, it should be understood that the user interface 112 may comprise a mobile device capable of wirelessly (e.g., wirelessly through a Wi-Fi connection) connecting to the flow orchestration core computing device 224. For example only, the user interface 112 may be a mobile phone or device capable of obtaining information via the network 208, such as a PDA, tablet PC, or netbook with wireless capabilities. In another example, the flow orchestration device computing device 224 may be a desktop device located at a physical location remote from the analysis system 100.

Flow orchestration core application

As shown in FIG. 4, the orchestration core application 220 includes components for information flow, such as communication interfaces 404 a-404 c, a orchestration decision maker component 416, a orchestration engine component 412, and a orchestration state component 408. The flow orchestration state component 408 receives and saves all information about the flow orchestration state (i.e., the state of sample processing and analysis for the system 100 including the pre-analysis system and the analysis system). The orchestration decision maker component 416 implements an algorithm that determines the next action to take based on the orchestration state received from the orchestration state component 408. The task of the communication interfaces 404a to 404c is to process input information from the analysis and pre-analysis instruments for updating the flow orchestration state.

The orchestration engine component 412 provides protected access to the orchestration state, operates the orchestration decision maker component 416, and performs decisions made by the orchestration decision maker component 416 in the form of instructions distributed to computing devices 232, 236a1, and 236a 2. As previously described, the flow orchestration core application 220 is a state machine. Thus, state changes that occur during the decision making process may invalidate the decision. The orchestration engine component 412 provides protected access to the orchestration state component 408 when making decisions, such that the decisions made by the orchestration core application 220 are atomic decisions (i.e., make one decision at a time).

In one embodiment, to ensure that such decisions are atomic, the flow orchestration engine component 412 runs on its own threads and is configured to implement one or more policies to prevent status updates during decision making. In other embodiments, threads are not instant (on the fly) configurable. For example, in one embodiment, the orchestration engine component 412 is configured to lock the orchestration state when making a copy of the orchestration state. This copy of the flow orchestration state is used in the decision making process. This allows the locking of the flow orchestration state to be applied for a short period of time, limiting the chances of race conditions. A race condition may occur when multiple pieces of state data change during execution of a decision. For example, a decision may begin with a batch of thirty patient samples, and at the end of the decision there may be two batches of sixty samples. These two states are identical. If the flowthrough state is not under the control of the flowthrough engine component 412, an inconsistent state of sixty samples of a batch may be seen, thus making an "invalid" decision.

In another embodiment, the flow orchestration engine component 412 may be configured to first determine what action to perform, and then perform that action. Additionally, the orchestration engine component 412 may be configured to apply locking to the orchestration state during decision making. If the decision as to which action to perform is quick, it may also be allowed to apply the lock for a short period of time. The delayed decision may delay processing and the delayed decision may prevent state updates.

In another embodiment, all state changes are automatically entered into the queue. The flow orchestration engine component 412 may be configured to wake up from a wait state (e.g., exit a wait state or a sleep state) and process each change in the queue. When the queue is empty, the orchestration engine component 412 can be configured to subsequently run the orchestration decision maker component 416 and perform the decision.

In another embodiment, the orchestration core application 220, which may be implemented by the orchestration core computing device 224, is configured to apply locking on the orchestration engine component 412 and the orchestration state component 408. If the orchestration engine component 412 is in a wait state, the lock is released, which indicates that all activities associated with the lock state have been completed. In this embodiment, the lock is maintained for a longer period of time and other threads may be prevented from executing if the orchestration engine component 412 is busy. Because the lock time is longer, race conditions are more likely to occur.

Flow arrangement sub-application system

As shown in FIG. 5A, the analysis instruments 108a1 and 108a2 and the pre-analysis instrument 104 include flow orchestration sub-applications 240, 244a1, 244a2. These applications 240, 244a1, and 244a2 are stored on respective memories of computing devices 232, 236a1, and 236a2 and provide instructions to their respective processors that relate to coordination and control of hardware devices (e.g., hardware devices as described above) within units 104, 108a1, and 108a 2. The orchestration subsystems 240, 244a1, and 244a2 are communication links between the orchestration core application 220 and the various components/subsystems/hardware within the instruments 104, 108a1, and 108a 2. In this regard, sub-applications 240, 244a1, and 244a2 facilitate execution of instructions provided by flow orchestration core application 220 and allow for modularization of each instrument 104, 108a1, and 108a 2. Thus, as shown, instructions flow from the flow orchestration core application 220 to the various devices of the instruments 104, 108a1, and 108a 2. Such generic instructions are programmed by granting rights as the instructions pass in a direction towards the hardware device, which translates into target actions for the discrete device. For example, when a rack of samples is received by the pre-analysis instrument 104, one or more of the flow orchestration sub-applications 240 issue specific instructions to a specific device 264 to complete the tasks required to support the receipt of the rack of samples into the pre-analysis instrument 104. In this regard, information flows from the various devices 264 to the flow orchestration core application 220. Such information may include the operational status of the device 264, the current level of the consumable, and the location of the particular sample. This pyramid structure allows the flow orchestration core application 220 to focus on high-level decision making and information gathering.

The orchestration sub-applications 240, 244a1, and 244a2 may be configured similar to the orchestration core application 220 to coordinate activities within each unit 104, 108a1, 108a2 and among the various devices across units 104, 108a1, 108a 2. For example, the conveyor manager sub-application of the pre-analytical instrument 104 and the robotic arm manager sub-application of the second analytical instrument 108a2 may coordinate the availability and operation of the respective conveyors and robotic arms to transfer sample containers from the conveyor of the pre-analytical instrument 104 to the robotic arm of the analytical instrument 108a 2.

Further, the sub-applications 240, 244a1, 244a2 may be state machines running on their own threads. For example, the pre-analysis instrument 104 may have a shelf manager sub-application, which is a state machine running on its own thread. The rack manager sub-application may be responsible for coordinating the movement of one rack of samples throughout the pre-analytical instrument 104. For example, a shelf manager sub-application may host a shelf object and make decisions based on a shelf state value assigned to the object, which may be a single enumeration indicating where the shelf is and what operations are being performed on it. Such decisions may include which rack of samples to move to and where the rack of samples is to be moved to. In addition, the rack manager sub-application coordinates the transfer of racks using other components or stations (e.g., sample conversion stations or rack lifts) within the pre-analytical instrument 104.

However, since the shelf manager sub-application is a state machine, state changes that occur during the decision making process can invalidate the decision. To ensure that such decisions are atomic, the shelf manager sub-application is configured to implement one or more policies to prevent the state from being updated during the decision making process. For example, in one embodiment, the shelf manager sub-application may be configured to apply a lock to the shelf state while making a copy of the shelf state. Such a copy would be used in the decision making process. This will allow the lock to be applied for a short period of time, limiting the chances of race conditions.

FIG. 5B is a block diagram of a flow orchestration core application and a flow orchestration sub-application of the centralized analysis system described with reference to FIG. 2B and FIG. 3B. As shown in FIG. 5B, the orchestration subsystems 240B, 244B1, and 244B2 are communication links between the orchestration core application 220B and the various components/subsystems/hardware within the instruments 104B, 108B1, and 108B 2. The orchestration sub-applications 240b, 244b1, and 244b2 may be configured similar to the orchestration core application 220b to coordinate activities within each unit 104b, 108a1, 108a2 and among the various devices across units 104b, 108a1, 108a 2. The sub-applications 240b, 244b1, 244b2 may be state machines running on their own threads. Core application 220b may be a state machine running on its own thread.

Multi-layer flow arrangement core application architecture

Fig. 6 illustrates an architecture of the flow orchestration core application 220, as shown, having a multi-instrumentation services layer 610, a flow orchestration layer 620, and an instrumentation module layer 630. Each layer is made up of a plurality of system user objects, each encapsulating a separate user operation category. The plurality of system user objects advantageously includes (1) a service level object layer 610 that includes a module service base module 614 for the system shown in FIG. 6. The service level object layer 610 is part of a flow orchestration control application service module 612, the flow orchestration control application service module 612 being in communication with modules in the flow orchestration layer 620, the instrumentation module control layer 630, and the instrumentation module layer 650. The flow control application service module 612 communicates with a module 646 that requests sample information, a module 642 that coordinates batches, a module 636 that manages module registration, and a module 632 that updates inventory status. The flow orchestration control application service module 612 also communicates with other modules in its layers (i.e., with the module service base module 614, and with the service base module 616 through the module service base module 614).

In one embodiment, the orchestration engine module (or component) 624 communicates with the module services base module 614, and the module services base module 614 also receives instructions from the orchestration control application service module 612. The orchestration engine module 624 obtains the orchestration state from the orchestration state module 622. Flow orchestration state module 622 receives state information from each module in layer 630, and indirectly from each module in layer 650. These modules are an inventory status updater module 632, a consumable-per-assay module 634, a module registration manager 636, a module status module 638, a lot module 540, a reconciled lot module 642, a sample module 644, and a requested sample information module 646. In response to a request from the orchestration engine module 624, the orchestration decision module 626 determines whether the orchestration engine module 624 is to dispatch instructions to other modules.

The request sample information module 646 communicates with the instrument registration module 658 to provide instructions and obtain information regarding registration and tracking of individual samples in the instrument. In one embodiment, sample information is obtained by reading a sample code on a received sample container by an instrument. Sample codes on the transfer containers are also registered to identify and track the transfer containers in the instrument. Note that the flow orchestration control application module 612 initiates a sample information request from the request sample module 646, which causes the instrument registration module 658 to obtain information about the sample container and the transfer container. When sample information is obtained, the sample information in sample information module 644 is updated. The updated sample information is passed to a flow orchestration state module 622.

Layer 630 also has a module 642, which module 642 coordinates the lot by communicating with an instrument coordination lot module 656 in the instrument. By interacting with the reconciliation batch module in layer 630, instrument reconciliation batch module 656 fills the shuttle with samples designated as the same batch by flow orchestration control application service module 612. The reconciliation batch module 642 also provides instructions to the instrument reconciliation batch module 656 to activate the batch processor devices in the instrument reconciliation batch module 656 and to the instrument reconciliation batch module 656 to initiate the shuttle transfer. The reconciliation batch module 642 communicates with both the flowline status module 622 and the batch module 640 (which in turn communicates with the flowline status module 622).

Layer 630 also has a module 640, which module 640 passes the module state to the flow orchestration state module 622. The module status module 638 obtains information from the module registration manager 636, and the module registration manager 636 receives instructions and directives from the flow orchestration control application service module 612 in layer 610. Module registration manager 636 also passes information to flow orchestration state module 622. Based on instructions from the flow orchestration control application service module 612, the module registration manager 636 communicates with the instrumentation registration module 654.

As described above, layer 630 has a module 632 that updates inventory status. Inventory status module 632 receives instantiation instructions from flow orchestration control application service module 612 and updates flow orchestration status module 622 with any status updates. The inventory status update module 632 controls the inventory module 652 in the pre-analysis instrument to obtain various information about the status of consumables in the instrument. The information includes inventory information about available consumables; obtaining consumable materials according to the requirement; reserving consumables; recovering the consumable; changing the inventory.

In another embodiment, the shelf manager sub-application may be configured to first determine actions to perform and then perform those actions. Additionally, the shelf manager sub-application may be configured to apply locking to the shelf state during decision making. This may also allow the lock to be applied for a short period of time if the decision as to which action to perform is made quickly.

In another embodiment, all shelf state changes are automatically entered into the queue. The shelf manager sub-application may be configured to wake up from the wait state and process each change in the queue. When the queue is empty, the shelf manager sub-application may be configured to perform the decision.

In yet another embodiment, the shelf manager sub-application may be configured to apply locking on the shelf manager sub-application. If the shelf manager sub-application is in a wait state (which indicates that all activities associated with the locked shelf state have been completed), the lock is released.

Instrument and measurement state

In one embodiment, the instrument is provided with a defined status. For example, the instrument status may be defined as shown in table 1.

TABLE 1 State definition

Referring to fig. 7 and 8, commands to change one state to another are shown. For example, when the instrument is in a power-down state, a power-up command changes state to "offline idle". While the offline process (e.g., instrument service, software update, etc.) is being performed, the offline idle state may change to "offline busy," where the offline idle state will remain until after the offline process is completed. If there is no offline procedure to prevent the state from changing from offline idle to online idle, a command is used to bring the instrument online and change state to online idle. In the online idle state, the instrument start-up procedure may be indicated. After completion, the instrument will return to the online idle state. If the instrument pauses during execution (pauses busy), no new process is started until the state is resumed to be busy and the process is completed. When the instrument is in the on-line idle state, it will always be available to receive commands for further activity unless entering the suspended idle state, in which case no new process may be initiated or instructions may be received to take the instrument off-line.

The system also has a defined assay state. In one embodiment, the assay may have one of the states listed in table 2 below.

TABLE 2 definition of measurement State

Fig. 9 shows how the state is stored for a particular assay. If the status of the assay is "not allowed", then the regional rules of the assay are applied, in which case the assay will be provided in a "failed" status, which will allow the assay to be performed, but the assay results will not meet patient requirements. Execution would be challenged to achieve eligibility. If the state is acceptable, but a new version of the assay has been released, the older version of the assay is still performed until the new version is acceptable.

Determining the assay or the sequence of assay steps

The flow orchestration core application 220 may determine an order of execution of the assays or assay steps based on the received samples, the ordered assays, and the availability of resources 248, 252. FIG. 10 is a block diagram of a non-limiting exemplary method 1000 of determining an order of measurement or execution of measurement steps for a sample to maximize performance. In one embodiment, the flow orchestration core application 220 may implement the method 1000 or a portion of the method 1000. After beginning at block 1004, at block 1008, the method 1000 receives a scanned sample code. For example, after a sample in a container reaches the input window 116 of the analysis system 100, the code scanner 304 of the analysis system 100 may scan a sample identifier, such as a bar code and a two-dimensional code, affixed to the sample container. The method 1000 may receive a sample code scanned as the scanner 304 scans the sample code. At decision block 1012, if the scanner 304 scans and receives additional sample codes, the method 1000 may return to block 1008 to receive more sample codes. The additional sample code may be from the same sample or from another sample received by the analysis system 100.

If, at decision block 1012, no additional sample codes are scanned and received, method 1000 may proceed to block 1016 where, at block 1016, method 1000 determines an assay to be performed on the received and scanned samples. For example, the method 1000 may receive measurement instructions for the received and scanned sample from the laboratory information system 204 or the hospital information system. The method 1000 may determine an assay to be performed on the sample based on the sample identification and the assay instructions determined from the sample code. For example, a doctor may order three tests A, B and C for a patient, and a sample code 123456 may be affixed to the container containing the patient sample. After the method 1000 receives the sample code 123456, the method 1000 may determine the identity of the sample (i.e., the sample of the patient) and determine the three assays that the physician has ordered or designated for the patient.

The method 1000 proceeds to decision block 1020 where the method 1000 determines whether the condition of each sample meets the requirements of one or more assays for sample ordering. The condition of the sample may be sample volume, sample age, sample quality (e.g., sample opacity). For example, three assays A, B and C ordered by a physician for a patient require 1ml, 5ml and 10ml, respectively. However, the volume of patient sample determined by the pre-analytical instrument 104 may be only 15ml. Thus, the volume of the patient sample cannot meet the total requirements of the ordered three assays, as the volume of the patient sample is only sufficient to perform two assays. If the sample does not meet the requirements of the ordered one or more assays, then the method 1000 proceeds to block 1024 where the method 1000 notifies the user that the sample condition does not meet the requirements of the ordered assays. For example, the flow orchestration core application 220 may display an error message using the user interface 112 of the analysis system 100. The method 1000 then ends at block 1028.

In some embodiments, the assay instructions for the sample may include a priority of the assay to be performed. The method 1000 may determine that an assay should be performed on a sample even if the condition of the sample does not meet the requirements of all assays for which the sample is ordered. For example, an assay instruction for a patient sample may indicate that the results of assays A and B can only be interpreted together. The measurement instructions may also instruct measurement a to be more important than measurement C. Thus, method 1000 may proceed from block 1020 to perform assays a and B and inform the user that assay C will not be performed. In some implementations, the method 1000 may display possible assays that may be performed on a sample and request user input regarding the assays that should be performed.

At decision block 1020, if the sample condition meets the requirements of the ordered assays, then the method 1000 proceeds to decision block 1032 where the method 1000 determines whether the analysis system 100, including the pre-analysis instrument 104 and the analysis instrument 108, has sufficient resources to perform all ordered assays. If the analysis system 100 does not contain sufficient resources, the method 1000 proceeds to block 1024 where the user is notified that the analysis system 100 does not include sufficient resources to perform the determination of the subscription. The method 1000 then proceeds to block 1028 where the method 1000 ends in block 1028. For example, the pre-analytical instrument 104 may need to pipette a patient's sample from a sample container into three smaller containers. However, the pre-analytical instrument 104 may have no pipette tips, or may have only two smaller receptacles. The method 1000 may inform the user via the user interface 112 that the user needs to stock more pipette tips and containers in the pre-analytical instrument 104.

Table 3 shows exemplary resources of the analysis system 100, which analysis system 100 may require exclusive access so that each resource may be used for preparation or analysis of only one sample or a batch of samples. Some of these resources may be automatically initiated by the analysis system 100. Some of these resources may require a particular user initiation or user action (possibly after analysis system 100 provides the user with an option for the user to select). For example, a user may initiate emptying of the waste container of the analysis system 100. As another example, during routine maintenance, the analysis system 100 may pause until the user confirms that the extraction area has been cleaned. Table 4 shows exemplary additional resources of the analysis system 100.

TABLE 3 resources of analysis System that may require exclusive Access

Group of	Name of the name	Start-up
			Maintenance of	Daily use	User scheduling or request
Sample of	Conversion of	Frame in hotel
			Sample of	By passing through	Frame in hotel
Sample of	HPV sample lot	Assembly lot
			State change	Software update	User scheduling
State change	Pause Dory	User request
			Frame	Loading sample rack	Shelf in I/O tray
Frame	Unloading completed rack	User request
			Consumable material	Drawer for storing Dory consumable	User request
Consumable material	Emptying Roz waste	User request
			Intervention	Clamping the tube in the shuttle	Consumable failure

TABLE 4 analysis of resources of the system

In one embodiment, the method 1000 may determine a combination of assays that may be performed in the event of insufficient system resources and let the user determine the assays that should be performed. In another embodiment, the assay instructions may include an assay and sample priority such that the method 1000 may notify the user of the lack of system resources and proceed from decision block 1032 to perform the assay based on the assay and sample priority.

At decision block 1032, if the analysis system 100 contains sufficient resources, the method 1000 proceeds to block 1036 where a determination step or assay is determined that the analysis system 100 can simultaneously perform in block 1036. For example, if assays a and B ordered for a patient require heating at 65 ℃ and 95 ℃, respectively, and if the analytical instrument 108 contains only one heating plate for heating the sample, then these two steps cannot be performed simultaneously. However, if the analytical instrument 108 comprises two or more heated plates, both assay steps may be performed simultaneously.

The method 1000 proceeds to decision block 1040 to determine if the test instruction includes any special instructions. For example, a special instruction may state that the measurement instruction for a particular patient is an urgent instruction and has the highest priority. As another example, the special instructions may indicate that both assays are performed or that neither assay is performed (possibly because the patient's assay results need to be interpreted together). If there are no special instructions, the method 1000 proceeds to block 1044 to determine an execution order to maximize the performance index. The performance index may be based on one or more factors, such as the duration of time for performing all assays, the effort for performing all assays, and the quality or accuracy of the assay results. The order of execution may be affected by the scheduled events. For example, the scheduled events may be routine maintenance, scheduled firmware or software updates, scheduled hardware upgrades, and scheduled outages. The order of execution may be affected by the physical or logical configuration of the components of the analysis system 100. For example, the order of execution may be affected by the physical or logical configuration of the pre-analytical instrument 104, the analytical instrument 108, the electronics 264 and 268. The order of execution may be affected by the type of sample container or other identifying element of the sample. For example, for the type of assay ordered for a sample, a container containing the received sample may not be preferred. The execution sequence may include steps of transferring the sample from the received sample container to a more suitable sample container. The method 1000 then ends at block 1028.

At decision block 1040, if the metering instruction includes a special instruction, the method 1000 may proceed to block 1048 to determine the order of execution of the metering to be performed in a special instruction prioritized manner while maximizing the performance index. For example, if the patient's order of metering is an emergency order, the method 1000 may determine an order of execution that maximizes the performance of the metering in addition to the emergency commanded performance of the metering. In some embodiments, the measured performance is minimized unless all emergency instructions are executed first. The method 1000 then ends at block 1028.

Example order determination

FIG. 11 is a schematic diagram of a non-limiting example of determining an order of execution of assay steps for a sample to maximize performance. The analysis system 100 may include three resources A, B and C. The three sources may be, for example, vortexes, pipettes, and heated plates. Assays 1, 2 and 3 require the use of these three resources in the order A, B and C, A, C and B, and B, A and C. To maximize performance, the assay steps of different assays requiring the same resources can be placed in one batch. Fig. 11 shows three possible execution sequences of the assay steps. As shown in fig. 11, the execution order (1) requires a longer running time than the execution orders (2) and (3). However, if the emergency instruction includes a measurement of 1, then execution order (1) may maximize the performance index. In fig. 11, the step of requiring the determination of resource B may be batched while the emergency instruction is first executed to minimize the total run time.

The execution sequences (2) and (3) are shown as requiring the same run time. If the performance index is time-based and the measurement steps requiring resources A, B and C must be continuously performed, the execution order that maximizes the performance index may be the execution order (2). If the performance index is energy-based and resource B uses more energy than resource C, then the execution order that maximizes the performance index may be execution order (3).

Determining updated assays or sequences of assay steps

After the flow orchestration core application 220 determines the order of execution, the analysis system 100 may receive new assay instructions from the laboratory information system 204 or the hospital information system before execution of the assays on the samples is complete. After or before the analysis system 100 begins processing and analyzing the sample, new assay instructions may be received. FIG. 12 is a block diagram of a non-limiting exemplary method 1200 of determining an order of execution of a measurement or update of a measurement step after receiving a new measurement instruction. In one embodiment, the flow orchestration core application 220 may implement the method 1200 or a portion of the method 1200. After beginning at block 1204, the method 1200 proceeds to block 1208, where the orchestration core application 220 determines an order of execution of the assays for the sample subscriptions. The flow orchestration core application 220 may determine the order of execution of the assays based on the method 1000 described with reference to fig. 10.

The method 1200 proceeds to block 1212 where a new metering instruction is received. For example, the flow orchestration core application 220 may receive new metering instructions from the laboratory information system 204 over the network 208. The received new assay instructions may be for a new sample or an existing sample. For example, new assay instructions may be used to analyze existing samples previously received and scanned by the system 100. When a new assay instruction is received, the analysis system 100 may be in the process of performing one or more assays that have been ordered for the sample, or the analysis system 100 may wait for the instrumentation 264, 268 to become available and then perform one or more assays that have been ordered for the sample. As another example, new assay instructions may be used for samples 100 that have not been received and scanned.

The method 1200 proceeds to decision block 1216 to determine whether the new measurement instruction is for an existing sample or for a new sample. If a new measurement instruction is for a new sample, the method 1200 proceeds to block 1220 where the flow orchestration core application 220 receives a new sample identifier, such as a bar code or two-dimensional code. For example, the analysis system 100 may receive a new sample through the input window 116 of the analysis system. The flow orchestration core application 220 may receive sample codes scanned using the code scanner 304. After receiving the new sample code, method 1200 proceeds to block 1124 where the orchestration core application 220 may determine a new execution order. The new execution order may be based on assays or assay steps that the analysis system 100 may perform according to the assay or assay step currently being performed. Table 5 shows four states of assays or assay steps that may be performed simultaneously according to other assays or assay steps currently being performed. The most restrictive assay or assay step currently being performed may affect the prospective assay or assay step. In some embodiments, the most restrictive assay or assay step currently being performed determines a prospective assay or assay step that may be performed. The four states in table 5 are arranged in order from least restrictive to most restrictive. The least restrictive state is most expensive to implement in terms of analyzing the resources of the system 100.

TABLE 5 determination or determination step concurrency

At decision block 1216, if a new metering instruction is for a new sample, the method 1200 proceeds to block 1220 where the flow orchestration core application 220 may determine a new execution order. The flow orchestration core application 220 may determine a new execution order for the assays based on the method 1000 described with reference to fig. 10. The method ends at block 1228. The determined new execution order may be used to maximize performance metrics such as the time or effort required to complete the assay, or the priority of the assay.

In one embodiment, at block 1120, the method 1200 may determine a new execution order for the existing sample and the new sample prior to receiving the new sample code. The method 1200 may continue to determine a new execution order until a new sample code is received. Thus, when the analysis system 100 receives a new sample and the method 1200 receives a new sample code, the analysis system 100 may continue to perform assays to maximize performance without causing any time delay in determining a new execution order.

Determining the order of execution of the assay or assay steps

The flow orchestration core application 220 may determine an order of execution of the assays or assay steps based on the received samples, ordered assays, availability of resources 248, 252, and operational status of electronics 264, 268. FIG. 13 is a flow chart of an exemplary method 1300 of determining an order of execution of an assay or assay steps and an updated order of execution to maximize one or more performance metrics. In one embodiment, the flow orchestration core application 220 may implement the method 1300 or a portion of the method 1300. After beginning at block 1304, the method 1300 proceeds to block 1308, where the flow orchestration core application 220 receives assay instructions for biological samples of one or more subjects (e.g., patients). The assay instructions may include performing one or more assays on each of the one or more biological samples. For example, the assay instructions may include performing a whole blood count (CBC), a blood chemistry test, a blood enzyme test, and a blood test to assess the risk of heart disease of a sample of the subject, and performing a blood test to assess the risk of heart disease. The flow orchestration core application 220 may receive assay instructions from an instruction provider (e.g., a healthcare provider) or a laboratory person (e.g., a laboratory technician).

After receiving the assay instructions, the method 1300 proceeds to block 1312, where the flowline core application 220 determines an assay to be performed on the biological sample on the electronic instruments 264, 268 based on the assay instructions. Determining an assay to be performed may include retrieving information related to the assay from a database of a laboratory information management system.

From block 1312, the method 1300 proceeds to block 1316, where the orchestration core application 220 determines available metering resources and operational status of the electronics 264, 268. The assay resources may include diluents, reagents, assay control samples, pipette tips, sample tubes, extraction tubes, polymerase Chain Reaction (PCR) plates, available space in waste containers, or any combination thereof.

At block 1320, the flow orchestration core application 220 may determine the order of execution of the assays. For example, the order of execution may be based on available metering resources and the operating state of the electronics 264, 268 as determined at block 1316. The flow orchestration core application 220 may determine an order of execution to maximize one or more performance metrics of the analysis system 100. In one embodiment, the flow orchestration core application 220 may optionally receive sample scan code to determine received samples and determine an execution order for the received samples.

The performance index of the electronic system may include or be determined based on the number of valid measurements per time period. The number of effective assay results may be determined based on the biochemical stability of the biological sample and the biochemical stability of the assay resources per time period (e.g., one round per 8 hours, 24 hour period, one week or more). For example, the performance index may be determined based on the number of available measurements per time period. For example, the number of effective assay results may be optimized or maximized to ensure that the assay results are generated prior to final biochemical stability. All steps of performing an assay on a biological sample do not guarantee clinically usable results. Various factors may invalidate the result. For example, the flow orchestration core application 220 may track the biochemical lifetime of the inventory and samples under various conditions of assay protocol execution. Exceeding these lifetime limits may make the measurement result uncertain, thus reducing the throughput of the machine. Thus, the flow orchestration core application 220 may track the viability of patient samples, assay controls, assay reagents, and the like. These lifetimes change with the performance of the assay, and the biochemical properties of the sample change through the assay steps. The flow orchestration core application 220 may plan to ensure that all assays or assay steps are completed once started before the patient sample expires.

The performance index may include the number of biological samples tested per unit time period. For example, the primary indicator may be the number of samples tested per time period, such as the number of samples tested per day. The flow orchestration core application 220 may attempt to keep all analysis modules 268 and sub-modules, as well as pre-analysis modules 264 and sub-modules busy. The full utilization of these hardware resources may help the system achieve maximum throughput. The idle time of any module or sub-module can negatively impact overall performance.

In one embodiment, the performance indicators include the labor or time of laboratory personnel required to operate the analysis system 100 per unit time period. The flow orchestration core application 220 may track samples throughout its processing. Orchestration core application 220 may track samples across transitions to different containers and across different modules (analysis module, analysis sub-module, and pre-analysis module). Thus, laboratory personnel can relieve this responsibility and human error can be eliminated from the processing chain. Other laboratory personnel may query the location and progress of the determination of the patient sample. If multiple assays are ordered for a single patient sample, the flow orchestration may coordinate and track the execution of the multiple assays without laboratory personnel intervention. Performance metrics may include a maximum amount of time that the electronic system does not require laboratory personnel input per time period and/or a minimum number of times that the electronic system requires laboratory personnel input. For example, the performance index may be determined based on a maximum allowed time before the user must return to the system, a minimum number of times the user must return to the system within a given period of time.

The labor required may also be determined based on the number of interrupts of the electronic system per time period. For example, the second important indicator used by the system may be the labor required to operate the analysis system 100. The analysis system 100 may be designed to minimize the number of interruptions by laboratory personnel per round. By grouping together large batches of manual operations, disruption of specific laboratory functions can be minimized. This is balanced against achieving maximum throughput, which may require the operator to keep the instrument stock and prepare for more measurements.

Performance indicators may be determined based on one or more predetermined conditions (e.g., determined urgency, profile of the subject, identity of the instruction provider, or a combination thereof). The condition may be determined by the urgency of a determination specified by a service level agreement. For example, from a clinical practice perspective, it may be the urgency of the assay to be performed or the test to be completed, such as urgency in patient management. As another example, the urgency of the assay to be performed may be determined based on the patient profile (e.g., patient demographics and statistical properties of the assay and subject). For example, the urgency of an assay to be performed may be impacted by the business process of the laboratory operating the system and the need to meet service level agreements between the laboratory and the instruction provider (e.g., laboratory client). As another example, the condition may be a disposable event, such as a laboratory person temporarily misplacing the sample.

In one embodiment, the performance metrics include a weighting matrix having a number of valid assays per unit time period, a number of biological samples tested per unit time period, labor required to operate the electronic system per unit time period, and/or other variables or factors disclosed herein, weighted in ascending or descending order. In one embodiment, the performance metrics include metrics corresponding to the duration of the assay, the priority of the biological sample, the biochemical stability of each biological sample, the status of the electronics, the concurrency of multiple assay resources required to perform multiple assays, or any combination thereof. In another embodiment, the performance index reflects predetermined guidelines for the sample and assay. For example, the assay sequence may include parameters such as urgency of result, sample expiration, user-defined parameters, and the like. The performance index may reflect such parameters. The laboratory personnel may change the priority of a single sample or a group of samples to be processed.

Determining the order of execution may include determining the order of execution of one or more assays based on available assay resources. The flow orchestration core application may consider available inventory, operating status of hardware components, determination of patient order, sample availability, sample age, batch already being processed, availability of analysis modules, analysis sub-modules and pre-analysis modules, biochemical stability, and/or laboratory business practices. The efficient process arrangement can minimize consumable expenditures, idle analysis modules, analysis sub-modules and pre-analysis modules, and uncertainty results.

Determining the order of execution may include organizing the plurality of biological samples into a plurality of sample batches. The electronics may be configured to process a batch of samples simultaneously. The electronics may be configured with assay resources to process a batch of samples simultaneously. For example, thermal cycling requires a similar assay because all samples are exposed to the same temperature change and frequency. Thus, the samples may be organized into batches. The consumables and instrumentation 264, 268 may be designed to process samples in discrete batch sizes in each assay. For example, the instrumentation 264, 268 may be designed to process 96 samples in a 96-well plate format. Thus, to maximize the total throughput, each batch for the assay should include 96 samples.

At block 1324, the flow orchestration core application 220 may allocate assay resources to the assays to be performed. The flow orchestration core application 220 may track available assay resources and notify laboratory personnel when assay resources are not available or expected to be unavailable. For example, the flow orchestration core application 220 may track the current level of consumable inventory in each analysis module and pre-analysis module. The flow orchestration core application 220 knows the number of lots that have been allocated to a process. It knows the number of consumable inventory required for each assay type batch. This knowledge allows the flow orchestration core application 220 to make decisions about which samples should be processed and when to start.

After allocating metering resources, the method 1300 may proceed to block 1328, where the flow orchestration core application 220 may configure the electronics 264, 268 based on the execution order determined at block 1320. For example, the flow orchestration core application 220 may schedule the electronics 264, 268 to perform the assay based on the order of execution determined at block 1320.

At block 1332, the analysis system 100 may perform an assay on the biological sample using electronics configured based on the order of execution. The flow orchestration core application 220 may track the operational state of the electronics 264, 268 while performing the assay. Modular assay instruments are complex machines. Electrical, mechanical and pneumatic systems may fail. To achieve the highest sample index per day, the flow orchestration core application 220 may monitor device health and adapt the execution of the assays to the operating hardware. For example, the flow orchestration core application 220 may monitor the operational state of the electronics 264, 268. The operational states of the electronics 264, 268 may include a fault state, an offline state, an online state, a suspended state, a power down state, a busy state, an idle state, or any combination thereof. When the flow orchestration core application 220 determines or receives an indication that the operational state of one of the electronics 264, 268 is a fault state, the flow orchestration core application 220 may notify laboratory personnel of the fault state.

Alternatively or additionally, the flow orchestration core application 220 may inform laboratory personnel when to replenish stock in the analysis system 100 and what stock to replenish. Inventory items include diluents, reagents, assay control samples, pipette tips, sample tubes, extraction tubes, and PCR plates. The available resources may include available space in various waste containers.

At decision block 1336, if the operational state of one of the electronics 264, 268 is a fault state, the method 1300 proceeds to block 1340 where the flow orchestration core application 220 releases the assay resources allocated for performing the assays that have not been completed. After releasing the metering resources, the method 1300 proceeds to block 1316, at block 1316, the flow orchestration core application 220 may determine updated available metering resources and an operational state of the updated electronics 264, 268 (including an unavailable operational state of one of the electronics 264, 268), and determine an order of execution of the updates of the incomplete metering based on the updated available metering resources and the operational state of the updated electronics 265, 268. In one embodiment, the flow orchestration core application 220 continuously determines the order of execution of the updates, and releases resources and allocates resources. The updated execution sequence may be based on the operating state of the electronics 264, 268, available resources, as well as new measurement instructions and new samples received.

If the operational status of the electronics 264, 268 does not include a fault status during the performance of the assay, the analysis system 100 may continue performing the assay on the biological sample until all assays or assay steps are completed, the method 1300 ends at block 1344.

FIG. 14 is a flow chart of an exemplary method 1400 of determining an order of execution of an assay or assay steps and an updated order of execution to maximize one or more performance metrics. In one embodiment, the flow orchestration core application 220 may implement the method 1400 or a portion of the method 1400. After beginning at block 1404, the method 1400 may proceed to blocks 1408, 1412, 1416, 1420, 1424, 1428, and 1432, as described with reference to blocks 1308, 1312, 1316, 1320, 1324, 1328, and 1332.

At decision block 1436, the flow orchestration core application may determine that no more measurements need to be made on the sample. The method 1400 may then proceed to block 1440, where the flow orchestration core application releases the assay resources allocated for performing the unfinished assay, as described with reference to block 1340 in fig. 13. For example, the flow orchestration core application may receive results of an assay of biological samples determined using one or more electronic instruments using the determined order. The flow orchestration core application may determine that a second assay need not be performed on the same biological sample or another biological sample. For example, a work cell that may contain one or more assays may be eliminated due to an inference result from a previous assay result. Such cancellation may save costs or time since the second/pending determination no longer needs to be performed. The flow orchestration core application may determine that the pending determination is no longer relevant to clinical diagnosis through a set of rules. For example, a first inexpensive assay for determining a physiological condition or state may have a low false positive rate and a high false negative rate, and a second expensive assay for determining the same physiological condition may have a low false positive rate and a low false negative rate. The instructions received by the flow orchestration may include performing two assays on the sample, and the flow orchestration core application may determine that the first assay should be performed before the second assay is performed. If the result of the first assay is negative, a second assay may be performed. If the result of the first determination is positive, the flow orchestration core application may determine that the second determination does not need to be performed. The flow orchestration core application may determine an order of execution of the updates (excluding performing the second determination on the sample) to maximize at least one performance indicator of the analysis system. Resources may be freed based on the order of execution of the updates.

If all assays are needed, the analysis system may continue to perform assays on the biological sample until all assays or assay steps are completed, where the method 1400 ends at block 1444.

Additional features

And storing the measurement result. The analysis system 100 or 100A may perform the assays based on the assay sequence received from the laboratory information system and the execution sequence determined by the flow orchestration core application. Although the modules listed below are related to the analysis system 100 shown in fig. 2A, these same assays may be similarly performed by the analysis system 100A of fig. 2B. After the assay is complete, the analysis system 100 may send the assay results to the laboratory information system 204 via the network 208. Because of network or other issues, the analysis system 100 may not be able to establish a connection with the laboratory information system 204 via the network 208 when the assay results are available. In this embodiment, the analysis system 100 may store the assay results locally and then send the results to the laboratory information system 204 once a connection is established. The analysis system 100 may attempt to periodically reestablish the connection. If the connection cannot be reestablished, the laboratory personnel may be notified of the fault condition. The notification may be, for example, an email, text, sound, or other indication that the results were not sent to the laboratory information system 204. The analysis system 100 may store the assay results in an unencrypted format or an encrypted format using a symmetric key scheme.

Inventory and operational integrity are monitored. The flow orchestration core application 220 may determine an order of execution of the assays or assay steps based on the received samples, ordered assays, availability of resources 248, 252, and operational status of electronics 264, 268. The flow orchestration core application 220, the flow orchestration sub-application 240 of the pre-analysis instrument 104, or the flow orchestration sub-application 244 of the analysis instructions 108 may track available metering resources. The assay resources may include consumables 256, 268 and reagents 272, 276. The assay resources may include diluents, reagents, assay control samples, pipette tips, sample tubes, extraction tubes, polymerase Chain Reaction (PCR) plates, available space in waste containers, or any combination thereof.

Modular assay instruments are complex machines. Electrical, mechanical and pneumatic systems may fail. To achieve maximum performance, the flow orchestration core application 220 may monitor device health and the integrity of the electronics 264, 268, and adapt the execution of each determination performed to the operating hardware. For example, the flow orchestration core application 220 may monitor the operational state of the electronics 264, 268. The operational states of the electronics 264, 268 may include a fault state, an offline state, an online state, a suspended state, a power down state, a busy state, an idle state, or any combination thereof. As another example, the analysis system 100 may include an externally or internally mounted Uninterruptible Power Supply (UPS). The flow orchestration core application 200 may monitor the health of the UPS. When the flow orchestration core application 220 determines or receives an indication that the operational state of one of the electronics 264, 268 is a fault state, the flow orchestration core application 220 may notify laboratory personnel of the fault state.

The analysis system 100 may generate reports of the inventory and operational integrity of the electronics 264, 268. For example, when the flow orchestration core application 220 determines that a component of the electronics 264, 268 has a fault state, the analysis system 100 can generate a report containing diagnostic data and code indicating that a particular component has failed and needs repair or replacement. The flow orchestration core application 220 may re-determine the execution order based on the failure. Some assays may be paused and restarted while other assays may be repeated.

The flow orchestration core application 220 may coordinate the operation of multiple independent but connected instruments that require the availability of hardware and consumables between the instruments to properly prepare and analyze individual samples. The separate and connected instruments may include a pre-analytical instrument 104, an analytical instrument 108, and instrument devices 264, 268. For example, in order to perform an assay on a sample, the sample may have to be pipetted. If either the pipette robot or pipette tip of the pre-analytical instrument 104 or the consumable 268 and reagent 276 of the analytical instrument 108 are not available, the flow orchestration core application 220 may determine the order of execution to exclude the assay performed on the sample.

Status indicators. The analysis system 100 may include a plurality of visual indicators across a plurality of independent but connected instruments. The analysis system 100 may use a visual indicator to indicate to a user of the system 100 that the user needs to pay attention to the system 100. For example, a visual indicator associated with the analysis system 100 may flash red when the overall system fails. As another example, an indicator associated with the pre-analysis system 104 may flash yellow light when a consumable 256, such as a pipette tip, needs to be replenished as soon as possible.

And (5) logging. The analysis system 100 may aggregate and store log files for a plurality of individual but connected instruments for later retrieval. For example, the analysis system 100 may aggregate and store log files of the performed assays, the operating status of the instruments 104, 108 and devices 264, 268, and the level of consumables 256, 268 and reagents 272, 276. For example, the log file may include results of the measurements being performed or intermediate results. The analysis system 100 may transmit log file data to a central or remote data storage device to allow remote troubleshooting by analysis of the log. For example, when a component of the pre-analysis instrument 104 has a fault condition, the analysis system 100 may retrieve a log file containing such fault condition from the pre-analysis instrument 104 and transmit the log file to the laboratory information system 204 for diagnosing the fault condition. The log file information may be transmitted based on the importance or timing of the log file information. For example, log file information containing the fault status of the entire analysis system 100 may be prioritized over log file information indicating that consumables should be replenished as soon as possible.

Operational coordination and parameters are determined. The instrumentation 264, 268 may include physical hardware components (e.g., motor encoders, integrated circuits, solenoid valves, etc.), whereby the flow orchestration core application 220 is able to track the operational state of the hardware in each instrument. In one embodiment, the instrumentation 264, 268 may include interactive position detectors and cameras, and the flow orchestration core application 220 may determine the proper operational coordination and parameters of the instrumentation 264, 268 or components thereof. For example, the pre-analytical instrument 104 may include a pipette robot with a position detector. The pre-analysis instrument 104 may include a camera that captures images of the position detector. The flow orchestration core application 220 may use the images of the position detectors to determine coordinates and parameters of the pipette robot. As another example, the pipette robot may include a plurality of position detectors, and the pre-analytical instrument 104 may include three cameras orthogonal to each other. The flow orchestration core application 220 may determine coordinates and parameters of the pipette robot in three dimensions using images captured by orthogonal cameras. The captured images may also be used to calibrate the components of the instrumentation 264, 268. The position detector may be fixed to the assembly or may be movable on the assembly. Determining operational coordination and parameters of the components may require fewer movable position detectors. The position detector may use different colors to indicate its status, such as in use or malfunctioning.

An uninterruptible power supply. The analysis system 100, the pre-analysis instrument 104, the analysis instrument 108, or the instrument devices 264, 268 may include an externally or internally mounted Uninterruptible Power Supply (UPS). In the event of a power failure, the UPS may provide sufficient power to the analysis system 100 or components thereof to ensure that all data is stored to a persistent storage device, such as a Solid State Drive (SSD) or a Hard Disk Drive (HDD). The data stored in the persistent storage device in the event of a power failure may include the results of the measurements being performed or intermediate results. The data may include the status and parameters of the analysis system 100 and its components.

Video surveillance. The analysis system 100 may include an internal camera that captures video surveillance data of the internal workings of the system 100. The analysis system 100 may store the video surveillance data and display the video on demand to a user or technician of the system 100. In one embodiment, the video surveillance data is stored in a persistent internal storage device for later retrieval.

For example, when a fault condition of a component of the analysis system 100 is detected, a laboratory person or technician may wish to view the captured video. As another example, a laboratory person may wish to view video tracking a sample of interest to ensure that the sample is not tampered with. The analysis system 100 may automatically package video with logs and other data to support remote assessment of errors or problems.

To coordinate with other computer systems or subsystems. In one embodiment, the flow orchestration core application 220 may coordinate with other systems associated with the analysis system 100. For example, the flow orchestration core application 220 may determine an execution order based on the operational states of the pre-analysis instrument 104 and the analysis instrument 108. As another example, the flow orchestration core application 220 of one analysis system 100 may determine an order of execution based on the operational state of another analysis system 100. In one embodiment, the flow orchestration sub-application 240 of the pre-analysis instrument 104 may affect the execution order determined by the flow orchestration core application 220 for the pre-analysis instrument 104 and the analysis instrument 108, and vice versa.

A working list of samples. The flow orchestration core application 220 may automatically build and release a working list of samples for processing corresponding to nominal operation of the analysis system 100 or components thereof when a sample group appears. For example, the flow orchestration core application 200 may automatically build and release a working list of samples for performing a process corresponding to the nominal operation of the device when a sample group appears and according to user-defined rules based on day of week, month of day, time of day, or any combination thereof. As another example, the flow orchestration core application 220 may automatically build and release a working list of samples for performing processing corresponding to nominal operation of the device when a sample group appears and according to user-defined rules (as applied to specific tests ordered for each sample) based on day of the week, month of the day, time of day, or any combination thereof.

The sample is removed. The flow orchestration core application 220 may monitor the processing and analysis of the samples and alert laboratory personnel when raw sample containers that the laboratory personnel are removing or have removed should be taken for further inspection and evaluation. For example, the flow orchestration core application may alert the user when the original sample container that has been removed from the system should be retrieved for further inspection and evaluation, and provide sample information and location to laboratory personnel to facilitate sample retrieval. The sample information and location may include a sample identifier and a location of the sample, such as a location on a rack. When the sample returns to the analysis system 100, the flow orchestration core application 220 may re-determine the execution order.

Cloud-based process orchestration core application

Fig. 15 is a block diagram of an analysis system in communication with a laboratory information system and an analysis system over a network. The hospital 1504a may include a hospital information system 1508a that stores and processes hospital data. For example, the hospital information system 1508a may store patient data and prescription specification information. The hospital 1504a may also have an on-site hospital laboratory 1512a with a laboratory information system 204a and an analysis system 100 a. Laboratory information system 204a may receive the determination instructions 212 and patient information from hospital information system 1508a. Laboratory information system 204a may store requirements of assays that analysis system 100a is capable of performing. The analysis system 100a is capable of performing certain assays, such as a general cancer detection package (panel). Although the orchestration core application 220 is shown as controlling two analysis systems, the orchestration core application 220 is able to control numerous analysis systems with different functionality located in different geographic locations. The analysis systems 100a, 100B may be the analysis systems of fig. 2A and/or fig. 2B.

Laboratory 1512b, such as a stand-alone laboratory, may include laboratory information system 204b and analysis system 100b. Laboratory information system 204b may store the requirements of the assays that analysis system 100a is capable of performing. The capabilities of the analysis system 100b and the capabilities of the analysis system 100a may be the same or different. For example, the analysis system 100b of the laboratory 1512b can perform general cancer detection packages and specialized cancer guidelines.

To determine the order of execution of the analysis system 100a or the analysis system 100b, the flow orchestration core application 220 may receive assay instructions from the hospital information system 1508a, the laboratory information system 204a, or the laboratory information system 204 b. The flow orchestration core computing application 220 may track the capabilities of the analysis systems 100a, 100b. For example, the resources of analysis system 100a may become temporarily available and analysis system 100a may provide this information to flow orchestration core application 220.

Given the received metering instructions or scanned samples, the flow orchestration core application 220 may determine the order of execution of the analysis systems 100a, 100b to maximize performance metrics. For example, the hospital 1204a may prefer that its analysis system 100a perform as many assays as possible in order to minimize costs. However, depending on the availability and capabilities of analysis system 100a, flowline core application 220 may determine that analysis system 100b should perform certain assays for certain samples.

As another example, the metering instructions may indicate: a specific cancer detection package should be performed after a general cancer detection package determines that a patient is at risk for developing cancer. The initial order of execution of the analysis systems 100a, 100b as determined by the flowline core application 220 may include a general cancer detection package executed by the analysis system 100a of the hospital 1504 a. The order of execution of the analysis systems 100a, 100b may be determined using the methods 1000 and 1200 described with reference to fig. 10 and 12, respectively. If the results of a general cancer detection package indicate that the patient is at risk for cancer, the flow orchestration core application 220 may determine a new order of execution for the analysis system 100c of the laboratory 1512 b. This new order of execution may take into account the time required to transport the sample from the hospital 1504a to the laboratory 1512 b. The flow orchestration core application 220 may determine a new execution order using the methods 1000 and 1200 described with reference to fig. 10 and 12, respectively. For example, when the results of a general cancer detection package become available, the analysis system 100b may perform assays on other samples. A new execution order of the analysis system 100c may be determined to maximize the performance of the analysis system 100c or the combined performance of the analysis systems 100a, 100 b.

In one embodiment, the flow orchestration core application 220 may receive an indication that the analysis system 100b becomes unavailable. If the connection of the flow orchestration core application 220 to the analysis system 100b is lost or an emergency analysis instruction is executed, the analysis system 100b may become unavailable. Based on the unavailability of analysis system 100b, flow orchestration core application 220 may determine a new order of execution for analysis system 100 a. In one embodiment, the flow orchestration core application 220 determines the order of execution of some of the analysis systems in order to maximize performance metrics relative to those analysis systems, thereby improving the overall efficiency of processing the assay samples. For example, the hospital 1504a may have a contractual relationship with the laboratory 1512b such that the order of execution of the analysis systems 100a, 100b is determined in a manner that maximizes performance metrics relative to the two analysis systems 100a, 100 b.

FIG. 16 is a schematic of a flow orchestration core application stored in a cloud-based server in communication with a flow orchestration laboratory application to coordinate automated sample processing and analysis. The hospital 1504 may include a hospital information system 1508 that stores and processes hospital data. For example, the hospital information system 1508 may store patient data and prescription specification information. The hospital 150a may have a field hospital laboratory 1512 with a laboratory information system 204 and multiple analysis systems 100a, 100 b. Laboratory information system 204 may receive the measurement instructions and patient information from hospital information system 1508. The laboratory information system 204 may store requirements of assays that the analysis systems 100a, 100b are capable of performing.

The flow orchestration core application 220 on the cloud system 1600 may communicate with the flow orchestration laboratory application 1604 on the laboratory information system 204 to coordinate automated sample processing and analysis using the analysis systems 100a, 100 b. When the orchestration core application 220 is available, the orchestration laboratory application 1604 may send the received measurement instructions or scanned samples to the orchestration core application 220. Based on the information received from the orchestration laboratory application 1604 and similar information received from other orchestration laboratory applications, the orchestration core application 220 may determine the order of execution of the analysis systems 100a, 100b controlled by the orchestration laboratory application 1604 and the analysis systems controlled by the other orchestration laboratory systems. Thus, the order of execution determined by the flow orchestration core application 220 may maximize performance metrics given the received metering instructions or scanned samples. When the flow orchestration core application 220 is not available, the flow orchestration laboratory application 1604 can determine the order of execution of the analysis systems 100a, 100b to maximize performance metrics given the received metering instructions or scanned samples.

With this distributed architecture, the flow orchestration core application 220 and the flow orchestration laboratory application 1604 may maximize performance metrics given the available information and resources. For example, the order of execution determined by the flow orchestration core application 220 may be based on the capabilities of the analysis systems 100a, 100b in the laboratory 1512 and in another laboratory. Each laboratory has an analysis system capable of performing a generic cancer detection package. However, it may be more expensive to perform a typical cancer detection package using an analysis system in laboratory 1512. To reduce the cost of executing a cancer detection package, the flowline core application 220 may determine to execute a general cancer detection package using other laboratory analysis systems. Before sending the sample (or a portion of the sample) for the cancer detection package to other laboratories, the flowsheet laboratory application 1604 may lose connectivity with the flowsheet core application 220. Because the flowsheet laboratory application 1604 cannot determine whether a general cancer detection package can be completed even if a sample (or a portion of a sample) is sent to another laboratory, the flowsheet laboratory application 1604 can determine a new order of execution of the analysis systems 100a, 100 b.

In one embodiment, the cloud system 1600 may receive data or test results generated by the analysis systems 100a, 100b from the flowsheet laboratory application 1604 via its flowsheet core application 220. Although the orchestration core application 220 is shown as controlling two analysis systems 100a, 100b, the orchestration core application 220 is capable of controlling numerous analysis systems with different functions located in different geographic locations.

The laboratory 1512 may include many conventional systems 1608 that do not have automation capabilities. These legacy systems 1608 may be controlled by a laboratory-based middleware system that provides high availability and high performance links between laboratory platforms and other IT systems. This may be used primarily to run local laboratory operations. The cloud system 1600 may receive data or test results generated by these legacy systems 1608 from the legacy system laboratory interface 1616 of the laboratory information system 204 via its legacy system interface 1612. The legacy system laboratory interface 1616 may receive data generated by the legacy system 1608 from a laboratory-based middleware system. In one embodiment, the cloud system 1600 may receive data or test results generated by a point of care (POC) device via a POC interface.

By controlling the analysis systems 100a, 100b and receiving data and test results generated by the analysis systems 100a, 100b, the legacy system 1608, and the POC device 1615, the cloud system 1600 is able to manage relevant laboratory data and laboratory remote microbiological operations in an enterprise-wide manner. Value added services can always be implemented across all hospitals, laboratories and patient data sinks and provide insight regarding the use of hospitals, laboratories and patients. Examples of value added services include peer benchmarking and global monitoring. The received data and test results may be stored in a data mart capable of global clinical and diagnostic summarization. In one embodiment, data for different hospitals, institutions, or affiliated hospitals or institutions is stored in different databases 1624a, 1624b located at different locations 1632 a-1632 e.

Access to cloud functionality may be provided via an application 1636 distributed through an application portal 1640 that supports both legacy devices and mobile devices. The application portal 1640 may be centrally managed and redirects the user to a related technology specific application store. These application stores are able to enable distribution of applications 1636 that may be developed by third party developers (consistent with the architecture of cloud system 1600). Applications 1636, which may be developed by third party developers, may more flexibly address custom data management requirements.

In one embodiment, the cloud system 1600 utilizes social networks to enable hospitals, laboratories, and patients to better participate. The cloud system 1600 may provide better customer relationship management activities ranging from services and training to opportunities for inbound and outbound marketing activities.

The architecture of cloud system 1600 is scalable to meet changing market demands. In one embodiment, the architecture supports both public and local (private) clouds, eliminating the data hosting objection of users who wish to place all data behind their firewalls. The cloud system 1600 is secure, thus solving problems with data, HIPAA privacy, and regulatory compliance. The cloud system 1600 is also scalable and can support new/updated devices and modules.

In at least some of the foregoing embodiments, one or more elements used in an embodiment may be interchanged in another embodiment unless such an alternative is technically not available. Those skilled in the art will appreciate that various other omissions, additions and modifications may be made to the methods and structures described above without departing from the scope of the claimed subject matter. All such modifications and changes are intended to fall within the scope of the subject matter defined in the appended claims.

With respect to the use of substantially any plural and/or singular terms herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural permutations may be explicitly stated herein. As used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Any reference herein to "or" is intended to encompass "and/or" unless otherwise indicated.

It will be understood by those within the art that, in general, terms used herein, especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). Those skilled in the art will further understand that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to embodiments containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Further, in those instances where a convention analogous to "at least one of A, B and C, etc." is used, such a construction in general is intended in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include, but is not limited to, a system having only A, only B, only C, A and B, A and C, B and C, and/or A, B and C, etc.). In those instances where a convention analogous to "at least one of A, B or C, etc." is used, such a construction in general is intended in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include, but is not limited to, a system having only a, B, C, a and B, a and C, B and C, and/or A, B and C, etc.). Those skilled in the art will further appreciate that virtually any disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" will be understood to include the possibilities of "a" or "B" or "a and B".

In addition, where features or aspects of the invention are described in terms of Markush groups, those skilled in the art will recognize that the invention is thus also described in terms of any individual member or subgroup of members of the Markush group.

As will be understood by those skilled in the art, for any and all purposes (e.g., in terms of providing a written description), all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be readily identified as fully described, and the same range can be subdivided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each of the ranges discussed herein can be easily subdivided into a lower third, a middle third, and an upper third. Those of ordinary skill in the art will also understand that all language (e.g., "at most", "at least", "greater than", "less than", etc.) includes the recited numbers and refers to ranges that may be subsequently subdivided into the above-described sub-ranges. Finally, as will be appreciated by those skilled in the art, a range includes each individual member. Thus, for example, a group of 1 to 3 items refers to a group of 1, 2, or 3 items. Similarly, a group of 1 to 5 items refers to a group of 1, 2, 3, 4, or 5 items, and so on.

Although various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1. An electronic system for analyzing a plurality of biological samples using a plurality of electronic instruments, comprising:

a plurality of electronic instruments including a plurality of analysis modules and associated analysis sub-modules and a plurality of pre-analysis modules and associated pre-analysis sub-modules;

a memory storing available measurement resources, measurement resources required for a plurality of measurements, and performance indicators of the electronic system; and

a processor programmed to perform a method comprising:

receiving a plurality of assay instructions for a plurality of biological samples of at least one subject from an instruction provider;

determining, based on the assay instructions, one or more assays to be performed on each electronic instrument for each biological sample;

determining whether the condition of each biological sample meets the one or more assay requirements;

determining an operating state of the plurality of electronic instruments and the available assay resources in response to determining that the condition of each biological sample meets the one or more assay requirements;

Determining an order of execution of the one or more assays based on the available assay resources and the operational status of the plurality of electronic instruments to maximize at least one performance indicator of the electronic system;

allocating assay resources of the available assay resources to the one or more assays to be performed;

configuring each of the plurality of electronic instruments based on the execution order; and

performing the one or more assays on the plurality of biological samples using the configured plurality of electronic instruments in the determined order,

wherein determining the execution order comprises: the plurality of biological samples are organized into a plurality of sample batches according to the at least one performance indicator, and wherein the biological samples in each sample batch are processed using the same assay resources.

2. The electronic system of claim 1, wherein the performance index of the electronic system comprises a performance index related to a number of valid assays per time period, a number of biological samples tested per time period, or a combination thereof.

3. The electronic system of claim 2, wherein the number of valid assay results is determined based on the biochemical stability of the biological sample and the biochemical stability of an assay resource.

4. The electronic system of claim 2, wherein the performance metrics of the electronic system further comprise performance metrics related to: the time of the laboratory personnel required to operate the electronic system per time period, the maximum amount of time the electronic system does not require laboratory personnel input, the minimum number of times the electronic system requires laboratory personnel input per time period, or a combination thereof.

5. The electronic system of claim 4, wherein the required user time is determined based on a number of interrupts of the electronic system per time period.

6. The electronic system of claim 2, wherein the time period comprises a 24 hour time period.

7. The electronic system of claim 1, wherein the performance metrics of the electronic system comprise performance metrics related to consumable expenditures required to complete the one or more assays.

8. The electronic system of claim 1, wherein the performance metrics of the electronic system comprise performance metrics related to one or more predetermined conditions.

9. The electronic system of claim 8, wherein the one or more predetermined conditions comprise: an urgency of the determination, a profile of the at least one subject, an identity of the instruction provider, or a combination thereof.

10. The electronic system of claim 1, wherein determining the order of execution comprises: an order of execution of the one or more assays is determined based on the available assay resources.

11. The electronic system of claim 1, wherein the electronics are configured to process a batch of samples simultaneously.

12. The electronic system of claim 11, wherein a measurement resource is configured to the electronic instrument to process the batch of samples simultaneously.

13. The electronic system of claim 1, wherein determining one or more assays to perform comprises: information related to the one or more assays is retrieved from a database of a laboratory information management system.

14. The electronic system of claim 1, wherein the processor is further programmed to perform a method comprising:

monitoring an operational state of the electronic instrument, wherein the operational state comprises a fault state;

notifying laboratory personnel of the fault condition; and

an order of execution of the updates of the one or more assays is determined to maximize at least one performance indicator of the electronic system.

15. The electronic system of claim 14, wherein the at least one performance indicator for determining the order of execution and the at least one performance indicator for determining the updated order of execution are the same.

16. The electronic system of claim 14, wherein determining an order of execution of the updates comprises:

releasing the assay resources for performing the one or more assays that have not been performed;

updating available assay resources after releasing the assay resources for performing the one or more assays; and

based on the updated available assay resources and the operating state of the electronic instrument, an order of execution of the updates of the one or more assays is determined to maximize at least one performance indicator of the electronic system.

17. The electronic system of claim 1, wherein the processor is further programmed to perform a method comprising:

receiving results of performing a first assay of the one or more assays on biological samples of the plurality of biological samples, the results determined using one or more of the plurality of configured electronics in the determined order;

determining a second assay of the one or more assays that need not be performed on the biological sample; and

18. The electronic system of claim 1, wherein the processor is further programmed to perform a method comprising:

tracking the available assay resources; and

the laboratory personnel are notified when the measured resources are not available or are expected to be unavailable.

19. A method for high throughput automated bioassay on a plurality of electronic instruments, comprising:

receiving a plurality of assay instructions for a plurality of biological samples;

determining, based on the assay instructions, one or more assays to be performed on each of a plurality of electronic instruments for each biological sample;

determining available assay resources and status of the plurality of electronic instruments in response to determining that the condition of each biological sample meets the one or more assay requirements;

determining an order of execution of the one or more assays based on the available assay resources and the status of the plurality of electronic instruments to maximize at least one performance indicator of the electronic system;

20. The method of claim 19, wherein the performance metrics of the electronic system comprise performance metrics of each of the plurality of electronic instruments, and wherein the target performance metrics of the electronic system comprise target performance metrics for each electronic instrument to perform the one or more determinations.

21. The method of claim 20, wherein the performance indicator of each electronic instrument comprises an amount of idle time per time period.

22. The method of claim 19, wherein the performance metrics of the electronic system include metrics for: the duration of the assay, the priority of the biological sample, the biochemical stability of each biological sample, the status of the electronics, the concurrency of multiple assay resources required to perform multiple assays, or any combination of the foregoing.

23. The method of claim 19, wherein the determining the resource comprises: diluents, reagents, assay control samples, pipette tips, sample tubes, extraction tubes, polymerase chain reaction PCR plates, space available in waste containers, or any combination of the foregoing.

24. The method of claim 19, wherein the plurality of electronic instruments includes a plurality of analysis modules and associated analysis sub-modules and a plurality of pre-analysis modules and associated pre-analysis sub-modules.

25. A system for high throughput automated bioassay, comprising:

a memory storing instructions; and

a processor programmed by the instructions to perform a method comprising:

receiving a plurality of assay instructions for a plurality of biological samples from a plurality of analysis systems;

determining a plurality of assays to be performed for each of the plurality of biological samples based on the assay instructions;

identifying an available analysis system for running each type of assay in the plurality of assays;

determining whether the condition of each biological sample meets the requirements of the plurality of assays;

in response to determining that the condition of each biological sample meets the requirements of the plurality of assays, determining available assay resources within the identified analysis system for performing the plurality of assays;

Determining an order for performing each assay of the plurality of assays based on the available assay resources so as to maximize efficiency of performing the plurality of assays; and

instruct one or more analysis systems to perform a particular assay of the plurality of assays based on the determined order,

wherein determining the execution order comprises: the plurality of biological samples are organized into a plurality of sample batches according to at least one performance indicator, and wherein the biological samples in each sample batch are processed using the same assay resources.

26. The system of claim 25, wherein the processor is programmed to perform a method further comprising:

determining a measurement location of a first biological sample of the plurality of biological samples;

comparing the available analysis system at the assay location with a plurality of assays to be run at the assay location; and

initiating transport of the first biological sample from the assay location of the first biological sample to a second assay location.