Workflow planning manager

Abstract

It provides a workflow planning manager that coordinates the distribution of biological samples in the analytical system. [Solution] The analysis system comprises one or more diagnostic analyzers and a biological sample transport device. The workflow planning manager is configured to receive multiple requests for analytical tests, determine a proposed run containing at least some of the analytical tests and send it to a candidate diagnostic analyzer, receive predicted run filling information from the candidate diagnostic analyzer, and decide whether to proceed with or reject the proposed run based on the predicted run filling information. If the proposed run is to proceed, the workflow planning manager signals the transport device to transport some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer; if the proposed run is rejected, it determines an alternative proposed run or sends the proposed run to an alternative candidate diagnostic analyzer.

Description

Technical Field

[0001] Field of the Invention The present invention relates to a workflow planning manager for adjusting the distribution of biological samples in an analysis system, and a computer-implemented method for adjusting an analysis system.

Background Art

[0002] Background A laboratory environment such as a molecular laboratory may include automated testing equipment such as IVD (in vitro diagnosis) equipment that is used to perform various processes and tests on biological samples. Typically, a laboratory planning manager is configured to receive one or more test instructions that describe which processes to perform on each biological sample, and to instruct the laboratory equipment to execute the test instructions.

[0003] To process each test instruction, a number of resources may be required, including instrument resources (e.g., a transport system for sample holders and reaction vessels, a robotic arm equipped with pipettes for transferring and dispensing sample and / or reagent liquids, a fluid mixer, an incubator, a photodetector, 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 using these resources to process test instructions can be complex and typically includes pre-analysis steps, analysis steps, and post-analysis steps. Further, multiple processes involved in processing test instructions can be executed fully or partially in parallel and can share some of the same resources, thus increasing the complexity.

[0004] Furthermore, biological samples and the corresponding test instructions for each biological sample may arrive at the laboratory in a continuous flow during working hours, and each of these must be scheduled and processed. Each test instruction and biological sample may have different characteristics, including different test types to be performed (e.g., HBV, HIV, etc.) and a target turnaround time (TAT) for processing each test. In addition, each test instruction may be classified as an emergency test instruction or a routine test instruction. To improve throughput, multiple samples may be processed in parallel by laboratory equipment. However, incompatibility exists between tests, meaning that two incompatible tests cannot be processed simultaneously, for example, in the same run.

[0005] A series of test instructions performed by an instrument (e.g., a diagnostic analyzer such as an IVD instrument) is sometimes referred to as a run. It is desirable to plan the run so that samples are loaded into each diagnostic analyzer in an order and combination that is adapted and optimized to factors such as the priority of the test instructions, material usage, target turnaround time (TAT), cost, sample transport time, and waste generation. Therefore, developing and operating efficient workflows for automated testing equipment is challenging.

[0006] Existing solutions for laboratory calibration typically employ simplistic algorithms for directing samples and processes that lack flexibility or adaptability (e.g., to newly mandated test instructions or sample transport errors). Furthermore, existing solutions are ineffective in defining laboratory-scale workflows, forcing users to pre-classify biological samples before loading them into laboratory equipment.

[0007] Furthermore, such existing solutions typically implement a top-down long-term planning approach in which the sample workflow is determined based on prior knowledge of incoming test instructions. In these examples, laboratory equipment is provided with a predetermined list of tests to be processed. This list is typically the result of tactical decisions made in advance, for example, daily or weekly. However, such solutions require centralized control and up-to-date knowledge of the resources available in each piece of equipment in the laboratory. Moreover, these solutions are ineffective in responding to system changes such as incoming test instructions, sample identifier errors, sample transport system bottlenecks, changes in the state of laboratory equipment, and changes in resource levels. Furthermore, such solutions make it difficult to predict which samples will arrive in the laboratory and when, making it difficult to plan accurately throughout the day. In addition, unfilled runs of test instructions may be scheduled, reducing the overall occupancy and efficiency of the system (e.g., when emergency samples are received).

[0008] Therefore, there is a need for a more effective and adaptable method for managing the distribution of samples and test instructions in analytical systems. The present invention has been made in view of the above considerations. [Overview of the Initiative]

[0009] Summary of the Invention In general, the present invention relates to a system for adjusting diagnostic analyzers, wherein a planning manager proposes a run of tests to be performed by one of the diagnostic analyzers. The proposed run is sent to one of the diagnostic analyzers, and based on the analyzer's current resource level and capabilities, it is evaluated how much of the proposed run the diagnostic analyzer can fill. The planning manager can then adjust the proposed run based on this information until a run with an acceptable level of fill is reached. Furthermore, if any changes, such as new samples or test instructions arriving in the system, or changes in resource status are detected, the planning manager can renegotiate the proposed run to accommodate the detected changes.

[0010] Accordingly, in a first aspect, embodiments of the present invention provide a workflow planning manager for coordinating the distribution of biological samples in an analysis system. The analysis system comprises one or more diagnostic analyzers for performing one or more tests on a biological sample, and a transport device for transporting the biological sample to one or more diagnostic analyzers. 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; to determine a proposed run including at least some of the requested analytical tests; to transmit the proposed run to one or more candidate diagnostic analyzers of the diagnostic analyzers; to receive predicted run filling information from the candidate diagnostic analyzers, the predicted run filling information including instructions on which of the requested analytical tests in the proposed run may be processed by the candidate diagnostic analyzers; and to decide whether to proceed with or reject the proposed run based on the predicted run filling information. If the proposed run is to proceed, the workflow planning manager is configured to signal the transport device to transport the biological sample (e.g., some or all thereof) specified in the proposed run to the candidate diagnostic analyzers. If a proposed run is rejected, the workflow planning manager may be configured to determine an alternative proposed run or to send the proposed run to an alternative candidate diagnostic analyzer.

[0011] Advantageously, the workflow planning manager can respond to changes in system resources and incoming test instructions by planning sample distribution for each run. Furthermore, by sending proposed runs to the analyzer for evaluation, the workflow planning manager can use up-to-date information on the analyzer's capabilities without having to control the analyzer itself. In this way, the workflow planning manager can ensure that the optimal laboratory workflow can be determined and updated based on changing information to minimize resource usage and maximize laboratory throughput, while ensuring that target TAT and emergency status are met.

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

[0013] The workflow planning manager (e.g., a tuner, planning module, etc.) may be a central processing component of a system, such as a server or processor, that is communicatively coupled to each of the diagnostic analyzers and transport devices.

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

[0015] A request for analytical testing may be a test instruction, each associated with one or more biological samples. For example, each test instruction may specify one or more processing steps to be performed on the associated biological sample(s), a target turnaround time (TAT) within which the test instruction should be processed, and / or an emergency status indicating whether the test instruction is an emergency or routine test instruction. An emergency test instruction may be considered a high-priority test instruction that should be processed without delay.

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

[0017] A run may 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 may be performed in parallel or partially in parallel by the diagnostic analyzer. Biological samples specified by the tests requested in a run may be transported to candidate analyzers in one or more racks. Each run may correspond to (for example, include) one or more racks of biological samples in the analytical system. For example, each run may include 20 to 200, more preferably 50 to 150, and more preferably 96 tests (and / or biological samples). Each rack may have a corresponding number of slots for housing biological samples in sample containers.

[0018] The transport of some or all of the biological samples in a proposed run may include the transport of all of the biological samples corresponding to the analytical tests specified in the proposed run (regardless of whether those tests are indicated in the predicted run packing information). In this way, the racks used to transport the biological samples do not need to be rearranged or sorted before transport. In another example, the transport of some or all of the biological samples in a proposed run may include the transport of (only) the biological samples corresponding to the analytical tests specified in the proposed run and identified in the predicted run packing information. Thus, only the biological samples that are expected to be performed by the diagnostic analyzer may be transported to the diagnostic analyzer.

[0019] The workflow planning manager may be configured to receive predictive run-fill information from candidate diagnostic analyzers via an analyzer interface module. The analyzer interface module, described in detail below, may be configured to provide an interface for communication between the workflow planning module and one or more diagnostic analyzers.

[0020] Determining a proposed run may include selecting several tests from the requested tests and including the selected tests in the proposed run, in accordance with a workflow optimization scheme. The workflow optimization scheme may include one or more optimization goals or factors configured to be optimized when the workflow planning manager constructs the proposed run.

[0021] For example, selecting multiple tests according to a workflow optimization method may include selecting analytical tests from the requested tests based on one or more optimization factors. For instance, analytical tests may be selected based on one or more of the following: the number of tests per test type in the requested tests, the target turnaround time for each requested test, the compatibility between the requested tests (e.g., for processing by the same diagnostic analyzer), the total TAT (for processing all selected analytical tests), the TAT for individual samples (for each analytical test), the amount of QC (quality control) materials used, reagents used (or other resources) required to perform each test, load balancing of the diagnostic analyzer, minimizing cost and / or resource usage, and / or run filling. Such factors may be considered when selecting requested tests for a proposed run, where the requested tests can be processed by the same diagnostic analyzer, have a compatible target turnaround time, and / or are tests of the same test type. By structuring the run according to one or more of these factors, the time it takes to run the run can be reduced while minimizing the overall resource usage of the analytical system.

[0022] In some examples, selecting multiple tests according to a workflow optimization method may include identifying requested tests whose relevant target turnaround time (TAT) has already elapsed. Furthermore, requested tests whose target TAT has elapsed over the maximum period may then be given priority for inclusion in the proposed run (for example, such requested tests may be selected first for the proposed run, before other test requests with later target TATs).

[0023] Furthermore, in some examples, selecting multiple tests according to a workflow optimization scheme may include minimizing the number of co-loaded samples in a proposed run. A co-loaded sample can be understood as a biological sample corresponding to a requested test that is included in a rack sent to one of the analyzers for the run to run, but is incompatible with that analyzer and / or other requested tests in that run. Thus, a co-loaded sample may be a sample that is transported to an analyzer but is not actually processed in that analyzer. By minimizing the presence of co-loaded samples during a run, more tests can be performed per run, thus improving system efficiency and reducing the time and cost per test processed within the system.

[0024] In some examples, selecting multiple tests according to a workflow optimization scheme may include selecting requested tests that are designated as urgent, and / or selecting the requested tests with the earliest target turnaround time. The optimization scheme may require that requested tests designated as urgent be selected first, followed by the requested tests with the earliest target turnaround time.

[0025] In some examples, selecting multiple tests for a proposed run (according to a workflow optimization scheme) may involve using mixed-integer programming, MIP, based on one or more cost functions and / or optimization targets or factors (e.g., predicted turnaround time, target turnaround time, and / or urgency status associated with each requested test) to optimize the proposed run against workflow performance metrics such as the number of co-pilot samples, time overruns, load balancing, resource usage, or any other appropriate workflow performance metrics.

[0026] Selecting multiple tests for a proposed run may include any combination of the considerations described above. For example, the selection may take into account test urgency and / or target turn-around time and / or test suitability and / or co-rider samples, etc.

[0027] The workflow planning manager may be configured to populate the proposed run with the required tests for the target fill number. For example, the target fill number may be the number of tests required to fill a run (or rack). For example, the target fill number may be 20 - 200 tests per run, or more preferably 90 tests per run. The target fill number may be the maximum capacity of the run (e.g., 96 test instructions / samples), or the target fill number may be less than the maximum capacity of the run (e.g., 80% - 95% of the maximum capacity, e.g., 90 test instructions or samples). By populating the run in this way before sending it to the analyzer, it is possible to advantageously reduce cost, resource usage, and TAT while maximizing the efficiency of the entire analysis system.

[0028] Determining a proposed run may include selecting an initial plurality of tests (e.g., according to a workflow optimization scheme) and then populating the proposed run by allocating additional tests to the proposed run to meet the target fill number. The additional tests may be selected according to a filling scheme configured to maximize the usefulness of each proposed run. Advantageously, by populating each run (e.g., with less urgent tests), the system may operate more efficiently and be able to process more test instructions in a shorter time.

[0029] Populating the proposed run may include allocating the required tests to the proposed run according to the order of the target turn-around times associated with each of the required tests (e.g., from earliest to latest, from shortest to longest, etc.).

[0030] The system may further include a buffer (e.g., a storage area or holding rack) for storing biological samples before transport to one or more diagnostic analyzers. Filling the proposed run may then involve allocating the requested tests to the proposed run according to the time it takes for the biological samples to arrive in the buffer (e.g., oldest to newest, oldest to most recent, earliest to latest, etc.). In this way, biological samples that arrive in the buffer first may be allocated to runs before those that arrive later, thus reducing the average individual turn-to-attach (TAT) of samples in the system.

[0031] In a further example, filling a proposed run may include allocating the requested tests to the proposed run according to the time of receipt of the requested tests by the workflow planning manager (e.g., oldest to newest, oldest to most recent, earliest received to latest received, etc.). In this way, older test instructions (e.g., received via the internet) may take precedence even if the biological samples associated with those test instructions have arrived in the analytical system more recently than other biological samples.

[0032] The workflow planning manager may be further configured to determine the maximum delay that can be applied while still meeting the target turnaround time associated with each requested test in the proposed run. In this case, the workflow planning manager can wait for the maximum delay before sending the proposed run to the candidate diagnostic analyzer. In this way, the proposed run is more likely to be filled and filled with suitable tests. This is because waiting for a delay increases the chances of more test instructions reaching the system, thus triggering a recalculation and, in some cases, improvement of the proposed run. As a result, the overall efficiency and throughput of the laboratory may be improved.

[0033] The workflow planning manager may be configured to validate a proposed run before sending it to a candidate diagnostic analyzer by determining whether the proposed run is full and / or urgent. If the proposed run is determined to be full or urgent, it may be sent to the candidate diagnostic analyzer; if the proposed run is determined to be neither full nor urgent, it may be discarded. A proposed run may be determined to be full if the number of requested tests included in the proposed run is equal to or greater than the aforementioned target fill number or the maximum run capacity.

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

[0035] The workflow planning manager may be configured to repeatedly (and sequentially) determine new proposed runs in response to the detection of system changes until each requested test has been performed. Advantageously, by continuously re-evaluating runs, the workflow planning manager can adapt pending workflows and operate to respond to system changes in an efficient manner without being tied to specific pre-calculated workflows. For example, existing emergency samples in the system may be included in a new run that includes additional samples, as opposed to the workflow planning manager simply interrupting a predefined, inflexible workflow to process emergency samples first.

[0036] The workflow planning manager may be configured to send a proposed run to multiple candidate diagnostic analyzers and receive predicted run fill information from each candidate diagnostic analyzer. The decision to proceed with or reject the proposed run may include analyzing the predicted run fill information from each candidate diagnostic analyzer. Proceeding with the proposed run may include selecting one of the candidate diagnostic analyzers to execute the proposed run based on the predicted run fill information.

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

[0038] The decision to proceed with or reject a proposed run may be based on the results of an optimization check process. For example, determining whether to proceed with or reject a proposed run may involve comparing predicted run-filling information with the pass / fail criteria (to optimize the proposed run according to the pass / fail criteria). The pass / fail criteria may include one or more of the following: the threshold percentage of requested tests in the proposed run that can be filled by the candidate diagnostic analyzer, whether or not there are requested tests designated as urgent in the proposed run, whether or not the requested tests designated as urgent can be filled by the candidate diagnostic analyzer, and / or the target time for initiating the proposed run. If one or more of the pass / fail criteria are not met by the predicted run-filling information, the workflow planning manager may reject the proposed run.

[0039] The predicted run filling information may include an estimated turnaround time for processing the proposed run in the candidate diagnostic analyzer. The optimization check process for deciding whether to proceed with or reject the proposed run may include determining whether the estimated turnaround time matches the relevant target turnaround time for the requested tests in the proposed run. Therefore, if the estimated turnaround time is longer or slower than one or more of the target turnaround times, the workflow planning manager may reject the proposed run. If the estimated turnaround time is shorter or faster than one or more of the target turnaround times, the workflow planning manager may proceed with the proposed run.

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

[0041] Once a proposed run is accepted (for example, decided to proceed), the workflow planning manager may be configured to receive (or wait for) a transport update from the candidate diagnostic analyzer indicating which biological samples have arrived at the candidate diagnostic analyzer. The workflow planning manager may then send a signal to the diagnostic analyzer instructing it to run the proposed run, discard the proposed run, modify the proposed run, or delay the proposed run, based on the transport update. For example, if all the biological samples specified in the proposed run (and / or predicted run fill information) have arrived at the candidate diagnostic analyzer, the workflow planning manager may signal the candidate diagnostic analyzer to run the proposed run. If one or more biological samples have not arrived at the candidate diagnostic analyzer, the workflow planning manager may signal the diagnostic analyzer to run the proposed run with the samples it has, provided that a test designated as urgent can be performed and / or that at least a predetermined minimum number of required samples have arrived at the diagnostic analyzer. The workflow planning manager may include in the decision of a new (subsequent) proposed run any test instructions associated with biological samples that have not yet reached a candidate diagnostic analyzer, so that any pending test instructions may be rescheduled.

[0042] The workflow planning manager may be further configured to detect the end of a shift condition, indicating that no further requested tests have come in (for example, for the current shift, period, day, etc.). In response to the detection of the end of a shift condition, the workflow planning manager may adjust the optimization check process to relax (e.g., reduce) the pass / fail criteria for deciding whether to proceed with or reject the proposed run, and / or lower the target number of runs to fill the proposed run. For example, if the end of a shift condition is detected, the workflow planning manager may be configured to proceed with the proposed run, even if not full, to complete the execution of each test requested in that shift.

[0043] In a second aspect, embodiments of the present invention provide an analytical system for analyzing biological samples. The analytical system comprises one or more diagnostic analyzers for performing analysis on a biological sample, a transport device for transporting the biological sample to one or more diagnostic analyzers, and a workflow planning manager for coordinating the distribution of the biological sample to the diagnostic analyzers, the workflow planning manager being communicatively connected to each diagnostic analyzer and transport device. The workflow planning manager is configured to receive multiple requests for analytical tests to be processed by the system, each request corresponding to a biological sample; determine a proposed run containing at least some of the requested analytical tests; send the proposed run to one or more candidate diagnostic analyzers; receive predicted run filling information from the candidate diagnostic analyzers, the predicted run filling information containing instructions on which of the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer; and decide whether to proceed with or reject the proposed run based on the predicted run filling information. If the proposed run is to proceed, the workflow planning manager is configured to signal a transport device to transport some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer. If the proposed run is rejected, the workflow planning manager may be configured to determine an alternative proposed run or send the proposed run to an alternative diagnostic analyzer.

[0044] The workflow planning manager of the analysis system may include any combination of the features described above in relation to the first embodiment.

[0045] In a third aspect, a computer implementation method is provided for arranging an analytical system for analyzing a biological sample, the system comprising one or more diagnostic analyzers for performing the analysis, each diagnostic analyzer comprising an analyzer programming module for operating the diagnostic analyzer, a transport device for transporting a biological sample to the one or more diagnostic analyzers, and a workflow planning manager for executing the computer implementation method. The method includes receiving multiple requests for analytical tests to be processed by the system, each request corresponding to a biological sample; determining a proposed run containing at least some of the requested analytical tests; transmitting the proposed run to one or more candidate diagnostic analyzers; receiving predictive run filling information from the analyzer programming module of the candidate diagnostic analyzers, the predictive run filling information including instructions on which of the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer; determining whether to proceed with or reject the proposed run based on the predictive run filling information; signaling a transport device to transport some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer if the proposed run is to proceed; and determining an alternative proposed run or transmitting the proposed run to an alternative diagnostic analyzer if the proposed run is rejected.

[0046] As described above, the planning module may communicate with diagnostic analyzers via an analyzer interface module configured to manage communication between the planning module and one or more diagnostic analyzers. The functionality of the analyzer interface module is sometimes referred to as middleware for the analysis system, as it can act as a bridge between the planning functions of the workflow planning manager and individual diagnostic analyzers.

[0047] Accordingly, a fourth aspect of the present invention provides an analyzer interface module for interfacering 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 comprising a plurality of requested analytical tests to be performed by the diagnostic analyzer on one or more biological samples; 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 filling information based on the candidate run schedule, the predicted run filling information comprising instructions on which of the requested analytical tests in the proposed run can be processed by the analyzer in the candidate run schedule; and transmit the predicted run filling information to the workflow planning manager.

[0048] Advantageously, by negotiating proposed runs with the workflow planning manager in this way, the workflow planning manager can gain an up-to-date understanding of how many of the proposed runs can be filled based on the current resource levels and analyzer status, while still allowing the processing components of the analysis system to operate in a modular manner. For example, by running the analyzer resource optimization process locally, predicted run filling information can be determined in the analyzer (or within the analyzer interface module) based on the latest optimization software running on the analyzer, without the need to recreate the optimization software on the workflow planning manager. Thus, the analyzer interface module allows diagnostic analyzers within the analysis system to be updated and replaced more easily than in conventional analysis systems, while ensuring efficient operation and throughput of the analysis system.

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

[0050] The analyzer interface module may be connected to one or more diagnostic analyzers. For example, the analyzer interface module may be a separate component from the diagnostic analyzers, for example, in the form of software running on a central server and connected to one or more diagnostic analyzers. Alternatively, each analyzer interface module may form part of the diagnostic analyzer, for example, as a software application running on the diagnostic analyzer. In these examples, the analyzer interface module can be understood as 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 fill information may further include the predicted total turnaround time (TAT) and / or available start times for the candidate run schedule. The available start times may be absolute or relative time periods indicating the next possible time the diagnostic analyzer could be available to perform the proposed run. The predicted run fill may also be considered an alternative to the proposed run (e.g., an opposing proposal, a modified proposed run), indicating which of the requested tests in the proposed run could be performed by the diagnostic analyzer and when. The workflow plan manager may then accept or reject the alternative. Thus, the proposed run, as modified by the predicted run fill information, may be considered a run agreed upon for performance by the diagnostic analyzer.

[0052] Determining a candidate run schedule according to an analyzer resource optimization process may include determining a set of analyzer resources available (e.g., requested, needed, desired) to perform the requested analytical tests in the proposed run. The set of analyzer resources may then be compared to an inventory of available analyzer resources to determine which of the requested analytical tests in the proposed run can be performed by that analyzer. The analyzer resource optimization process may also be a local workflow planning process performed locally by one or more diagnostic analyzers (or analyzer interface modules). Furthermore, the analyzer resource optimization process may be proprietary software configured to determine the workflow of 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 cassettes, loaded control miniracks, and / or time slots indicating the period during which the analyzer hardware is available.

[0054] The proposed run may include the predicted or planned time at which the biological sample arrives at the analyzer. Determining candidate run schedules according to an analyzer resource optimization process may then include comparing a set of analyzer resources with a predicted inventory of available analyzer resources at the predicted arrival time (e.g., analyzer resources that are predicted to be installed and available at the diagnostic analyzer at the predicted arrival time of the biological sample).

[0055] In response to the transmission of predicted run filling information, the analyzer interface module may be further configured to receive a confirmation message from the workflow planning manager indicating that the proposed run and / or candidate run schedule has been accepted, and to provide the analyzer with the proposed run to be executed according to the candidate run schedule.

[0056] The analyzer interface module may be configured to assign allocation slots (e.g., reserved slots) of the diagnostic analyzer to candidate run schedules. Allocation slots may be assigned after receiving (e.g., in response to) an instruction that a candidate run schedule has been accepted. The assignment of an allocation slot may prevent further scheduling of proposed runs in that slot due to the reservation of that slot. Thus, the diagnostic analyzer may receive a biological sample and prepare to run a proposed run in the allocation slot assigned to that run.

[0057] After an allocation slot is assigned to an accepted proposed run, the analyzer interface module may be configured to determine the predicted resource availability of consumables and / or waste storage units within the diagnostic analyzer during that allocation slot. If the predicted resource availability is determined to be insufficient to run the proposed run, the analyzer interface module may send a request for additional resources to the workflow planning manager. The request may ask for additional consumables(s) and / or for the waste storage unit to be emptied or replaced. For example, resource availability may be determined to be insufficient if it is predicted that consumables or waste storage units will be depleted before the time allocated for the allocation slot assigned to the proposed run.

[0058] The analyzer interface module may be further configured to reserve analyzer resources such as consumables and analyzer hardware that are required (e.g., requested, desired) to run the accepted proposed run (within the allocated allocation slot).

[0059] The analyzer interface module may be configured to receive one or more additional proposed runs and to determine additional candidate run schedules for each of the additional proposed runs. Determining additional candidate run schedules may include considering 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 may be configured to receive alerts from the diagnostic analyzer indicating when some or all of the biological samples in an accepted candidate run schedule have been received by the analyzer. The analyzer interface may then send an indicator to the workflow planning manager indicating which of the biological samples have been received by the diagnostic analyzer.

[0061] The analyzer interface module may be configured to trigger the execution of an accepted candidate run schedule by the diagnostic analyzer based on the received biological sample, in response to receiving a workflow instruction from the workflow planning manager.

[0062] The analyzer interface module may be configured to cancel the execution of a reserved allocation slot and a proposed run in response to receiving a cancellation instruction from the workflow planning manager and / or in response to a determination that, at the time of the reserved allocation slot, the expected biological sample required to perform the proposed run has not reached the diagnostic analyzer (and no workflow instruction has been received from the workflow planning manager). Canceling a proposed run and / or a reserved allocation slot may also include canceling any subsequent reserved allocation slots. In this way, runs scheduled for subsequent reserved allocation slots, which may have been determined under the assumption that the (first) reserved slot would be realized, can be recalculated based on the latest information, including available resources and remaining pending test instructions.

[0063] Therefore, interface modules allow the system to be more responsive to changes and adopt more efficient workflows compared to solutions that require pre-planned runs to remain unchanged.

[0064] A fifth aspect provides a computer implementation method for an analyzer interface module for interfacing with a diagnostic analyzer and a workflow planning manager for an analysis system for analyzing biological samples, the method comprising: receiving a proposed run from a workflow planning manager, the proposed run comprising a plurality of requested analytical tests to be performed by a diagnostic analyzer on one or more biological samples; determining a candidate run schedule for performing the requested analytical tests in the proposed run according to an analyzer resource optimization process; generating predicted run filling information based on the candidate run schedule, the predicted run filling information comprising instructions on which of the requested analytical tests in the proposed run can be processed by the analyzer within the candidate run schedule; and transmitting the predicted filling information to the workflow planning manager.

[0065] The computer implementation method may be carried out by the analyzer interface module described above in any of the embodiments described above.

[0066] In a further example, the computer implementation method may be carried out by an analysis system comprising a workflow planning manager and at least one analyzer interface module. Thus, the computer implementation method may be a distributed computer implementation method carried out by a workflow planning manager and / or at least one analyzer interface module. Thus, the distributed computer implementation method may include any of the features described above with respect to a third embodiment, which includes steps performed by the workflow planning manager.

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

[0068] A seventh aspect of the present invention provides an analysis system for analyzing biological samples, comprising: a diagnostic analyzer for performing analysis on the biological samples; a transport device for transporting the biological samples to the analyzer; a workflow planning manager for coordinating the distribution of biological samples within the system, the workflow planning manager being communicatively connected to an analyzer interface module and a transport device; and an analyzer interface module for interfacering 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 comprising a plurality of requested analytical tests to be performed by the diagnostic analyzer on one or more biological samples; 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 filling information based on the candidate run schedule, the predicted run filling information comprising instructions on which of the requested analytical tests in the proposed run can be processed by the analyzer within the candidate run schedule; and transmit the predicted filling information to the workflow planning manager.

[0069] The system may include any of the features described above with respect to the fourth aspect.

[0070] An eighth aspect of the present invention provides an analysis system for analyzing a biological sample. The analysis system comprises one or more diagnostic analyzers for performing analysis on a biological sample, a transport device for transporting the biological sample to one or more diagnostic analyzers, and a workflow planning manager for coordinating the distribution of the biological sample to the diagnostic analyzers, the workflow planning manager being communicatively connected to each diagnostic analyzer via an analyzer interface module and to the transport device. The workflow planning manager is configured to receive a plurality of requests for analytical tests to be processed by the system, with each analytical test being configured to receive a plurality of requests 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 among one or more diagnostic analyzers. The analyzer interface module is configured to receive a proposed run from the workflow planning manager, determine a candidate run schedule for performing the requested analytical tests in the proposed run according to the analyzer resource optimization process, generate predicted run filling information based on the candidate run schedule, the predicted run filling information includes instructions on which of the requested analytical tests in the proposed run can be processed by the analyzer in the candidate run schedule, and transmit the predicted filling information to the workflow planning manager. The workflow planning manager is configured to receive the predicted run filling information from the analyzer interface module and determine whether to proceed with or reject the proposed run based on the predicted filling information. If the proposed run is to proceed, the workflow planning manager is configured to signal the transport device to transport some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer. If the proposed run is rejected, the workflow planning manager may be configured to determine an alternative proposed run or to send the proposed run to an alternative diagnostic analyzer device.

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

[0072] In an additional embodiment, a computer-readable medium is provided which, when executed by a computer, includes instructions causing the computer to execute the computer implementation method of the third and / or fifth embodiment. Additional embodiments of the present invention may relate to a system configured to execute the computer implementation methods described above. Specifically, the system may include a processor configured to execute each embodiment of the computer implementation method of the present invention.

[0073] An additional aspect of the present invention may provide a computer program that, when executed by a computer, includes instructions causing the computer to perform steps of the computer implementation method of the above-described aspect of the present invention. A further aspect of the present invention may provide a computer-readable storage medium storing a computer program of the above-described aspect of the present invention.

[0074] The present invention includes combinations of the described embodiments and preferred features, unless such combinations are clearly unacceptable or explicitly avoided. [Brief explanation of the drawing]

[0075] Next, embodiments and experiments illustrating the principle of the present invention will be described with reference to the attached figures.

[0076] [Figure 1] Flowchart of biological samples processed in a molecular testing laboratory. [Figure 2] A flowchart illustrating an updated procedure for distributing and processing biological samples in a molecular laboratory. [Figure 3] A diagram of a system for processing biological samples according to an aspect of the present invention. [Figure 4] A flowchart illustrating the process for adjusting the distribution of biological samples in an analytical system. [Figure 5] A flowchart of the process for determining a proposed run for processing biological samples. [Figure 6] A flowchart illustrating the process for negotiating and agreeing on a proposed run. [Figure 7] A diagram outlining the process for validating the proposed run. [Figure 8] A diagram illustrating the process for renegotiating proposed runs based on biological samples reaching the diagnostic analyzer. [Figure 9] A flowchart of the workflow planning manager agreeing on a proposed run with the diagnostic analyzer. [Figure 10] A flowchart illustrating the process for interfaced between the diagnostic analyzer and the workflow planning manager. [Figure 11] A flowchart of further process steps for interface between the diagnostic analyzer and the workflow planning manager. [Figure 12] A diagram illustrating additional communication between the workflow planning manager, diagnostic analyzer, and transport device. [Figure 13] A diagram illustrating additional communication between the workflow planning manager, diagnostic analyzer, and transport device. [Figure 14] A diagram illustrating additional communication between the workflow planning manager, diagnostic analyzer, and transport device. [Figure 15] A diagram illustrating additional communication between the workflow planning manager, diagnostic analyzer, and transport device. [Figure 16] A state diagram showing the state transitions of the analyzer allocation slots. [Modes for carrying out the invention]

[0077] Detailed description of the invention Hereinafter, aspects and embodiments of the present invention will be described with reference to the attached figures. Further aspects and embodiments will be apparent to those skilled in the art. All references mentioned herein are incorporated herein by reference.

[0078] Figure 1 shows a flow chart of biological samples being processed in the molecular domain of the laboratory.

[0079] First, in point 1, samples arrive at the laboratory in a continuous flow during working hours. Each sample has different characteristics, including the type of test performed on each biological sample, such as a hepatitis B blood (HBV) test or a human immunodeficiency virus (HIV) test, and the target turnaround time (TAT). Additionally, each biological sample and its corresponding test may be classified as an emergency test or a routine test.

[0080] In the laboratory, samples may undergo different operations in a pre-analysis area (see point 2 in Figure 1) before being sorted in a 5-position rack ("RD5 rack") within a buffer (AOB) to await processing by one or more diagnostic analyzers (e.g., labeled "cx800").

[0081] Next, at point 6, the rack containing the samples for processing is removed from the AOB and transported to the diagnostic analyzer, where the requested results corresponding to those samples are processed at point 7.

[0082] Diagnostic analyzers such as the CX800 shown in Figure 1 function in a run, with each sample specified in the run loaded into the analyzer before the entire run is executed. A run consists of, for example, up to 96 requested tests processed in the analyzer. Each type of analyzer in the laboratory may have different capabilities, capacities, and throughputs, and therefore the time it takes to process a run can vary. For example, a run may take 2-3 hours.

[0083] Traditionally, each diagnostic analyzer may be provided with a predefined menu of tests to be processed. This menu is the result of tactical decisions made, for example, daily or weekly. Non-conformities exist between tests, and therefore, two non-conforming tests cannot be processed simultaneously. The table below shows possible test menus and configurations for a laboratory including three diagnostic analyzers (A1-A3). [Table 1]

[0084] For example, using the analyzers in the table above, the following operations may be possible. A) If a run containing HIV and HBV testing is submitted to A2, the entire run may be processed. B) If the same run containing both HIV and HBV testing is sent to A1, only the HIV test will be processed, and the HBV sample will be prepared as a "co-running sample." In other words, the HBV test must be included in a separate run to be required to return to AOB. C) If a run with HBV and MPLX tests is submitted to A2, only the HBV or MPLX test may be processed. This is because those conformity groups also produce “co-drive samples.”

[0085] Therefore, it is crucial to set up runs in an efficient manner to avoid unnecessary impacts on processing costs, turnaround time (TAT), resource usage, and compliance with laboratory regulatory standards (e.g., compliance with service levels agreements (SLAs)). However, accurate planning throughout the day can be hindered because it is difficult to predict which test orders are about to arrive at the laboratory and when they will arrive. In addition, creating and scheduling non-full runs can reduce the overall occupancy of the system, thus increasing the cost per test order, cost and resource usage per test type, overall cost, and average throughput time. In a further example, co-loaded samples included in a run (i.e., samples sent to a diagnostic analyzer but not processed by that analyzer) necessitate creating additional runs and additional sample transport operations to process the co-loaded samples. Such co-loaded samples can overload the transport system, make setting up full runs difficult, and jeopardize the system's ability to meet the test target TAT. Furthermore, the acceptance of emergency samples can impact the entire system, forcing it to process them immediately and potentially disrupting efficient operation, for example by causing delays in previously planned runs. Therefore, the run composition, the transport system's capacity, and the amount of time the analyzer needs to process each can affect the system's overall performance. Moreover, since only the diagnostic analyzers themselves have access to all information regarding their status (including reagent status, estimated time to complete the run, etc.), determining a laboratory workflow that efficiently utilizes available resources in the laboratory is challenging.

[0086] Conventional methods for calibrating a laboratory (as shown in the table above) involve evaluating test suitability and then applying simple algorithms such as FIFO or Greedy to determine the workflow. However, the inventors have found that such methods are insufficient to ensure the efficient operation of the laboratory.

[0087] Figure 2 shows 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 configured to perform an intermediate process is introduced in Figure 2, which includes considering the samples in the buffer (e.g., unprocessed samples arriving in the laboratory), communicating with the diagnostic analyzer, and reaching an agreement on optimized possible combinations of samples to send to the analyzer as a run. The agreed run is then sent to the diagnostic analyzer, which then requests the samples specified in the run from the buffer and processes the samples according to the requested tests in the agreed run.

[0088] 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, for example, as resources are depleted. In particular, this method can advantageously address and respond to specific, continuously changing, and unpredictable constraints on laboratory equipment (e.g., diagnostic analyzers or transport devices). Such constraints may include, for example, transport time, processing and transport bottlenecks, barcode errors, analyzer processing capacity, and the availability of materials and consumables. By using the reactive method for determining the workflow described herein, only currently available resources are scheduled for use, while ensuring that the schedule is as flexible as possible to respond to new (and potentially urgent) samples and test instructions that may arrive in the laboratory.

[0089] The following diagram provides further details on how the workflow and distribution of biological samples are determined in this manner.

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

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

[0092] The Workflow Planning Manager 2 is communicatively connected to each diagnostic analyzer 8n and transport device 6. The Workflow Planning Manager 2 (e.g., regulator, planning components, planning module, central controller, etc.) is configured to oversee all devices in System 1 (e.g., pre-analysis / post-analysis devices, diagnostic analyzers 8n, transport device 6, etc.), as well as all sample tubes available at any given time within System 1. As described herein, the Workflow Planning Manager 2 is configured to run a planning algorithm based on constraint programming and to run a predictive model used to calculate the optimized distribution of samples to the diagnostic analyzers 8n at a given time, called a workflow, based on historical data collected from the laboratory.

[0093] In this example, System 1 comprises 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 configured to provide an interface between one or more diagnostic analyzers 8n and Workflow Planning Manager 2. As shown in Figure 3, each analyzer interface module 10n may be connected to one or more diagnostic analyzers 8n. Alternatively, each analyzer interface module 10n may form part of the 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 separate component from the diagnostic analyzer 8n, for example, as software running on a central server and connected to one or more diagnostic analyzers 8n.

[0094] In this specification, the term “module” is used to refer to a functional module configured or adapted to perform a particular function. Modules may be implemented in hardware (i.e., they may be separate physical components within a computer), software (i.e., they may represent separate sections of code that, when executed by a processor, cause a processor to perform a particular function), or a combination of both.

[0095] The workflow planning manager 2 is configured to receive multiple requests (e.g., test instructions) that require analytical tests to be processed by system 1, with each analytical test corresponding to a biological sample. Incoming biological samples are stored in racks within the sample buffer 4 until they are transported by transport device 6 to one of the diagnostic analyzers 8n.

[0096] The workflow planning manager 2 is configured to negotiate with one or more diagnostic analyzers 8n to agree on a workflow that includes one or more runs of the requested tests, and then instruct the transport device 6 to transport the biological samples to the diagnostic analyzers 8n to process the agreed-upon runs. Each diagnostic analyzer 8n is configured to perform local optimization of the proposed runs based on the filled samples, consumables, reagents, and other resources present within the analyzer 8n to generate a locally optimized run schedule. The runs may (or may not) be performed according to the locally optimized run schedule.

[0097] Importantly, the Workflow Planning Manager 2 is configured to continuously renegotiate and redetermine the planned run when additional samples and test instructions arrive at System 1 or when the status of the Diagnostic Analyzer 8n changes. Thus, System 1 can react to and adapt to changing circumstances and determine a more efficient workflow than existing solutions for processing test instructions, without requiring prior knowledge of which test instructions will be requested in advance.

[0098] Figure 4 shows a flowchart of the process for coordinating the distribution of biological samples in System 1. This process may be carried out by the Workflow Planning Manager 2 in Figure 2. The following steps can be separated into two stages: a planning stage in which a proposed run is prepared based on the information available in System 1, and then an execution stage in which the Workflow Planning Manager 2 negotiates the proposed run with the analyzer 8n and manages any unpredictable events that may occur before the execution of the proposed run begins.

[0099] First, in step S100, the workflow planning manager 2 receives multiple requests for analytical testing. These requests may be called test instructions, and each test instruction includes an identifier for the biological sample, specifications for one or more processes to be performed on the biological sample, and optionally, a target TAT for the test instruction.

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

[0101] In addition to the requested tests, the workflow planning manager 2 can also access information including the number of tests per received test type, the target TAT for each test, and compatibility information indicating which tests are compatible with each other and can be run in the same run by the same diagnostic analyzer 8n. 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 run. Thus, the workflow planning manager 2 can use this information to build a proposed run and select one or more candidate diagnostic analyzers 8n to which the proposed run will be sent.

[0102] Whenever a change in System 1 is detected, such as a new sample reaching sample buffer 4, a change in the priority of test instruction changes, the addition or deletion of test instructions for a sample, or a change in the status of one or its diagnostic analyzer 8n (e.g., on / off, run start, run end), the 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 may also be performed periodically, for example, after a predetermined number of minutes have elapsed since the last proposed run was determined.

[0103] Next, in step S104, the proposed run is sent to one or more candidate diagnostic analyzers 8n (for example, by sending the proposed run to the interface module 10n of the candidate diagnostic analyzer 8n).

[0104] Next, in step S106, the candidate diagnostic analyzer 8n receives predictive run filling information from the candidate diagnostic analyzer 8n. The predictive run filling information includes instructions on which of the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer 8n. For example, the predictive run filling information may take the form of alternatives (e.g., opposing proposals, additional / alternative proposed runs, modified proposed runs).

[0105] Next, in step S108, the workflow planning manager 2 reviews the predicted run completion information and decides whether to proceed with or reject the proposed run based on the predicted run completion information and the results of the optimization check process. Therefore, proceeding with the proposed run may include accepting the proposed run with modifications as necessary, taking into account the predicted run completion information.

[0106] Deciding whether to proceed with or reject a proposed run according to the optimization check process involves comparing predicted run filling information with predetermined acceptance criteria, such as whether the run is sufficiently full (for example, by determining whether a threshold percentage of proposed runs can be filled by candidate diagnostic analyzers 8n), whether there are samples and / or requested tests in a proposed run designated as urgent, and whether those samples and / or requested tests can be filled by candidate diagnostic analyzers, and / or whether the estimated time at which the run can be started is fast enough to meet the target TAT for the requested tests in the proposed run. If each (or one or more) of the acceptance criteria is 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.

[0107] If the proposed run is to proceed, the workflow planning manager 2 proceeds to step S110, where the workflow planning manager 2 signals the transport device 6 to transport some or all of the biological samples specified in the proposed run to the candidate diagnostic analyzer. For example, the transport device 6 may be instructed to transport each biological sample specified in the proposed run to the candidate diagnostic analyzer 8n, or it may be instructed to transport only the biological samples specified in the prediction run fill data (e.g., the biological samples specified in the proposed run that the candidate diagnostic analyzer 8n is instructed to process).

[0108] In particular, the diagnostic analyzer 8n will not execute the proposed run until it has received all the samples specified in the agreed run or confirmation instructions from the workflow planning manager 2. In this way, if an unexpected event occurs when sending samples to the candidate analyzer 8n (for example, if not all samples arrive on time due to a bottleneck or barcode reading error), the workflow planning manager 2 can update the workflow by deciding whether to immediately execute the run with the samples that have arrived, discard the run, or wait for the samples to arrive before executing the run.

[0109] If the proposed run is rejected, the workflow planning manager 2 proceeds to step S112 to determine an alternative proposed run (including a different selection of the requested tests) or to send the proposed run to an alternative candidate diagnostic analyzer 8n. Determining an alternative proposed run can be considered as returning to the beginning and repeating the process in Figure 4.

[0110] Figure 5 shows a flowchart of the process for determining the proposed run according to the workflow optimization method. As mentioned above, this process is sometimes called the planning stage S200, which is performed before the execution stage S300. The workflow optimization method includes three algorithms for selecting the requested tests to be submitted to the proposed run. The three algorithms are executed according to the following flow.

[0111] In step S302, the OaP (Override and Process) selection algorithm is used to select test instructions for one or more proposed runs. This algorithm is executed only when one or more types of tests need to be performed in the next immediate run, triggered by a specific action from the user, such as when the laboratory is at the end of a shift. Test selection is based on their TAT, and if two or more tests have the same TAT but one of them is indicated as urgent, the latter is selected first.

[0112] When the OaP state is triggered (for example, by a user), the OaP selection algorithm is used, and one or more runs are initiated until the set of test instructions instructed by the user is processed. The system remains in OaP until all of that set of test instructions has been processed in a more immediate run, according to the user's request. Therefore, the session in which the OaP selection algorithm is used is not limited to a single run, but extends to as many runs as necessary to process the user test type selected for OaP processing.

[0113] If there is not enough sample to set up a full run, the filling algorithm in step S206 (described below) is executed in the run-filling trial. Alternatively, if the proposed run is full but still contains samples affected by OaP, the proposed run is sent to the candidate analyzer, the OaP selection algorithm remains activated, and the workflow planning manager 2 continuously creates additional proposed runs until the OaP condition (triggered by the user) ends.

[0114] Alternatively, if the OaP selection algorithm is not activated by the user, the workflow planning manager determines the proposed run according to the emergency run selection algorithm in step S204.

[0115] The purpose of the emergency selection algorithm is to set up runs containing requested tests that need to be executed immediately, otherwise their target TATs may not be met. This algorithm is a mathematical optimization algorithm based on mixed-integer programming (MIP). The algorithm selects only tests that fall within a predefined planning period (e.g., 4 hours). That is, requested tests whose relevant target TATs fall within the planning period are selected. The emergency selection algorithm may also be used to determine multiple proposed runs to correspond to each of the requested tests whose target TATs fall within the planning period, each run being allocated to a candidate analyzer 8n, and the time each run should be executed is such that it satisfies the target TATs of the tests in the run.

[0116] Additionally, the MIP algorithm of the emergency selection algorithm can optionally be used to determine the selected analyzer for performing the proposed run.

[0117] The emergency run selection algorithm is configured to delay the execution of each proposed run as much as possible while still meeting the target TAT for the tests in the run. The advantage of this is that it provides visibility into additional requests for tests and biological samples that arrive within System 1 (e.g., within the buffer). For the responsive operation of the workflow planning manager, this means that more pending tests may be received, thus increasing the likelihood of creating a fully optimized run.

[0118] After submitting to a 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 submitted to additional requested tests according to the fill algorithm in order to fill the run. If the run is already full, the workflow planning manager 2 proceeds directly to the execution phase S300, where the proposed run is negotiated with one or more diagnostic analyzers 8n before being executed or rejected.

[0119] The fill algorithm can be triggered after the execution of the OaP algorithm or the emergency run algorithm, or independently of whether the previous algorithm proposed a run. For example, if OaP is not triggered by the user and there are no requested tests with imminent deadlines (i.e., emergency tests), the workflow planning manager may proceed directly to the fill algorithm to determine the proposed run.

[0120] The filling algorithm is configured to update the runs proposed by previous algorithms to be as full as possible, or, if there are no existing run proposals, to attempt to create a full run that includes only filling tests (e.g., requested tests where the target TAT is not at risk). The filling algorithm is configured to select tests according to the following rules listed in order of priority: i. Minimizing co-loaded samples: Co-loaded samples are samples that are sent to analyzer 8n for test processing but are contained in racks for which no tests are performed. Such samples visit analyzer 8n and are then returned to buffer 4 after the run has run. Therefore, the time spent by such samples in analyzer 8n is downtime because the samples cannot be allocated to another run until they are returned to the buffer. Accordingly, the workflow planning manager is configured to load each proposed run with requested tests for which the samples are located in the same rack that is about to be sent to analyzer 8n, thus reducing the presence of co-loaded samples. ii. Requested tests with imminent deadlines: Potential tests to be included in the run are sorted according to their associated target TAT, for example, from the earliest deadline to the furthest deadline, and allocated to the proposed run. iii. Tie-break: Next, tests may be used to introduce each of those biological samples into the proposed run according to their arrival time in System 1 (for example, according to their arrival time in Buffer 4).

[0121] In addition, each of the selection algorithms in steps S202-S206 may also consider one or more of the following factors. -STAT (Short Turnaround Time) samples: Corresponds to those that need to be run urgently and therefore have a shorter TAT than other tests of the same type. The algorithm focuses on meeting the TAT, but the algorithm must select between two samples with the same remaining TAT, but in the case of a competition where one of them is designated as STAT (e.g., Urgent), the latter will be selected first. - Test suitability: Workflow Planning Manager 2 (which implements one of the selection algorithms described above) is configured to take into account that there are types of tests that cannot be run together in the same run.

[0122] Prioritizing when a test deadline has already passed: If a requested test deadline has already passed and its target turnaround time (TAT) has already been exceeded, Workflow Planning Manager 2 (which implements one of the selection algorithms described above) is configured to prioritize selecting the test that has been due the longest. For example, if one test is due two hours ago and three other tests are due one hour ago, Workflow Planning Manager 1 is configured to first select the test that is two hours ago.

[0123] Figure 6 shows a flowchart of the process for verifying and agreeing on a proposed run between the workflow planning manager 2 and the diagnostic analyzer 8n, and deciding whether or not to proceed with the proposed run. This part of the process may be referred to as execution phase S300, as described above.

[0124] First, in step S302, the workflow planning manager 2 is configured to validate the proposed run to determine whether the proposed run is appropriate before negotiating with the candidate diagnostic analyzer 8n.

[0125] Figure 7 outlines the process for validating the proposed run. As shown in Figure 7, validating the proposed run involves determining whether the proposed run is urgent or full.

[0126] An emergency run may be a run that includes tests that must be performed now, otherwise their target TAT will not be met. For example, an emergency run may be a proposed run output by the emergency run selection algorithm described above for Figure 5.

[0127] Determining whether a proposed run is full may involve comparing the number of requested tests and / or samples in the proposed run with the target number of samples. The target number of samples may be the maximum capacity of the run or a specific percentage of the maximum capacity, the maximum capacity being based, for example, on the capacity of system 1, the rack size, and the diagnostic analyzer 8n. For example, the maximum number of samples a run may contain may be 96, and a run may be considered full if it contains at least 96-x samples, where x may be, for example, 5 to 20 samples.

[0128] The target number of samples to be filled may be relaxed (i.e., reduced) at the end of the shift, for example, before scheduled laboratory downtime. At this point, new samples and requested tests may stop arriving, and therefore the workflow planning manager 2 may stop prioritizing the scheduling of full runs, as this may not be possible at the end of the shift.

[0129] If a proposed run is determined to be full or urgent, it can be successfully validated and negotiated with analyzer 8n. However, if a proposed run is determined to be neither full nor urgent, it is discarded. The laboratory may operate more efficiently by accepting unfilled runs only in urgent cases. For example, non-urgent runs may be delayed until enough test instructions come in to fill them, or runs may be recalculated to include more test instructions.

[0130] Returning to Figure 6, once the proposed run is successfully validated, the workflow planning manager 2 proceeds to step S304 to negotiate with one or more diagnostic analyzers 8n for the valid and validated proposed run. The negotiation involves sending the proposed run to the candidate diagnostic analyzers 8n for evaluation, as described above for steps S104-S106 in Figure 4, and in response, receiving predicted run fill information from the candidate analyzers 8n.

[0131] To negotiate a proposed run, the workflow planning manager 2 is first configured to select one of the diagnostic analyzers 8n as a candidate analyzer 8n. If the proposed run was the output of an emergency run algorithm, the analyzer 8n that the run needs to run on may be known and selected as a candidate analyzer 8n. Otherwise, for example, if the proposed run was the output of a fill algorithm, the workflow planning manager 2 searches for the most suitable of the available diagnostic analyzers 8n. In this example, the workflow planning manager 2 evaluates all available diagnostic analyzers 8n that can accept the run and looks for one that has the necessary reagents installed to run the proposed run. From these, the workflow planning manager 2 is configured to select the diagnostic analyzer 8n that has been idle the longest as a candidate analyzer 8n. The purpose of this is to distribute the load of diagnostic analyzers 8n within system 1.

[0132] After selecting a candidate analyzer 8n, the workflow planning manager 2 is configured to send the proposed run to the candidate analyzer 8n, for example, via the interface module 10n of the candidate analyzer 8n. The candidate analyzer 8n is then configured to perform a local optimization process to determine whether each of the tests in the proposed run can be performed based on different factors, such as the following: 1) If sufficient reagents are available; 2) If additional QC (Quality Control) steps and samples are required to perform the proposed run; QC is included in runs that occupy one or more of the 96 positions that the run may have, depending on the instrument. Generally, QC may be required once every 24 hours for each test type, but this requirement can be adjusted by the user. The workflow planning manager does not have knowledge of whether QC is required in a run. For example, the workflow planning manager may propose a run that includes 96 test instructions and samples. Candidate analyzer 8n may propose, for example, that only perform 94 of the proposed tests because two of the positions in the run must be assigned to QC. 3) Ensure that different types of tests in the proposed run comply with the analyzer-specific requirements; the number of tests per test type in the run may need to be performed in pairs. Thus, if the proposed run includes five positions assigned to a certain type of test, six positions in the run may be reserved by the candidate analyzer for this test type. 4) If each test in the proposed run is compatible with the run on the same diagnostic analyzer 8n.

[0133] If the candidate diagnostic analyzer 8n is unable to perform all the requested tests included in the proposed run, the candidate diagnostic analyzer 8n also considers the priority of each requested test (e.g., their target TAT, with the earliest having the highest priority). In this case, the candidate diagnostic analyzer 8n sends a counter-proposal (e.g., in the form of predicted run fill information) to the workflow planning manager 2, which includes the requested tests that can be performed, the requested tests that cannot be performed and the reasons why, and a predicted run start time that indicates when the candidate analyzer 8n may next be available to perform the proposed run.

[0134] Next, the workflow planning manager 2 proceeds to step S306, where it determines whether to accept (e.g., proceed with) the proposed run based on the predicted run filling information from the candidate analyzer 8n.

[0135] To determine whether to proceed with the proposed run, the workflow planning manager 2 is configured to determine from the predicted run filling information whether a threshold percentage of the requested tests in the proposed run can be performed by the candidate analyzer 8n. For example, the threshold may be 90% of the proposed tests. Additionally, the workflow planning manager 2 is configured to determine whether the predicted run start date and / or time falls within the threshold deviation of the predicted start date and / or time determined by the workflow planning manager 2 when the proposed run was decided. If the above conditions are met, the workflow planning manager 2 is configured to proceed to step S308 and signal the transport device 6 to begin transferring the biological samples necessary to perform the proposed run to the candidate analyzer 8n.

[0136] However, if the workflow planning manager 2 determines that the predicted run fill information differs too much from the initial proposed run, for example, because one or more of the above thresholds are not met, further action is required. The further action that the workflow planning manager 2 can take depends on the root cause of the unfilled area determined by the candidate analyzer 8n. For example, the following root causes and further actions may be determined:

[0137] Cause: Reagent or QC is locked or missing: This could be because candidate analyzer 8n (which may be capable of running two runs in parallel) has locked the reagent cassette required for a specific test in the proposed run in order to run a different run that is already running. In other cases, QC material may be missing in the candidate analyzer, and therefore a specific test cannot be performed.

[0138] Action 1) If one or more affected tests are urgent, the Workflow Plan Manager 2 shall rerun the plan by recording that the test type is not available on its analyzer 8n and by redetermining alternative suggested runs and / or by selecting alternative candidate analyzers.

[0139] Action 2) If there are no urgent tests affected, Workflow Planning Manager 2 runs the filler selection algorithm again to remove any requested tests that cannot be performed from the proposed run and generate a new proposed run.

[0140] Cause: The diagnostic candidate analyzer 8n is unavailable or its capacity has decreased.

[0141] Action: In this case, the workflow planning manager 2 is configured to remove this analyzer 8n from the list of available analyzers 8n, then re-evaluate the proposed run and re-select a candidate analyzer 8n.

[0142] Cause: The reagent cassette needs to be replaced.

[0143] Action: In this case, Workflow Planning Manager 2 is configured to accept the proposed run and proceed.

[0144] When the workflow planning manager 2 decides to proceed with the proposed run, it instructs the transport device 6 to transfer the sample to the candidate diagnostic analyzer 8n. The racks containing the sample then begin to arrive at the candidate analyzer 8n. If all racks arrive at the analyzer on time (for example, by a reserved allocation slot in analyzer 8n), the workflow planning manager 2 signals to the analyzer that it is processing the proposed run. However, if one or more racks do not arrive at analyzer 8n on time, the workflow planning manager 2 is configured to decide whether to delay, proceed with, or discard the proposed run.

[0145] Figure 8 illustrates the process of monitoring biological samples arriving at candidate diagnostic analyzer 8n and renegotiating a proposed run if a sample is not received by candidate diagnostic analyzer 8n. Samples arrive at candidate diagnostic analyzers in racks, each rack configured to contain multiple biological samples. However, if one or more of the expected racks are missing, for example, due to a barcode reading error or traffic 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.

[0146] First, if all racks containing biological samples corresponding to tests marked as urgent have reached candidate diagnostic analyzer 8n, the workflow planning manager 2 is configured to instruct candidate diagnostic analyzer 8n to perform the run. If, instead, the number of racks awaiting arrival is less than the threshold number of racks (e.g., 2 racks), it is assumed that there is a barcode error and manual user intervention is required. In this case, the run is renegotiated and performed on the samples that have reached candidate diagnostic analyzer 8n.

[0147] However, if the number of racks exceeds the threshold when candidate diagnostic analyzer 8n reaches it, the cause of the missing racks is identified as a delay caused by congestion. In this case, workflow planning manager 2 renegotiates the same run as candidate diagnostic analyzer 8n, but delays the start when the racks arrive. This renegotiation occurs only once. Therefore, if one or more samples / racks are still missing from candidate diagnostic analyzer 8n at the time the run is renegotiated (delayed), the run is discarded without being renegotiated.

[0148] Once Workflow Planning Manager 2 signals to initiate a proposed run, it continues to monitor System 1 for events such as the arrival of new test instructions, and then re-evaluates and negotiates a new proposed run as needed.

[0149] As described above, System 1 may include an analyzer interface module 10n configured to handle negotiations and communication between the workflow planning manager 2 and one or more diagnostic analyzers 8n. The interface between the workflow planning manager 2 and each diagnostic analyzer 8n operates on the basis of promise theory [2]. The following description of Figures 9 to 16 refers to this interface.

[0150] The Workflow Planning Manager 2 is the only component in System 1 that has access to the status of each diagnostic analyzer 8n and transport device 6 within System 1. Furthermore, the Workflow Planning Manager 2 is the only component in System 1 that is aware of all currently available biological samples. On the other hand, each diagnostic analyzer 8n knows (and cares for) only its internal state and status, so the Law of Demeter [1] applies, which states that objects in a system interact only with their immediate neighbors and have limited knowledge of the internal workings of other objects. This means that each diagnostic analyzer 8n cares only for the biological samples loaded (physically loaded into that analyzer 8n) and the work instructions associated with those biological samples. A diagnostic analyzer 8n is not configured to perform any processing or planning to consider biological samples that are not within its range (e.g., not physically loaded into that analyzer 8n).

[0151] Therefore, the interface module 10n operates to coordinate the information held by each component in system 1 to agree on a proposed run for processing the sample.

[0152] Figure 9 illustrates the communication exchanged between the workflow planning manager 2 (labeled "planning component") and the diagnostic analyzer 8n. Figure 9 shows a typical method of interaction between these two components in pseudo-language.

[0153] The interaction is initiated when the workflow planning manager 2 asks each diagnostic analyzer 8n how and when to schedule a proposed run if a particular set of biological samples is loaded into the diagnostic analyzer 8n before or at a given time (e.g., "virtually loaded samples"). The analyzers 8n then take on the role of executing their internal logic and evaluating their internal state, which includes knowledge of loaded consumables and resources, as well as the availability of hardware redundant components, in order to propose the allocation of the "virtually loaded samples" to each "virtual run" (e.g., candidate run schedule).

[0154] Next, each diagnostic analyzer 8n responds to the workflow planning manager 2 with a “promise” (e.g., a counter-proposal) that provides the workflow planning manager 2 with sufficient information so that the promise or offer from each other diagnostic analyzer 8n can be evaluated. For example, the promise may take the form of the predictive run filling information described above.

[0155] Workflow Planning Manager 2 may be configured to prioritize one or more optimization goals (e.g., reducing costs, e.g., QC-related costs) as described above, to improve throughput, or to reduce the total turnaround time (TAT) of all requested tests within System 1. Using the optimization goals along with historical data and predictive models, Workflow Planning Manager 2 can select the best promise (e.g., alternative) from the diagnostic analyzer to satisfy the optimization goals (e.g., according to the optimization check scheme described above).

[0156] If one promise is determined to be acceptable, the workflow planning manager 2 notifies the corresponding analyzer 8n that the promise has been accepted. At this point, the analyzer 8n must reserve and allocate the necessary resources (e.g., reagent cassettes) so that the promise can be fulfilled immediately once the agreed-upon biological sample is loaded into the selected diagnostic analyzer 8n. As described above, if a proposed run is rejected in light of the promises received from each analyzer 8n, the workflow planning manager 2 may initiate new negotiations with the diagnostic analyzers 8n using an alternative proposed run.

[0157] Figure 10 shows a flowchart of the interaction process between the diagnostic analyzer 8n and the workflow planning manager 2. This process may be carried out by one or more of the interface modules 10n shown in Figure 3. As described above, each interface module 10n may form part of the diagnostic analyzer 8n.

[0158] First, in step S400, the interface module 10n receives a proposed run from the workflow planning manager 2 as part of a request for a proposed allocation slot. The proposed run includes several requested analytical tests that will be performed by the diagnostic analyzer 8n.

[0159] Next, in step S402, the interface module 10n determines a candidate run schedule according to the resource optimization process of the analyzer 8n. The resource optimization process of the analyzer 8n is a local scheduling function performed by the candidate diagnostic analyzer 8n to determine a candidate schedule for processing a set of test instructions. Therefore, the resource optimization process of the analyzer 8n may be performed by the proprietary software of that particular diagnostic analyzer 8n, based on the specific resources, settings, and capabilities of that analyzer 8n.

[0160] Next, in step S404, the interface module 10n generates (or receives) predictive run-filling information based on a candidate run schedule (e.g., a promise or alternative). The predictive run-filling information includes at least an indication of which of the requested analytical tests in the proposed run can be processed by the analyzer 8n according to the candidate run schedule. The predictive run-filling information may also include information about the proposed allocation slots of the analyzer 8n regarding when the proposed run can next be performed according to the candidate run schedule. For example, the proposed allocation slots may be the time period during which the diagnostic analyzer 8n will next be available, and / or the time period during which the diagnostic analyzer 8n is expected to next have the necessary resources available to perform the proposed run.

[0161] Finally, in step S406, the interface module 10n sends the predicted run fill information to the workflow planning manager 2 in order to determine whether or not to proceed with the proposed run, taking the predicted run fill information into consideration.

[0162] If the Workflow Planning Manager 2 rejects a proposed run (for example, based on predicted run fill information, or because a new test instruction has been received and triggered a recalculation of the proposed run), or if the Workflow Planning Manager 2 chooses to proceed with the proposed run using another diagnostic analyzer 8n, the process may terminate there until another proposed run is received.

[0163] However, if the workflow planning manager 2 decides that the proposed run should proceed, the interface module 10n is configured to reserve the proposed allocation slot of the analyzer 8n for the proposed run and to arrange for the diagnostic analyzer 8n to perform the proposed run in that slot.

[0164] Figure 11 shows a flowchart of further process steps for interface between the diagnostic analyzer 8n and the workflow planning manager 2 when the proposed run is being performed. Thus, the process in Figure 11 may be performed after the process in Figure 10. Similar to Figure 10, the process in Figure 11 may be performed in part or in whole by an interface module that runs middleware and communicates with the diagnostic analyzer 8n, or by the diagnostic analyzer 8n itself.

[0165] First, in step S408, the interface module 10n (or diagnostic analyzer 8n) receives confirmation from the workflow planning manager 2 that the proposed run has been accepted, taking into account the predicted run occupancy information. The confirmation may take the form of a request asking the analyzer 8n to reserve an allocation slot for executing the proposed run. The interface module 10n then reserves (or signals the diagnostic analyzer 8n to reserve) an allocation slot for the proposed run. For example, the interface module 10n may reserve a proposed allocation slot that was previously determined and proposed to the workflow planning manager 2.

[0166] The allocation of slots to proposed runs is governed by the following rules: Firstly, each analyzer 8n can receive multiple requests for allocation slots before one of the proposed slots is accepted by the workflow planning manager 2. When creating a new allocation slot, analyzer 8n does not consider previously determined but unaccepted allocation slots, but it does consider previously accepted but unrealized allocation slots. Thus, analyzer 8n is configured to avoid scheduling pending runs in the same slot in order to avoid conflicts.

[0167] Furthermore, each diagnostic analyzer 8n is configured to consider one or more of the following factors when determining and reserving allocation slots for proposed runs: - Planned maintenance window for analyzer 8n, - Performance degradation due to the unavailability of hardware redundancy modules on analyzer 8n. -Which reagent cassette is currently loaded in analyzer 8n? - How many control miniracks are currently installed in analyzer 8n?

[0168] However, the diagnostic analyzer 8n does not consider the following when allocating and reserving allocation slots: - Availability of consumables for analyzer 8n, or - Waste storage capacity in analyzer 8n.

[0169] Rather, the diagnostic analyzer 8n is configured to notify the workflow planning manager 2 of any missing resources required to run the next run (for example, a proposed run for which the next allocation slot is reserved). If the required resources are not loaded by the scheduled start time of the agreed run, the reserved allocation slot is canceled.

[0170] In addition, the following rules governing allocation slots apply: Firstly, an allocation slot is considered to be realized as soon as the execution of a proposed and accepted run begins. Additionally, the diagnostic analyzer 8n is configured to start the allocation slot (and process the planned run assigned to that slot) as soon as all agreed samples for a planned run have been received by the analyzer 8n, even if this occurs before the agreed start time of the allocation slot (assuming all resources, supplies, and necessary consumables are available in the analyzer 8n). When the workflow planning manager 2 requests an allocation slot, the diagnostic analyzer 8n (or interface module) is configured to allocate and reserve the allocation slot for only the next (and only) possible run. An allocation slot is never allocated to (for example, not reserved for) two or more proposed runs.

[0171] Once an allocation slot is reserved for a proposed run, the process in Figure 10 proceeds to step S412, in which the diagnostic analyzer 8n (and / or interface module 10n) determines whether the current stock of consumables in the diagnostic analyzer 8n is sufficient and / or whether sufficient waste storage is available in the diagnostic analyzer 8n in order to perform the proposed run within the reserved allocation slot. If there is sufficient stock 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, in which a signal is sent to the workflow planning manager 2 requesting that the consumables be replenished and / or the waste storage be emptied.

[0172] 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 performing a different previously scheduled run, running a maintenance routine, or in an idle state. During this waiting period, the transport device 6 is operated to transport the biological sample specified in the proposed run to the diagnostic analyzer 8n. The diagnostic analyzer 8n arrives, records and counts the biological sample loaded into the diagnostic analyzer 8n.

[0173] Next, in step S418, at the start time of the reserved allocation slot, the interface module 10n sends the count of the received biological samples to the workflow planning module. The interface module 10n may also send the ID numbers of the received biological samples.

[0174] Next, as described above, the workflow planning module 2 decides whether to proceed (or not) based on the count of received biological samples. For example, if all biological samples have arrived, the workflow planning manager 2 may proceed. However, if biological samples are missing due to, for example, a bottleneck in system 1, a barcode reading error, or a hardware failure, the workflow planning manager 2 may decide, based on the count and which biological samples have arrived, whether to cancel or delay the reserved allocation slot, or to proceed with the proposed run in the reserved slot using only the received biological samples.

[0175] Therefore, in step S420, the interface module 10n checks whether a workflow instruction has been received from the workflow planning manager 2 confirming that the proposed run should be started.

[0176] If a workflow instruction is received, the interface module 10n proceeds to step S422, signaling the diagnostic analyzer 8n to perform the proposed run (e.g., according to the candidate run schedule) using the received biological sample. However, if no workflow instruction is received (e.g., within a predetermined time limit after the start time of the reserved slot), or if a cancellation instruction is received instead, the interface module 10n proceeds to step S424, canceling the reserved allocation slot. All subsequent reserved slots already allocated for periods after the reserved allocation slot are also canceled so that they can be renegotiated. This is because subsequent allocation slots are calculated under the assumption that the current allocation slot will be realized. If this is not the case, the assumptions made in those calculations may fall apart, and therefore, the inventors have found it more efficient to redetermine all proposed runs and allocated slots based on all available actual resources and unprocessed test instructions.

[0177] The additional behavioral rules followed by the analyzer interface module 10n include the following: - If there is a sample barcode reading error, the diagnostic analyzer 8n will still load the rack. The allocation slot may be canceled because no work instructions were received from the planning module at the time the rack could be unloaded again. -If a connection to Workflow Planning Module 2 is not available before a Workflow Instruction is received, the accepted allocation slots cannot be held, and the scheduled runs for those slots will not be executed. However, if a work instruction is received from Workflow Planning Manager 2 before the connection to Workflow Planning Module 2 is lost (for example, after all biological samples corresponding to the run have reached Diagnostic Analyzer 8n), the run will be executed. - If a rack is accepted or loaded onto analyzer 8n and none of the biological samples in that rack are part of a distribution slot (e.g., one that needs to be processed in a scheduled run), the rack is immediately unloaded and returned to buffer 4. However, as an exception to this rule, if one or more of the samples in a rack are scheduled to be used in a run that was not performed (e.g., part of an unfilled distribution slot), the rack is held for a certain period (e.g., 5 minutes).

[0178] Figures 12-15 are flowcharts illustrating communication between the workflow planning manager 2, the diagnostic analyzer 8n, and the transport device 6. These diagrams show examples of specific commands and data sent between the workflow planning manager 2 and the diagnostic analyzer 8n during the above interaction.

[0179] Figure 12 shows a workflow planning manager 2 requesting an allocation slot to perform a proposed run (i.e., GetAllocationSlotProposal) and a diagnostic analyzer 8n responding with a proposed allocation slot. The workflow planning manager 2 is configured to request an allocation slot from each available diagnostic analyzer 8n (which can process a specific test in a proposed run). Each diagnostic analyzer 8n then performs internal logic to determine a candidate run schedule that includes a proposed allocation slot defining a time period for performing the proposed run, taking into account the loaded reagent cassette, the availability of hardware redundant modules, and predetermined control rules. The proposed allocation slot is sent to the workflow planning manager 2 (i.e., AllocationSlotProposal) as, for example, part of the predicted run filling information described above.

[0180] The GetAllocationSlotProposal message includes a list of sample containers, and for each sample container, it includes 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 to the diagnostic analyzer 8n.

[0181] The AllocationSlotProposal message may include the following: - Allocation slot identifier, - Allocation slot expiration time (indicates how long an allocation slot remains valid before it expires if it is not accepted or rejected by the workflow planning manager), - The sample group includes a list of sample test instruction identifiers assigned to the sample group, a list of newly added controls (only if new controls need to be used), an estimated time when processing may begin, and a delta time indicating when results may become available.

[0182] A list of unscheduled sample test instructions, including the sample test instruction identifier and the reason why each identified sample test instruction was not scheduled in the candidate run schedule.

[0183] Allocation slot suggestions (e.g., predicted run filling information) are not permanently stored in the diagnostic analyzer 8n. Therefore, only the workflow planning module 2 has knowledge of each different allocation slot suggestion from each diagnostic analyzer 8n and selects the most appropriate of the suggested slots to execute the suggested run. As described above, if none of the suggested allocation slots are determined to be appropriate, the workflow planning manager 2 is configured to request a new suggestion from the analyzer 8n(s).

[0184] However, if the workflow planning manager 2 decides to accept the proposed allocation slot and proceed with the proposed run, it reserves the proposed allocation slot by sending a command to the relevant analyzer 8n.

[0185] Figure 13 shows a flowchart of the communications involved in reserving a proposed allocation slot.

[0186] First, Workflow Planning Manager 2 sends a ReserveAllocationSlot command containing the following data: -Target equipment (e.g., candidate diagnostic analyzer 8n rather than the accepted allocation slot proposed) - Proposed allocation slot identifier

[0187] For each sample container, a list of instructions is provided, including the sample ID (e.g., barcode), the test(s) to be performed on that sample container, test information including the test code (e.g., USI), the test priority status, the latest estimated time to arrive, and the latest run start time.

[0188] Next, the diagnostic analyzer 8n responds with an acknowledgment message (ReserveAllocationSlotAck) and a subsequent instruction (AllocationSlotReserved event message) indicating that the allocation slot is reserved, including the target equipment ID, allocation slot identifier, and allocation slot status. The diagnostic analyzer then sends an instruction (for example, an AllocationSlotRealization event or an AllocationSlotReservationFail event) to the workflow planning manager 2 indicating whether the allocation slot reservation was successful or not.

[0189] At some point, the workflow planning manager operates the transport device 6 to transport the biological samples (organized in the RD5 rack) to the diagnostic analyzer 8n that has reserved an allocation slot. As described above, in relation to Figure 8, the diagnostic analyzer 8n is configured to notify the workflow planning manager 2 of the arrival of the biological samples and any biological samples that 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 returns the responsibility to the workflow planning manager 2 to determine what to do next with the samples, as some of the samples may have already arrived at the analyzer 8n. As described above in relation to Figure 8, the workflow planning manager 2 is configured to decide whether to renegotiate or delay the proposed run depending on which samples have arrived at the analyzer 8n.

[0190] Figure 14 shows a sequence diagram of this interaction.

[0191] First, a SampleLoaded event containing the sample container ID (e.g., sample tube barcode) is sent from analyzer 8n to workflow planning manager 2. In particular, if all samples that need to be processed in the reserved allocation slot have arrived, the diagnostic analyzer 8n executes the proposed run. However, if one or more samples are missing, the diagnostic analyzer 8n waits until the scheduled start time of the reserved allocation slot has elapsed before sending an AllocationSlotDiscarded message to workflow planning manager 2 indicating that the reserved allocation slot should be discarded. At this point, workflow planning manager 2 must decide how to proceed according to the method shown in Figure 8.

[0192] In some examples, a workflow planning component may want to cancel a proposed run and revoke the reserved allocation slot associated with that proposed run (for example, to renegotiate the proposed run in consideration of system changes and / or new urgent test instructions arriving at the system). This interaction is shown in Figure 15.

[0193] To cancel a reserved allocation slot, the workflow planning manager 2 first sends a command ("RevokeAllocationSlot") to the diagnostic analyzer 8n instructing it to cancel (revoke) the reserved allocation slot.

[0194] If the proposed run scheduled for that allocation slot has not yet started, the diagnostic analyzer 8n cancels the allocation slot and responds to the workflow planning manager 2 with an AllocationSlotRevoked message containing the allocation slot ID. On the other hand, if the proposed run for the reserved allocation slot has already started, the diagnostic analyzer 8n responds with an AllocationSlotRevocationNotPossible message containing the allocation slot ID and the reason why the allocation slot cannot be revoked.

[0195] Figure 16 shows a state diagram illustrating different states of the allocation slots managed by the diagnostic analyzer 8n. These states are summarized in the table below. [Table 2]

[0196] The following table summarizes the transitions between each state and the triggers that may lead to each transition. These triggers and transitions are managed locally by the diagnostic analyzer 8n (or analyzer interface module 10n). [Table 3]

[0197] 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 cooperative approach enables efficient operation without the need to expose the internal workings of each component in system 1 to one another, thereby satisfying the Law of Demeter, and its benefits include improved maintainability and adaptability of system 1 (e.g., the laboratory) and the components within the system. Because each component is less dependent on the internal workings of other components, it is easier to modify the internal workings of each component without affecting other components in system 1.

[0198] Furthermore, compared to known solutions, an advantage of the proposed solution is that the optimization method implemented by the workflow planning manager 2 and the local optimization algorithm within the analyzer 8n can be modified and developed independently. Modifying one does not require modifying the other.

[0199] In this way, the proposed solution allows for the separation of the workflow planning manager 2 and the analyzer 8n, thus providing all the advantages of a modular solution in terms of scalability, maintainability, and performance.

[0200] Features disclosed in the foregoing description, or in the following claims, or in the accompanying drawings, and expressed in particular forms therein, or with respect to means for performing the disclosed functions, or methods or processes for obtaining the disclosed results, may be used, individually or in any combination thereof, as needed, to realize the invention in its various forms.

[0201] While the present invention is described in conjunction with the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art given this disclosure. Therefore, the exemplary embodiments of the present invention described above are illustrative and not limiting. Various modifications to the embodiments described may be made without departing from the spirit and scope of the invention.

[0202] To avoid any misunderstanding, any theoretical explanations provided herein are provided solely for the purpose of improving the reader's understanding. The inventors do not wish to be bound by any of these theoretical explanations.

[0203] Any headings used herein are for organizational purposes only and should not be construed as limiting the subjects described.

[0204] Throughout this Spec., including the following claims, unless the context requires otherwise, the words “comprise” and “include,” as well as variations such as “comprises,” “is equipped,” and “include,” will be understood to mean the inclusion of the integer or step or group of integers or steps described, but not the exclusion of any other integer or step or group of integers or steps.

[0205] It should be noted that the singular forms “a,” “an,” and “the” as used herein and in the appended claims include multiple referents unless the context clearly indicates otherwise. Ranges may be expressed herein as “about” one particular value to and / or “about” another particular value. When such ranges are expressed, another embodiment includes one particular value to and / or other particular values. Similarly, the use of the antecedent “about” will be understood to mean that a particular value forms another embodiment when the value is expressed as an approximation. The term “about” with respect to numbers is arbitrary and means, for example, + / - 10%.

Claims

1. A workflow planning manager for coordinating the distribution of biological samples in an analytical system, wherein the analytical system One or more diagnostic analyzers for performing one or more tests on the biological sample, A transport device for transporting the biological sample to one or more diagnostic analyzers, Equipped with The aforementioned workflow planning manager, Receiving multiple requests for analytical tests to be processed by the system, wherein each analytical test corresponds to a biological sample, Determine a proposed run that includes at least some of the aforementioned requested analytical tests, The proposed run is transmitted to one or more candidate diagnostic analyzers of the diagnostic analyzers, Receiving predictive run filling information from the candidate diagnostic analyzer, wherein the predictive run filling information includes instructions on which of the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer. Based on the aforementioned predicted run occupancy information, a decision is made to proceed with or reject the proposed run. It is configured to do the following: If the proposed run proceeds, the workflow planning manager is configured to signal the transport device to transport some or all of the biological samples specified for the proposed run to a candidate diagnostic analyzer. If the proposed run is rejected, the workflow planning manager is configured to determine an alternative proposed run or to send the proposed run to an alternative candidate diagnostic analyzer. Workflow planning manager.

2. To determine the proposed run, Selecting multiple tests from the requested tests according to the workflow optimization method, The selected tests are to be included in the proposed run, A workflow planning manager according to claim 1, including the following:

3. Selecting the multiple tests according to the workflow optimization method described above is The number of tests for each test type in the aforementioned required tests, The target turnaround time for each requested test, and / or Conformity between the aforementioned required tests, Based on, It is possible to process these in the same diagnostic analyzer. Having a suitable target turnaround time, Tests of the same test type, and / or The workflow planning manager according to claim 2, comprising selecting the tests to select the requested tests for the proposed run that minimize the number of co-pilot samples in the proposed run.

4. Selecting the multiple tests according to the workflow optimization method described above is First, select the required test that has been designated as urgent, Next, select the test that has the shortest target turnaround time among the requested tests, A workflow planning manager according to claim 2 or 3, including the following:

5. To determine the proposed run, Selecting a number of initial tests according to the aforementioned workflow optimization method, Next, the proposed run is filled by allocating additional tests to the proposed run to meet the target number of filled units. A workflow planning manager according to any one of claims 2 to 4, including the workflow planning manager according to any one of claims 2 to 4.

6. The aforementioned workflow planning manager, To determine the maximum delay that can be applied while still satisfying the target turnaround time associated with each of the requested tests in the proposed run, Waiting for the maximum delay before sending the proposed run to the candidate diagnostic analyzer, A workflow planning manager according to any one of claims 1 to 5, further configured to perform the following:

7. The workflow planning manager is configured to validate the proposed run before sending it to the candidate diagnostic analyzer by determining whether the proposed run is full and / or urgent. If the proposed run is determined to be full or urgent, the proposed run is sent to the candidate diagnostic analyzer. The workflow planning manager according to any one of claims 1 to 6, wherein if the proposed run is determined to be neither full nor urgent, the proposed run is discarded.

8. The aforementioned workflow planning manager, Detecting system changes, In response to the detection of the aforementioned system change, the proposed run is determined, It is further configured to do the following: The aforementioned system change, A new biological sample reaches the system. The requested test may be added to the aforementioned multiple requested tests, or removed from the aforementioned multiple requested tests, or The operating status of one of the diagnostic analyzers is updated. It can be detected in response to one or more of the following: A workflow planning manager according to any one of claims 1 to 7.

9. The workflow planning manager according to claim 8, further configured to repeatedly determine a new proposed run in response to the detection of a system change until each of the requested tests among the plurality of requested tests has been performed.

10. The workflow planning manager is configured to send the proposed run to multiple candidate diagnostic analyzers and to receive predicted run fill information from each of the multiple candidate diagnostic analyzers. Deciding whether to proceed with or reject the proposed run includes analyzing the respective predictive fill information from each diagnostic analyzer. The workflow planning manager according to any one of claims 1 to 9, wherein advancing the proposed run includes selecting one of the candidate diagnostic analyzers for executing the proposed run based on the respective predicted run filling information.

11. To decide whether to proceed with or reject the aforementioned proposed run, This includes comparing the predicted run filling information with the pass / fail criteria, wherein the pass / fail criteria are The threshold percentage of the required test in the proposed run, which can be filled by the candidate diagnostic analyzer, Whether there are any tests required in the proposed run that has been designated as urgent, and whether the required tests that have been designated as urgent can be performed by the candidate diagnostic analyzer, and / or Target time to initiate the proposed run A workflow planning manager according to any one of claims 1 to 10, comprising one or more of the following:

12. If the proposed run proceeds, the workflow planning manager will: The candidate diagnostic analyzer receives a transport update indicating which of the biological samples has reached the candidate diagnostic analyzer. A workflow planning manager according to any one of claims 1 to 11, further configured to send a signal to the diagnostic analyzer instructing whether to execute the proposed run, discard the proposed run, modify the proposed run, or delay the proposed run based on the transport update.

13. Detecting the end of a shift condition indicating that no further requested tests have come in, In response to the detection of the end of the shift condition, reduce the pass / fail criteria for deciding whether to proceed with or reject the proposed run, and / or lower the target number of runs required to complete the proposed run. A workflow planning manager according to any one of claims 1 to 12, further configured to perform the following:

14. A computer implementation method for adjusting an analytical system for analyzing biological samples, wherein the system is One or more diagnostic analyzers for performing analysis, each of which is equipped with an analyzer programming module for operating the diagnostic analyzer, A transport device for transporting the biological sample to one or more diagnostic analyzers, A workflow planning manager for executing the aforementioned computer implementation method, The computer implementation method comprises, Receiving multiple requests for analytical tests to be processed by the system, wherein each analytical test corresponds to a biological sample, Determine a proposed run that includes at least some of the aforementioned requested analytical tests, The proposed run is transmitted to one or more candidate diagnostic analyzers of the diagnostic analyzers, Receiving predictive run filling information from the analyzer programming module of the candidate diagnostic analyzer, wherein the predictive run filling information includes instructions on which of the requested analytical tests in the proposed run can be processed by the candidate diagnostic analyzer. Based on the aforementioned predicted run occupancy information, a decision is made to proceed with or reject the proposed run. If the proposed run proceeds, the transport device will be signaled to transport some or all of the biological samples specified for the proposed run to a candidate diagnostic analyzer. If the proposed run is rejected, determine an alternative proposed run or send the proposed run to an alternative diagnostic analyzer. Computer implementation methods, including those mentioned above.

15. A computer-readable medium that, when executed by a computer, includes instructions causing the computer to execute the computer implementation method described in claim 14.

Images