阅读说明：本技术 高效执行生物测定的系统和方法 (System and method for efficiently performing biometrics ) 是由 克拉克·鲍尔斯 威廉·霍华德·加里森 迈克尔·T·范西克勒 迈克尔·芬斯克 于 2018-12-06 设计创作，主要内容包括：公开了一种用于以批次类型方式处理生物样本的自动化实验室系统。在一个实施例中,所述系统可以接收用于在多个设备之间进行生物样本处理的测定指令。设备可以包括预分析仪器和一个或多个分析系统。所述系统可以包括流程编排核心应用,其用于确定用于针对样本订购的测定的执行顺序。(An automated laboratory system for processing biological samples in a batch-type manner is disclosed. In one embodiment, the system can receive assay instructions for processing a biological sample between a plurality of devices. The apparatus may include a pre-analytical instrument and one or more analytical systems. The system may include a flow orchestration core application for determining an execution order for the assays ordered for the sample.)

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 metrics 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 the available assay resources and the operational status of the plurality of electronic instruments;

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

allocating a measurement resource of the available measurement resources to the one or more measurements 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.

2. The electronic system of claim 1, wherein the performance indicators of the electronic system comprise performance indicators 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 biochemical stability of the biological sample and biochemical stability of an assay resource.

4. The electronic system of claim 2, wherein the performance indicators of the electronic system further comprise performance indicators related to: a time of a laboratory worker required to operate the electronic system per time period, a maximum amount of time the electronic system requires no input from the laboratory worker, a minimum number of times the electronic system requires input from the laboratory worker 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 interruptions 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 indicators of the electronic system include performance indicators related to consumable expenditures required to complete the one or more assays.

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

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

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

11. The electronic system of claim 1, wherein determining an execution order comprises: organizing the plurality of biological samples into a plurality of sample batches.

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

13. The electronic system of claim 12, wherein an assay resource is configured to the electronic instrument to process the batch of samples simultaneously.

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

15. 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

determining an order of execution of the one or more measured updates to maximize at least one performance indicator of the electronic system.

16. The electronic system of claim 15, wherein the at least one performance indicator used to determine the execution order and the at least one performance indicator used to determine the updated execution order are the same.

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

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

updating available measurement resources after releasing the measurement resources for performing the one or more measurements; and

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

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

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

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

determining an order of execution of the one or more measured updates to maximize at least one performance metric of the electronic system.

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

tracking the available assay resources; and

laboratory personnel are notified when assay resources are unavailable or expected to be unavailable.

20. A method for conducting biometrics on a plurality of electronic instruments in a high-throughput automated manner, 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 a status of the plurality of electronic instruments;

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

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.

21. The method of claim 20, wherein the performance indicators of the electronic system comprise performance indicators of each of the plurality of electronic instruments, and wherein the target performance indicators of the electronic system comprise target performance indicators of each of the electronic instruments performing the one or more assays.

22. The method of claim 21, wherein the performance metric for each electronic instrument includes an amount of idle time per time period.

23. The method of claim 20, wherein the performance metrics of the electronic system comprise metrics for: a duration of an assay, a priority of a biological sample, a biochemical stability of each biological sample, a status of the electronic instrument, a concurrency of a plurality of assay resources required to perform a plurality of assays, or any combination thereof.

24. The method of claim 20, wherein the determining resources 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 thereof.

25. The method of claim 20, wherein the plurality of electronic instruments comprises a plurality of analysis modules and associated analysis sub-modules and a plurality of pre-analysis modules and associated pre-analysis sub-modules.

26. The method of claim 20, wherein determining an order of performance of the one or more assays comprises allocating assay resources to the one or more assays to be performed.

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

a memory storing measurement resources and performance indicators associated with each of the plurality of electronic instruments;

a database of assays to be performed on a biological sample;

a database of available electronic instruments in communication with the electronic system, wherein the database includes available assay resources for each electronic instrument;

an order of execution of each of the assays performed on the biological sample and an identification of an electronic instrument scheduled to perform the assay;

an interface configured to transmit operating instructions to a first electronic instrument listed in the execution sequence to perform a first assay; and

a processor programmed to perform a method comprising:

monitoring the first electronic instrument to determine when the first assay is complete;

instructing a second electronic instrument to perform a second assay on the biological sample; and

updating an execution schedule in the electronic system to indicate that a second assay has begun.

28. A system for high-throughput automated biometric determination, comprising:

a memory to store 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, based on the assay instructions, a plurality of assays that need to be performed for each of the plurality of biological samples;

identifying available analysis systems for running each type of assay 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

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

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

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

comparing available analysis systems at the assay location to 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.

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 is helpful for the healthcare industry to diagnose and treat diseases quickly and efficiently. With increasing demand, clinical laboratories that perform such diagnostic tests receive hundreds or thousands of samples per day. Automation of sample analysis may help address the challenges presented by managing such a large number of samples. Automated sample analysis is typically performed by automated analysis instruments, which are typically self-contained systems that perform multiple steps of processing on biological samples to obtain diagnostic results.

Automated clinical analytical 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 generally not directly available for analysis. To prepare a sample for testing with an automated analytical instrument, a laboratory technician typically transfers an aliquot of the sample from a primary container or tube received by the laboratory into an auxiliary container or tube suitable for the analytical instrument. In addition, the skilled person will generally need to know what test is to be performed on the sample, so that the skilled person can select the test-specific reagents or diluents to be paired with the sample. This is time consuming and may cause operator operational errors and exposure to infectious diseases.

Pre-analytical instruments are intended to help prepare samples for analysis and further to remove technician intervention in the process scheduling between the receipt of samples from the laboratory and the appearance of analytical instrument test results. However, many of these instruments still require significant technician involvement, for example, before the sample is loaded into the pre-analytical instrument, after the sample is prepared by the pre-analytical instrument, and after the analysis is completed by the analytical instrument.

For example, some pre-analysis 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 prone to error.

Furthermore, many of these systems cannot be integrated with one or more analytical instruments. In this regard, a technician is required to manually transfer the sample from the pre-analytical instrument to the analytical instrument and from the analytical instrument to a storage location upon completion of the analysis. This shifts the technician's attention to tedious work and can be distracting because the technician must constantly be aware of the progress of the pre-analytical instrument and the sample in the analytical instrument in order for the technician to be ready to transfer the sample as it is prepared, thereby minimizing downtime.

Furthermore, current pre-analytical and analytical instruments typically process samples in a continuous stream 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-analysis instruments typically do not take into account other information besides that provided by the user 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 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 the entire batch is complete for manual transfer to the analytical instrument. Alternatively, the technician may transfer a portion of the batch to the analytical instrument, which may reduce the productivity of the analytical instrument.

Disclosure of Invention

Systems and methods for running assays on biological samples and conducting biological assays with high throughput automation are disclosed herein. In one embodiment, the system comprises: a memory to store instructions; and a processor programmed with the instructions to perform a method comprising: receiving a plurality of assay instructions for a plurality of biological samples; and determining, based on the assay instructions, a plurality of assays that need to be performed for each of the plurality of biological samples; 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 the 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, based on the assay instructions, a plurality of assays that need to be performed for each of a plurality of biological samples; 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 the one or more analytical instruments to perform a plurality of assays based on the determined order.

In one embodiment, the system comprises: a memory to store instructions; and a processor programmed with 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, based on the assay instructions, a plurality of assays that need to be performed for each of a plurality of biological samples; identifying available analysis systems for running each assay of a 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 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 automated module configured to prepare a biological sample for at least one molecular assay; at least one second automated module for receiving the biological sample prepared by the first automated module and performing a molecular assay on the received biological sample, wherein the first automated module and the second automated module 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 for processing the biological sample from the analysis system 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 a state of the automated instruments is communicated to the flow orchestration layer, and based on a current state of the analysis system, the flow orchestration core computing device groups the two or more biological samples into batches and communicates 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 process orchestration core application described herein.

FIG. 7 is a block diagram showing various instrument states for an analysis system.

FIG. 8 is a block diagram showing 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 an exemplary method of determining an assay or an order of performance of assay steps for a sample to maximize performance of an analysis system.

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

FIG. 12 is a flow diagram of an exemplary method of determining an updated order of execution of assays or assay steps after receiving new assay instructions in an analysis system.

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

FIG. 14 is a flow diagram of another exemplary method of determining an order of performance of assays or assay steps and updating the order of performance to maximize a performance metric.

FIG. 15 is a block diagram of a process orchestration core application communicating with hospital and laboratory information systems and analysis systems over a network.

Fig. 16 is a schematic diagram of a cloud server-based process orchestration core application in communication with a process 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 dictates 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 here. It will be 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 not counted in a variety of different configurations, all of which are explicitly contemplated and made part of this disclosure.

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 process orchestration computing device receives input from the laboratory information system, coordinates the operation of one or more analyzers and pre-analyzers for processing samples in an information transparent and efficient manner, thereby increasing the overall efficiency of running assays on multiple analysis systems and analyzers (also referred to as analyzers and assay devices). It is contemplated that the flow orchestrates various discrete inputs to the computing device, 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 comprise 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 108 b. The pre-analysis instrument 104 can include a user interface 112 for receiving user input and an input window 116 for receiving a sample. Each of these units 104, 108a and 108b is modular. Thus, the pre-analysis instrument 104 may be coupled to one or more analysis instruments. Further, each analytical instrument in communication with 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 papillomavirus ("HPV") assays, while the second analytical instrument 108B may perform bacterial and parasitic assays, such as those used for detecting chlamydia trachomatis, neisseria gonorrhoeae, trichomonas vaginalis, group B streptococcus, enteric bacteria, and enteric parasites. However, in some embodiments, analysis system 100 may be configured such that first analysis instrument 108a and second analysis instrument 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.

Pre-analytical instrument 104 and analytical instruments 108a, 108b each have hardware components that allow them to perform specified operations. For example, in one embodiment, the pre-analysis instrument 104 may be configured to pre-process a biological sample in order to prepare the sample for analysis by the analysis instruments 108a, 108 b. In this regard, the pre-analysis instrument 104 may have a tray/shuttle handling robot capable of transporting a tray/shuttle of sample containers from one location to another location within the instrument and to an adjacent analysis instrument, a sample container handling robot capable of transporting and/or decapping individual sample containers, a pipette robot capable of drawing a sample from one container into another container, a diluent applicator for diluting the sample, a vortexer for vortexing the sample, a heating plate for heating the sample, and a cooling unit for cooling the sample. The analytical instruments 108a, 108b may also have robots capable of moving containers within their individual instruments, from the pre-analytical instrument 104, and back to the pre-analytical 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 for sample purification (along with paramagnetic particles added to the sample)), and any other hardware components necessary to perform instrument operations.

In addition to hardware components, the pre-analysis instrument 104 also includes a staging or accumulation zone. These areas are locations where 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 the 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 can process the sample for analysis in the analytical instrument 104. Analytical instrument 108 may be configured to perform an assay on a biological sample, while pre-analytical instrument 104 may be configured to prepare the sample for analysis by analytical instrument 108. For example, the pre-analysis instrument 104 may transfer a biological sample from one container to another container suitable for use by the analysis instrument 108, and may also vortex, 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, stand-alone units having a robot capable of transferring biological samples back and forth between the various units when coupled together.

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

The analysis system 100 can include a flow orchestration core application 220 executed by a flow orchestration core computing device 224, the flow orchestration core computing device 224 communicating with the analytical instrument 108 and the pre-analytical instrument 104 through a cross-instrument interface 228, and communicating with the laboratory information system 204 through the 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 malicious software that may impede 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 pre-analysis instruments 104 to achieve efficient utilization of available resources and maintain the activity of these resources at or above a predetermined threshold level. The performance of the analysis system 100 may be determined based on the performance indicators. For example, the performance metric may be a maximum percentage of usage of the processing resources available for the processing demand at a given point in time. In addition, the flow orchestration core application 220 utilizes information received from the laboratory information system 204, the analytical instruments 108, and the pre-analytical instruments 104 to reduce, significantly reduce, or even eliminate operator involvement and make high-level decisions on the activities to be performed in each instrument based on changing circumstances.

In one embodiment, the computing devices 232, 236 of the pre-analysis instrument 104 and the analysis instrument 108 execute the flow orchestration sub-applications 240, 244. Such flow orchestration sub-applications 240, 244 are linked to the flow orchestration core application 220 for implementing the instructions provided by the flow orchestration core application 224. In this regard, decisions and instructions for implementing such decisions are passed down from flow orchestration core application 220 to the particular hardware component performing the indicated action. Instructions become more specific as they move down the chain from the flow orchestration core application to the various hardware devices. Information is also passed up from the various hardware devices to the flow orchestration core application, so that the flow orchestration core application frequently receives status updates that inform the decision-making processes.

The flow orchestration core application 220 and 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 analytical instruments 108 and the pre-analytical instruments 104. Since the idle time of system resources can reduce overall performance, the goal is to achieve the required hardware resource utilization within such an instrument.

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

In addition to performing batch processing on samples, the flow orchestration core application 220 may also obtain a large amount of information input from various sources in controlling and coordinating the processing resources 248, 252 of the pre-analytical instrument 104 and analytical instrument 108. Such information includes the inventory of consumables 256, 260 of the instrument and the allocation of that inventory for the processes in the queue, the operating status of the instrument hardware, the assays ordered to be performed on the sample, the availability of the sample; the lot that has been in process, the age of the sample, the availability of the pre-analytical instrument 104 and the analytical instrument 108, the availability of the instrument devices 264, 268 of the pre-analytical instrument 104 and the analytical instrument 108, the biochemical stability of the sample and reagents 272, 276, and the business or compliance practices of the 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 so that the analysis system 100 can remain operational while hardware is replaced and consumables are replenished.

The flow orchestration core application 220 receives measurement instructions from a variety of different external systems (e.g., the laboratory information system 204, the hospital information system, and another analysis system). In some embodiments, when the sample arrives in the pre-analysis instrument 104, the pre-analysis instrument 104 knows exactly what processing is to be performed on the sample. The decision on the actual processing can to a large extent be made in advance. That is, when a sample arrives at the pre-analysis instrument, the required decisions regarding batching, timing, metering, and consumable resources are all incorporated into the flowcharting core application 220.

The flow orchestration core application 220 may include three components: a flow arrangement state component, a flow arrangement decision maker component and a flow arrangement 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 flow orchestration state component stores state information. The process orchestration status component is configured to receive the operational status of the system hardware and instrumentation devices 264, 268. Thus, each instrument and sub-modules within each instrument are configured to output information about its status, and this status information can be used directly but more commonly is passed to the flow orchestration status module through the logic of the applicable instrument. The flow orchestration decider 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 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 lot being processed. Using this information, the process orchestration core application 220 is configured to determine a net consumable inventory and make process flow determinations based on the net inventory amount to ensure that no consumable parts are available to process the sample. In addition, the flow orchestration core application 220 is configured to notify the user of the need to replenish certain consumables 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 examples. Various sensors may be implemented to track such consumables 256, 260, such as level sensors for bulk diluent. Also, the flow orchestration core application 220 may track the initial consumable inventory and how many consumables 256, 260 have been used from the initial consumable inventory to determine the net worth.

Coordination core application 220 also tracks the operating state of analytical instrument 108 and pre-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 instrument devices 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. One 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 a component operational error or failure. In this regard, the flow orchestration core application 220 has a predetermined error protocol that it will execute in the event of a component operational error or failure. Another function performed by the flow orchestration core application 220 is to know both the instruments, equipment and individual components needed to process a given batch, and whether hardware components, pre-analytical instruments and analytical instruments are currently participating in or allocated to a process.

The flow orchestration core application 220 communicates with one or more information systems to obtain the 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 need not obtain sample assay ordering information, thereby reducing user error and freeing up time for technicians to undertake other tasks.

The flow orchestration core application 220 is also configured to track the biological/chemical/mechanical life 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 life of the sample and consumable exceeding the limit can adversely affect the authenticity of the assay results. This lifetime decreases over time and the biochemical properties of the reagents or samples may change if the age of the reagents or samples exceeds a certain threshold. The flow orchestration core application 220 may prioritize the samples in a way that ensures that the assay protocol steps are completed before the samples or reagents have exceeded their lifetime.

The flow orchestration core application 220 may also be configured to receive information from the pre-analysis system 104 and the analysis system 108, which will allow the samples to be tracked throughout the sample processing. This includes tracking the acquisition of sample aliquots that are dispensed into different containers for sample processing, and the transport of samples from one instrument to another, e.g., transport of samples from pre-analytical instrument 104 to analytical instrument 108 (and vice versa). This enables the laboratory technician to query the system and instrument for the sample location and its progress of the assay. If multiple assays are ordered for a single patient sample, the procedural orchestration core application 220 coordinates and tracks the performance of the multiple assays for the single sample without user intervention, thereby maximizing or at least increasing the overall efficiency of performing 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 analytics system 100B in fig. 2B is a centralized system with the functionality of the flow orchestration sub-applications 240B, 244B executed by the flow 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 108 b. The pre-analysis instrument 104b can process the sample for analysis in the analysis instrument 104 b. Analytical instrument 108b can be configured to perform an assay on a biological sample, while pre-analytical instrument 104b can be configured to prepare the sample for analysis by analytical instrument 108 b. The analysis system 100b may communicate with the laboratory information system 204b via the network 208 b. Analysis system 100b can include a process orchestration core application 220b executed by a process orchestration core computing device 224b, the process orchestration core computing device 224b communicating with analysis instrument 108b and pre-analysis instrument 104b through an interface 228b (e.g., a cross-instrument interface, an inter-device interface, or an intra-device interface). The analysis system 100b may communicate with the laboratory information system 204b via the network 208 b. Flow orchestration core application 220b may coordinate processes and manage resources between one or more analytical instruments 108b and pre-analytical instrument 104b to achieve efficient utilization of available resources and to maintain the activity of these resources at a predetermined threshold level or higher.

The flow orchestration core computing device 224b executes the flow orchestration sub-applications 240b, 244 b. Such flow orchestration sub-applications 240b, 244b are linked to the flow orchestration core application 220b to implement the instructions provided by the flow orchestration core application 220 b. In this regard, decisions and instructions for implementing such decisions are passed down from the flow orchestration core application 220b to the flow orchestration sub-applications 240b, 244b and then to the particular hardware component that performs the indicated action. These instructions become more specific as they move down the chain from flow orchestration core application 220b to flow orchestration sub-applications 240b, 244b to the various hardware devices. Information is also passed up from the various hardware devices to the flow orchestration core sub-applications 240b, 244b to the flow orchestration core application 220b, so that the flow orchestration core application 224b and the 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 analytical instrument 108b and the pre-analytical instrument 104 b. The procedural orchestration core application 220b makes decisions regarding biological samples to be processed and evaluated by the pre-analytical instrument 104b and the analytical instrument 108b, respectively, based on information from the laboratory information system 204 b. In addition to performing batch processing on the samples, the flow orchestration core application 220b also obtains a large amount of information input from various sources in controlling and coordinating the processing resources 248b, 252b of the pre-analytical instrument 104b and analytical instrument 108 b. The procedural orchestration core application 220b receives measurement instructions from a variety of different external systems (e.g., the laboratory information system 204b, the hospital information system, and another analysis system).

The flow orchestration core application 220b may include three components: a flow arrangement state component, a flow arrangement decision maker component and a flow arrangement engine component. The process orchestration core application 220b may track consumable inventory. The flow orchestration core application 220b also tracks the operating state of the analytical instrument 108b and the pre-analytical instrument 104b itself. The orchestration core application 220b is also configured to track the biological/chemical/mechanical life 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 flow orchestration core application 220b may also be configured to receive information from the pre-analysis system 104b and the analysis system 108b via flow orchestration sub-applications 240b, 244b, which will allow the samples to be tracked throughout the sample processing.

In the embodiment illustrated in FIG. 2B, the flow orchestration core application 220B, the flow orchestration sub-application 240B and the flow orchestration sub-application 244B are illustrated as three components of the flow orchestration core computing device 224B. However, this is merely illustrative and is not intended to be limiting. In another embodiment, the flow orchestration core computing device 224b may implement the flow orchestration core application 220b, which may perform the functions of the flow orchestration sub-applications 240b, 244 b. In one embodiment, the flow orchestration core computing device 224b includes a flow orchestration sub-application linked to the flow orchestration core application 220b to implement the instructions provided by the flow 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 embodiments 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., barcodes, QR codes) on sample containers or sample holders. the flow orchestration core computing device 224 communicates with a pre-analysis instrument computer control device 232 of a pre-analysis instrument 104 and one or more analyzer computer control devices 236a, 236a2 of an analysis instrument 108a, 108b (shown here as two such control devices; each control device IS for one analysis instrument). As shown, the flow orchestration core computing device 224 connects to a network 208, the network 208 also connects to a laboratory information system 204 ("L IS") L IS 204. the IS204 may be coupled to a laboratory diagnostic room or diagnostic laboratory diagnostic room computer control devices associated with storing and maintaining patient records, doctors ordering diagnostic instruments, or other diagnostic instruments 38 a, 224 a communications mechanism may also allow the flow orchestration core computing devices 224 a, 236, 26 a, and other medical instruments, 26 a, which are coupled to share information via a communications mechanisms, 224, and/18 a communications.

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

The analyzer computer devices 236a1, 236a2 may also each include a processor and storageA device. In addition to connecting to cross-instrument interface 228, analyzer computing device 236a1 also connects to module interface 312a1, and module interface 312a1 connects to analytical instrument A₁Thereby allowing the 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 relating to the pair of signals provided to the analyzer instrument a via the system 100₁The sample(s) under analysis is subjected to control of the physical operations utilized in the analysis. In this regard, the analyzer computing device 236a1 facilitates control of the analyzer instrument a via the processor of the analyzer computing device 236a1₁Each instrument/device in (1). The analyzer computing device 236a2 is similarly configured for its respective analysis 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 intelligently perform the preparation and pre-processing of multiple different samples contained in multiple different containers.

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

Each of the devices 232, 236a1, 236a2 and the process orchestration core computing devices 224 and L IS204 are at different nodes of the network 208 and are capable of communicating with each other directly and indirectly, however, as shown, the process orchestration core computing device 224 generally serves as a control interface between L IS204 and the computing devices 232, 236a1, 236a2 of the analytical instruments 108a, 108b and pre-analytical instruments 104. various protocols and systems may be used to interconnect the computing devices 232, 236a1, 236a2 and the process orchestration core computing devices 224 and L IS within the network 208. the network 208 may utilize standard communication protocols (e.g., Ethernet and Wi-Fi) and protocols proprietary to one or more companies, as well as various combinations of the foregoing.

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

Process orchestration core application and sub-application states

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

The communication interfaces 404 a-404 c forward information related to state changes in the analytical instruments and pre-analytical instruments to the process orchestration status component 408, the process orchestration status component 408 being part of either the pre-analytical instrument computing device 232 or one of the analyzer computing devices 236a1 or 236a 2. The process orchestration status component 408 passes the status changes to the process orchestration engine component 412 of either the pre-analyzer instrumentation computing device 232 or the analyzer computing device 236a1 or 236a 2. The flow orchestration engine component 412 is in two-way communication with the flow orchestration decision component 416 of either the pre-analyzer instrument computing device 232 or the analyzer computing device 236a1 or 236a 2. In response to a request from the flow orchestration engine component 412, the flow orchestration decision component 416 determines whether the flow orchestration engine component 412 is to dispatch instructions to the analytics device 108 and the pre-analytics device 104.

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

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

The instructions may be any set of instructions (e.g., machine code) that are directly executed by one or more processors or any set of instructions (e.g., script) that are indirectly executed by one or more processors. In this regard, the terms "instructions," "applications," "steps," and "programs" may be used interchangeably herein. The instructions may be stored in an object code format for direct processing by a processor, or in any other computing device language, including scripts or collections of separate source code modules that are interpreted or pre-compiled as needed. The function, method and routine of the instructions will be described in more detail below.

Data may also be formatted in any computing device readable format, such as, but not limited to, binary values, ASCII, or Unicode.

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

In some embodiments, the processor or memory may actually comprise multiple processors and/or memories, which may or may not be stored within the same physical housing. For example, the memory may be a hard drive or other storage medium located in a housing different from that of the processor. Thus, references to a processor, computing device, or memory are to be understood as including references to a collection of processors, computing devices, or memories 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 depends largely on design choice. As shown, the flow orchestration core computing device 224 may also communicate with the code scanner 304 and the user interface 112 of 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 the housing of the pre-analysis instrument 104 (shown in FIG. 2A). However, it should be understood that the user interface 112 may include a mobile device capable of wirelessly connecting (e.g., wirelessly over a Wi-Fi connection) to the flow orchestration core computing device 224. By way of example only, the user interface 112 may be a mobile phone or device capable of obtaining information via the network 208, such as a wireless-enabled PDA, tablet PC, or netbook. 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.

Process orchestration core application

As shown in FIG. 4, the flow orchestration core application 220 includes components for information flow, such as the communication interfaces 404 a-404 c, the flow orchestration decider component 416, the flow orchestration engine component 412, and the flow orchestration status component 408. The process orchestration state component 408 receives and saves all information about the process 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 flow orchestration decider component 416 implements an algorithm that determines the next action to take based on the flow orchestration status received from the flow orchestration status component 408. The task of the communication interfaces 404a to 404c is to process input information from the analysis instruments and pre-analysis instruments for updating the process orchestration state.

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

In one embodiment, to ensure that such decisions are atomic, flow orchestration engine component 412 runs on its own thread and is configured to implement one or more policies to prevent state updates during decision making. In other embodiments, the threads are not immediately (on the fly) configurable. For example, in one embodiment, the flow orchestration engine component 412 is configured to lock the flow orchestration state when making copies of the flow orchestration state. This copy of the flow orchestration state is used for the decision making process. This allows the locking of the application flow choreography state in a shorter period of time, thereby limiting the opportunity for race conditions. Race conditions may occur when multiple pieces of state data change during execution of a decision. For example, there are thirty patient samples in one lot at the start of a decision and sixty samples in two lots at the end of the decision. The two states are identical. If the flow orchestration state is not under the control of the flow orchestration engine component 412, the inconsistent state of a batch of sixty samples may be seen, thus making an "invalid" decision.

In another embodiment, the flow orchestration engine component 412 can be configured to first determine what action to perform and then perform the action. Additionally, the flow orchestration engine component 412 can be configured to apply a lock on the flow orchestration state during the decision making process. It may also allow the lock to be applied in a short period of time if the decision as to which action to perform is fast. The delayed decision may delay processing and the delayed decision may prevent status 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 the wait state or sleep state) and process each change in the queue. When the queue is empty, the flow orchestration engine component 412 can be configured to then run the flow orchestration decision component 416 and perform the decision.

In another embodiment, the flow orchestration core application 220, which may be implemented by the flow orchestration core computing device 224, is configured to apply locking on the flow orchestration engine component 412 and the flow orchestration state component 408. If the flow 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 time and other threads may be prevented from executing if flow orchestration engine component 412 is busy. Because the lock-up time is longer, race conditions are more likely to occur.

Process arrangement sub-application system

As shown in fig. 5A, analytical instruments 108a1 and 108a2 and pre-analytical instrument 104 include a flow orchestration sub-application 240, 244a1, 244a 2. These applications 240, 244a1, and 244a2 are stored on respective memories of the computing devices 232, 236a1, and 236a2 and provide instructions to their respective processors relating to the coordination and control of hardware devices (e.g., as described above) within the units 104, 108a1, and 108a 2. The procedural orchestration subsystems 240, 244a1 and 244a2 are the communication links between the procedural orchestration core application 220 and the various components/subsystems/hardware within the instruments 104, 108a1 and 108a 2. In this regard, the sub-applications 240, 244a1, and 244a2 help execute instructions provided by the flow orchestration core application 220 and allow for modularity 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 permissions as the instructions pass in the direction toward the hardware device, which translates into the targeted action of the discrete device. For example, when a sample is received by the pre-analysis instrument 104, one or more flow orchestration sub-applications 240 issue specific instructions to specific devices 264 to accomplish the tasks required to support the receipt of this sample 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 operating status of the device 264, the current level of consumables, and the location of a particular sample. This pyramid structure allows the process orchestration core application 220 to focus on high-level decision making and information collection.

The orchestration sub-applications 240, 244a1, and 244a2 may be configured, similar to the orchestration core application 220, to coordinate activities between various devices within each cell 104, 108a1, 108a2 and across cells 104, 108a1, 108a 2. For example, the conveyor manager sub-application of pre-analysis instrument 104 and the robotic arm manager sub-application of second analysis instrument 108a2 may coordinate the availability and operation of respective conveyor and robotic arms to transfer sample containers from the conveyor of pre-analysis instrument 104 to the robotic arm of analysis 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 activities of moving a rack of samples throughout the pre-analysis instrument 104. For example, the rack manager sub-application may host rack objects and make decisions based on rack status values assigned to the objects, which may be a single enumeration indicating where the rack is and what operations are being performed on it. Such decisions may include which sample to move and where the sample is to be moved. In addition, the rack manager sub-application coordinates the transfer of the rack with other components or stations (e.g., sample conversion stations or rack elevators) within the pre-analysis instrument 104.

However, since the shelf manager sub-application is a state machine, state changes that occur during decision making 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 state updates during decision making. For example, in one embodiment, the rack manager sub-application may be configured to apply locks to rack states while making copies of the rack states. 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 chance of race conditions.

FIG. 5B is a block diagram of a flow orchestration core application and a flow orchestration sub application of the centralized analytics system described with reference to FIGS. 2B and 3B. As shown in fig. 5B, process orchestration subsystems 240B, 244B1, and 244B2 are communication links between process orchestration core application 220B and the various components/subsystems/hardware within 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 between various devices within each cell 104b, 108a1, 108a2 and across cells 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 the architecture of the flow orchestration core application 220, which as shown has a multi-instrument service layer 610, a flow orchestration layer 620, and an instrument module layer 630. Each layer is composed of a plurality of system user objects, each encapsulating a separate class of user operations. The plurality of system user objects advantageously includes (1) a service level object layer 610, including a module service base module 614 for the system shown in FIG. 6. The service level object layer 610 is part of a process orchestration control application service module 612, and the process orchestration control application service module 612 communicates with modules in the process orchestration layer 620, the instrumentation module control layer 630, and the instrumentation module layer 650. The process control application service module 612 communicates with a module for requesting sample information 646, a module for coordinating lots 642, a module for managing module registration 636, and a module for updating inventory status 632. The flow orchestration control application service module 612 also communicates with other modules in its layer (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 flow orchestration engine module (or component) 624 is in communication with the module services base module 614, and the module services base module 614 also receives instructions from the flow orchestration control application services module 612. The process orchestration engine module 624 obtains the process orchestration status from the process orchestration status module 622. The flow orchestration status module 622 receives status information from each module in the layer 630, and indirectly from each module in the layer 650. These modules are the inventory status updater module 632, the available consumables per assay module 634, the module registration manager 636, the module status module 638, the lot module 540, the coordinated lot module 642, the sample module 644, and the request sample information module 646. In response to a request from flow orchestration engine module 624, flow orchestration decision module 626 determines whether flow 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 about the registration and tracking of individual samples in the instrument. In one embodiment, the sample information is obtained by the instrument reading a sample code on a received sample container. The sample code on the transfer container is also registered to identify and track the transfer container 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 containers and the transfer containers. When sample information is obtained, the sample information in sample information module 644 is updated. The updated sample information is passed to the process orchestration status module 622.

Tier 630 also has a module 642 that coordinates lots by communicating with an instrument coordinate lot module 656 in the instrument with module 642. By interacting with the coordinate batch module in layer 630, instrument coordinate batch module 656 populates the shuttle with samples that are designated as the same batch by process orchestration control application service module 612. Coordinated batch module 642 also provides instructions to instrument coordinated batch module 656 to initiate a batch processor device in instrument coordinated batch module 656, and provides instructions to instrument coordinated batch module 656 to initiate a shuttle transfer. The coordinate batch module 642 communicates with both the process orchestration status module 622 and the batch module 640 (which in turn communicates with the process orchestration status module 622).

Layer 630 also has a module 640, and module 640 passes the module status to the flow orchestration status 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. The module registration manager 636 also passes information to the process orchestration status 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, tier 630 has a module 632 that updates the 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 an inventory module 652 in the pre-analytical instrument to obtain various information regarding the status of consumables in the instrument. The information includes inventory information about available consumables; obtaining consumables as required; reserving consumables; recovering consumables; the inventory is changed.

In another embodiment, the shelf manager sub-application may be configured to first determine the actions to be performed and then perform the actions. Additionally, the rack manager sub-application may be configured to apply locks to rack states in the decision making process. This may also allow the lock to be applied in 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 a 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 rack manager sub-application may be configured to apply locks on the rack 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 assay conditions

In one embodiment, the instrument is provided with a defined state. For example, the instrument state 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 an instrument is in a power down state, a power up command changes state to "offline idle". The offline idle state may change to "offline busy" when an offline procedure (e.g., instrument service, software update, etc.) is being performed, and in the case of performing an offline procedure, the offline idle state will remain until after the offline procedure is completed. If there is no offline procedure that prevents the change of state from offline idle to online idle, then a command is used to bring the instrument online and change the state to online idle. In the online idle state, the instrument start-up procedure may be instructed. Upon completion, the instrument will return to the online idle state. If the instrument is paused (suspended busy) during execution, no new process is started until the state is restored to online busy and the process is completed. When the instrument is in the online idle state, it will always be available to receive commands to perform further activities unless a suspend idle state is entered, in which case no new processes may be initiated or instructions may be received to take the instrument offline.

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

TABLE 2 definition of assay conditions

Fig. 9 shows how the states are stored for a particular assay. If the assay status is "not allowed," regional rules for the assay are applied, in which case the assay will be provided in a "not-good" status that will allow the assay to be performed, but the assay result will not meet the patient's requirements. To be qualified, implementation will be challenged. If the state is qualified, but a new version of the assay has been released, the older version of the assay is still performed before the new version is qualified.

Determining the assay or the sequence of assay steps

The flow orchestration core application 220 may determine the order of execution of the assays or assay steps based on the received samples, the ordered assays, and the availability of the resources 248, 252. FIG. 10 is a block diagram of a non-limiting exemplary method 1000 of determining an assay or order of performance of assay 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 starting 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 barcode and a two-dimensional code, affixed to the sample container. The method 1000 may receive the scanned sample code as the scanner 304 scans the sample code. At decision block 1012, if the scanner 304 scans for and receives additional sample codes, the method 1000 may return to block 1008 to receive more sample codes. The additional sample codes may be from the same rack sample or from another rack sample received by the analysis system 100.

At decision block 1012, if no additional sample codes are scanned and received, the method 1000 may proceed to block 1016 at block 1016 where the method 1000 determines the 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 a assay to be performed on a sample based on a sample identification and assay instructions determined from a sample code. For example, a doctor may order three tests A, B and C for a patient, and a container containing a patient sample may have a sample code 123456 affixed thereto. After the method 1000 receives the sample code 123456, the method 1000 can determine the identity of the sample (i.e., the patient's sample) and determine the three tests that the physician has ordered or specified 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 measurements for the order of the samples. The condition of the sample may be sample volume, age of the sample, sample quality (e.g., sample opacity). For example, three tests A, B and C ordered by the doctor for the patient require 1ml, 5ml and 10ml, respectively. However, the volume of the patient sample determined by the pre-analysis instrument 104 may be only 15 ml. Thus, the volume of the patient sample cannot meet the total requirements of the three assays ordered because the volume of the patient sample is only sufficient to perform two assays. If the sample does not satisfy the requirements of the ordered one or more assays, the method 1000 proceeds to block 1024 where the method 1000 notifies the user that the sample condition does not satisfy the requirements of the ordered assay in block 1024. 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 a sample may include a priority of the assay to be performed. The method 1000 may determine the assay that should be performed on the sample even if the condition of the sample does not meet the requirements of all assays ordered for the sample. For example, the measurement instructions for a patient sample may indicate that the results of measurements a and B can only be interpreted together. The assay instructions may also indicate that assay a is more important than assay C. Accordingly, method 1000 may proceed from block 1020 to perform assays a and B and notify the user that assay C will not be performed. In some embodiments, the method 1000 may display possible assays that may be performed on the sample and request user input regarding the assay that should be performed.

At decision block 1020, if the sample conditions meet the requirements of the ordered assay, the method 1000 proceeds to decision block 1032, where the method 1000 determines whether the analysis system 100, including the pre-analytical instrument 104 and the analytical instrument 108, has sufficient resources to perform all of the 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 ordered determination. The method 1000 then proceeds to block 1028, where the method 1000 ends. For example, the pre-analysis 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 vessels. The method 1000 may notify the user via the user interface 112 that the user needs to stock more pipette tips and containers in the pre-analysis instrument 104.

Table 3 shows exemplary resources of the analysis system 100, which analysis system 100 may require exclusive access such that each resource may only be used for the preparation or analysis of one sample or 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 (perhaps after the analysis system 100 provides the user with an option for the user to select). For example, a user may initiate emptying 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 an analytics system that may require exclusive access

Group of	Name (R)	Starting up
			Maintenance	Daily	User scheduling or requesting
Sample(s)	Conversion	Frame in hotel
			Sample(s)	By passing	Frame in hotel
Sample(s)	HPV sample batches	Assembly batch
			State change	Software update	User scheduling
State change	Pause Dory	User request
			Rack	Loading sample rack	Shelf in I/O tray
Rack	Unloading completed rack	User request
			Consumable material	Storage Dory consumable drawer	User request
Consumable material	Emptying Roz waste	User request
			Intervention	Clamping tubes in shuttles	Failure of consumable

TABLE 4 resources of the analysis System

In one embodiment, method 1000 may determine a combination of measurements that may be performed in the event of insufficient system resources and allow the user to determine the measurements 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 an 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 the assay steps or assays that the analysis system 100 may perform simultaneously are determined. 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, these two steps may not be performed simultaneously. However, if the analysis instrument 108 comprises two or more heating plates, the two assay steps may be performed simultaneously.

Method 1000 proceeds to decision block 1040 to determine whether the test instruction includes any special instructions. For example, a special instruction may state that the measured 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 metric. 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 execution order may be affected by the scheduled events. For example, the scheduled event may be routine maintenance, a scheduled firmware or software update, a scheduled hardware upgrade, and a scheduled power outage. The order of execution may be affected by the physical or logical configuration of the components of the analysis system 100. For example, the execution order may be influenced by the physical or logical configuration of the pre-analytical instrument 104, the analytical instrument 108, the electronic instruments 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 comprise the step 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 instructions include special instructions, the method 1000 may proceed to block 1048 to determine an order of execution of the metering to be performed in a special instruction prioritized manner while maximizing the performance metric. For example, if the patient's order of the assay is an emergency order, the method 1000 may determine an order of execution that maximizes performance of the assay in addition to the performance of the assay of the emergency order. 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. These three resources may be, for example, vortexes, pipettes, and heating plates. Assays 1, 2 and 3 required 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 measurement steps of different measurements requiring the same resources may be placed in a batch. Fig. 11 shows three possible execution sequences of the assay steps. As shown in fig. 11, the execution sequence (1) requires a longer running time than the execution sequences (2) and (3). However, if the emergency instruction includes a determination of 1, the execution order (1) may maximize the performance index. In fig. 11, the step of determining that resource B is needed may be batch processed while the emergency instruction is first executed to minimize the total run time.

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

Determining updated assays or sequence of assay steps

After the flow orchestration core application 220 determines the execution order, the analysis system 100 may receive new measurement instructions from the laboratory information system 204 or the hospital information system before the execution of the measurements on the sample is complete. New assay instructions may be received after or before the analysis system 100 begins processing and analyzing the sample. FIG. 12 is a block diagram of a non-limiting exemplary method 1200 of determining an updated execution order of a measurement or measurement steps 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 starting at block 1204, the method 1200 proceeds to block 1208, where the flow 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 execution order of the metering 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 at block 1212. 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 instrument devices 264, 268 to become available and then perform one or more assays that have been ordered for the sample. As another example, new metering 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 metering instruction is for an existing sample or for a new sample. If a new metering instruction is used 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 barcode 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 a sample code scanned using the code scanner 304. After receiving the new sample code, the method 1200 proceeds to block 1124 where the flow orchestration core application 220 may determine a new execution order. The new execution order may be based on the assay or assay step that the analysis system 100 may perform according to the assay or assay step currently being executed. Table 5 shows four states of assays or assay steps that can be performed simultaneously depending on the other assay or assay step 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 the prospective assay or assay step that can be performed. The four states in table 5 are ordered from least restrictive to most restrictive. The least restrictive state is the most expensive to implement in terms of resources of the analysis system 100.

TABLE 5 determination or determination of procedure complications

At decision block 1216, if a new metering instruction is used for the 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 metering 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 a performance metric, 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 before receiving the new sample code. The method 1200 may continue to determine new execution orders until 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 can continue to perform the assay to maximize performance without causing any time delay in determining the new execution order.

Determining the performance of an assay or assay stepLine sequence

The flow orchestration core application 220 may determine the order of execution of the assays or assay steps based on the received samples, the ordered assays, the availability of the resources 248, 252, and the operational status of the electronic instruments 264, 268. FIG. 13 is a flow diagram of an exemplary method 1300 of determining an order of execution of assays or assay steps and updating the order of execution to maximize one or more performance indicators. 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 procedural orchestration core application 220 receives measurement instructions for a biological sample 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 Complete Blood Count (CBC), a blood chemistry test, a blood enzyme test, and a blood test to assess a cardiac risk of a sample of the subject, and performing a blood test to assess a cardiac risk. The flow orchestration core application 220 may receive measurement instructions from an instruction provider (e.g., a healthcare provider) or laboratory personnel (e.g., a laboratory technician).

After receiving the metering instructions, the method 1300 proceeds to block 1312, where the flow orchestration core application 220 determines, based on the metering instructions, the metering to be performed on the biological sample on the electronic instruments 264, 268. Determining the assay to perform 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 flow orchestration core application 220 determines available measurement resources and the operating state of the electronic instruments 264, 268. 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 an order of execution of the measures. For example, the execution order may be based on the available assay resources determined at block 1316 and the operating state of the electronic instruments 264, 268. The flow orchestration core application 220 may determine an execution order to maximize one or more performance metrics of the analysis system 100. In one embodiment, the flow orchestration core application 220 may optionally receive a sample scan code to determine the 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 valid assay results can be determined based on the biochemical stability of the biological sample and the biochemical stability of the assay resource per time period (e.g., one round per 8 hours, 24 hour time 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 assays can be optimized or maximized to ensure that the assay results are generated before final biochemical stability. All steps of performing an assay on a biological sample do not guarantee clinically useful results. Various factors may invalidate the results. For example, the flow orchestration core application 220 may track the biochemical lifetime of the inventory and sample under various states of assay protocol execution. Exceeding these lifetime limits may cause uncertainty in the assay results and thus reduce the throughput of the machine. Thus, the orchestration core application 220 may track the viability of patient samples, assay controls, assay reagents, and the like. These lifetimes vary as the assay is performed, and the biochemical properties of the sample are altered by the assay steps. The procedural 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 of the analysis module 268 and sub-modules busy, as well as the pre-analysis module 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 the 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 be relieved of this responsibility and human errors can be eliminated from the processing chain. Other laboratory personnel may ask the patient sample for location and progress of the assay. If multiple assays are ordered for a single patient sample, the process orchestration can coordinate and track the performance of the multiple assays without the intervention of laboratory personnel. The performance indicators 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 indicator 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 time period.

The labor required may also be determined based on the number of interruptions of the electronic system per time period. For example, a second important indicator of system usage may be the labor required to operate the analysis system 100. The analysis system 100 may be designed to minimize the number of interruptions for each round of laboratory personnel. By grouping large batches of manual operations together, disruptions to a particular laboratory function can be minimized. This is balanced against achieving maximum throughput, which may require the operator to reserve instrumentation and prepare for more assays.

The performance index may be determined based on one or more predetermined conditions (e.g., a determined urgency, a profile of the subject, an identity of the provider of the instruction, or a combination thereof). The condition may be determined by the measured urgency as specified by the service level agreement. For example, from a clinical practice point of view, there may be an urgency of the assay to be performed or the test to be completed, such as in patient management. As another example, the urgency of the assay to be performed may be determined based on a patient profile (e.g., patient demographics and statistical attributes of the assay and the subject). For example, the urgency of the assay to be performed may be influenced by the business flow of the laboratory operating the system and the need to meet service level agreements between the laboratory and the instruction provider (e.g., laboratory customer). As another example, the condition may be a one-time event, such as a laboratory person temporarily misplacing a sample.

In one embodiment, the performance indicator includes a weighting matrix having a number of valid measurements 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 indicators include indicators corresponding to a duration of the assay, a priority of the biological samples, a biochemical stability of each biological sample, a status of the electronic instrument, a concurrency of a plurality of assay resources required to perform a plurality of assays, or any combination thereof. In another embodiment, the performance index reflects a predetermined guideline for sampling and measurement. For example, the assay order may include parameters such as result urgency, sample expiration, user-defined parameters, and the like. The performance index may reflect such parameters. 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 an order of execution of one or more assays based on available assay resources. The process orchestration core application may consider available inventory, operating status of hardware components, measurements ordered by patients, sample availability, sample age, lot already processed, availability of analysis modules, analysis sub-modules, and pre-analysis modules, biochemical stability, and/or laboratory business practices. Efficient process scheduling can minimize consumable expenditure, 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 can be configured to process a batch of samples simultaneously. The electronics can be configured with measurement resources to process a batch of samples simultaneously. For example, similar measurements are required for thermocycling performance, since all samples are exposed to the same temperature change and frequency. Thus, 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 instrument devices 264, 268 may be designed to process 96 samples in a 96-well plate format. Therefore, in order to maximize the total throughput, each batch used for the assay should include 96 samples.

At block 1324, the flow orchestration core application 220 may allocate the metering resources to the metering to be performed. The flow orchestration core application 220 may track available measurement resources and notify laboratory personnel when measurement resources are not available or are expected to be unavailable. For example, the process 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 batches that have been allocated to the process. It knows the amount of consumable stock 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 the metering resources, the method 1300 may proceed to block 1328, where the flow orchestration core application 220 may configure the electronic instruments 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 measurements based on the execution order determined at block 1320.

At block 1332, the analysis system 100 can perform an assay on the biological sample using the electronics configured based on the execution order. The flow orchestration core application 220 may track the operational state of the electronics 264, 268 while performing the measurements. Modular assay instruments are complex machines. Electrical, mechanical and pneumatic systems may fail. To achieve the highest daily sample index, the process orchestration core application 220 may monitor device health and adapt the performance of the measurements to the operating hardware. For example, the flow orchestration core application 220 may monitor the operational state of the electronics 264, 268. The operating state of the electronics 264, 268 can 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 electronic instruments 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 notify laboratory personnel when and what inventory is to be replenished in the analysis system 100. 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 status of one of the electronic instruments 264, 268 is a failed status, the method 1300 proceeds to block 1340, where the orchestration core application 220 releases the measurement resources allocated to perform the not-yet completed measurement. After releasing the measurement resources, the method 1300 proceeds to block 1316 where the flow orchestration core application 220 may determine the updated available measurement resources and the updated operational state of the electronic instruments 264, 268 (including the unavailable operational state of one of the electronic instruments 264, 268), and determine an updated order of execution of the incomplete measurements based on the updated available measurement resources and the updated operational state of the electronic instruments 265, 268. In one embodiment, the flow orchestration core application 220 continuously determines the execution order of the updates and releases and allocates resources. The updated execution order may be based on the operational status of the electronics 264, 268, the 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 performance of the assay, the analysis system 100 can continue to perform the assay on the biological sample until all assays or assay steps are completed, with the method 1300 ending at block 1344.

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

At decision block 1436, the flow orchestration core application may determine that the sample no longer needs to be instrumented. The method 1400 may then proceed to block 1440 where the flow orchestration core application releases the measurement resources allocated to perform the incomplete measurements, as described with reference to block 1340 in fig. 13. For example, the procedural orchestration core application may receive results of assays of the biological samples determined using the determined order using one or more electronic instruments. The procedural orchestration core application may determine a second assay that 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 inferences from previous assays. This elimination may save cost or time since the second/pending assay no longer needs to be performed. The procedural orchestration core application may determine through a set of rules that the pending assay is no longer relevant to the clinical diagnosis. 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 a first assay should be performed before a 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 assay is positive, the flow orchestration core application may determine that the second assay does not need to be performed. The flow orchestration core application may determine an updated execution order (excluding the second measurement from being performed on the sample) to maximize at least one performance metric of the analysis system. The resources may be released based on the execution order of the updates.

If all assays are needed, the analysis system can 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 can perform the assays based on the assay order received from the laboratory information system and the execution order determined by the flow orchestration core application. Although the modules listed below are associated with 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 completed, the analysis system 100 may send the assay results to the laboratory information system 204 over the network 208. Due to network or other issues, the analysis system 100 may not be able to establish a connection with the laboratory information system 204 through 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 the connection is established. The analysis system 100 may attempt to periodically re-establish 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 can store the assay results in an unencrypted format or an encrypted format using a symmetric key scheme.

Inventory and operational integrity is monitored. The flow orchestration core application 220 may determine the order of execution of the assays or assay steps based on the received samples, the ordered assays, the availability of the resources 248, 252, and the operational status of the electronic instruments 264, 268. The flow orchestration core application 220, the flow orchestration sub-application 240 of the pre-analysis instrumentation 104, or the flow orchestration sub-application 244 of the analysis instructions 108 may track available measurement resources. The assay resources may include consumables 256, 268 and reagents 272, 276. 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 integrity of the electronics 264, 268 and adapt the execution of each measurement performed to the operating hardware. For example, the flow orchestration core application 220 may monitor the operational state of the electronics 264, 268. The operating state of the electronics 264, 268 can 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 process 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 electronic instruments 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 electronic instruments 264, 268. For example, when the flow orchestration core application 220 determines that a component of the electronic instruments 264, 268 has a fault status, the analysis system 100 may generate a report containing diagnostic data and code indicating that the particular component has failed and needs to be repaired or replaced. The flow orchestration core application 220 may re-determine the execution order based on the fault. 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 a single sample. The separate and connected instruments may include the pre-analytical instrument 104, the analytical instrument 108, and the 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 consumables 268 and reagents 276 of the analytical instrument 108 are not available, the flow orchestration core application 220 may determine an execution order to exclude the assays performed on the sample.

A status indicator. The analysis system 100 may include multiple visual indicators across multiple 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 is required to pay attention to the system 100. For example, a visual indicator associated with the analysis system 100 may flash a red light when the overall system fails. As another example, an indicator associated with the pre-analysis system 104 may flash a yellow light when a consumable 256, such as a pipette tip, needs to be replenished as soon as possible.

And (6) logging. The analysis system 100 may aggregate and store log files for multiple independent but connected instruments for later retrieval. For example, the analysis system 100 may aggregate and store log files of performed assays, operational status of the instruments 104, 108 and devices 264, 268, and levels of consumables 256, 268 and reagents 272, 276. For example, the log file may include results of the assays 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 through analysis of the log. For example, when a component of the pre-analytical instrument 104 has a fault condition, the analysis system 100 can retrieve a log file containing such fault condition from the pre-analytical instrument 104 and transmit the log file to the laboratory information system 204 for use in 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 instrument devices 264, 268 may include physical hardware components (e.g., motor encoders, integrated circuits, solenoid valves, etc.) whereby the flow orchestration core application 220 can track the operational state of the hardware in each instrument. In one embodiment, the instrument devices 264, 268 may include interactive position detectors and cameras, and the flow orchestration core application 220 may determine the correct operational coordination and parameters of the instrument devices 264, 268 or components thereof. For example, the pre-analysis 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 orchestration core application 220 may determine coordination and parameters of the pipette robot using the image of the position detector. As another example, the pipette robot may include multiple position detectors, and the pre-analysis instrument 104 may include three cameras that are orthogonal to each other. The flow orchestration core application 220 may determine coordination and parameters of the pipette robot in three dimensions using images captured by orthogonal cameras. The captured images may also be used to calibrate components of the instrument devices 264, 268. The position detector may be fixed to the assembly or may be movable on the assembly. Fewer movable position detectors may be required to determine the operational coordination and parameters of the components. The position detector may use different colors to indicate its status, e.g. in use or malfunctioning.

An uninterruptible power supply. The analytical system 100, pre-analytical instrument 104, analytical instrument 108 or 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 Hard Disk Drive (HDD). The data stored into the persistent storage device in the event of a power failure may include the results of the assay being performed or intermediate results. The data may include the status and parameters of the analysis system 100 and its components.

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

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

Coordinating 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 the execution order based on the operational state 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 the execution order 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 order of execution 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 set is present. For example, the flow orchestration core application 200 may automatically build and release a worklist of samples for performing processing corresponding to nominal operation of the device when a sample group appears, and according to user-defined rules based on day of the week, number of days of the month, 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 the specific test that has been ordered for each sample) based on day of the week, number of days of the month, time of day, or any combination thereof.

The sample is removed. The orchestration core application 220 may monitor the processing and analysis of the sample and alert laboratory personnel when the original sample container that the laboratory personnel is removing or has removed should be taken for further review and evaluation. For example, the flow orchestration core application may alert the user when an original sample container that has been removed from the system should be taken for further review 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. The flow orchestration core application 220 may re-determine the execution order when the sample returns to the analysis system 100.

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 designation information. The hospital 1504a may also have a field hospital laboratory 1512a with a laboratory information system 204a and an analysis system 100 a. The laboratory information system 204a may receive the determination instructions 212 and the patient information from the hospital information system 1508 a. The laboratory information system 204a may store requirements for assays that the 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 flow orchestration core application 220 is shown as controlling two analysis systems, the flow orchestration core application 220 can control a multitude of analysis systems with different functionality located in different geographical locations. The analysis systems 100a, 100B may be the analysis systems of fig. 2A and/or fig. 2B.

Laboratory 1512b, such as a standalone laboratory, may include laboratory information system 204b and analysis system 100 b. The laboratory information system 204b may store requirements for the assays that the 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 a general cancer detection package and specialized cancer guidelines.

To determine the order of execution of the analysis system 100a or the analysis system 100b, the procedure orchestration core application 220 may receive measurement 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 analytics system 100a, 100 b. For example, resources of the analytics system 100a may become temporarily available, and the analytics system 100a may provide this information to the flow orchestration core application 220.

Given the received metering instructions or the scanned samples, the flow orchestration core application 220 may determine an execution order of the analysis systems 100a, 100b to maximize the performance index. For example, 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 the analysis system 100a, the flow orchestration core application 220 may determine that the analysis system 100b should perform certain assays for certain samples.

As another example, the metering instructions may indicate: a specialized cancer detection package should be performed after a general cancer detection package determines that a patient is at risk for cancer. The initial execution order of the analysis systems 100a, 100b as determined by the procedural orchestration 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 procedural 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 hospital 1504a to laboratory 1512 b. The flow orchestration core application 220 may determine the new execution order using the methods 1000 and 1200 described with reference to fig. 10 and 12, respectively. For example, the analysis system 100b may perform assays on other samples when the results of a general cancer detection package become available. A new execution order for 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. The analysis system 100b may become unavailable if the connection of the flow orchestration core application 220 to the analysis system 100b is lost or an urgent analysis instruction is executed. Based on the unavailability of the analytics system 100b, the flow orchestration core application 220 may determine a new execution order for the analytics system 100 a. In one embodiment, the flow orchestration core application 220 determines the execution order of some analysis systems in order to maximize performance metrics with respect to those analysis systems, thereby increasing the overall efficiency of processing the assay samples. For example, hospital 1504a may have a contractual relationship with laboratory 1512b such that the order of execution of analysis systems 100a, 100b is determined in a manner that maximizes performance metrics with respect to both analysis systems 100a, 100 b.

Fig. 16 is a schematic diagram of a process orchestration core application stored in a cloud-based server that communicates with a process 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 designation information. The hospital 150a may have an on-site hospital laboratory 1512 with a laboratory information system 204 and a plurality of analysis systems 100a, 100 b. The laboratory information system 204 may receive the measurement instructions and patient information from the hospital information system 1508. The laboratory information system 204 may store requirements for assays that the analysis system 100a, 100b is capable of performing.

The process orchestration core application 220 on the cloud system 1600 may communicate with the process 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 flow orchestration core application 220 is available, the flow orchestration laboratory application 1604 may send the received metering instructions or the scanned samples to the flow orchestration core application 220. Based on information received from the flow orchestration laboratory application 1604 and similar information received from other flow orchestration laboratory applications, the flow orchestration core application 220 may determine an execution order for the analysis systems 100a, 100b controlled by the flow orchestration laboratory application 1604 and the analysis systems controlled by the other flow orchestration laboratory systems. Thus, the execution order determined by the flow orchestration core application 220 may maximize the performance metric given the received metering instructions or the scanned samples. When the flowcharting core application 220 is not available, the flowcharting laboratory application 1604 can determine an execution order for the analysis systems 100a, 100b to maximize performance metrics given 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 execution order 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 another laboratory. Each laboratory has an analysis system capable of performing a general cancer detection package. However, performing a general cancer detection package using an analytical system in laboratory 1512 can be more expensive. To reduce the cost of executing a cancer detection package, the flow orchestration core application 220 may determine to execute a general cancer detection package using an analysis system of another laboratory. The flow orchestration lab application 1604 may lose connection with the flow orchestration core application 220 before sending the sample (or a portion of the sample) for the cancer detection package to other labs. Because the flow orchestration laboratory application 1604 cannot determine whether a typical cancer detection package can be completed even if the sample (or a portion of the sample) is sent to other laboratories, the flow orchestration laboratory application 1604 may determine a new execution order for the analysis systems 100a, 100 b.

In one embodiment, cloud system 1600 may receive data or test results generated by analysis systems 100a, 100b from flow orchestration laboratory application 1604 via its flow orchestration core application 220. Although the flow orchestration core application 220 is shown as controlling two analysis systems 100a, 100b, the flow orchestration core application 220 can control a multitude of analysis systems with different functionality located in different geographical 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 the laboratory platform 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 a legacy systems laboratory interface 1616 of the laboratory information system 204 via its legacy systems interface 1612. The legacy system laboratory interface 1616 may receive data generated by the legacy system 1608 from the laboratory-based middleware system. In one embodiment, cloud system 1600 may receive data or test results generated by a point-of-care detection (POC) device via a POC interface.

By controlling the analysis systems 100a, 100b and receiving the 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 remote microbiological operations of the laboratory on an enterprise-wide basis. The aggregation of data across all hospitals, laboratories and patients enables value-added services and provides insight about hospital, laboratory and patient use. Examples of value added services include peer-to-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 redirect users to related technology specific application stores. These application stores enable distribution of applications 1636 that may be developed by third party developers (consistent with the architecture of cloud system 1600). Applications 1636 that may be developed by third party developers may be more flexible in addressing custom data management requirements.

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

The architecture of the cloud system 1600 is extensible to meet changing market demands. In one embodiment, the architecture supports both public and local (private) clouds, eliminating data-ownership objections for users who wish to place all data behind their firewalls. The cloud system 1600 is secure, thus solving issues regarding data, HIPAA privacy, and regulatory compliance. Cloud system 1600 is also extensible 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 used interchangeably in another embodiment unless such an alternative is not technically feasible. Those skilled in the art will recognize 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 variations are intended to fall within the scope of the subject matter as 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. Various singular/plural permutations may be expressly set forth herein for the sake of clarity. 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, and 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 "includes" should be interpreted as "includes but is not limited to," etc.). It will be further understood by those within the art 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, where those conventions similar to "at least one of A, B and C, etc." are used, in general such configurations are intended that one skilled in the art would understand the conventions (e.g., "a system having at least one of A, B and C" would include, but not be limited to, systems having a only, B only, C only, a and B, a and C, B and C, and/or A, B and C, etc.). In those instances where a convention analogous to "A, B or at least one of C, etc." is used, in general such a construction is intended that one skilled in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include, but not be limited to, systems having a only, B only, C only, a and B, a and C, B and C, and/or A, B and C, etc.). It will be further understood by those within the art 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 possibility 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 thereby also described in terms of any single 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 subranges and combinations of subranges thereof. Any listed range can be readily identified as being 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 range discussed herein may be easily subdivided into a lower third, a middle third, and an upper third. Those skilled in the art will also appreciate that all language (e.g., "at most," "at least," "greater than," "less than," etc.) includes the number recited and refers to ranges that can be subsequently subdivided into the aforementioned subranges. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1 to 3 items refers to a group having 1, 2, or 3 items. Similarly, a group having 1 to 5 items refers to groups having 1, 2, 3, 4, or 5 items, and so on.

While 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.