Workflow Planning Manager

Abstract

A workflow planning manager is provided for coordinating the distribution of biological samples in an analytical system. The analytical system includes one or more diagnostic analyzers and delivery devices. The manager is configured to: receive multiple requests for analytical tests to be processed by the system; determine proposed runs; transmit the proposed runs to candidate diagnostic analyzers; receive predicted run completion information from the candidate diagnostic analyzers; and determine whether to continue or reject the proposed runs based on the predicted run completion information. When the proposed run is to be continued, the manager is configured to signal the delivery device to deliver some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer, and when the proposed run is rejected, the manager is configured to determine an alternative proposed run or transmit the proposed run to an alternative candidate diagnostic analyzer.

Description

Technical Field

[0001] This invention relates to a workflow planning manager for coordinating the distribution of biological samples in an analytical system; and a computer-implemented method for coordinating an analytical system. Background Technology

[0002] Laboratory environments, such as molecular laboratories, may contain automated laboratory equipment, such as IVD (in vitro diagnostic) instruments, used to perform various processes and tests on biological samples. Typically, a laboratory planning manager is configured to receive one or more test orders describing which processes to perform on each biological sample and to direct laboratory equipment to execute those test orders.

[0003] Processing each test order may require a variety of resources, including instrumental resources (e.g., transfer systems for sample holders and reaction vessels, robotic arms with pipettes for transferring and quantifying sample and / or reagent liquids, fluid mixers, incubators, photodetectors, etc.) and consumable resources (e.g., reagents, disposable fluid carriers such as tubes, reaction vessels, multiwell plates or other fluid carriers for sample fluids and reagents, disposable pipette tips, etc.). The sequence of processing test orders using these resources can be complex and typically includes pre-analytical, analytical, and post-analytical steps. Furthermore, the multiple processes involved in processing a test order may run fully or partially in parallel and share some of the same resources, thus introducing added complexity.

[0004] Furthermore, biological samples and corresponding test orders for each sample may arrive at the laboratory during working hours in a continuous flow, each of which must be scheduled and processed. Each test order and biological sample may have different characteristics, including: the different type of test to be performed (e.g., HBV, HIV, etc.), and the target turnaround time (TAT) for processing each test. Additionally, each test order can be categorized as an urgent test order or a routine test order. Multiple samples can be processed in parallel by laboratory equipment to increase throughput. However, incompatibilities exist between tests, meaning that two incompatible tests cannot be processed simultaneously, for example, in the same run.

[0005] A series of test orders performed by instruments (e.g., diagnostic analyzers such as IVD instruments) can be referred to as a run. Runs need to be planned so that samples are loaded into each diagnostic analyzer in a sequence and combination that adapts to and optimizes factors such as test order priority, material usage, target TAT, cost, sample delivery time, and waste generation. Therefore, developing and operating efficient workflows for automated laboratory equipment is challenging.

[0006] Existing solutions for coordinating laboratories typically employ simple algorithms for ordering samples and processes that are inflexible or unadaptable (e.g., for new test orders or sample delivery errors). Furthermore, existing solutions are ineffective for defining laboratory-wide workflows, forcing users to pre-sort biological samples before loading them into laboratory equipment.

[0007] Furthermore, such existing solutions typically implement top-down, long-term planning schemes, thereby determining sample workflows based on prior knowledge of incoming test orders. In these instances, laboratory equipment provides a predefined list of tests to be processed. This list is often the result of tactical decisions made in advance (e.g., daily or weekly). However, such solutions require up-to-date knowledge of central control and available resources in each instrument within the laboratory. Moreover, these solutions are ineffective in responding to changes in the system, such as incoming test orders, incorrect sample identifiers, bottlenecks in the sample transport system, changing status of laboratory equipment, and fluctuating resource levels. Additionally, such solutions struggle to predict which samples will arrive at the laboratory and when, making accurate planning throughout the day difficult. Furthermore, the possibility of scheduling incomplete test orders (e.g., if urgent samples are received) reduces overall system utilization and efficiency.

[0008] Therefore, a more efficient and adaptable method is needed to manage the allocation of samples and test orders in analytical systems. This invention was conceived in view of the above considerations. Summary of the Invention

[0009] In summary, the present invention relates to a system for coordinating diagnostic analyzers, wherein a planning manager proposes a test run to be performed by one of the diagnostic analyzers. The proposed run is transmitted to one of the diagnostic analyzers to assess how many of the proposed runs the analyzer can complete based on its current resource level and capabilities. The planning manager can then adjust the proposed run based on this information until an acceptable level of completion is achieved. Furthermore, when changes such as new samples arriving at the system, changes in test orders, or changes in resource status are detected, the planning manager can renegotiate the proposed run to accommodate the detected changes.

[0010] Therefore, in a first aspect, embodiments of the present invention provide: a workflow planning manager for coordinating the allocation of biological samples in an analytical system. The analytical system includes: one or more diagnostic analyzers for performing one or more tests on the biological samples; and a delivery device for delivering the biological samples to the one or more diagnostic analyzers. The workflow planning manager is configured to: receive multiple requests for analytical tests to be processed by the system, each analytical test corresponding to a biological sample; determine a proposed run including at least some of the requested analytical tests; transmit the proposed run to a candidate diagnostic analyzer among the one or more diagnostic analyzers; receive predicted run completion information from the candidate diagnostic analyzer, the predicted run completion information including an indication of which analytical tests among the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer; and determine, based on the predicted run completion information, whether to continue or reject the proposed run. When it is to continue the proposed run, the workflow planning manager is configured to signal the delivery device to deliver the biological samples (e.g., some or all) specified in the proposed run to the candidate diagnostic analyzer. When a proposed run is rejected, the workflow planning manager can be configured to determine alternative proposed runs or transfer proposed runs to alternative candidate diagnostic analyzers.

[0011] Advantageously, the workflow planning manager can respond to changing resources and incoming test orders in the system by planning sample allocation on a run-by-run basis. Furthermore, by transmitting proposed runs to the analyzer for evaluation, the workflow planning manager can utilize up-to-date information about the analyzer's capabilities without needing to control the analyzer itself. In this way, the workflow planning manager can ensure that optimal laboratory workflows can be identified and updated based on evolving information to minimize resource usage and maximize laboratory throughput, while ensuring compliance with target TATs and emergency situations.

[0012] Furthermore, by negotiating with candidate diagnostic analyzers in this manner, rather than requesting information about the current resources and capabilities of candidate analyzers, Demeter's Law [1] is followed, thereby decoupling processing between system components and limiting the amount of coupling between components. As a result, the analytical system is more responsive and adaptable to changes in the system, such as the removal or addition of diagnostic analyzers or the updating of existing analyzers, compared to existing analytical systems.

[0013] Workflow planning managers (e.g., coordinators, planning modules, etc.) can be the central processing component of the system, such as a server or processor, which is communicatively coupled to each of the diagnostic analyzers and delivery devices.

[0014] The analytical system can be an automated laboratory, such as a molecular laboratory. An automated laboratory may include multiple diagnostic analyzers (e.g., instruments, analyzers, IVD instruments, analytical devices, etc.) configured to perform pre-analytical, analytical, and / or post-analytical steps for each component of a biological sample.

[0015] Requests for analytical testing can be test orders, each associated with one or more biological samples. For example, each test order may specify: one or more processing steps to be performed on the associated biological sample, the target turnaround time (TAT) to which the test order should be processed, and / or an indication of whether the test order is urgent or an urgent status of a regular test order. Urgent test orders can be considered high-priority test orders that should be processed immediately.

[0016] Requests for analytical tests (e.g., test orders) can be received from third-party systems such as medical centers, research centers, hospitals, and doctors' clinics, and / or from users who input test orders into the interface device. Each analytical test can indicate an identifier (ID) corresponding to one of the biological samples. Each biological sample can be identified by an ID reader (such as a barcode reader or QR code reader) (when it arrives at the analytical system and / or when it is within the analytical system), which is configured to read the ID attached to the sample container containing the biological sample.

[0017] A run can refer to a list or schedule of analytical tests to be processed by a diagnostic analyzer. One or more of the tests specified in each run can be performed by the diagnostic analyzer in parallel or partially in parallel. The biological samples specified by the requested tests in a run can be transferred to the candidate analyzer within one or more sample racks. Each run can correspond to (e.g., include) one or more biological sample racks within the analytical system. For example, each run may include 20 to 200, more preferably 50 to 150, more preferably 96 tests (and / or biological samples). Each sample rack may include a corresponding number of slots for housing the biological samples in sample containers.

[0018] The transfer of some or all biological samples in a proposed run may include transferring all biological samples corresponding to the analytical tests specified in the proposed run (regardless of whether these tests are indicated in the predicted run completion information). In this way, the sample racks used for transferring biological samples do not need to be rearranged or reordered prior to transfer. In other instances, the transfer of some or all biological samples in a proposed run may include (only) transferring biological samples corresponding to the analytical tests specified in the proposed run and also identified in the predicted run completion information. Therefore, only biological samples intended to be performed by the diagnostic analyzer can be transferred to the diagnostic analyzer.

[0019] The workflow planning manager can be configured to receive predicted run completion information from candidate diagnostic analyzers via the analyzer interface module. The analyzer interface module, discussed in detail below, can be configured to provide an interface for communication between the workflow planning module and one or more of the diagnostic analyzers.

[0020] Determining the execution of a proposal may include: selecting multiple tests from the requested tests based on a workflow optimization scheme, and populating the execution of the proposal with the selected tests. The workflow optimization scheme may include one or more optimization goals or factors that the workflow planning manager is configured to optimize during the execution of the proposal.

[0021] For example, selecting multiple tests based on a workflow optimization scheme may include choosing analytical tests from the requested tests based on one or more of the optimization factors. For example, analytical tests may be selected based on any one or more of the following: the number of tests of each type in the requested tests, the target turnaround time for each requested test, compatibility between the requested tests (e.g., processing for the same diagnostic analyzer), total TAT (for processing all selected analytical tests), TAT (for each analytical test) for a single sample, QC (quality control) material usage required to perform each test, reagent usage (or other resources), diagnostic analyzer load balancing, minimization of cost and / or resource usage, and / or run fill. Such factors can be considered to select the requested tests for a proposed run that: can be processed in the same diagnostic analyzer, have compatible target turnaround times, and / or are of the same type. By constructing the run based on one or more of these factors, the time spent performing the run can be reduced while minimizing the overall resource usage of the analytical system.

[0022] In some instances, selecting multiple tests based on workflow optimization schemes may include: requested tests that identify the associated target time interval (TAT) that has elapsed. Additionally, requested tests with the longest elapsed target TAT can then be prioritized to populate the proposed run (e.g., tests for such requests can be selected first for the proposed run, before other requested tests with later target TATs).

[0023] Furthermore, in some instances, selecting multiple tests based on workflow optimization schemes may include minimizing the number of passenger samples in a proposed run. A passenger sample can be understood as a biological sample included in a sample rack that has been sent to one of the analyzers for a run, but which corresponds to a requested test incompatible with that analyzer and / or other requested tests in that run. Therefore, a passenger sample can be a sample sent to an analyzer but not actually processed within that analyzer. By minimizing the presence of passenger samples in a run, more tests can be performed per run, thereby improving system efficiency and reducing the time and cost of each test being processed in the system.

[0024] In some instances, selecting multiple tests based on a workflow optimization scheme may include: selecting requested tests designated as urgent, and / or selecting tests with the fastest target turnaround time for the requested tests. The optimization scheme may require first selecting requested tests designated as urgent, and then selecting the requested test with the fastest target turnaround time.

[0025] In some instances, the selection of multiple tests for a proposed run (based on the workflow optimization scheme) may include, for example, using a mixed-integer programming (MIP) to optimize the proposed run against workflow performance metrics such as passenger sample size, overdue time, load balancing, resource usage, or any other suitable workflow performance metric, based on one or more cost functions and / or optimization objectives or factors (e.g., predicted turnaround time, target turnaround time, or emergency status associated with each of the requested tests).

[0026] The selection of multiple tests for the proposed run can include any combination of the considerations mentioned above. For example, the selection could consider testing urgency and / or target turnaround time, or testing compatibility and / or passenger samples, etc.

[0027] The workflow planning manager can be configured to populate proposed runs with a target population number of requested tests. For example, the target population number could be the number of tests required to populate a run (or sample rack). For instance, the target population number could be between 20 and 200 tests per run, or more preferably 90 tests per run. The target population number could be the maximum capacity of the run (e.g., 96 test orders / samples), or it could be less than the maximum capacity of the run (e.g., between 80% and 95% of the maximum capacity, such as 90 test orders or samples). Populating in this way before sending them to the analyzer can advantageously reduce costs, resource usage, and time-to-action (TAT), while maximizing the efficiency of the overall analysis system.

[0028] Determining the run of a proposal may include: selecting initial multiple tests (e.g., optimizing a workflow), and then populating the run of the proposal by assigning additional tests to meet a target population number. Additional tests can be selected based on a population scheme configured to maximize the utility of each run of the proposal. Advantageously, by populating each run (e.g., with less urgent tests), the system can operate more efficiently and process more test orders in a shorter amount of time.

[0029] The process of filling a proposal may include assigning the requested tests to the proposed runs in order of the target turnaround time associated with each of the requested tests (e.g., from fastest to newest, shortest to longest, etc.).

[0030] The system may further include a buffer (e.g., a storage area or rack) for storing biological samples before they are transferred to one or more diagnostic analyzers. Filling a proposed run can then include assigning the requested test to the proposed run based on the time the biological samples arrive in the buffer (e.g., earliest to latest, latest to most recent, earliest to latest, etc.). In this way, biological samples that arrive in the buffer first can be assigned to runs preceding those that arrive later, thereby reducing the average individual TAT of samples in the system.

[0031] In a further example, filling a proposed run may include assigning the requested tests to the proposed run based on the time the workflow planning manager received the requested tests (e.g., from earliest to latest, from latest to most recent, from earliest received to latest received, etc.). In this way, even if the biological samples associated with those test orders physically arrive at the analysis system later than other biological samples, earlier test orders (e.g., received via the Internet) can be prioritized.

[0032] The workflow planning manager can be further configured to determine the maximum delay that can be applied while still meeting the target turnaround time associated with each of the requested tests in the proposed run. The workflow planning manager can then wait for the maximum delay before transmitting the proposed run to the candidate diagnostic analyzer. In this way, the likelihood of the proposed run being filled, and the likelihood of it being filled with compatible tests, is increased because the waiting delay provides an increased opportunity for more test orders to arrive in the system, thereby triggering the proposed run to be recalculated and potentially improved. Therefore, the overall efficiency and throughput of the laboratory can be improved.

[0033] The workflow planning manager can be configured to verify proposed runs before transferring them to the candidate diagnostic analyzer by determining whether the proposed run is full and / or whether the proposed run is urgent. A proposed run can be transferred to the candidate diagnostic analyzer when it is determined to be full or urgent, and can be discarded when it is determined to be neither full nor urgent. A proposed run is considered full when the number of requested tests included in it equals or exceeds the aforementioned target fill quantity or the run's maximum capacity.

[0034] The workflow planning manager can be further configured to detect system changes and, in response to the detection of system changes, determine proposed runs. System changes can be detected in response to the detection of any one or more of the following: a new biological sample arrives at the system, a requested test is added or removed from multiple requested tests, or the operational status of one of the diagnostic analyzers is updated.

[0035] The workflow planning manager can be configured to repeatedly (and continuously) determine new proposed runs in response to detected system changes, up to the execution of each of the requested tests. Advantageously, by continuously redefining runs, the workflow planning manager can effectively adapt pending workflows and runs to changes in the system, without being bound by specific pre-calculated workflows. For example, instead of simply interrupting predefined and inflexible workflows to prioritize urgent samples, existing urgent samples in the system can be included in a new run with additional samples.

[0036] The workflow planning manager can be configured to transmit proposed runs to multiple candidate diagnostic analyzers and receive corresponding predicted run completion information from each candidate analyzer. Determining whether to proceed with or reject the proposed run may then include analyzing the predicted run completion information from each candidate diagnostic analyzer. Proceeding with the proposed run may then involve selecting one of the candidate diagnostic analyzers to execute the proposed run based on the predicted run completion information.

[0037] The workflow planning manager can be configured to select candidate diagnostic analyzers based on the operational status of each diagnostic analyzer in the system and / or based on an index (e.g., a menu) of analytical tests that each diagnostic analyzer can perform. In some instances, the workflow planning manager can be configured to select candidate diagnostic analyzers to balance the workload of the diagnostic analyzers. In other instances, the workflow planning manager can be configured to select candidate diagnostic analyzers by choosing the available analyzer that has been idle for the longest time.

[0038] Determining whether to proceed with or reject a proposed run can be based on the results of an optimization check process. For example, determining whether to proceed with or reject a proposed run may include comparing predicted run completion information with acceptance criteria (in order to optimize the proposed run according to the acceptance criteria). Acceptance criteria may include one or more of the following: the percentage of threshold tests in the proposed run that the candidate diagnostic analyzer can complete, the presence of any requested tests indicated as urgent in the proposed run, and whether the candidate diagnostic analyzer can complete those requested tests indicated as urgent, and / or the target time to start the proposed run. If the predicted run completion information does not meet one or more acceptance criteria, the workflow planning manager may reject the proposed run.

[0039] The predicted run completion information may include the estimated turnaround time for processing the proposed run at the candidate diagnostic analyzer. An optimization check process for determining whether to proceed with or reject the proposed run may then include determining whether the estimated turnaround time is compatible with the relevant target turnaround time for the tests requested in the proposed run. Therefore, the workflow planning manager may reject the proposed run when the estimated turnaround time is longer or later than one or more of the target turnaround times. Conversely, the workflow planning manager may proceed with the proposed run when the estimated turnaround time is shorter or earlier than one or more of the target turnaround times.

[0040] As the proposed run continues, the workflow planning manager can be further configured to send a confirmation message to the candidate diagnostic analyzer, indicating that the proposed run (and the predicted run completion information) has been accepted. As described above, the delivery device can then deliver some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer. This may include delivering biological samples corresponding to the requested tests to the candidate diagnostic analyzer, as indicated in the proposed run and also in the predicted run completion information.

[0041] When a proposed run is accepted (e.g., determined to proceed), the workflow planning manager can be configured to receive (or await receiving) transmission updates from the candidate diagnostic analyzer indicating which biological samples have arrived. The workflow planning manager can then signal to the diagnostic analyzer based on the transmission updates, indicating whether to execute the proposed run, discard the proposed run, modify the proposed run, or postpone the proposed run. For example, if all biological samples specified in the proposed run (and / or predicted run completion information) have arrived at the candidate diagnostic analyzer, the workflow planning manager can signal the candidate diagnostic analyzer to execute the proposed run. If one or more biological samples have not yet arrived at the candidate diagnostic analyzer, the workflow planning manager can signal the diagnostic analyzer to execute the proposed run with the samples it has already received, provided that tests indicated as urgent can be performed and / or at least a minimum number of the required samples have arrived at the diagnostic analyzer. The workflow planning manager can include test orders associated with biological samples that have not yet arrived at the candidate diagnostic analyzer when a new (subsequent) proposed run is determined, allowing for the rescheduling of unprocessed test orders.

[0042] The workflow planning manager can be further configured to detect shift end conditions (e.g., for the current shift, time period, date, etc.) indicating that no further requests for testing are imminent. In response to the detection of a shift end condition, the workflow planning manager can adjust and optimize the checking process to relax (e.g., reduce) the acceptance criteria used to determine whether to proceed or reject a proposed run and / or lower the target fill count for filling the proposed run. For example, when a shift end condition is detected, the workflow planning manager can be configured to proceed with the proposed runs, even if they are not full, to complete the execution of each of the requested tests within that shift.

[0043] In a second aspect, embodiments of the present invention provide an analytical system for analyzing biological samples. The analytical system includes: one or more diagnostic analyzers for performing analysis on the biological samples; a delivery device for transferring the biological samples to the one or more diagnostic analyzers; and a workflow planning manager for coordinating the allocation of biological samples to the diagnostic analyzers, the workflow planning manager being communicatively connected to each diagnostic analyzer and the delivery device. The workflow planning manager is configured to: receive multiple requests for analytical tests to be processed by the system, each analytical test corresponding to a biological sample; determine proposed runs including at least some of the requested analytical tests; transmit the proposed runs to candidate diagnostic analyzers of the one or more diagnostic analyzers; receive predicted run completion information from the candidate diagnostic analyzers, the predicted run completion information including an indication of which analytical tests among the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzers; and determine, based on the predicted run completion information, whether to continue or reject the proposed run, wherein: when to continue the proposed run, the workflow planning manager is configured to signal the delivery device to transfer some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzers. When a proposed run is rejected, the workflow planning manager can be configured to either identify alternative proposed runs or transfer the proposed run to an alternative diagnostic analyzer.

[0044] The workflow planning manager of the analysis system can include any combination of the features mentioned above regarding the first aspect.

[0045] In a third aspect, a computer-implemented method is provided for coordinating an analytical system for analyzing biological samples, the system comprising: one or more diagnostic analyzers for performing the analysis, each diagnostic analyzer including an analyzer programming module for operating the diagnostic analyzer; a delivery device for transferring biological samples to the one or more diagnostic analyzers; and a workflow planning manager for performing the computer-implemented method. The method includes: receiving multiple requests for analytical tests to be processed by the system, each analytical test corresponding to a biological sample; determining a proposed run including at least some of the requested analytical tests; transmitting the proposed run to a candidate diagnostic analyzer of one or more diagnostic analyzers; receiving predicted run completion information from an analyzer programming module of the candidate diagnostic analyzer, the predicted run completion information including an indication of which analytical tests in the proposed run can be processed by the candidate diagnostic analyzer; determining, based on the predicted run completion information, whether to continue or reject the proposed run; when the proposed run is to continue, signaling a delivery device to transmit some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer; and when the proposed run is rejected, determining alternative proposed runs or transmitting the proposed run to an alternative diagnostic analyzer device.

[0046] As described above, the planning module can communicate with the diagnostic analyzer via the analyzer interface module, which is configured to manage communication between the planning module and one or more of the diagnostic analyzers. The analyzer interface module can be considered middleware of the analysis system, acting as a bridge between the planning functions of the workflow planning manager and the individual diagnostic analyzers.

[0047] Therefore, in a fourth aspect of the invention, an analyzer interface module is provided for interfacing between a diagnostic analyzer and a workflow planning manager of an analytical system for analyzing biological samples. The analyzer interface module is configured to: receive a proposed run from the workflow planning manager, the proposed run including a plurality of requested analytical tests to be performed by the diagnostic analyzer on one or more biological samples; determine, according to an analyzer resource optimization process, candidate run schedules for performing the requested analytical tests in the proposed run; generate predicted run completion information based on the candidate run schedules, the predicted run completion information including indications of which analytical tests among the requested analytical tests in the proposed run can be processed by the analyzer in the candidate run schedules; and transmit the predicted completion information to the workflow planning manager.

[0048] Advantageously, by negotiating proposed runs with the workflow planning manager in this manner, the workflow planning manager can gain an up-to-date understanding of how many proposed runs can be completed, based on the analyzer's current resource levels and status, while still operating the analysis system's processing components in a modular manner. For example, by running the analyzer resource optimization process locally, predicted run completion information can be determined on the analyzer (or in the analyzer interface module) based on the latest optimization software running on the analyzer, without having to recreate the optimization software on the workflow planning manager. Therefore, the analyzer interface module makes it easier to update and replace diagnostic analyzers in the analysis system than in traditional analysis systems, while ensuring the effective operation and throughput of the analysis system.

[0049] The diagnostic analyzer may be one of the diagnostic analyzers mentioned above with respect to the first aspect (e.g., candidate diagnostic analyzers). The interface module may include or be formed of middleware for managing communication between the workflow planning module and one or more diagnostic analyzers in the analysis system.

[0050] An analyzer interface module can connect to one or more diagnostic analyzers. For example, the analyzer interface module can be a component separate from the diagnostic analyzer, running as software on a central server and connecting to one or more diagnostic analyzers. Alternatively, each analyzer interface module can form part of a diagnostic analyzer, for example, as a software application running on the diagnostic analyzer. In these instances, the analyzer interface module can be understood as representing the outward-facing portion of the diagnostic analyzer's control software, configured to receive and process communications from the workflow planning manager.

[0051] The predicted run completion information may further include the predicted total turnaround time (TAT) and / or the available start time for the candidate run schedule. The available start time can be an absolute time or a relative time period indicating when the diagnostic analyzer can next execute the proposed run. The predicted run completion can be considered a counter-proposal (e.g., a counter-proposal, a modified proposed run, etc.) indicating which and when each requested test in the proposed run can be executed by the diagnostic analyzer. The workflow planning manager can then accept or reject the counter-proposal. Therefore, a proposed run modified by the predicted run completion information can be considered an agreed run to be executed by the diagnostic analyzer.

[0052] Determining candidate run schedules based on the analyzer resource optimization process may include: identifying a set of analyzer resources that can be used (e.g., needed, required, desired) to perform the requested analytical tests in the proposed run. This set of analyzer resources can then be compared to an inventory of available analyzer resources to determine which of the requested analytical tests in the proposed run the analyzer can perform. The analyzer resource optimization process can be a local workflow planning process executed locally by one or more of the diagnostic analyzers (or analyzer interface modules). Alternatively, the analyzer resource optimization process can be proprietary software configured specifically to determine workflows for the type of diagnostic analyzer it is installed on.

[0053] The inventory of available analyzer resources may include one or more of the following: analyzer hardware, loaded reagent kits, loaded control miniature sample racks, and / or time slots indicating when the analyzer hardware is available.

[0054] The proposed run may include the predicted or planned time of arrival of biological samples at the analyzer. Then, determining the candidate run schedule based on the analyzer resource optimization process may include comparing the set of analyzer resources with the predicted inventory of available analyzer resources at the predicted arrival time (e.g., analyzer resources installed and available in the diagnostic analyzer at the predicted arrival time of the biological samples).

[0055] In response to the transmission of predicted run completion information, the analyzer interface module can be further configured to receive confirmation messages from the workflow planning manager indicating that the proposed run and / or candidate run schedule has been accepted, and to provide the proposed run to the analyzer for execution based on the candidate run schedule.

[0056] The analyzer interface module can be configured to assign allocated time slots (e.g., reserved slots) of the diagnostic analyzer to candidate run schedules. An allocated time slot can be assigned after receiving an indication that a candidate run schedule has been accepted. The assignment of an allocated time slot can be prevented from scheduling further proposed runs within that time slot by reserving it. Therefore, the diagnostic analyzer can be prepared to receive biological samples and execute the proposed run within the allocated time slot assigned to that run.

[0057] After assigning a time slot to an acceptable proposed run, the analyzer interface module can be configured to determine the predicted resource availability of consumables and / or waste storage in the analyzer during that time slot. If the predicted resource availability is determined to be insufficient to execute the proposed run, the analyzer interface module can send a request for additional resources to the workflow planning manager. This request could be for providing additional consumables and / or for emptying or replacing waste storage. For example, if the predicted consumables or waste storage are exhausted before the time slot assigned to the proposed run, insufficient resource availability can be determined.

[0058] The analyzer interface module can be further configured to reserve analyzer resources, such as consumables and analyzer hardware, which are required (e.g., needed, desired) for executing the accepted proposal (in the assigned time slot).

[0059] The analyzer interface module can be configured to receive one or more additional proposed runs and determine additional candidate run schedules for each of the additional proposed runs. Determining additional candidate run schedules may include taking into account reserved analyzer resources and / or reserved allocation slots to avoid allocating reserved resources and / or reserved allocation slots to the additional proposed runs.

[0060] The analyzer interface module can be configured to receive alarms from the diagnostic analyzer indicating when some or all of the biological samples in an acceptable candidate run schedule have been received at the analyzer. The analyzer interface can then transmit instructions to the workflow planning manager indicating which biological samples have been received at the diagnostic analyzer.

[0061] The analyzer interface module can be configured to trigger the diagnostic analyzer to execute the accepted candidate run schedule based on the received biological sample in response to receiving a workflow order from the workflow planning manager.

[0062] The analyzer interface module can be configured to cancel the execution of a reserved allocation slot and the proposed run in response to receiving a cancellation order from the workflow planning manager, and / or in response to the determination at the time when the expected biological samples required to execute the proposed run have not yet arrived at the diagnostic analyzer (and a workflow order has not yet been received from the workflow planning manager). Canceling the proposed run and / or the reserved allocation slot may also include canceling any subsequent reserved allocation slots. In this way, runs scheduled for subsequent reserved allocation slots can be recalculated based on up-to-date information including available resources and remaining unprocessed test orders, which may have already been determined under the premise that the (first) reserved slot will be fulfilled.

[0063] Therefore, compared to solutions that require pre-planned, unchanging operations, interface modules enable systems to better respond to changes and adopt more efficient workflows.

[0064] In a fifth aspect, a computer-implemented method is provided for an analyzer interface module for interfacing with a diagnostic analyzer and a workflow planning manager of an analytical system for analyzing biological samples. The method includes: receiving a proposed run from the workflow planning manager, the proposed run including multiple requested analytical tests to be performed by the diagnostic analyzer on one or more biological samples; determining candidate run schedules for performing the requested analytical tests in the proposed run according to an analyzer resource optimization process; generating predicted run completion information based on the candidate run schedules, the predicted run completion information including indications of which analytical tests among the requested analytical tests in the proposed run can be processed by the analyzer in the candidate run schedules; and transmitting the predicted completion information to the workflow planning manager.

[0065] The computer-implemented method can be executed by the analyzer interface module discussed in any of the foregoing aspects.

[0066] In a further example, the computer-implemented method can be executed by an analysis system including a workflow planning manager and at least one analyzer interface module. Therefore, the computer-implemented method can be a distributed computer-implemented method executed by the workflow planning manager and / or at least one analyzer interface module. Thus, the distributed computer-implemented method can include any of the features discussed above with respect to the third aspect, including steps executed by the workflow planning manager.

[0067] In the sixth aspect, a system is provided for implementing the computer implementation methods of the third and / or fifth aspects.

[0068] In a seventh aspect of the invention, an analytical system for analyzing biological samples is provided, the system comprising: a diagnostic analyzer for performing analysis on the biological samples; a delivery device for transferring the biological samples to the analyzer; a workflow planning manager for coordinating the allocation of biological samples in the system, the workflow planning manager being communicatively connected to an analyzer interface module and the delivery device; and an analyzer interface module for interfacing between the diagnostic analyzer and the workflow planning manager, wherein the analyzer interface module is configured to: receive a proposed run from the workflow planning manager, the proposed run including a plurality of requested analytical tests to be performed by the diagnostic analyzer on one or more biological samples; determine, according to an analyzer resource optimization process, a candidate run schedule for performing the requested analytical tests in the proposed run; generate predicted run completion information based on the candidate run schedule, the predicted run completion information including an indication of which analytical tests among the requested analytical tests in the proposed run can be processed by the analyzer in the candidate run schedule; and transmit the predicted completion information to the workflow planning manager.

[0069] The system may include any of the features mentioned in the fourth aspect above.

[0070] In an eighth aspect of the invention, an analytical system for analyzing biological samples is provided. The analytical system includes: one or more diagnostic analyzers for performing analysis on the biological samples; a delivery device for transferring the biological samples to the one or more diagnostic analyzers; and a workflow planning manager for coordinating the allocation of the biological samples to the diagnostic analyzers, the workflow planning manager being communicatively connected to each diagnostic analyzer and to the delivery device via an analyzer interface module. The workflow planning manager is configured to: receive a plurality of requests for analytical tests to be processed by the system, each analytical test corresponding to a biological sample; determine a proposed run including at least some of the requested analytical tests; and transmit the proposed run to an analyzer interface module connected to a candidate diagnostic analyzer connected to the one or more diagnostic analyzers. The analyzer interface module is configured to: receive the proposed run from the workflow planning manager; determine a candidate run schedule for performing the requested analytical tests in the proposed run according to an analyzer resource optimization process; generate predicted run completion information based on the candidate run schedule, the predicted run completion information including an indication of which analytical tests among the requested analytical tests in the proposed run can be processed by the analyzer in the candidate run schedule; and transmit the predicted completion information to the workflow planning manager. The workflow planning manager is configured to receive predicted run completion information from the analyzer interface module and determine whether to continue or reject the proposed run based on the predicted completion information. Specifically, when the proposed run is to continue, the workflow planning manager is configured to signal the delivery device to transfer some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer. When the proposed run is rejected, the workflow planning manager can be configured to determine alternative proposed runs or transfer the proposed run to an alternative diagnostic analyzer device.

[0071] The system may include one or more (e.g., multiple) analyzer interface modules, each of which is connected to one or more (e.g., corresponding) diagnostic analyzers and is configured to operate as described above.

[0072] In another aspect, a computer-readable medium including instructions that, when executed by a computer, cause the computer to perform computer-implemented methods of the third and / or fifth aspects. Additional aspects of the invention may relate to a system configured to perform the aforementioned computer-implemented methods. Specifically, the system may include a processor configured to perform the corresponding computer-implemented method aspects of the invention.

[0073] An additional aspect of the invention may provide a computer program including instructions that, when executed by a computer, cause the computer to perform the steps of a computer-implemented method of the above-described aspects of the invention. Another aspect of the invention may provide a computer-readable storage medium having a computer program of the foregoing aspects of the invention stored thereon.

[0074] The present invention includes combinations of the described aspects and preferred features, unless such combinations are clearly not permitted or explicitly avoided. Attached Figure Description

[0075] Embodiments and experiments illustrating the principles of the invention will now be discussed with reference to the accompanying drawings, in which:

[0076] Figure 1 shows a flowchart of the process of handling biological samples in a molecular laboratory;

[0077] Figure 2 shows a flowchart of an updated method for dispensing and processing biological samples in a molecular laboratory;

[0078] Figure 3 shows a diagram of a system for processing biological samples according to an aspect of the present invention;

[0079] Figure 4 shows a flowchart of the process for distributing biological samples in a coordinated analytical system;

[0080] Figure 5 shows a flowchart of the process for determining a proposal for processing biological samples;

[0081] Figure 6 shows a flowchart of the process for negotiating and agreeing on proposals;

[0082] Figure 7 shows an outline of the process used to verify the proposal's execution;

[0083] Figure 8 illustrates the process for renegotiation proposals based on biological samples arriving at the diagnostic analyzer;

[0084] Figure 9 shows a flowchart of the process where the workflow planning manager and the diagnostic analyzer reach a proposal;

[0085] Figure 10 shows a flowchart of the process for establishing an interface connection between the diagnostic analyzer and the workflow planning manager;

[0086] Figure 11 shows a flowchart of the further processing steps for interface connection between the diagnostic analyzer and the workflow planning manager;

[0087] Figure 12 Figure 15 illustrates additional communication between the illustrated workflow planning manager, diagnostic analyzer, and conveyor; and

[0088] Figure 16 shows a state diagram illustrating the state transition of the analyzer's time slot allocation. Detailed Implementation

[0089] Aspects and embodiments of the invention will now be discussed with reference to the accompanying drawings. Other aspects and embodiments will be apparent to those skilled in the art. All documents mentioned herein are incorporated by reference.

[0090] Figure 1 shows a flowchart of processing biological samples in the molecular region of the laboratory.

[0091] First, at point 1, samples arrive at the laboratory in a continuous flow during the working hours. Each sample has distinct characteristics, including: the type of test to be performed on each biological sample, such as a hepatitis B blood test (HBV), a human immunodeficiency virus (HIV) test, etc.; and the target turnaround time (TAT). Furthermore, each biological sample and its corresponding test can be categorized as either an urgent or routine test.

[0092] In the laboratory, samples may undergo different operations in the pre-analysis area (see point 2 in Figure 1), and then be sorted in a 5-position sample rack (“RD5 sample rack”) in the buffer (AOB) to await processing by one or more diagnostic analyzers (e.g., labeled “cx800”).

[0093] Next, at point 6, the sample holder containing the samples to be processed is retrieved from the AOB and transferred to the diagnostic analyzer, where the requested samples corresponding to those samples are processed at point 7.

[0094] A diagnostic analyzer such as the CX800 shown in Figure 1 operates in a run, where each sample specified in the run is loaded into the analyzer before the entire run is performed. A run consists of, for example, up to 96 requested tests to be processed in the analyzer. Each type of analyzer in a laboratory may have different capabilities, capacities, and throughput, and therefore the time to process a run can vary. For example, a run may take 2 to 3 hours.

[0095] Traditionally, a predefined test menu can be provided for each diagnostic analyzer. This menu is the result of tactical decisions made, for example, daily or weekly. Incompatibilities exist between tests, and therefore it is impossible to process two incompatible tests simultaneously. The table below illustrates the possible test menus and configurations for a laboratory that includes three diagnostic analyzers (A1 to A3).

[0096]

[0097] For example, the analyzers in the table above can be used to perform the following operations:

[0098] A) If a run that includes HIV and HBV testing is sent to A2, the entire run can be processed;

[0099] B) If the same run containing both HIV and HBV text is sent to A1, only the HIV test will be processed, and the HBV sample will be created as a "passenger sample." In other words, the HBV test will need to be returned to AOB and must be included in a separate run.

[0100] C) If a run with both HBV and MPLX tests is sent to A2, only the HBV or MPLX test may be processed because their compatibility group also creates "passenger samples".

[0101] Therefore, it is important to set up runs efficiently to avoid unnecessary impacts on processing costs, turnaround time (TAT), resource usage, and laboratory compliance with regulatory standards (e.g., Service Level Agreement (SLA) compliance). However, the difficulty in predicting which test orders will arrive at the laboratory and when can affect accurate planning throughout the day. Furthermore, the creation and scheduling of underutilized runs can reduce overall system occupancy, thereby increasing the cost per test order, cost per test type, resource utilization, total cost, and average throughput time. In a further instance, passenger samples included in a run (i.e., samples sent to a diagnostic analyzer but not processed by it) necessitate the creation of additional runs and additional sample transfer operations to handle these passenger samples. Such passenger samples can overload the transfer system, making it difficult to set up full-load runs and jeopardizing the system's ability to meet test target TATs. Additionally, the receipt of urgent samples can impact the entire system as they force immediate processing, impairing effective operation, for example, by causing delays to previously planned runs. Therefore, the composition of a run, the capacity of the transfer system, and the amount of time the analyzer needs to process runs can each influence the overall performance of the system. Furthermore, determining laboratory workflows that effectively utilize available resources in the laboratory is challenging because only the diagnostic analyzer itself can access all information about its status (e.g., reagent status, expected time to complete the run, etc.).

[0102] Traditional methods for coordinating laboratories assess test compatibility (as shown in the table above) and then apply simple algorithms such as FIFO or Greedy to determine the workflow. However, the inventors have found that such methods are insufficient to ensure the effective operation of the laboratory.

[0103] Figure 2 illustrates a flowchart of an updated method for distributing and processing biological samples in a molecular laboratory. In addition to the steps in Figure 1, an optimizer is introduced in Figure 2, configured to perform intermediate processes including: considering samples in a buffer (e.g., unprocessed samples that have already arrived at the laboratory), communicating with a diagnostic analyzer, and agreeing on optimized possible combinations of samples to be sent to the analyzer as a run. The agreed run is then sent to the diagnostic analyzer, which subsequently requests the samples specified in the run from the buffer and processes the samples according to the requested tests in the agreed run.

[0104] In this way, more efficient use of analyzers in the laboratory can be achieved, while enabling the system to respond more effectively to changes in incoming samples and analyzer status, such as when resources are depleted. In particular, this method is advantageously able to adapt to and respond to specific, continuously changing, and unpredictable constraints of instruments in the laboratory (e.g., diagnostic analyzers or delivery systems). Such constraints may include, for example, delivery time, processing and delivery bottlenecks, barcode errors, analyzer processing capacity, availability of materials and consumables, etc. By using a reactive approach to determine the workflow as described herein, only currently available resources are scheduled for use, while ensuring that scheduling is as flexible as possible to respond to new (and potentially urgent) sample and test orders that may arrive at the laboratory.

[0105] The following figures provide further details on the workflow and methods for identifying and allocating biological samples in this manner.

[0106] Figure 3 shows a schematic diagram of analytical system 1 for analyzing biological samples. For example, system 1 can be a laboratory as shown in Figure 2.

[0107] System 1 includes one or more diagnostic analyzers 8n for performing analysis on biological samples, a transport device 6 (e.g., a transport system) for transferring biological samples to one or more diagnostic analyzers 8n, and a workflow planning manager 2 for coordinating the allocation of biological samples to the diagnostic analyzers 8n.

[0108] Workflow Planning Manager 2 is communicatively connected to each diagnostic analyzer 8n and delivery device 6. Workflow Planning Manager 2 (e.g., coordinator, planning component, planning module, central controller, etc.) is configured to supervise all devices in System 1 (e.g., pre- / post-analytical devices, diagnostic analyzer 8n, delivery device 6, etc.) and all sample tubes readily available in System 1. As discussed herein, Workflow Planning Manager 2 is configured to execute planning algorithms based on constraint programming and a predictive model that uses historical data collected from the laboratory to calculate the optimal allocation of samples to the diagnostic analyzer 8n at a given point in time, referred to as the workflow.

[0109] In this example, system 1 includes multiple diagnostic analyzers 8a-n, and workflow planning manager 2 is communicatively connected to each diagnostic analyzer 8n via one or more analyzer interface modules 10n, each analyzer interface module 10n being configured to provide an interface between the one or more diagnostic analyzers 8n and workflow planning manager 2. As shown in Figure 3, each analyzer interface module 10n may connect to one or more diagnostic analyzers 8n. Alternatively, each analyzer interface module 10n may be part of a diagnostic analyzer 8n, for example, as a software application running on the diagnostic analyzer 8n. In a further example, each analyzer interface module 10n may be a component separate from the diagnostic analyzer 8n, for example, as software running on a central server and connected to one or more of the diagnostic analyzers 8n.

[0110] In this document, the term "module" is used to refer to a functional module that is configured or adapted to perform a specific function. Modules can be implemented in hardware (i.e., they can be individual physical components within a computer), in software (i.e., they can represent individual segments of code that, when executed by a processor, cause the processor to perform a specific function), or in a combination of both.

[0111] Workflow planning manager 2 is configured to receive multiple requests (e.g., test orders) for analytical tests to be processed by system 1, each analytical test corresponding to a biological sample. Incoming biological samples are stored in sample racks in sample buffer 4 until they are conveyed by delivery device 6 to one of the diagnostic analyzers 8n.

[0112] Workflow Planning Manager 2 is configured to negotiate with one or more of the diagnostic analyzers 8n to agree on a workflow that includes one or more runs of the requested test, and then directs delivery device 6 to transfer biological samples to the diagnostic analyzer 8n for processing the agreed run. Each diagnostic analyzer 8n is configured to locally optimize the proposed run based on the loaded samples, consumables, reagents, and other resources present in the analyzer 8n to generate a locally optimized run schedule. The run can then be executed (or not executed) based on the locally optimized run schedule.

[0113] Importantly, the Workflow Planning Manager 2 is configured to continuously renegotiate and re-determine planned runs as additional samples and test orders arrive at System 1 or as the status of the diagnostic analyzer 8n changes. Therefore, System 1 is responsive and adaptable to changing circumstances, and can determine more efficient workflows for handling test orders than existing solutions, without needing to know in advance which test orders will be requested.

[0114] Figure 4 illustrates a flowchart of the process for coordinating the allocation of biological samples in System 1. This process can be executed by the workflow planning manager 2 shown in Figure 2. The steps can be divided into two phases: a planning phase, in which a proposed run is prepared based on the information available in System 1, and then an execution phase, in which the workflow planning manager 2 negotiates the proposed run with the analyzer 8n and manages any unforeseen events that may occur before the proposed run begins.

[0115] First, in step S100, the workflow planning manager 2 receives multiple requests for analytical tests. A request may be referred to as a test order, and each test order includes an identifier for the biological sample, specifications for one or more procedures to be performed on the biological sample, and optionally, the target TAT of the test order.

[0116] Next, in step S102, the workflow planning manager 2 determines a proposed run that includes at least some of the requested analysis tests. The proposed run is determined by selecting multiple tests from the requested tests according to a workflow optimization scheme. The workflow optimization scheme is the process of selecting tests for the proposed run to meet the target TAT and / or combine compatible tests together.

[0117] In addition to the requested tests, the Workflow Planning Manager 2 can access information including the number of tests received for each test type, the target TAT for each test, and compatibility information indicating which tests are compatible with each other and can be executed by the same diagnostic analyzer 8n in the same run. Furthermore, the Workflow Planning Manager 2 can access the current status of each analyzer 8n and the menu of tests that each analyzer 8n can execute. Therefore, the Workflow Planning Manager 2 can use this information to construct proposed runs and select one or more candidate diagnostic analyzers 8n to which the proposed runs are sent.

[0118] Each time a change is detected in System 1, such as: a new sample arriving at Sample Buffer 4, a change in the priority of the test sequence, a test sequence being added to or removed from a sample, or a status change of a diagnostic analyzer 8n (e.g., on / off, start of run, end of run, etc.), Workflow Planning Manager 2 is configured to retrieve the above information and determine whether a new proposed run can be constructed based on the updated information. This action can also be performed periodically, for example, after a predetermined number of minutes since the last proposed run was determined.

[0119] Next, in step S104, the proposed run is transmitted to one or more candidate diagnostic analyzers 8n (e.g., by transmitting the proposed run to the interface module 10n of the candidate diagnostic analyzer 8n).

[0120] Next, in step S106, the candidate diagnostic analyzer 8n receives predicted run completion information. The predicted run completion information includes an indication of which analytical tests among the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer 8n. For example, the predicted run completion information may take the form of a counter-proposal (e.g., a counter-proposal, an additional / alternative proposed run, or a modified proposed run).

[0121] Next, in step S108, the workflow planning manager 2 reviews the predicted run completion information and determines whether to continue or reject the proposed run based on the predicted run completion information and the results of the optimization check process. Therefore, continuing the proposed run may include accepting the proposed run and modifying it as necessary based on the predicted run completion information.

[0122] Determining whether to proceed with or reject a proposed run based on the optimization check process involves comparing the predicted run completion information with pre-defined acceptance criteria, such as: whether the run is sufficiently full (e.g., by determining whether the candidate diagnostic analyzer 8n can meet a threshold percentage of the proposed run); whether there are any samples and / or requested tests indicated as urgent in the proposed run, and whether the candidate diagnostic analyzer can meet these samples and / or requested tests; and / or whether the estimated time when the run can begin is fast enough to meet the target TAT of the tests requested in the proposed run. If each (or one or more) acceptance criteria are met, the workflow planning manager 2 is configured to proceed with the proposed run. However, if one or more or all of the acceptance criteria are not met, the workflow planning manager 2 is configured to reject the proposed run.

[0123] When the proposed run is to continue, the workflow planning manager 2 proceeds to step S110, whereby the workflow planning manager 2 signals the delivery device 6 to transfer some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer 8n. For example, the delivery device 6 may be instructed to transfer each of the biological samples specified in the proposed run to the candidate diagnostic analyzer 8n, or only the biological samples specified in the predicted run completion data may be transferred (e.g., the candidate diagnostic analyzer 8n indicates which biological samples it can process specified in the proposed run).

[0124] It is worth noting that the diagnostic analyzer 8n will not execute a proposed run until all samples specified in the agreed run or confirmation order have been received from the workflow planning manager 2. In this way, if an unexpected event occurs while sending samples to the candidate analyzer 8n (e.g., not all samples arrive on time due to a bottleneck or barcode reading error), the workflow planning manager 2 can update the workflow by determining whether to immediately execute a run on the samples that have indeed arrived, discard the run, or wait for the samples to arrive before executing the run.

[0125] When a proposed run is rejected, the workflow planning manager 2 proceeds to step S112, where it determines alternative proposed runs (including different options for the requested test) or transfers the proposed run to the alternative candidate diagnostic analyzer 8n. Determining alternative proposed runs can be considered as returning to the beginning and repeating the process of Figure 4.

[0126] Figure 5 shows a flowchart of the process for determining the proposed run based on the workflow optimization scheme. As mentioned above, this process can be referred to as the planning phase S200, which is executed before the execution phase S300. The workflow optimization scheme includes three algorithms for selecting the requested tests to populate the proposed run. These three algorithms are executed according to the following flow:

[0127] In step S302, the OaP (Coverage and Processing) selection algorithm is used to select test orders to fill one or more proposed runs. This algorithm is only executed when one or more types of tests need to be performed in the next immediate run triggered by a specific action from the user, for example, when the lab is at the end of a shift. Test selection is done using their TAT (Time To Actual Amount), and if two or more tests with the same TAT exist but one is indicated as urgent, the latter will be selected first.

[0128] When an OaP state is triggered (e.g., by a user), the OaP selection algorithm is used to populate one or more runs until a set of test orders indicated by the user is processed. The system remains in the OaP until all of that set of test orders are processed in a more immediate run based on user requests. Therefore, a session in which the OaP selection algorithm is used is not limited to a single run, but rather to multiple runs necessary for processing the user-selected test type for OaP processing.

[0129] If there are not enough samples to set up a full run, the fill algorithm in step S206 (described below) will be executed to attempt to fill the run. Alternatively, if the proposed run is full but there are still samples affected by OaP, the proposed run will be transferred to the candidate analyzer, and the OaP selection algorithm will remain active, and the workflow planning manager 2 will continuously create other proposed runs until the OaP state (triggered by the user) is complete.

[0130] Alternatively, if the user has not activated the OaP selection algorithm, in step S204, the workflow planning manager will determine the proposed run based on the emergency run selection algorithm.

[0131] The purpose of the Emergency Selection Algorithm is to establish a run that includes requested tests that need to be executed immediately, otherwise their target TAT will be compromised. This algorithm is a mathematical optimization algorithm based on Mixed Integer Programming (MIP). The algorithm selects only tests that fall within a predefined planning range (e.g., 4 hours). That is, the requested tests whose associated target TAT is included in the planning range. The Emergency Selection Algorithm can be used to determine multiple proposed runs to accommodate each requested test whose target TAT falls within the planning range. Each run is assigned to a candidate analyzer 8n, along with the time each run should be executed for to satisfy the test's target TAT during the run.

[0132] In addition, the MIP algorithm of the emergency selection algorithm can be optionally used to determine the selected analyzer for executing the proposed run.

[0133] The urgent run selection algorithm is configured to delay the execution of each proposed run as much as possible, while still satisfying the target TAT of the running test. The advantage of this is gaining visibility into additional requests for tests and biological samples arriving at System 1 (e.g., in a buffer). Due to the reactive operation of the workflow planning manager, this means more pending tests can be received, and thus increases the likelihood of creating a complete and optimized run.

[0134] After filling the proposed run according to the OaP and / or emergency run selection algorithm, the workflow planning manager 2 is configured to proceed to step S206, where the proposed run is filled with additional requested tests according to the filling algorithm. If the run is already full, the workflow planning manager 2 will proceed directly to the execution phase S300, where the proposed run is negotiated with one or more diagnostic analyzers 8n before execution or rejection.

[0135] The fill algorithm can be triggered after the OaP algorithm or the emergency run algorithm has been executed, or it can be triggered independently, regardless of whether a previous algorithm has proposed a run. For example, if the OaP is not triggered by the user and there are no requested tests that are about to expire (i.e., emergency tests), the workflow planning manager can proceed directly to the fill algorithm used to determine the proposed run.

[0136] The fill algorithm is configured to update previously proposed runs to be as complete as possible, or, if no existing run proposal exists, to attempt to create a complete run that includes only the fill tests (e.g., the requested tests for which the target TAT poses no risk). The fill algorithm is configured to select tests based on the following rules (listed in order of priority):

[0137] Passenger Sample Minimization: Passenger samples are those included in the sample rack and sent to Analyzer 8n for processing testing, but no specific tests are performed on these samples. These samples will access Analyzer 8n and then be returned to buffer 4 after the run is executed. Therefore, the time these samples spend in Analyzer 8n is non-operational time, as the samples cannot be allocated to another run before returning to the buffer. Therefore, the workflow planning manager is configured to populate each proposed run with requested tests whose samples are located in the same sample rack to be sent to Analyzer 8n, thereby reducing the presence of passenger samples.

[0138] ii. Requested tests that are about to expire: Potential tests included in the run will be categorized and assigned to the proposed run according to their associated target time (TAT) (e.g., from the earliest to the furthest expiry date).

[0139] iii Winning Rule: Next, tests can be used to populate the proposed run based on the arrival time of their respective biological samples in System 1 (e.g., based on the arrival time in Buffer 4).

[0140] Furthermore, each selection algorithm in steps S202-206 may also consider one or more of the following factors:

[0141] -STAT (Short Turnaround Time) Samples: These correspond to tests that require urgent execution and therefore have a shorter TAT than other tests of the same type. The algorithm prioritizes meeting the TAT, but in cases where the algorithm needs to choose between two samples with the same remaining TAT but one of them is indicated as STAT (e.g., urgent), the latter will be chosen first.

[0142] - Test compatibility: Workflow Planning Manager 2 (which implements any of the above selection algorithms) is configured to consider test types that cannot be executed together in the same run.

[0143] Prioritization when tests have expired: If a requested test has expired where its target time interval (TAT) has been exceeded, Workflow Planning Manager 2 (implementing any of the selection algorithms described above) is configured to prioritize the test that has expired the longest. For example, if one test has expired two hours ago and three tests have expired one hour ago, Workflow Planning Manager 1 is configured to first select the test that has expired two hours ago.

[0144] Figure 6 illustrates a flowchart of the process for verifying and approving the proposed run between the workflow planning manager 2 and the diagnostic analyzer 8n, and for determining whether to continue the proposed run. This part of the process can be referred to as the execution phase S300 as described above.

[0145] First, in step S302, the workflow planning manager 2 is configured to verify the proposed operation to determine its suitability before negotiating with the candidate diagnostic analyzer 8n.

[0146] Figure 7 illustrates an outline of the process for verifying the execution of a proposal. As shown in Figure 7, verifying the execution of a proposal involves determining whether the execution of the proposal is urgent or whether the execution of the proposal is full.

[0147] An emergency run might be a run that contains tests that must be performed now, otherwise its objective TAT cannot be met. For example, an emergency run could be a run that has already been proposed by the emergency run selection algorithm discussed above for Figure 5.

[0148] Determining whether a proposed run is full may include comparing the number of requested tests and / or samples in the proposed run to a target fill quantity. The target fill quantity may be the run's maximum capacity or a percentage of that maximum capacity, based on, for example, the capacity of System 1, sample rack size, and diagnostic analyzer 8n. For example, a run may contain a maximum of 96 samples, and a run may be considered full if it contains at least 96 - x samples, where x may be, for example, between 5 and 20 samples.

[0149] The target fill quantity can be relaxed (i.e., reduced) at the end of the shift, for example, before the planned lab downtime. At this point, new samples and requested tests may stop arriving, and therefore Workflow Planning Manager 2 is able to stop prioritizing full runs, as this may not be possible at the end of the shift.

[0150] When a proposed run is determined to be full or urgent, it is successfully validated and can be negotiated with Analyzer 8n. However, when a proposed run is determined to be neither full nor urgent, it is discarded. By accepting unfilled runs only in urgent situations, the laboratory can be operated more efficiently. For example, non-urgent runs can be delayed until there are enough test orders to fill them, or runs can be recalculated to include more test orders.

[0151] Returning to Figure 6, when the proposed run is successfully verified, the workflow planning manager 2 proceeds to step S304 to negotiate the verified proposed run with one or more of the diagnostic analyzers 8n. Negotiation includes transmitting the proposed run to the candidate diagnostic analyzer 8n for evaluation, and in response, receiving predicted run completion information from the candidate analyzer 8n, as discussed above with reference to steps S104-S106 of Figure 4.

[0152] To negotiate the proposed run, Workflow Planning Manager 2 is configured to first select one of the diagnostic analyzers 8n as a candidate analyzer 8n. If the proposed run is the output of an emergency run algorithm, the analyzer 8n on which the run needs to be executed can be known and selected as a candidate analyzer 8n. Otherwise, for example, if the proposed run is the output of a fill algorithm, Workflow Planning Manager 2 will search for the most suitable available diagnostic analyzer 8n. In this example, Workflow Planning Manager 2 will evaluate all available diagnostic analyzers 8n that are acceptable for the run and search for analyzers that have the reagents required to execute the proposed run installed. From these analyzers, Workflow Planning Manager 2 is configured to select the diagnostic analyzer 8n with the longest idle time as a candidate analyzer 8n. The purpose of this is to balance the load on the diagnostic analyzers 8n in System 1.

[0153] After selecting a candidate analyzer 8n, the workflow planning manager 2 is configured to transmit the proposed run to the candidate analyzer 8n, for example, via the interface module 10n. The candidate analyzer 8n is then configured to perform a local optimization process to determine whether each of the proposed run's in-process tests can be executed based on various factors such as:

[0154] 1) Are there enough reagents available?

[0155] 2) Are additional QC (Quality Control) steps and samples required to perform the proposed run? QC is included by the instrument in the run, occupying one or more of the possible 96 locations the run may have. Typically, QC may be required every 24 hours for each type of test, although this requirement can be adjusted by the user. The workflow planning manager is unaware of whether QC is required in the run. For example, the workflow planning manager might suggest a run containing 96 test orders and samples. The candidate analyzer 8n could reverse this by suggesting only performing 94 of the proposed tests, since, for example, two locations in the run must be allocated to QC.

[0156] 3) Ensure that different types of tests comply with the analyzer's specific requirements during the proposed run; the number of tests of each test type may need to be executed in pairs for each run. Therefore, if the proposed run includes five positions assigned to a certain test type, the candidate analyzer can reserve six positions for that test type during the run.

[0157] 4) If each of the proposed tests in operation is compatible with being performed in the same diagnostic analyzer 8n.

[0158] If the candidate diagnostic analyzer 8n is unable to execute all the requested tests included in the proposed run, the candidate diagnostic analyzer 8n will also consider the priority of each requested test (e.g., its target TAT, where the fastest has the highest priority). The candidate diagnostic analyzer 8n then sends a counter-proposal (e.g., in the form of predicted run completion information) to the workflow planning manager 2, which includes the requested tests that can be processed, the requested tests that cannot be processed, an indication of the reason, and a predicted run start time indicating when the candidate analyzer 8n will be available to execute the proposed run next.

[0159] Next, the workflow planning manager 2 proceeds to step S306 to determine whether to accept (e.g., continue) the proposed run based on the predicted run completion information from the candidate analyzer 8n.

[0160] To determine whether to continue the proposed run, the workflow planning manager 2 is configured to determine, based on predicted run completion information, whether the threshold percentage of the requested test in the proposed run can be performed by the candidate analyzer 8n. For example, the threshold could be 90% of the proposed test. Furthermore, the workflow planning manager 2 is configured to determine whether the predicted run start date and / or time is within a threshold deviation of the expected start date and / or time, which is determined by the workflow planning manager 2 during its determination of the proposed run. If the above conditions are met, the workflow planning manager 2 is configured to continue to step S308 and simultaneously signal the delivery device 6 to begin transferring the required biological sample to the candidate analyzer 8n to execute the proposed run.

[0161] However, if the Workflow Planning Manager 2 determines that the predicted run completion information differs significantly from the initially proposed run—for example, because one or more of the aforementioned thresholds are not met—further action is required. The further actions that the Workflow Planning Manager 2 may take depend on the root cause of the candidate analyzer 8n's incomplete run. For example, the following root causes and further actions can be identified:

[0162] Cause: Reagent or QC locked or missing: This could be because the candidate analyzer 8n (which may be able to perform two runs in parallel) is locked with the kit required for a specific test in the proposed run in order to perform the different run it has already performed. In other instances, QC materials may be missing from the candidate analyzer, thus preventing certain tests from being performed.

[0163] Action 1) If one or more of the affected tests are urgent, the Workflow Planning Manager 2 will record the test types that are not available in the analyzer 8n and will re-execute the plan by re-identifying alternative proposals for execution and / or by selecting alternative candidate analyzers.

[0164] Action 2) If no urgent tests are affected, the Workflow Planning Manager 2 will remove the requested tests that cannot be executed from the proposed run and will run the fill selection algorithm again to generate a new proposed run.

[0165] Cause: Candidate diagnostic analyzer 8n is unavailable or the capacity of analyzer 8n has been reduced.

[0166] Action: In this case, Workflow Planning Manager 2 is configured to exclude Analyzer 8n from the list of available Analyzer 8n, and then redetermine the proposed run and reselect candidate Analyzer 8n.

[0167] Reason: The reagent kit needs to be replaced.

[0168] Action: In this case, Workflow Planning Manager 2 is configured to accept and continue running the proposal.

[0169] When the workflow planning manager 2 decides to proceed with the proposed run, it instructs the conveyor 6 to transfer the sample to the candidate diagnostic analyzer 8n. Next, sample racks containing the sample begin arriving at the candidate analyzer 8n. If all sample racks arrive at the analyzer on time (e.g., via a reserved allocation slot in analyzer 8n), the workflow planning manager 2 signals to the analyzer that the proposed run is being processed. However, if one or more sample racks do not arrive at the analyzer 8n on time, the workflow planning manager 2 is configured to determine whether to delay, continue, or discard the proposed run.

[0170] Figure 8 illustrates the process for monitoring biological samples arriving at the candidate diagnostic analyzer 8n and renegotiating the proposed operation if no sample is received at the candidate diagnostic analyzer 8n. Samples arrive at the candidate diagnostic analyzer in sample racks, each rack being configured to contain multiple biological samples. However, if one or more intended sample racks are lost, for example due to a barcode reading error or transport congestion in the transport system 6, the analyzer interface module 10n sends a message to the workflow planning manager 2, which performs the evaluation shown in Figure 8.

[0171] First, if all sample racks containing biological samples corresponding to tests marked as urgent arrive at the candidate diagnostic analyzer 8n, the workflow planning manager 2 is configured to instruct the candidate diagnostic analyzer 8n to perform a run. Otherwise, if the number of sample racks to arrive is less than the threshold number of sample racks (e.g., 2 sample racks), a barcode error is assumed and manual user intervention is required. In this case, the run is renegotiated and performed with the samples arriving at the candidate diagnostic analyzer 8n.

[0172] However, if more than a threshold number of sample racks have arrived at the candidate diagnostic analyzer 8n, the cause of the missing sample racks is identified as a delay due to transport congestion. In this case, the workflow planning manager 2 renegotiates the same run with the candidate diagnostic analyzer 8n, but with a delay upon sample rack arrival. This renegotiation will only occur once. Therefore, if one or more samples / sample racks are still missing on the candidate diagnostic analyzer 8n during the renegotiation (delayed) run, the run will not be renegotiationed again and the sample rack will be discarded.

[0173] Once Workflow Planning Manager 2 has signaled the start of a proposed run, it continues to monitor events in System 1, such as new test orders being received, and then renegotiates and negotiates new proposed runs as needed.

[0174] As described above, system 1 may include an analyzer interface module 10n, which is configured to handle negotiation and communication between one or more of the workflow planning manager 2 and the diagnostic analyzers 8n. The interface between the workflow planning manager 2 and each diagnostic analyzer 8n operates based on commitment theory [2]. Figure 9 The following description up to Figure 16 pertains to this interface.

[0175] Workflow planning manager 2 is the only component within system 1 capable of accessing the status of each diagnostic analyzer 8n and delivery device 6 within system 1. Furthermore, workflow planning manager 2 is the only component in system 1 that knows all currently available biological samples. On the other hand, each diagnostic analyzer 8n only knows (and cares about) its internal state and status, thus applying Demeter's Law [1], whereby objects in the system only interact with their immediate neighbors and have limited knowledge of the internal workings of other objects. This means that each diagnostic analyzer 8n is only concerned with the biological samples loaded (physically loaded into the analyzer 8n) and the work orders associated with those biological samples. Diagnostic analyzers 8n are not configured to perform any processing or planning to consider biological samples not within their scope (e.g., physically loaded into the analyzer 8n).

[0176] Therefore, the interface module 10n operates to coordinate the information stored by each component in system 1 in order to agree on the proposed operation to process the sample.

[0177] Figure 9 illustrates the communication exchanged between the Workflow Planning Manager 2 (labeled "Planning Component") and the Diagnostic Analyzer 8n. Figure 9 also illustrates the general method of interaction between these two components using pseudo-language.

[0178] The interaction begins with the Workflow Planning Manager 2 querying each Diagnostic Analyzer 8n to determine how and when proposed runs will be scheduled if a specific set of biological samples (e.g., “virtually loaded samples”) are loaded into the Diagnostic Analyzer 8n before or at a given time point. The Analyzer 8n then executes its internal logic and evaluates its internal state, including knowledge of loaded consumables and resources and the availability of redundant hardware components, to recommend assigning each “virtually loaded sample” to a “virtual run” (e.g., candidate run scheduling).

[0179] Next, each of the diagnostic analyzers 8n responds to the workflow planning manager 2 with a "commitment" (e.g., a counter-proposal), providing the workflow planning manager 2 with sufficient information to evaluate the commitment or proposal in response to proposals from each of the other diagnostic analyzers 8n. For example, a commitment could be in the form of the predicted run completion information described above.

[0180] Workflow Planning Manager 2 can be configured to prioritize one or more optimization objectives as described above (e.g., to reduce costs, such as QC-related costs), to increase throughput, or to reduce the total TAT of all requested tests in System 1. Then, using the optimization objectives along with historical data and predictive models, Workflow Planning Manager 2 can select the best commitment (e.g., a counter-proposal) from the diagnostic analyzer to achieve the optimization objective (e.g., based on the optimization check scheme described above).

[0181] If a commitment is determined to be acceptable, the workflow planning manager 2 notifies the corresponding analyzer 8n that its commitment has been accepted. At this point, the analyzer 8n must reserve and allocate the necessary resources (e.g., reagent kits) so that the commitment can be fulfilled immediately once the agreed-upon biological sample is loaded into the selected diagnostic analyzer 8n. As mentioned above, if a proposed run is rejected based on commitments received from each analyzer 8n, the workflow planning manager 2 can initiate new negotiations with the diagnostic analyzer 8n using alternative proposed runs.

[0182] Figure 10 shows a flowchart of the interaction process between the diagnostic analyzer 8n and the workflow planning manager 2. This process can be performed by one or more of the interface modules 10n in Figure 3. As mentioned above, each interface module 10n can form part of the diagnostic analyzer 8n.

[0183] First, in step S400, the interface module 10n receives a proposed run from the workflow planning manager 2 as part of a request to allocate time slots for the proposal. The proposed run includes multiple requested analytical tests to be performed by the diagnostic analyzer 8n.

[0184] Next, in step S402, the interface module 10n determines candidate run schedules based on the analyzer 8n resource optimization process. The analyzer 8n resource optimization process is a local scheduling function executed by the candidate diagnostic analyzer 8n to determine candidate schedules for processing a set of test orders. Therefore, the analyzer 8n resource optimization process can be performed by the proprietary software of that specific diagnostic analyzer 8n based on the specific resources, settings, and functions of that analyzer 8n.

[0185] Next, in step S404, interface module 10n generates (or receives) predicted run completion information based on candidate run schedules (e.g., commitments or counter-proposals). The predicted run completion information includes at least an indication of which requested analysis tests in the proposed run can be processed by analyzer 8n according to the candidate run schedule. The predicted run completion information may also include information about the allocated time slots for the proposed run by analyzer 8n, indicating when the proposed run can be executed according to the candidate run schedule. For example, the allocated time slots could be the time period when the diagnostic analyzer 8n will become available next and / or the time period when the diagnostic analyzer 8n expects to have the necessary resources available to execute the proposed run.

[0186] Finally, in step S406, the interface module 10n transmits the predicted run completion information to the workflow planning manager 2 to determine whether the proposed run should continue based on the predicted run completion information.

[0187] If Workflow Planning Manager 2 rejects the proposed run (e.g., based on predicted run completion information, or because a new test order has been received, triggering a recalculation of the proposed run), or if Workflow Planning Manager 2 has chosen to continue the proposed run using another diagnostic analyzer 8n, the process can end there until another proposed run is received.

[0188] However, if the workflow planning manager 2 determines that the proposal should continue to run, the interface module 10n is configured to reserve the proposal allocation time slot for the diagnostic analyzer 8n and schedule the diagnostic analyzer 8n to execute the proposal in that time slot.

[0189] Figure 11 shows a flowchart of additional processing steps for interface connection between the diagnostic analyzer 8n and the workflow planning manager 2 when the proposed runtime continues. Therefore, the process in Figure 11 can... Figure 10 The process is executed after the process shown in Figure 10. As shown in Figure 11, the process can be executed in part or in whole by the interface module that runs the middleware and communicates with the diagnostic analyzer 8n, or by the diagnostic analyzer 8n itself.

[0190] First, in step S408, the interface module 10n (or the diagnostic analyzer 8n) receives confirmation from the workflow planning manager 2 that the proposed run has been accepted based on the predicted run completion information. This confirmation may take the form of requesting the reservation of an allocation slot for the analyzer 8n to execute the proposed run. Then, the interface module 10n reserves (or signals the diagnostic analyzer 8n to reserve) an allocation slot for the proposed run. For example, the interface module 10n may reserve an allocation slot for a proposal previously determined and proposed to the workflow planning manager 2.

[0191] The allocation of time slots to proposed runs is subject to the following rules. First, each analyzer 8n can receive multiple requests for time slot allocation, and then the workflow planning manager 2 accepts one of the proposed time slots. When generating new time slot allocations, analyzer 8n does not consider previously determined but unaccepted allocations, but it does consider previously accepted but not yet effective allocations. Therefore, analyzer 8n is configured to avoid scheduling pending runs in the same time slot to prevent conflicts.

[0192] Furthermore, when each diagnostic analyzer 8n determines and reserves allocation slots for a proposed run, it is configured to consider one or more of the following factors:

[0193] - The upcoming scheduled maintenance window for Analyzer 8n;

[0194] - Performance degradation due to the unavailability of the hardware redundancy module on the analyzer 8n;

[0195] - Which reagent kits are currently loaded into the Analyzer 8n?

[0196] - How many control miniature sample holders are currently loaded in the analyzer 8n?

[0197] However, when the diagnostic analyzer 8n assigns and reserves time slots, it does not consider:

[0198] - Availability of consumables in the Analyzer 8n; or

[0199] Waste storage capacity in the Analyzer 8n.

[0200] Instead, the diagnostic analyzer 8n is configured to notify the workflow planning manager 2 of any missing resources required for the next run (e.g., for a proposed run for which an allocation slot has been reserved). If the required resources are not loaded before the scheduled start time of the agreed run, the reserved allocation slot is cancelled.

[0201] In addition, the following rules apply to managing the allocation of time slots. First, a time slot allocation is considered effective once a suggested and accepted run begins execution. Furthermore, the Diagnostic Analyzer 8n is configured to begin allocating time slots (and process the planned run allocated to that time slot) once Analyzer 8n receives all agreed samples for the planned run, even if this occurs before the agreed start time of the time slot allocation (assuming all resources, supplies, and required consumables are available at Analyzer 8n). When the Workflow Planning Manager 2 requests a time slot allocation, the Diagnostic Analyzer 8n (or the interface module) is configured to assign and reserve the time slot only for the next (and only once) possible run assignment. A time slot will never be assigned to (e.g., reserved for) more than one proposed run.

[0202] Once an allocation slot has been reserved for the proposed run, the process in Figure 10 proceeds to step S412, where the diagnostic analyzer 8n (and / or interface module 10n) determines whether the current inventory of consumables in the diagnostic analyzer 8n is sufficient, and / or whether there is sufficient waste storage in the diagnostic analyzer 8n available to execute the proposed run in the reserved allocation slot. If there is sufficient inventory of consumables and sufficient waste storage is available, the process proceeds to step S416. However, if more consumables or waste storage is required, the process proceeds to step S414, where a signal is transmitted to the workflow planning manager 2 requesting the replenishment of consumables and / or the emptying of waste storage.

[0203] In step S416, the interface module 10n waits until the start time of the reserved allocation slot. During this waiting period, the diagnostic analyzer 8n may be executing a previously scheduled different run, performing a maintenance routine, or may be idle. During this waiting period, the delivery device 6 is operated to transfer the biological sample specified in the proposed run to the diagnostic analyzer 8n. The diagnostic analyzer 8n records and counts the biological samples that arrive and are loaded into the diagnostic analyzer 8n.

[0204] Next, in step S418, at the start of the reserved allocation time slot, the interface module 10n transmits the count of the received biological samples to the workflow planning module. The interface module 10n can also transmit the ID number of the received biological samples.

[0205] Then, as described above, the workflow planning module 2 determines whether to continue (or not) based on the count of received biological samples. For example, if all biological samples have arrived, the workflow planning manager 2 can continue. However, if biological samples are missing, for example due to bottlenecks in system 1, barcode reading errors, hardware failures, etc., the workflow planning manager 2 can determine, based on the count and which biological samples have arrived, whether to cancel or delay the reserved allocation slot, or whether to continue the proposed operation in the reserved slot using only the received biological samples.

[0206] Therefore, in step S420, the interface module 10n checks to see if it has received a confirmation proposal from the workflow planning manager 2 for a workflow order that should start.

[0207] If a workflow order has been received, the interface module 10n proceeds to step S422 and signals the diagnostic analyzer 8n to execute the proposed run (e.g., according to the candidate run schedule) using the received biological sample. However, if a workflow order has not yet been received (e.g., a predetermined time limit after the start time of the reserved time slot), or if a cancellation order is received instead, the interface module 10n proceeds to step S424 and cancels the reserved allocation time slot. All subsequent reserved time slots allocated within a period after the reserved allocation time slot will also be canceled so that they can be renegotiated. The rationale is that subsequent allocation time slots are calculated under the premise that the current allocation time slot will take effect. If this is not the case, the assumptions made in its calculation may be broken, therefore the inventors have found that it is more efficient to redetermine all proposed runs and allocation time slots based on available actual resources and all unprocessed test orders.

[0208] Other behavioral rules followed by the analyzer interface module 10n include:

[0209] - If a sample barcode reading error occurs, the diagnostic analyzer 8n will load the sample holder in any manner. The allocated time slot may be cancelled if a work order is not received from the planning module on time; in this case, the sample holder can be unloaded again.

[0210] - If no connection to Workflow Planning Module 2 is available before a workflow order is received, the accepted allocated time slots cannot be maintained, and the scheduled runs for those time slots are not executed. However, if a work order has been received from Workflow Planning Manager 2 before the connection to Workflow Planning Module 2 is lost (e.g., after all biological samples corresponding to the run have arrived at Diagnostic Analyzer 8n), the run is executed.

[0211] - If a sample rack is received or loaded onto analyzer 8n, and any biological samples within that rack are not part of any allocation slot (e.g., to be processed in a scheduled run), the sample rack will be immediately unloaded and returned to buffer 4. However, an exception to this rule is that if one or more samples in the rack are scheduled for use in an unexecuted run (e.g., part of an incomplete allocation slot), the sample rack will be held for a period of time (e.g., 5 minutes).

[0212] Figures 12 through 15 are flowcharts illustrating the communication between the workflow planning manager 2, the diagnostic analyzer 8n, and the conveying device 6. These figures show examples of specific orders and data transferred between the workflow planning manager 2 and the diagnostic analyzer 8n during the aforementioned interactions.

[0213] Figure 12 illustrates a diagram depicting the workflow planning manager 2 requesting an allocation slot (i.e., GetAllocationSlotProposal) for executing a proposed run and the diagnostic analyzer 8n responding with the proposed allocation slot. The workflow planning manager 2 is configured to request an allocation slot from each available diagnostic analyzer 8n (capable of handling a specific test within the proposed run). Each diagnostic analyzer 8n then executes internal logic to determine candidate run schedules, including the availability of loaded kits, hardware redundancy modules, and pre-determined control rules, including the proposed allocation slot that defines the time period for executing the proposed run. For example, the proposed allocation slot is transmitted to the workflow planning manager 2 (i.e., AllocationSlotProposal), for instance, as part of the predicted run completion information discussed above.

[0214] The GetAllocationSlotProposal message contains a list of sample containers, and for each sample container: the sample container ID (e.g., barcode), a list of tests to be performed, the test code, the test priority status, and the latest estimated arrival time of the sample container on the diagnostic analyzer 8n.

[0215] The AllocationSlotProposal message may contain:

[0216] - Assign time slot identifiers,

[0217] - Allocation slot expiration time (indicates the valid time before the allocated slot expires if the workflow planning manager does not accept or reject the allocation).

[0218] - Sample group, including: a list of sample test order identifiers assigned to the sample group, a list of newly added controls (only if a new control must be used), an estimated time when processing can begin, and an incremental time indicating when results can be provided.

[0219] A list of unscheduled sample test orders, including sample test order identifiers and the reason why each identified sample test order was not scheduled in the candidate run schedule.

[0220] The proposed time slot allocations (e.g., predicted run completion information) are not persistently stored on the diagnostic analyzer 8n. Therefore, only the workflow planning module 2 is aware of each different time slot allocation proposal from each diagnostic analyzer 8n and will select the most suitable time slot from the proposal to execute the proposed run. As described above, if none of the proposed time slot allocations is determined to be suitable, the workflow planning manager 2 is configured to request a new proposal from the analyzer 8n.

[0221] However, if the Workflow Planning Manager 2 decides to accept the proposed allocation slots and continue running the proposal, it will reserve the proposed allocation slots by sending a command to the Correlation Analyzer 8n.

[0222] Figure 13 shows a flowchart of the communications involved in the allocation of time slots for the reserved proposal.

[0223] First, Workflow Planning Manager 2 sends a ReserveAllocationSlot command containing the following data:

[0224] - Target instrument (e.g., a candidate diagnostic analyzer 8n with an accepted time slot allocation)

[0225] - Proposed allocation slot identifier

[0226] For each sample container, the following order list is included: sample ID (e.g., barcode); test information, including the test to be performed on that sample container, test code (e.g., USI); test priority status; latest predicted arrival time; and latest run start time.

[0227] Next, the diagnostic analyzer 8n responds with an acknowledgment message (ReserveAllocationSlotAck), followed by an indication that the allocated slot has been reserved (AllocationSlotReserved event message), which includes the target instrument ID, the allocated slot identifier, and the allocated slot status. The diagnostic analyzer then sends an indication to the workflow planning manager 2 indicating whether the allocation slot reservation was successful (e.g., an AllocationSlotRealization event or an AllocationSlotReservationFail event).

[0228] At a certain point in time, the workflow planning manager operates the delivery device 6 to transfer the biological sample (tissue in the RD5 sample holder) to the diagnostic analyzer 8n in a reserved allocation slot. As described above, with respect to Figure 8, the diagnostic analyzer 8n is configured to notify the workflow planning manager 2 of the arrival of the biological sample and which biological samples have not yet arrived at the analyzer 8n. If one or more samples belonging to a reserved allocation slot do not arrive at the diagnostic analyzer 8n by the specified latest arrival time, the diagnostic analyzer 8n is configured to discard the reserved allocation slot and all subsequent reserved allocation slots. This places the responsibility back with the workflow planning manager 2 to decide what to do next with the samples, as some of the samples may have already arrived at the analyzer 8n. The workflow planning manager 2 is configured to determine whether to renegotiate or delay the proposed run, depending on which samples have already arrived at the analyzer 8n, as discussed above with respect to Figure 8.

[0229] Figure 14 shows the sequence diagram of this interaction.

[0230] First, the analyzer 8n sends a SampleLoaded event, including the sample container ID (e.g., sample tube barcode), to the workflow planning manager 2. It's worth noting that if all samples requiring processing within the reserved allocation slot have arrived, the diagnostic analyzer 8n will execute the proposed run. However, if one or more samples are missing, the diagnostic analyzer 8n will wait until the scheduled start time of the reserved allocation slot has elapsed before sending an indication (AllocationSlotDiscarded message) to the workflow planning manager 2 that the reserved allocation slot will be discarded. At this point, the workflow planning manager 2 must determine how to proceed according to the method shown in Figure 8.

[0231] In some instances, the workflow planning component may want to cancel a proposed run and revoke the reserved allocation slots associated with that run (e.g., renegotiating the proposed run in light of system changes and / or new urgent test orders arriving in the system). This interaction is illustrated in Figure 15.

[0232] In order to cancel the reserved allocation slot, the workflow planning manager 2 first sends a command (“RevokeAllocationSlot”) to the diagnostic analyzer 8n, instructing the diagnostic analyzer 8n to cancel (revoke) the reserved allocation slot.

[0233] If the run of the proposal scheduled for that allocated slot has not yet started, the diagnostic analyzer 8n cancels the slot allocation and responds to the workflow planner 2 with an AllocationSlotRevoked message containing the allocated slot ID. However, if the run of the proposal has already started in a reserved allocated slot, the diagnostic analyzer 8n responds with an AllocationSlotRevocationNotPossible message containing the allocated slot ID and the reason for not cancelling the slot allocation.

[0234] Figure 16 shows a state diagram illustrating the different states of the allocated time slots managed by the diagnostic analyzer 8n. The following table summarizes these states.

[0235]

[0236] The table below summarizes the transitions between each state and the triggers that may occur for each transition. These triggers and transitions are managed locally by the Diagnostic Analyzer 8n (or Analyzer Interface Module 10n).

[0237]

[0238] By employing the method described herein, the laboratory can be operated more efficiently without requiring the workflow planning manager 2 to access all information regarding the capabilities and current status of each diagnostic analyzer 8n in the system, or the current load of each analyzer 8n. Advantageously, this collaborative approach enables efficient operation without exposing the internal operations of each component in system 1 to each other, thus satisfying Demeter's Law. Its benefits include increased maintainability and adaptability of system 1 (e.g., the laboratory) and its internal components. Because each component is less dependent on the internals of other components, it is easier to change the internal operations of each component without affecting other components in system 1.

[0239] Furthermore, compared to known solutions, the proposed solution offers the advantage of the fact that the optimization scheme executed by the Workflow Planning Manager 2 and the local optimization algorithms in the Analyzer 8n can be changed and evolved independently. Changing one does not require changing the other.

[0240] In this way, the proposed solution decouples the Workflow Planning Manager 2 and the Analyzer 8n, thereby providing all the benefits of a modular solution in terms of evolvability, maintainability, and performance.

[0241] The features disclosed in the foregoing specification, or the manner in which the disclosed functions are expressed or implemented in a particular form in the following claims, or the methods or processes for obtaining the disclosed results, may be used individually or in any combination in various forms to achieve the present invention.

[0242] While the invention has been described in conjunction with the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art upon presentation of this disclosure. Therefore, the exemplary embodiments of the invention described above are to be considered illustrative rather than restrictive. Various changes may be made to the described embodiments without departing from the spirit and scope of the invention.

[0243] To avoid any doubt, any theoretical explanations provided in this article are intended to improve the reader's understanding. The inventor does not wish to be bound by any of these theoretical explanations.

[0244] Any chapter headings used herein are for organizational purposes only and should not be construed as limiting the subject matter described.

[0245] Throughout the specification, including the following claims, unless the context otherwise requires, the words “comprise” and “include”, as well as variations such as “comprises” and “comprising” and “including”, shall be understood to imply inclusion of the stated integer or step or group of integers or steps, but not to exclude any other integer or step or group of integers or steps.

[0246] It should be noted that, as used in this specification and the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context explicitly specifies otherwise. A range herein may be expressed as from “about” one particular value and / or to “about” another particular value. When expressing such a range, another embodiment includes from one particular value and / or to another particular value. Similarly, when a value is expressed as an approximation, the use of the antecedent “about” will be understood to form another embodiment of a particular value. The term “about” in relation to numerical values ​​is optional and means, for example, + / - 10%.

Claims

1. A workflow planning manager for coordinating the distribution of biological samples in an analytical system, the analytical system comprising: One or more diagnostic analyzers for performing one or more tests on the biological sample, and A delivery device for delivering the biological sample to one or more diagnostic analyzers. The workflow planning manager is configured to: The system receives multiple requests for analytical tests to be processed by the system, each corresponding to a biological sample. Determine the execution of the proposal, which includes at least some of the requested analytical tests; The proposed operation is transmitted to the candidate diagnostic analyzer among the one or more diagnostic analyzers. Receive predicted run completion information from the candidate diagnostic analyzer, the predicted run completion information including indications of which of the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer, and The decision to continue or reject the proposed run is made based on the predicted run completion information, wherein: When the proposed operation is to continue, the workflow planning manager is configured to signal the delivery device to deliver some or all of the biological samples specified in the proposed operation to the candidate diagnostic analyzer, and When the proposed run is rejected, the workflow planning manager is configured to determine an alternative proposed run or to transfer the proposed run to an alternative candidate diagnostic analyzer.

2. The workflow planning manager of claim 1, wherein determining the execution of the proposal comprises: Select multiple tests from the requested tests based on the workflow optimization plan, and Fill the proposed run with the selected tests.

3. The workflow planning manager according to claim 2, wherein selecting the plurality of tests according to the workflow optimization scheme includes selecting the tests based on the following: The number of tests for each test type in the requested tests. The target turnaround time for each requested test, and / or The compatibility between the requested tests is considered in order to select the requested test for the proposed run, wherein the requested tests are: They can be processed in the same diagnostic analyzer. With compatible target turnaround time, Tests of the same test type, and / or To minimize the number of transient samples during the operation of the proposed program.

4. The workflow planning manager according to any one of claims 2 or 3, wherein selecting the plurality of tests according to the workflow optimization scheme includes: First, select the requested test that is designated as urgent, and Then, select the test with the fastest target turnaround time from the requested tests.

5. The workflow planning manager according to any one of claims 2 to 4, wherein determining the execution of the proposed operation comprises: Based on the aforementioned workflow optimization scheme, select initial multiple tests, and The proposed run is then populated by assigning additional tests to the proposed run to meet the target fill quantity.

6. The workflow planning manager according to any of the preceding claims, wherein the workflow planning manager is further configured to: Determine the maximum delay that can be applied while still meeting the target turnaround time associated with each of the requested tests in the operation of the proposed test, and Wait for the maximum delay, and then transmit the proposed operation to the candidate diagnostic analyzer.

7. The workflow planning manager according to any of the preceding claims, wherein: The workflow planning manager is configured to verify the proposed run by determining whether the proposed run is full and / or whether the proposed run is urgent before transmitting it to the candidate diagnostic analyzer, wherein: When the proposed run is determined to be full or urgent, the proposed run is transmitted to the candidate diagnostic analyzer, and The execution of the proposal is discarded when it is determined that the execution is neither full nor urgent.

8. The workflow planning manager according to any of the preceding claims, further configured to: Changes in the detection system, and In response to the detection of the system change, the operation of the proposal is determined; The system change can be detected in response to one or more of the following: New biological samples arrive at the system The requested test was added or removed from multiple requested tests, or The operating status of one of the diagnostic analyzers was updated.

9. The workflow planning manager of claim 8, further configured to: repeatedly determine the execution of new proposals in response to the detection of system changes, until each of the plurality of requested tests has been executed.

10. The workflow planning manager according to any of the preceding claims, The workflow planning manager is configured to transmit the proposed run to multiple candidate diagnostic analyzers and receive corresponding predicted run completion information from each of the multiple candidate diagnostic analyzers. Determining whether to continue or reject the proposed operation includes analyzing the corresponding predicted completion information from each diagnostic analyzer, and Continuing to run the proposal includes selecting one of the candidate diagnostic analyzers to perform the proposed run based on the corresponding predicted run completion information.

11. The workflow planning manager according to any of the preceding claims, wherein determining whether to continue or reject the proposed execution comprises: The predicted run completion information is compared with acceptance criteria, which include one or more of the following: The percentage of the threshold values ​​for the requested tests that can be performed by the candidate diagnostic analyzer during the operation of the proposed test. The proposed test includes whether there are any requested tests designated as urgent during the operation of the test, and whether these requested tests designated as urgent can be performed by the candidate diagnostic analyzer, and / or The target time for starting the proposed operation.

12. The workflow planning manager according to any of the preceding claims, wherein when the execution of the proposal is to continue, the workflow planning manager is further configured to: Receive delivery updates from the candidate diagnostic analyzer, the delivery updates indicating which of the biological samples have arrived at the candidate diagnostic analyzer, and Based on the delivery update, a signal is transmitted to the diagnostic analyzer, indicating whether to execute the proposed operation, discard the proposed operation, modify the proposed operation, or delay the proposed operation.

13. The workflow planning manager according to any of the preceding claims, further configured to: The shift end condition is detected, indicating that no further requested tests are imminent; and In response to the detection of the shift end condition, the acceptance criteria for determining whether to continue or reject the proposed run are lowered and / or the target filling quantity for filling the proposed run is reduced.

14. A computer-implemented method for coordinating an analytical system for analyzing biological samples, the system comprising: One or more diagnostic analyzers for performing analysis, each diagnostic analyzer including an analyzer programming module for operating the diagnostic analyzer; A delivery device for delivering the biological sample to one or more diagnostic analyzers, and A workflow planning manager for performing the computer-implemented method, the computer-implemented method comprising: The system receives multiple requests for analytical tests to be processed by the system, each corresponding to a biological sample. Determine the execution of the proposal, which includes at least some of the requested analytical tests. The proposed operation is transmitted to the candidate diagnostic analyzer among the one or more diagnostic analyzers. The system receives predicted run completion information from the analyzer programming module of the candidate diagnostic analyzer, the predicted run completion information including indications of which of the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer. Based on the predicted completion information, it is determined whether to continue or reject the proposed operation, and When the proposed operation is to continue, a signal is sent to the delivery device to deliver some or all of the biological samples specified in the proposed operation to the candidate diagnostic analyzer. When the proposed operation is rejected, an alternative proposed operation is determined or the proposed operation is transferred to an alternative diagnostic analyzer.

15. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the computer-implemented method according to claim 14.

Images