Method and apparatus for generating a physical layout for an automated laboratory diagnostic system

Abstract

A system and method for generating an optimal physical layout for an automated laboratory diagnostic system can include generating a tentative physical layout based on laboratory requirements, simulating sample testing within the automated laboratory diagnostic system using the tentative physical layout, iterating the generation of the tentative physical layout in response to the simulation not meeting one or more laboratory goals, and outputting a final physical layout in response to the simulation meeting the laboratory requirements and the one or more laboratory goals. Numerous other aspects are also provided.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 385,400, filed November 29, 2022, entitled "METHODS AND APPARATUS FOR GENERATING PHYSICAL LAYOUTS OF AUTOMATED LABORATORY DIAGNOSTIC SYSTEMS," the disclosure of which is incorporated herein by reference in its entirety for all purposes.

[0002] The present disclosure relates to generating a physical layout for an automated laboratory diagnostic system. [Background technology]

[0003] Automated laboratory diagnostic systems, such as the Atellica® Solution available from Siemens Medical Solutions USA, Inc., Malvern, Pennsylvania, can be used to perform clinical chemistry / measurement tests or analyses on biological fluid samples, such as urine, serum, plasma, interstitial fluid, and cerebrospinal fluid, to identify analytes or other components therein. Such systems can be designed to process multiple samples simultaneously. For example, in large reference laboratories where multiple such systems can be connected by a laboratory automation network (e.g., Aptio® Automation FlexLab, also available from Siemens), the number of samples present on the system at any given time can reach hundreds or even thousands. These samples can be contained in sample containers (e.g., blood collection tubes), which are loaded onto sample carriers and transported into the automated laboratory diagnostic system. One or more reagents can be added to the biological fluid sample, and the resulting measurement or test reaction can produce various changes in the sample that can be detected and / or manipulated to determine the concentration of analytes or other components present in the sample.

[0004] An automated laboratory diagnostic system typically includes: a plurality of sample carriers configured to receive sample containers containing the biological fluid samples to be analyzed; a plurality of modules for pre-processing, analyzing, and post-processing the biological fluid samples; and a sample transport system including hardware such as movable tracks configured to move the sample carriers throughout the automated laboratory diagnostic system.

[0005] The modules of an automated laboratory diagnostic system can perform automated analytical sample preparation and handling operations, such as sorting, batch preparation, centrifuging sample containers to separate sample components, and removing caps to facilitate sample access. These modules can include, for example, sample handling handlers, centrifuges, quality assurance modules, decappers, heaters, aspiration / dispensing modules, and storage and / or refrigeration modules. These modules can also include various analyzers, such as, for example, clinical chemistry analyzers, immunoassay analyzers, and molecular testing analyzers. An automated laboratory diagnostic system can include multiple modules of the same or similar types, thereby enabling the system to efficiently process / analyze multiple samples in parallel and / or have multiple identical modules configured differently (e.g., pre-loaded with different reagents) perform the same type of analysis / test on different biological fluid samples, without having to reconfigure the module each time a different type of biological fluid sample is tested / analyzed by that module.

[0006] After an operator places a biological fluid sample (contained in a sample container) into the sample handling module of an automated laboratory diagnostic system, the sample container is automatically placed into a sample carrier. The sample container can have a machine-readable label (e.g., a barcode label), which is read by the system. The label can indicate the test / analysis to be performed on the sample and can include, for example, an accession number that can be correlated to demographic information stored in the hospital's laboratory information system (LIS) along with the test order and / or other information. In response to the information read on the sample container label, the system creates an instruction list that specifies a specific sequence of destinations (e.g., modules) based on each desired test or analysis process. These destinations can be in a specific sequence (e.g., the sample first visits the centrifuge module and then the decapper module), and time windows between destinations can be specified (e.g., the sample carrier can be scheduled to arrive at the aspiration / dispensing module within a 90-second time window from the previous decapper module). These time windows can help ensure that samples are prepared and analyzed before they deteriorate or become unusable, at which point any results obtained may be uncertain. Automated laboratory diagnostic systems can automatically handle the processing of many samples simultaneously by automatically routing each sample container loaded in a sample carrier to one or more modules via a sample transport system based on an instruction list. Summary of the Invention [Problem to be solved by the invention]

[0007] Each automated laboratory diagnostic system may have a unique and varying set of system requirements, which may include configuration parameters and physical design constraints. Automated laboratory diagnostic systems may also have various goals, which may be prioritized and may be related, for example, to system performance, associated costs, and / or supply usage. Some of these requirements and goals may include, for example, the types of tests / analyses the system can perform, the types and number of modules to be included in the system, the number of samples processed per day, etc. Because there are so many possible requirements and / or goals, determining the optimal physical layout for a given system can be difficult. In some systems, the physical layout is optimized to maximize sample throughput or sample turnaround time, while in other systems, minimizing reagent / calibration costs, the size of the system's physical footprint, or any combination thereof, may be a primary concern. Determining the "optimal physical layout" is specific to both the system's requirements and goals. Therefore, there is a need for a method and apparatus for determining the optimal physical layout of an automated laboratory diagnostic system based on a given set of system requirements and goals. [Means for solving the problem]

[0008] According to a first aspect, a method for generating a physical layout for an automated laboratory diagnostic system includes receiving, with a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload. The method also includes receiving, with the processor executing layout generation software, one or more laboratory goals and, via the processor executing the layout generation software, identifying specific types of modules and their redundancy to be included in a preliminary physical layout based on the laboratory requirements. The method further includes, via the processor executing the layout generation software, placing the specific modules in the preliminary physical layout and, based on the laboratory requirements, connecting the specific modules placed in the preliminary physical layout using a sample transport system to complete the preliminary physical layout. The method further includes simulating sample tests using the preliminary physical layout and repeating the identifying, placing, and connecting process in response to the simulation not satisfying one or more laboratory goals. The method also includes outputting, via a user interface connected to the processor, a final physical layout in response to the simulation satisfying one or more laboratory goals.

[0009] According to a second aspect, a system for generating a physical layout of an automated laboratory diagnostic system includes a computer including a processor, memory, and a user interface, with layout generation software stored in the memory. The processor executing the layout generation software is operable to receive (a) laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload, and (b) one or more laboratory goals. The processor executing the layout generation software is also operable to identify specific types of modules and their redundancy to be included in a preliminary physical layout based on the laboratory requirements. The processor executing the layout generation software is further operable to arrange specific modules within the preliminary physical layout and, based on the laboratory requirements, to connect specific modules arranged in the preliminary physical layout using a sample transport system to complete the preliminary physical layout. The processor executing the layout generation software is also further operable to: simulate sample inspections using the interim physical layout; repeat the identifying, placing, and linking in response to a simulation of a subset of inspections performed on the interim physical layout not meeting one or more laboratory goals; and output, via a user interface, a final physical layout in response to the simulation meeting one or more laboratory goals.

[0010] According to a third aspect, a method for generating a physical layout for an automated laboratory diagnostic system includes receiving, on a processor executing layout generation software, a set of predefined physical layouts for the automated laboratory diagnostic system; receiving laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload; and receiving one or more laboratory goals. The method also includes simulating a sample test using a physical layout from the set of predefined physical layouts that includes all modules required to perform the sample test. The method further includes repeating the simulation of the sample test using a physical layout from the set of predefined physical layouts that includes all modules required to perform the sample test in response to a previous simulation not satisfying the laboratory requirements and one or more laboratory goals. The method further includes outputting, via a user interface connected to the processor, the one predefined physical layout in response to the simulation of the predefined physical layout satisfying the laboratory requirements and one or more laboratory goals.

[0011] According to a fourth aspect, a method for generating a physical layout for an automated laboratory diagnostic system is provided, the method comprising receiving, at a processor executing layout generation software, a set of predefined physical layouts for the automated laboratory diagnostic system. The method also comprises receiving, at a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload. The method further comprises receiving, at a processor executing layout generation software, one or more laboratory goals. The method also comprises selecting a physical layout from the set of predefined physical layouts that includes all modules required to perform the sample tests. The method further comprises simulating the sample tests using the selected physical layout. If the laboratory requirements and one or more laboratory goals are not met, the method also comprises using a reinforcement learning or evolutionary algorithm to select a different physical layout from the set of predefined physical layouts that includes all modules required to perform the sample tests, and repeating the simulation. If the laboratory requirements and one or more laboratory goals are met by one of the predefined physical layouts, the method further comprises outputting the one predefined physical layout via a user interface connected to the processor.

[0012] Further aspects, configurations, and advantages of the present disclosure will be readily apparent from the following description and illustration of several exemplary embodiments, including the best mode contemplated for carrying out the disclosure. The present disclosure is also capable of other and different embodiments, and its several details can be modified in various respects, all without departing from the scope of the present disclosure.

[0013] The drawings described below are provided for illustrative purposes and are not necessarily drawn to scale. Accordingly, the drawings and descriptions should be regarded as illustrative in nature, and not restrictive. The drawings are not intended to limit the scope of the present disclosure in any way. [Brief explanation of the drawings]

[0014] [Figure 1-1] 1A-1C are plan views of three exemplary physical layouts of an automated laboratory diagnostic system according to one or more embodiments. [Figure 1-2] Continued from Figure 1-1. [Figure 2] FIG. 1 illustrates an exemplary automated laboratory diagnostic system capable of automatically processing multiple biological fluid samples, according to one or more embodiments. [Figure 3] FIG. 1 is a side view of a sample container that can contain a separated sample having a serum or plasma portion, according to one or more embodiments. [Figure 4] 4 is a side view of the sample container of FIG. 3 held in an upright orientation within a sample carrier that can be transported within the automated laboratory diagnostic system of FIG. 2 according to one or more embodiments. [Figure 5] 5A and 5B are top and side views, respectively, of an exemplary quality assurance module that can be used within an automated laboratory diagnostic system, according to one or more embodiments. [Figure 6] FIG. 1 is a block diagram of a computer operable to generate a physical layout of an automated laboratory diagnostic system, according to one or more embodiments. [Figure 7] FIG. 2 is a high-level operational diagram of layout generation software according to one or more embodiments. [Figure 8] 8A-8C illustrate an iterative process for generating a preliminary physical layout by a layout program of the layout generation software of FIG. 7, in accordance with one or more embodiments. [Figure 9] 9A, 9B, and 9C are diagrams illustrating three exemplary physical layouts generated by another embodiment of the layout program of the layout generation software of FIG. 7, according to one or more embodiments. [Figure 10] FIG. 1 illustrates a set of predetermined physical layouts for an automated laboratory diagnostic system, according to one or more embodiments. [Figure 11] 4 is a flow diagram of an example of an optimization process for optimizing a preliminary physical layout, according to one or more embodiments. [Figure 12] 1 is a flow diagram of an alternative optimization process for optimizing a preliminary physical layout, according to one or more embodiments. [Figure 13] 1 is a flow diagram of a method for generating a physical layout of an automated laboratory diagnostic system, according to one or more embodiments. [Figure 14] 1 is a flow diagram of another method for generating a physical layout of an automated laboratory diagnostic system according to one or more embodiments. [Figure 15] 1 is a flow diagram of another method for generating a physical layout of an automated laboratory diagnostic system according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0015] Regardless of grammatical use of the term, individuals with male, female, or other gender identities are included within the term.

[0016] The embodiments described herein include methods and apparatus for generating optimized physical layouts for automated laboratory diagnostic systems, particularly large automated laboratory diagnostic systems that process hundreds or even thousands of samples per day. As discussed above, each system has its own unique set of requirements and goals, such as the type of tests / analyses performed by the system, the types and number of modules included within the system, the available floor space in which the system will be installed, the system's expected workload, desired sample turnaround time, desired sample processing capacity, and the target purchase and / or operating costs of the system. As illustrated by physical layouts 100A, 100B, and 100C in FIGS. 1A, 1B, and 1C, respectively, automated laboratory diagnostic systems can be configured in a variety of ways based on the requirements and goals of each system. Each of the systems represented by physical layouts 100A, 100B, and 100C includes various modules 102 (only some of which are labeled) coupled to one another via a sample transport system 104. Module 102 may perform, for example, sample loading / unloading, centrifugation, sample quality check, sample characterization, decapping, aliquot preparation, clinical analysis or measurement, and sample or reagent storage / refrigeration.

[0017] Some of the factors to be considered when determining the physical layout of an automated laboratory diagnostic system include: floor plan details, including available physical space and architectural constraints (e.g., location of immovable columns), location of power sources, physical user access to the system, etc.; measurement / testing requirements; types of pre- and post-processing modules required; and various laboratory goals specific to the system, such as sample processing capacity (e.g., number of samples processed per day); sample turnaround time, reagent replacement rate, module load balancing, redundancy requirements, hardware costs, operating costs, etc.

[0018] Because many known automated laboratory diagnostic systems are modular in nature, an infinite number of physical layouts are potentially possible for each set of requirements and goals. To help simplify the physical layout process, some known systems offer a fixed set of predefined physical layouts. For example, one known system provider has 30 predefined physical layouts. However, even within a limited number of predefined physical layouts, determining which physical layout is optimal for a particular system based on all the possible requirements and / or goals described above remains a challenging task.

[0019] As an example, a physical layout may be determined by studying the operation and performance of existing physical layouts of other systems and determining the best physical layout based on trial and error and / or rules developed by highly experienced operators, or in some cases simply via intuition based primarily on anticipated / known test requirements and goals provided by the user. However, these processes are rarely exhaustive enough to yield optimal results and often result in a physical layout having more modules than necessary to meet a particular goal (e.g., processing power), thus potentially inadvertently and / or unnecessarily increasing costs associated with the system itself, its operation, maintenance, calibration, etc.

[0020] According to one or more embodiments provided herein, systems and methods for automatically generating a physical layout for an automated laboratory diagnostic system based on system requirements and goals are described below in conjunction with FIGS. 1A-15. The generated physical layout enables the system to perform desired tests / measurements and achieve all, or as many of, its desired goals while using only an optimal number of resources (e.g., modules, transport system components, etc.). In some embodiments, layout generation software executing on a computer processor can start with a "blank canvas" (i.e., no pre-determined or pre-positioned system components or layout configurations) and generate a physical layout based on the requirements and goals of the automated laboratory diagnostic system (hereinafter referred to as a "blank canvas embodiment"). In other embodiments, layout generation software executing on a computer processor can receive as input a set of pre-defined physical layouts for the automated laboratory diagnostic system along with the system requirements and goals, and select one of the pre-defined physical layouts that best meets the system requirements and goals (hereinafter referred to as a "pre-defined layout embodiment").

[0021] An embodiment of the layout generation software can include a reinforcement learning (RL) algorithm that receives system requirements and goals as input. The RL algorithm processes the received input and then outputs an optimized physical layout of the system that can be used to custom-fit an automated laboratory diagnostic system to a user's location. For example, in RL, an "agent" is trained to take "actions" within an "environment" (note that this terminology is known in the art). The agent uses a "policy" (which can also be a neural network) to take "observations" as input and output actions. In one embodiment, the observations can be goals determined through simulation of sample inspection for an initially determined (tentative) physical layout, and the outputs can be actions such as placing a new module, rotating a previously placed module, and connecting modules via components of the sample transport system (e.g., via track segments). RL also uses the concept of "rewards" to help guide the agent's learning; if an action is desirable, the learning setting associates it with a positive reward. Note that while some RL methods directly address training policy networks, other value-based methods can be used as well.

[0022] The RL environment is where the agent's behavior is evaluated. This can be done by running a simulation of a preliminary physical layout of the automated laboratory diagnostic system, as described above. The environment can use the physical layout generated by the agent (e.g., a layout program) to simulate a representative number of sample tests to be performed by the system and compare the simulation results with the system's goals. All these factors help form a reward function, which can include goals such as turnaround time (TAT) / sample throughput. The reward function can run a worklist simulation on the generated configuration to determine whether the goals (which can be weighted according to the proposed system's priorities) have been met.

[0023] RL training occurs iteratively, with the agent being trained for many "episodes." Each episode can start with a random set of sample test / system requirements and goals, for which the agent iteratively generates physical layouts while updating its weights using a reward function. An episode can be considered complete when the generated physical layout meets the requirements and goals, or after a certain timeout (i.e., the agent is unable to generate a physical layout that meets all requirements and goals within a reasonable amount of time). Eventually, with sufficient training, the agent begins to generate satisfactory physical layouts with very few iterations (i.e., the length of the episode is reduced). At this point, the policy is fixed (e.g., a neural network or similar machine learning algorithm associated with the agent's policy is fixed and weights / parameters do not change), and multiple iterations are run on the set of requirements and goals until the layout generation software generates a satisfactory physical layout. This is equivalent to running only one training episode, except that no weight updates are applied to the agent. Note that the "environment" used here is the same as that used in training (i.e., the simulation program), and the same observations from this environment are used to feed the RL agent. An example RL implementation is described in further detail below.

[0024] Other embodiments of the layout generation software may additionally or alternatively include evolutionary algorithms (EAs). As is known, EAs are particularly well suited to solving complex problems, such as generating physical layouts for automated laboratory diagnostic systems with complex requirements and goals.

[0025] 2 shows an exemplary physical layout of an automated laboratory diagnostic system 200 capable of automatically processing multiple sample containers 202 containing biological fluid samples. The following description of the components and operation of system 200 is provided to illustrate the functionally complex and potentially numerous requirements and goals that can be provided as input to layout generation software to generate a physical layout of a system having functionality and performance equivalent to system 200.

[0026] Sample containers 202 may be provided by a user and placed in one or more racks 204 located in a sample handling module 205, and then transported to and analyzed by one or more analyzer modules (e.g., first analyzer module 206, second analyzer module 208, and / or third analyzer module 210) located around the system 200. More or fewer analyzer modules may also be used in the system 200. The analyzer modules may be any number or combination of clinical chemistry analyzers, measuring instruments, etc. As used herein, the term "analyzer" refers to a device used to analyze the chemical properties or measure the presence, quantity, or functional activity of a target entity (analyte), such as DNA or RNA. Analytes commonly tested in clinical chemistry analyzers include enzymes, substrates, electrolytes, specific proteins, drugs of abuse, and therapeutic drugs. The sample container 202 can be any suitably transparent or translucent container, such as a blood collection tube, test tube, sample cup, cuvette, or other transparent or opaque glass or plastic container capable of containing a biological fluid sample and enabling imaging of the contained biological fluid sample. The sample container 202 can vary in size and can have different cap colors and / or cap types.

[0027] Referring to FIG. 3 , a biological fluid sample 312 can be provided in a sample container 302 of system 200, which is one embodiment of sample container 202 and can be a tube 315. Other sample container shapes and / or types can also be used. The sample containers can be capped by caps 314. The caps 314 can be of different types and / or colors (e.g., red, dark blue, light blue, green, gray, tan, yellow, or a combination of colors), which can indicate which test each sample container 302 is used for, the type of additives (e.g., reagents) contained in the container, whether the container includes a gel separator, whether the sample is provided under vacuum, etc. Other colors can also be used. In one or more embodiments, the cap type can be determined by a characterization method performed by system 200.

[0028] Each sample container 302 may include one or more labels 318, which may include identifying information 318i (i.e., indicia), such as a bar code, letters, numbers, or a combination thereof. Exemplary identifying information 318i may include or be associated with patient information (e.g., name, date of birth, address, and / or other personal information), tests to be performed, the date and time the sample was obtained, medical facility information, tracking and routing information, etc. (e.g., via a database in the laboratory information system (LIS) 212 shown in FIG. 2). Other information may also be included. The identifying information 318i may be machine-readable at various locations around the system 200. The machine-readable information may be darker (e.g., black) than the label material (e.g., white paper) so that it can be easily imaged. The identifying information 318i may indicate the patient's identity as well as the tests to be performed on the sample 312 or may be otherwise correlated to them via the LIS 212 or other test ordering system. Such identifying information 318i may be provided on a label 318, which may be affixed or otherwise provided on the exterior surface of the tube 315. As shown in FIG. 3, the label 318 does not extend along the entire circumference or entire length of the sample container 302, and thus, in a front view from the particular lateral direction shown, some or most of the sample 312 (e.g., serum or plasma portion 312SP) is visible (shown as a dot) and is unobstructed by the label 318.

[0029] The sample 312 can include any fluid to be tested and / or analyzed (e.g., serum, plasma, urine, interstitial fluid, cerebrospinal fluid, etc.). In some embodiments, the sample 312 can include a serum or plasma portion 312SP and a precipitated blood portion 312SB contained within a tube 315. Air 316 can be provided above the serum and plasma portions 312SP, and the boundary between them is defined as the liquid-air interface (LA). The boundary between the serum or plasma portion 312SP and the precipitated blood portion 312SB is defined as the serum-blood interface (SB). The interface between the air 316 and the cap 314 is defined as the tube-cap interface (TC). The tube height (HT) is defined as the height from the bottom of the tube 315 to the bottom of the cap 314 and can be used to determine the size of the tube (tube height). The height of serum or plasma portion 312SP is HSP, which is defined as the height from the top of serum or plasma portion 312SP at LA to the top of settled blood portion 312SB at SB. The height of settled blood portion 312SB is HSB, which is defined as the height from the bottom of settled blood portion 312SB to the top of settled blood portion 312SB at SB. HTOT is the total height of sample 312, which is equal to HSP plus HSB.

[0030] Referring again to FIG. 2 , the system 200 may include a base 216 (e.g., a frame, floor, or other structure) upon which a track 218 may be mounted. The track 218 may be a railed track (e.g., a monorail or multirail), a group of conveyor belts, a conveyor chain, a movable platform, or any other suitable type of transport mechanism. The track 218 may be circular or any other suitable shape, and in some embodiments, may be a closed track (e.g., an endless track). In operation, the track 218 may transport individual sample containers 202 via sample carriers 222 to various locations disposed about the track 218.

[0031] The sample carrier 222 may be a passive, non-driven puck that may be configured to carry a single sample container 202 on the track 218, or alternatively may be autonomous, including an on-board drive motor, such as a linear motor, that is programmed or controlled to move around the track 218 and stop at pre-programmed locations. Other configurations of the sample carrier 222 may also be used.

[0032] 4 shows a sample carrier 422, which is one embodiment of the sample carrier 222 of FIG. 2. The sample carrier 422 can include a holder 422H configured to hold the sample container 302 in a defined upright position and orientation. The holder 422H can include multiple fingers or leaf springs that secure the sample container 302 to the sample carrier 422, some of which can be movable or flexible to accommodate sample containers 202 / 302 of different sizes (widths). In some embodiments, the sample carrier 422 can move away from the sample loader / handler module 205 (FIG. 2) after receiving a sample container 202 / 302 from one or more racks 204. After pre-sorting and / or analysis of the sample in the sample container 202 / 302 is complete, the sample carrier 422 returns to the sample load / unload handler module 205 and can lower the sample container 202 / 302 into one or more racks 204 and then reload with another sample container 202 / 302.

[0033] 2, the sample loader / handler module 205 may be provided with a robot 224 that may be configured to grab a sample container 202 / 302 from one or more racks 204 and place the sample container 202 / 302 onto a sample carrier 222 / 422, which may be on an input lane of a track 218 within the sample loader / handler module 205. The robot 224 may also be configured to load the sample container 202 / 302 from the sample carrier 222 / 422 back onto one or more racks 204. The robot 224 may include one or more (e.g., at least two) robotic arms or components capable of movement in X (lateral) and Z (perpendicular to the plane of the page, as shown); Y and Z; X, Y, and Z; or r (radial) and θ (rotational). The robot 224 may be a gantry robot, an articulated robot, an R-θ robot, or other suitable robot, and the robot 224 may be equipped with robotic gripping fingers oriented, sized, and configured to lift and position the sample container 202 / 302.

[0034] When loaded onto the track 218, the sample carrier 222 / 422 carrying the sample container 202 / 302 can be transported to a first pre-treatment module 225. For example, the first pre-treatment module 225 can be an automated centrifuge configured to perform fractionation of each sample 312. The carrier 222 / 422 carrying the sample container 202 / 302 can be diverted to the first pre-treatment module 225 via an inflow lane or a suitable robot. After being centrifuged, the sample container 202 / 302 can exit onto an outflow lane or be otherwise removed by a robot and continue along the track 218. In the embodiment shown, the sample container 202 / 302 in the sample carrier 222 / 422 can then be transported to a quality assurance module 230.

[0035] The quality confirmation module 230 is configured to prescreen and perform one or more characterization methods. For example, the quality confirmation module 230 can automatically determine the presence, and possibly the extent or degree, of H, I, and / or L interfering substances contained in the sample 312, or whether the sample is normal (N). If the sample 312 is found to be free of H, I, and / or L, or to contain substantially low amounts of H, I, and / or L and considered normal (N), the sample 312 can proceed on the track 218, where it can be analyzed by one or more analyzer modules (e.g., the first, second, and / or third analyzer modules 206, 208, and / or 210). Other preprocessing operations can also be performed on the sample 312 and / or sample container 202 / 302. After analysis by one or more analyzer modules 206, 208, and / or 210, the sample containers 202 / 302 can be returned to the sample loading / unloading handler module 205 and reloaded or otherwise placed onto one or more racks 204.

[0036] In some embodiments, in addition to detecting HILN, segmentation of the sample container 202 / 302 and the sample 312 can be performed by the quality assurance module 230. From this segmented data, post-processing for quantification of the sample 312 (e.g., determining HSP, HSB, HTOT, and / or optionally determining the location of SB, LA, and / or TC) can be used. In some embodiments, characterization of the physical attributes (e.g., size—height and width (or diameter)) of the sample container 202 / 302 can be performed by the quality assurance module 230. Such characterization can include determining HT and W, and optionally TC and / or W. From this characterization, the size of the sample container 202 / 302 can be extracted. Furthermore, in some embodiments, the quality assurance module 230 can also determine the cap type, which can be used as a safety check and can indicate whether the wrong tube is being used for one or more ordered tests.

[0037] In some embodiments, a remote module 232 not directly tethered to the track 218 can be provided in the system 200. For example, an independent robot 233 (shown in dotted lines) can transport sample containers 202 / 302 containing samples 312 to the remote module 232 and return them after testing / pre-processing. Optionally, the sample containers 202 / 302 can be manually removed and returned. The remote module 232 can be used to test for specific components, such as hemolysis levels, or can be used for further processing, for example, to reduce hyperlipidemia levels with one or more additions and / or additional treatments, or to remove clots, air bubbles, or foamy material identified during characterization in the quality assurance module 230. Optionally, other pre-sorting using HILN detection methods can also be performed in the remote module 232.

[0038] Additional modules may be provided at one or more locations on or along track 218. For example, the additional modules may include a decap module, an aliquot module, one or more additional quality assurance modules 230, etc.

[0039] The system 200 may include multiple sensors 234 at one or more locations around the track 218. The sensors 234 may be used to detect the location of the sample containers 202 / 302 on the track 218, for example, by reading the identification information 218i or similar information (not shown) provided on each sample carrier 222 / 422. Any suitable means for tracking the location of the sample carriers 222 / 422 and / or sample containers 202 / 302 may be used, such as proximity sensors. All of the sensors 234 may interact with the computer 243, so that the location of each sample carrier 222 / 422 and / or sample container 202 / 302 along the track 218 may be known at all times.

[0040] The pre-processing module 225 and the analyzer modules 206, 208, and 210 may be equipped with robotic mechanisms and / or inflow lanes configured to remove sample carriers 222 / 422 and / or sample containers 202 / 302 from the track 218, and robotic mechanisms and / or outflow lanes configured to return the carriers 222 / 422 and / or sample containers 202 / 302 to the track 218.

[0041] System 200 can be controlled by computer 243, which can be a microprocessor-based central processing unit (CPU) or other suitable controller having suitable memory and suitable electronics and drivers for operating the various system components. Computer 243 can be housed as part of base 216 of system 200 or can be housed separate from base 216. Computer 243 can control movement of carriers 222 / 422 to and from sample load / unload handler module 205, movement around track 218, movement to and from first pre-processing module 225 and operation of first pre-processing module 225 (e.g., centrifuge), movement to and from quality assurance module 230, and movement to and from each analyzer module 206, 208, and 210. In some embodiments, the operations of each analyzer module 206, 208, and 210 performing various types of tests (e.g., assays or clinical chemistry) may be performed by a local workstation computer located at each analyzer module 206, 208, and 210, which is in digital communication with a computer 243, such as over a network 245, such as a local area network (LAN) or wireless area network (WAN) or other suitable communications network. In some cases, some or all of the operations of the analyzer modules 206, 208, and 210 described above may be provided by the computer 243.

[0042] Computer 243 may control system 200 according to software, firmware, and / or hardware commands or circuitry, such as those used in Dimension® clinical chemistry analyzers sold by Siemens Medical Solutions USA, Inc. of Malvern, Pennsylvania, USA. Other suitable systems for controlling system 200 may also be used. In some embodiments, control of quality assurance module 230 may also be provided by computer 243 according to embodiments described herein or another suitable computer.

[0043] Computer 243 can also be used to control the image processing and characterization methods described herein in connection with FIGS. 5A-5B (see below). Computer 243 can include, for example, a CPU or GPU, sufficient processing power, as well as RAM and suitable storage. In one example, computer 243 can be a multiprocessor-equipped PC with one or more GPUs, 8 GB or more of RAM, and a terabyte or more of storage. In another example, computer 243 can be a PC equipped with a GPU operating in parallelized mode, or possibly a PC equipped with a CPU. The Math Kernel Library (MKL) can also be used, having 8 GB or more of RAM and suitable storage.

[0044] In some embodiments, the system 200 may include a computer interface module (CIM) 247 that allows a user to easily and quickly access various control and status display screens. These control and status display screens may display and provide control of some or all aspects of multiple interrelated automated devices used in the preparation, pre-sorting, and analysis of the sample 312. The CIM 247 may be used to provide information regarding the operational status of the multiple interrelated automated devices, as well as information describing the location of the sample 312 and the status of the pre-sorting and testing that has been or is being performed on the sample 312. Thus, the CIM 247 is adapted to facilitate interaction between an operator and the system 200. The CIM 247 may include, for example, a display screen operable to display a menu including icons, scroll bars, boxes, and / or buttons that allow the operator to interact with the system 200. The menu may include multiple functional elements programmed to display and / or operate functional aspects of the automated laboratory diagnostic system 200.

[0045] 5A and 5B illustrate a quality verification module 530, which is one embodiment of the quality verification module 230 and is configured to perform the functions described above and below. The quality verification module 530 can be configured with programming instructions that, when executed by the computer 243, perform sample pre-sorting to ensure the validity of tests performed on the sample 312 contained in the sample container 202 / 302. For example, the quality verification module 530 can pre-sort with respect to container material, label condition, sample container orientation, the presence, and possibly the extent, of sample interfering substances (e.g., H, I, and / or L) in the sample 312 (e.g., its serum or plasma portion 312SP) prior to analysis by one or more of the analyzer modules 206, 208, and 210, etc. Pre-fractionation in this manner allows for additional processing, additional quantification or characterization, and / or disposal and / or modification of sample 312 without wasting valuable analyzer resources or, potentially, the presence of interfering substances that adversely affect the accuracy of test results. Additionally, pre-fractionation can provide improved characterization of future samples 312 in several ways.

[0046] In addition to detecting interferents, other detection methods can also be performed by the quality verification module 530 on the sample 312 contained within the sample container 202 / 302. For example, a method for providing segmentation data can be implemented in the quality verification module 530. The segmentation data can be used in a post-imaging process to quantify the sample 312, for example, to determine certain physical dimensional characteristics of the sample 312, such as determining the location of the LA and / or SB, and / or the HSP, HSB, HT, W, and / or HTOT. Quantification can also involve estimating the volume of the serum or plasma fraction (VSP) and / or the volume of the settled blood fraction (VSB), for example, based on quantifying the internal width W. Furthermore, the quality verification module 530 can be used to quantify the geometry of the sample container 202 / 302, i.e., to quantify certain physical dimensional characteristics of the sample container 202 / 302, such as the location of the TC, HT, and / or W or W of the sample container 202 / 302. Other quantifiable geometric configurations can also be determined.

[0047] The quality assurance module 530 can include a housing 502 that can at least partially surround or cover the track 218 to minimize the effect of external lighting. The sample containers 202 / 302 can be positioned inside the housing 502 at an imaging location 510 during an image acquisition sequence. The housing 502 can include one or more doors 504 to allow the carriers 222 / 422 to enter and exit the housing 502. In some embodiments, the ceiling can include an opening 506 ( FIG. 5B ) that allows the sample containers 202 / 302 to be loaded into the carriers 222 / 422 from above by a robot, which can include movable robotic fingers. The quality assurance module 530 can also include an image capture device 508, which can be a camera coupled to and controlled by the computer 243. The quality verification module 502 may further include a rear panel 514 positioned opposite the image capture device 508, with the sample container 302 positioned at an imaging location 510 between the image capture device 508 and the rear panel 514. The rear panel 514 may be coupled to and controlled by the computer 243 to provide suitable and / or changeable background or backlighting. The image capture device 508 and rear panel 514 may be rotatable about the imaging location 510, as indicated by arrow 512. The image capture device 508 may be used to capture images from different angles of the sample container 302 and / or the biological fluid sample 312 contained therein. The images may be analyzed, for example, by the computer 234 running artificial intelligence algorithms to perform the HILN determination and / or container / sample segmentation described above.

[0048] FIG. 6 illustrates a computer 600 operable to generate a physical layout of an automated laboratory diagnostic system based on the system's requirements (e.g., tests / analyses to be performed, available floor space, workload, etc.) and goals (e.g., performance and / or cost), according to one or more embodiments. The computer 600 includes a processor 602, a user interface 604, and a memory 606. The memory 606 includes layout generation software 608 and a database 610 stored therein. In some embodiments, the database 610 can be located remotely from and coupled to the computer 600. The layout generation software 608 is executable by the processor 602, and the database 610 contains data regarding modules and sample transport system components that may be included in the physical layout of the automated laboratory diagnostic system. The data stored in the database for each module can indicate the module's function, dimensions, footprint, and / or shape, execution time per sample per function, location of interaction / interface with the sample transport system, and other module specifications and configurations relevant to operation and performance and layout generation. The data stored in the database for the sample transport system can indicate each type and configuration of track segments (e.g., straight segments, curved segments, three-way and four-way switch segments, etc.), their dimensions, sample carrier transport speeds therethrough, associated track hardware (e.g., motors, track sensors, sample container robotic handlers, etc.), and other components and specifications related to modular linkage and sample carrier transport and layout generation. The user interface 604 includes any devices and / or components suitable for inputting data representing the system requirements and goals, and in some embodiments, a set of predetermined physical layouts (described in more detail below), and outputting a final physical layout that can be used to configure the automated laboratory diagnostic system for installation at a user's location.

[0049] 7 shows a high-level overview of layout generation software 708, according to one or more embodiments. Layout generation software 708 is one embodiment of layout generation software 608 and includes a layout program 710 and a simulation program 712, each executable by processor 602 of computer 600 (or separate processors and / or computer systems that can share information). In a blank canvas embodiment, layout program 710 receives requirements for a proposed system as input, processes the system requirements, generates a preliminary physical layout from a "blank canvas" (i.e., without any pre-determined or pre-positioned system components or layout configurations) based on the system requirements, and outputs the preliminary physical layout.

[0050] System requirements may include, for example, a list of pre-processing tasks, inspection / analysis, and post-processing tasks to be performed; types of samples to be received; expected workload (e.g., maximum number of samples to be handled simultaneously by the system); physical constraints such as available floor space in terms of area and shape (e.g., rectangular, square, L-shaped, J-shaped, etc.), fixed structures within the floor space such as columns, walls, etc.; location of power sources; minimum space requirements for user access to modules; etc.

[0051] System requirements may additionally or alternatively include environmental criteria. For example, an automated laboratory diagnostic system may need to be maintained within specific temperature and humidity limits. Thus, system requirements may include power usage limits and thermal management (e.g., that too many modules sharing a power supply can result in overheating). Adequate lighting conditions and / or vibration limits may also be considered system requirements.

[0052] System requirements can additionally or alternatively include human factors, such as biosafety and biosecurity practices, because the proposed system processes biological samples. For example, if the proposed system handles samples that may test positive for highly contagious diseases such as HIV or COVID-19, the physical layout may need to include safety features (e.g., blocked rooms, isolation areas, additional sterilization modules, etc.). Furthermore, because some areas of the system may interact with humans more frequently than others (e.g., the sample entry / exit handler module), system requirements can include additional constraints, such as optimizing the location of the sample entry / exit handler module relative to the system's entrance / exit points to minimize expected foot traffic. For example, if personnel only frequently enter and exit certain parts of the system, a "floor heat map" (showing high foot traffic) can be used as input.

[0053] 8 shows a simple example of one embodiment of a layout program 710 that can iteratively generate a preliminary physical layout for an automated laboratory diagnostic system using an RL algorithm. In some embodiments, an RL agent can start with a "blank canvas" (illustrated by iteration 0 preliminary physical layout 802) and have the following action space: place new modules (e.g., sample entry / exit handler, quality assurance module, aspiration / administration module; clinical chemistry analyzer, immunoassay analyzer, etc.); rotate / translate existing modules if needed; place new sample transport system track segments (e.g., lines, curves, or intersections / switches with specific orientations) to connect modules; and repeat until system requirements are met.

[0054] In the example of FIG. 8 , iterative generation of interim physical layouts can be based on system requirements: tests / analyses to be performed, available floor space configuration, workload, and minimum foot traffic through the system. The tests / analyses to be performed can be specified, for example, as the identification of analytes in two different types of biological fluids. The available floor space configuration can be specified in terms of the area (e.g., square feet) and / or dimensions / shape (e.g., squares) represented by the iteration 0 interim physical layout 802 (i.e., the “blank canvas”). The workload can specify the maximum number of samples that can be safely handled in the system simultaneously with little or no risk of collision with each other. The layout program 710 processes the input and, if needed, accesses database 610 to determine the specific modules needed, how each module is required, how supplies (reagents, cuvettes, probes, etc.) can be loaded and configured in each module, and how the modules can be arranged and connected via the sample transport system (e.g., track connections between modules).

[0055] In particular, as shown by interim physical layout 803 for iteration 1, layout program 710 can determine that sample entry / exit handler SH and analyzer module A1 are needed and can arrange SH, A1, and track section 804. Layout program 710 can place SH near system entrance 805 to minimize foot traffic to the system (if system entrance 805 is shown in the available floor space configuration provided as input). Layout program 710 can also determine that identical analyzer module A2 is needed to perform analyte identification for two different types of biological fluid, and each module can be configured to perform analyte identification for the respective biological fluid sample and / or can be loaded differently (e.g., with different reagents). Layout program 710 can then arrange module A2 and track segments 806 and 807 as shown in interim layout 808 for iteration 2. Layout program 710 may further determine that additional track segments 809 and 810 are needed to meet the required workload (i.e., the number of samples that can be safely handled in the system simultaneously with little or no risk of colliding with each other) and may arrange track segments 809 and 810 as shown in interim layout 811 for iteration 3. Layout program 710 may continue iteratively adding pre-processing and post-processing modules as needed to complete the interim physical layout after iteration 3. As described in further detail below, the interim physical layout may then be simulated by simulation program 712 to determine whether it meets the system goals (e.g., sample processing capacity and / or sample turnaround time) input into simulation program 712.

[0056] 9A, 9B, and 9C illustrate another example embodiment of the layout program 710, which can generate and output two or more interim physical layouts for the same set of requirements. In some embodiments, the layout generator 710 can again use a RL algorithm. In the example of FIGS. 9A-9C, the layout program 710 can determine that a sample handler (SH) and two analyzer modules AM1 and AM2 are needed to meet the input system requirements. Again, starting from a "blank canvas," the layout program 710 can generate three interim physical layouts 900A, 900B, and 900C, each of which meets the system requirements. As shown, each layout includes modules SH, AM1, and AM2, as well as various track segments connecting modules SH, AM1, and AM2 (only a few track segments are labeled; see, e.g., straight track segment 902, curved track segment 904, and crossover / switch track segment 906). As will be further described in more detail below, each of the interim physical layouts 900A, 900B, and 900C can be simulated by the simulation program 712 to determine which, if any, best meets the system goals (e.g., sample throughput and / or sample turnaround time) input into the simulation program 712.

[0057] 7, the layout program 710, in some embodiments, can also receive as input a set of pre-defined physical layouts in addition to the system requirements. The set of pre-defined physical layouts can be provided by the manufacturer of the automated laboratory diagnostic system. The layout program 710 can process the system requirements and the set of pre-defined physical layouts, and in some embodiments, can select and output the least complex or other physical layout from the received set of pre-defined physical layouts that meets the system requirements. The selected pre-defined physical layout is considered to be the tentative physical layout at this stage.

[0058] FIG. 10 illustrates an exemplary set 1000 of predefined physical layouts for an automated laboratory diagnostic system that can be input into layout program 710. In the illustrated embodiment, 50 predefined physical layouts are included in exemplary set 1000. Fewer or more predefined physical layouts may also be included. Any suitable format and / or nomenclature recognizable by layout program 710 can be used to describe the set of predefined physical layouts. Such format / nomenclature can indicate, for each predefined physical layout, the modules included (and therefore the functions performed) and how the modules are connected via the sample transport system. The format / nomenclature can also indicate the footprint, shape, and / or dimensions of each predefined physical layout. Alternatively, in some embodiments, layout program 710 can determine the functions performed by the modules, calculate the areas / dimensions, and / or obtain other information associated therewith based on data stored in database 610.

[0059] Referring again to FIG. 7 , the preliminary physical layout from layout program 710 is input to simulation program 712. Simulation program 712 also receives as input a representative subset of the sample tests / analyses to be performed by the proposed automated laboratory diagnostic system (i.e., the system for which its physical layout was generated). For those systems with a small menu of tests / analyses to be performed, all such tests / analyses can be provided as input to simulation program 712. Simulation program 712 also receives one or more goals to be achieved by the physical layout of the system. These goals can relate, for example, to performance, cost, operating parameters (e.g., total heat generated based on the number of samples processed per module per unit time), etc., as described in more detail below. These goals can also be prioritized and / or weighted. The simulated results of the sample tests / analyses are then evaluated against these goals at decision block 714.

[0060] System goals may include various performance criteria, such as sample processing capacity (e.g., total number of samples processed per 8-hour shift, day, week, etc.); sample turnaround time (e.g., individual sample processing rate); one or more minimum and / or maximum processing times for testing / analyzing a particular type of sample (e.g., blood, urine, etc.); one or more minimum and / or maximum processing times for performing one or more particular types of test / analysis, one or more minimum and / or maximum processing times for moving a sample from one location to another, etc.

[0061] System goals may additionally or alternatively include various cost goals, such as system purchase costs, maintenance costs, utility costs, supply costs (eg, reagent additives, cuvettes, and aspiration / dispensing probes), and the like.

[0062] In some embodiments, these goals may additionally or alternatively include module and track maintenance (e.g., based on application), module calibration and quality control (e.g., also based on application), and operating parameter limits related to the system's environment, including, for example, temperature, humidity, and / or vibration limits.

[0063] For blank canvas embodiments, simulation results that do not meet one or more goals (or do not fall within a predetermined acceptable range thereof) can indicate that the provisional physical layout is not considered optimized, and layout generation software 708 returns to layout program 710 to modify the provisional physical layout based on the requirements and the simulation results. For example, the simulation results can be used to modify (e.g., train) the RL agent's policy. This can include mapping the simulation results (e.g., key performance indicators (KPIs)) to reward values ​​that are fed into the policy training scheme used. For example, if the provisional physical layout is close to an optimized solution (e.g., one or more system goals, such as one or more KPIs, are nearly met), the reward value is made high (e.g., a large positive value), and therefore only few changes are made to the provisional physical layout. However, if the provisional physical layout is far from optimal (e.g., the provisional physical layout is not close enough to meeting the system goals), the reward value is made low or negative to encourage larger changes to the provisional physical layout.

[0064] For the predetermined layout embodiment, simulation results that do not meet one or more goals (or fall outside a predetermined acceptable range thereof) can similarly indicate that the selected interim physical layout is not considered optimized, and the software returns to the layout program 710 to select another predetermined physical layout based on the system requirements and the simulation results. As with the black canvas example above, the simulation results can be used to modify (e.g., train) the RL agent's policy, such as by mapping the simulation results to a reward value that is fed into the policy training scheme used. Unlike the blank canvas embodiment, however, the next interim physical layout selected must be one of the predetermined physical layouts (e.g., the predetermined physical layout that is closest to the modified physical layout predicted by use of the RL agent and trained policy). (Similarly, as described further below, an evolutionary algorithm can be used to mutate the current physical layout (on which the simulation was performed) to another predetermined physical layout.)

[0065] 11 shows an example of an optimization process 1100 of the layout generation software 708 (FIG. 7) for optimizing the preliminary physical layout, according to one or more embodiments. In some embodiments, the layout generation software 708 may use an evolutionary algorithm in the optimization process 1100.

[0066] In processing block 1102, the simulation program 712 simulates specimen inspection for a first interim physical layout received from the layout program 710. The first interim physical layout may be one generated by the layout program 710 from a "blank canvas" or may be the least complex layout (or other layout) selected by the layout program 710 from a set of predetermined physical layouts received as input by the layout program 710.

[0067] Simulation results from processing block 1102 are shown in data block 1104 and, in this example, may show that the immunoassay analyzer (IA) module is overworked, sample throughput targets are not being met, and sample turnaround time (TAT) for clinical chemistry (CC) analysis is not being met. These results indicate that the first interim physical layout is not optimized.

[0068] In response to these simulation results, the layout generation software 708 returns to the layout program 710 via the "No" branch of decision block 714 (see FIG. 7), the simulation results are analyzed (e.g., via an evolutionary algorithm used in the layout program 710), and the first interim embodiment is modified or replaced at process block 1106 as follows: In a blank canvas embodiment, based on these requirements, the simulation results, and any relevant data stored in database 610 (FIG. 6), the layout program 710 can modify the first interim physical layout. For example, the layout program 710 can add another immunoassay analyzer (IA) module to overcome overuse and throughput issues, or can relocate a clinical chemistry (CC) analyzer module closer to the sampler / handler module to reduce turnaround time (TAT). In a predetermined layout embodiment, layout program 710 may select another predetermined physical layout (e.g., the next least complex physical layout or another predetermined physical layout) from the set of predetermined physical layouts based on these requirements, the simulation results, and any relevant data stored in database 610 (FIG. 6).

[0069] In an alternative predetermined layout embodiment, the layout program 710 using the evolutionary algorithm can modify (rather than replace) the first interim physical layout in the same or similar manner as the blank canvas embodiment. For example, the evolutionary algorithm can be used to initially start with a first laboratory configuration, such as a simple diagnostic laboratory configuration (e.g., sample handler + clinical chemistry analyzer + immunoassay analyzer (SCI) of FIG. 10 ), as the first interim physical layout. Based on simulation results for the first interim physical layout, “children” of the first interim physical layout can be selected (e.g., SCII, SCCI, SHC-SCI, etc.). In this case, because a discrete set of choices is available, the decision variables are limited (e.g., the number of sample handlers (S), clinical chemistry analyzers (C), immunoassay analyzers (I), etc.) to be used in the physical layout. For example, consider a situation in which a customer wants to purchase a laboratory diagnostic system and is trying to determine a specific configuration to use. A first exemplary constraint for a diagnostic laboratory system is the laboratory area. Assuming this constraint is met, another constraint may be to minimize the required processing power or the cost to the customer.

[0070] Based on the results of simulations of the initial (tentative) physical layout for the laboratory system, an evolutionary algorithm can determine modifications or “mutations” to make to the initial physical layout. In addition, “crossover” can be used to extract useful components from multiple “parent” configurations. The results of mutation and crossover can be evaluated as “children” through simulation. Children that show improvement can be further mutated (if needed), while children that do not show improvement can be discarded. For example, if a simulation indicates that a particular chemistry analyzer is overused (e.g., via one or more key performance indicators (KPIs) or other laboratory goals), one mutation can be adding another replica chemistry analyzer to the existing configuration. Selection can involve running a simulation to verify whether the laboratory goals are met, while also verifying that the proposed physical layout (generated by mutation or crossover) is one of the available predetermined physical layouts. For example, if the initial (tentative) physical layout is SCI, the three “viable” mutations can be SCII, SSCII, and SSII, because these configurations are available predetermined physical layout configurations (see FIG. 10).

[0071] Upon completing the layout modification or selection of another predetermined physical layout, the layout program 710 outputs a second interim physical layout.

[0072] At process block 1108 , simulation program 712 simulates specimen inspection for the second interim physical layout received from layout program 710 .

[0073] Simulation results from processing block 1108 are shown in data block 1110 and, in this example, can similarly show that the sample throughput target is still not met, indicating that the second interim physical layout is also not optimized.

[0074] In response, layout generation software 708 again returns to layout program 710, which, in the case of blank canvas and alternative predetermined layout embodiments, can modify the second interim physical layout, e.g., to include additional parallel track segments, to alleviate specimen transportation bottlenecks and traffic congestion that may cause the layout to not meet throughput goals. In the case of predetermined layout embodiments, layout program 710 can again select a different predetermined layout (e.g., the next least complex layout or another suitable predetermined layout) from the set of predetermined physical layouts based on these requirements, recent simulation results, and any relevant data stored in database 610 (FIG. 6). Upon completing the layout modification or selection of another predetermined physical layout, layout program 710 outputs a third interim physical layout in process block 1112.

[0075] At process block 1114 , simulation program 712 simulates specimen inspection for the third interim physical layout received from layout program 710 .

[0076] As shown in data block 1116, in response to the simulation results from processing block 1114 meeting the goal (in this example), the simulated interim physical layout is deemed optimized in decision block 714 (FIG. 7) and output as the final physical layout in output block 716.

[0077] In response to the simulation results from processing block 1114 not meeting the goals, optimization process 1100 may continue for a predetermined period of time or a predetermined number of interim physical layouts, and if none of the simulated interim physical layouts are capable of meeting all of the goals, layout generation software 708 may stop execution of optimization process 1100. In this case, one or more of the interim physical layouts that meet most of the goals or come close to meeting some or all of the goals (one or more of the goals may be prioritized and / or weighted and provided as input to simulation program 712) may be output as one or more final physical layouts along with their respective simulation results at output block 716 (see FIG. 7 ).

[0078] FIG. 12 illustrates an alternative optimization process 1200 of layout generation software 708 ( FIG. 7 ) for optimizing a preliminary physical layout according to one or more predetermined layout embodiments having a small number of predetermined physical layouts (e.g., 10 or fewer). A layout program 710 of layout generation software 708 may first determine, at process block 1202, which one or more of the predetermined physical layouts meet system requirements. A simulation program 712, in some embodiments, may be based on a standard discrete event simulator (such as Emulate3D by Rockwell Automation, Inc. of Milwaukee, Wisconsin), and then, at process block 1204, may simulate sample inspection for all predetermined physical layouts determined to meet the system requirements. Simulation results, shown in data blocks 1206-1206n, may then be analyzed at process block 1208 to determine the best optimized physical layout based on the system requirements and objectives (some or all of the objectives may be prioritized or weighted). The determination in process block 1208 may be performed by simulation program 712 or another software entity of layout generation software 708. The best optimized physical layout determined in process block 1208 may then be output as the final physical layout, as shown in data block 1210 (and output block 716 in FIG. 7 ).

[0079] In an alternative blank canvas embodiment of optimization process 1100 of layout generation software 708, a portion of a physical layout may be placed by layout program 710 and then simulated by simulation program 712 based on the specific sample inspection and goals associated with that portion. When that portion successfully meets its goals, this alternative optimization process returns to layout program 710 to place another portion of the interim layout, which is then simulated by simulation program 712. Referring to Figure 8, this alternative optimization process (e.g., using an RL algorithm) proceeds as follows:

[0080] Iteration 0: Initialized with blank canvas 802;

[0081] Iteration 1: The RL agent runs the simulation and places the SH and analyzer module A1 connected by a straight line segment 804;

[0082] Iteration 2: The RL agent runs the simulation and places an additional analyzer module A2 by line segments 806 and 807;

[0083] Iteration 3: The RL agent runs the simulation and adds the intersection segments 809 and 810;

[0084] Iteration N: The process continues as described above until all modules and sample transport system components are placed and simulation results indicate that all goals have been met (or are best met), and layout modifications can be made in response to goals not being met, as described above.

[0085] The output of the final physical layout may include, for example, a detailed close-up of the modules and sample transport system, a list of the physical location of each module (e.g., given in terms of points in a preferred / general coordinate system), the physical location and identification of each track segment of the sample transport system (also e.g., given in terms of points in a preferred / general coordinate system), the degree of connectivity between the track segments (e.g., identifying where multiple track segments can be connected by a sample container robot handler), interaction points between the modules and the sample transport system (e.g., locations of track connections and / or sample container robot handlers), and / or the maximum number of sample carriers that can be simultaneously and safely handled by the sample transport system. Alternatively, or in addition, other information may be included in or along with the output of the final physical layout.

[0086] Advantageously, the layout generation software 608 / 708 is scalable, i.e., the layout generation software 608 / 708, supported by sufficient module and sample transport system data in the database 610, can be operable to generate physical layouts for automated laboratory diagnostic systems of various sizes and / or complexities.

[0087] 13 shows a flow diagram of a method 1300 for generating a physical layout of an automated laboratory diagnostic system, according to one or more embodiments. The method 1300 includes receiving, at a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload, at process block 1302. For example, this information may be provided by an operator to the processor 602 for use with the layout generation software 708.

[0088] At process block 1304, the method 1300 includes receiving one or more laboratory targets at a processor executing layout generation software.

[0089] At process block 1306, the method 1300 includes identifying, via a processor executing layout generation software, specific types of modules and their redundancies to be included in the preliminary physical layout based on laboratory requirements.

[0090] The method 1300 includes, at process block 1308, placing specific modules within the preliminary physical layout based on laboratory requirements via a processor executing layout generation software.

[0091] The method 1300 includes, at process block 1310, via a processor executing layout generation software, using a sample transport system to connect specific modules located within the preliminary physical layout based on laboratory requirements to complete the preliminary physical layout.

[0092] At process block 1312, the method 1300 includes simulating specimen inspection using the interim physical layout. For example, the simulation program 712 may be used to simulate specimen inspection using the interim physical layout. As mentioned above, the simulation program 712 may be executed by the processor 602 or a different computational resource.

[0093] At process block 1314, the method 1300 includes repeating the identifying, arranging, and connecting in response to the simulation not meeting one or more laboratory goals. Generally, the interim physical layout can be iteratively modified until one or more laboratory goals are met (or until it is determined that the desired goal cannot be met). For example, process block 1306 (identifying module types and redundancies to be included), process block 1308 (arranging modules based on laboratory requirements), process block 1310 (connecting modules in the interim physical layout using a transport system), and process block 1312 (simulating sample testing using the interim physical layout) can be repeated one, two, five, ten, twenty, fifty, or more times until one or more laboratory goals are met. In some embodiments, if the laboratory goals are not met within a predetermined number of iterations and / or a predetermined time period, the operator can be notified of which goals cannot be met and a physical layout that closely approximates meeting those goals can be provided. The method 1300 may then end.

[0094] If one or more laboratory goals have been met, then at process block 1316, the method 1300 includes outputting, via a user interface connected to the processor, the final physical layout in response to the simulation meeting the one or more laboratory goals.

[0095] 14 shows a flow diagram of another method 1400 of generating a physical layout for an automated laboratory diagnostic system according to one or more embodiments. Method 1400 includes receiving, at a processor executing layout generation software, a set of predefined physical layouts for the automated laboratory diagnostic system, at process block 1402. For example, a set of predefined physical layouts, such as set 1000 of FIG. 10 or another set of predefined physical layouts, can be provided to processor 602 (e.g., from database 610) for use with layout generation software 708.

[0096] At process block 1404, the method 1400 includes receiving, at a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload. For example, this information may be provided by an operator to the processor 602 for use with the layout generation software 708.

[0097] At process block 1406, the method 1400 includes receiving, at a processor executing layout generation software, one or more laboratory targets. An operator may, for example, provide the one or more laboratory targets.

[0098] The method 1400 includes simulating inspection of the specimen using a physical layout (which in some embodiments may be the least complex physical layout) of a set of predetermined physical layouts that includes all modules required to perform the specimen inspection, at processing block 1408. For example, the simulation program 712 may be used to simulate inspection of the specimen using the interim physical layout.

[0099] At process block 1410, method 1400 includes repeating a simulation of the sample test using a different physical layout of the set of predefined physical layouts that includes all modules needed to perform the sample test, in response to the previous simulation not meeting the laboratory requirements and one or more laboratory goals. In some embodiments, the different physical layout may be the next least complex physical layout, or a physical layout determined using RL or an evolutionary algorithm, as described above. Generally, simulation of different predefined physical layouts may continue until one or more laboratory goals are met (or until it is determined that the desired goal cannot be met). For example, process block 1408 may be repeated for different predefined physical layouts until one or more laboratory goals are met. In some embodiments, method 1400 may terminate if the predefined physical layout does not meet one or more laboratory goals.

[0100] Assuming one of the predetermined physical layouts meets one or more laboratory goals, at process block 1412, method 1400 includes outputting, via a user interface coupled to the processor, the one predetermined physical layout in response to the simulation of the predetermined physical layout meeting the laboratory requirements and the one or more laboratory goals.

[0101] 15 shows a flow diagram of another method 1500 of generating a physical layout for an automated laboratory diagnostic system according to one or more embodiments. Method 1500 includes receiving, at a processor executing layout generation software, a set of predefined physical layouts for the automated laboratory diagnostic system, at process block 1502. For example, a set of predefined physical layouts, such as set 1000 of FIG. 10 or another set of predefined physical layouts, can be provided to processor 602 (e.g., from database 610) for use with layout generation software 708.

[0102] At process block 1504, the method 1500 includes receiving, at a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload. For example, this information may be provided by an operator to the processor 602 for use with the layout generation software 708.

[0103] At process block 1506, the method 1500 includes receiving, at a processor executing layout generation software, one or more laboratory targets. An operator, for example, can provide the one or more laboratory targets.

[0104] The method 1500 includes selecting a physical layout of the set of predetermined physical layouts that includes all modules required to perform the specimen inspection at processing block 1508. In some embodiments, the selected physical layout may be the least complex physical layout.

[0105] The method 1500 includes simulating specimen inspection using the selected physical layout at process block 1510. For example, the simulation program 712 may be used to simulate specimen inspection using the selected physical layout.

[0106] The method 1500 includes, at decision block 1512, determining whether the simulation met the laboratory requirements and one or more laboratory goals.

[0107] If, at decision block 1512, it is determined that the simulation did not meet the laboratory requirements and one or more laboratory goals, at process block 1514, a different physical layout from the set of predetermined physical layouts is selected using a reinforcement learning or evolutionary algorithm that includes all modules needed to perform the sample tests, and the simulation (process block 1510) is repeated. In some embodiments, the different physical layout may be the next least complex physical layout. Generally, simulation of different predetermined physical layouts may continue until one or more laboratory goals are met (or until it is determined that the desired goal cannot be met). For example, process block 1514 and process block 1510 may be repeated for different predetermined physical layouts until one or more laboratory goals are met. In some embodiments, method 1500 may end if the predetermined physical layout does not meet one or more laboratory goals.

[0108] Assuming one of the predetermined physical layouts meets the one or more laboratory goals, at process block 1516, method 1500 includes outputting, via a user interface connected to the processor, the predetermined physical layout that meets the laboratory requirements and the one or more laboratory goals.

[0109] As described above, numerous factors can be considered as part of the physical layout optimization process. For example, physical space constraints to be considered can include at least one of available floor space, power availability and location, user access to modules, temperature requirements, humidity requirements, security requirements, and biosafety requirements. Similarly, exemplary laboratory goals to be considered can include at least one of sample processing capacity, sample turnaround time, hardware costs, operating costs, supply costs, reagent replacement rates, module load balancing, failure tolerance, and weighted combinations of any of these. Failure tolerance considerations can include design choices that address robustness to failures, such as when a section or segment of the travel path becomes unavailable due to service maintenance, analyzer downtime during consumable / reagent replacement, or other service. Other considerations can include measurement menus relative to the physical layout, pre- and post-processing module requirements, operator / maintenance access, and the like. One or more of these factors can be considerations used during implementation of the reinforcement learning or evolutionary algorithms described herein.

[0110] In at least some embodiments, the optimized physical layout determined via one or more of the methods described herein can include the modules / analyzers to be installed (e.g., which pre- or post-processing modules, which analyzers, how many modules / analyzers, how each module or analyzer can be loaded / prepared, track connections between modules / analyzers, etc.).

[0111] As a further example of applying reinforcement learning to physical layout selection, in some embodiments, the reward function used can be shaped by factors including key performance indicators (KPIs) such as TAT / throughput. The reward function can run a simulation of the worklist against the interim physical layout to determine whether throughput / TAT requirements have been met. Generally, throughput / TAT is a common KPI to optimize, but the reward function can also include other factors (e.g., reagent change-out rates, required quality control calibrations, etc.) that can be weighted according to customer requirements.

[0112] In some embodiments, training can be performed iteratively, training the agent for many "episodes." Each episode can start with a random set of worklists / constraints, for which the agent iteratively designs a physical layout while updating the policy weights using a reward function. An episode can be considered complete, for example, when the designed physical layout satisfies the constraints and requirements, or after a certain timeout (e.g., the agent is unable to find a suitable physical layout within a predetermined amount of time). Eventually, with sufficient training, the agent can begin to design a suitable physical layout within a few iterations (e.g., the length of the episode is reduced), which identifies when training has converged. After training has converged, the neural network underlying the policy can be fixed (e.g., weights / parameters do not change). Multiple iterations can be run on a set of laboratory constraints / requirements until the layout program 710 creates a suitable physical layout. This is equivalent to running only one training episode, except that no weight updates are applied to the RL agent policy. The "environment" used can still be the same as that used during training, and the same observations from this environment can be used to feed the RL agent.

[0113] One or more of the methods described herein may be implemented in computer program code, such as part of an application (or other executable instructions) executable on a computer as one or more computer program products. Other systems, methods, computer program products, and data structures may also be provided. Each computer program product described herein may be carried by a non-transitory medium readable by a computer (e.g., a DVD, a hard drive, random access memory, etc.).

[0114] While the present disclosure is susceptible to various modifications and alternative forms, specific method and apparatus embodiments have been shown by way of example in the drawings and are herein described in detail. It should be understood, however, that the particular methods and apparatus disclosed herein are not intended to limit the disclosure, which is defined by the following claims.

Claims

1. 1. A method for generating a physical layout of an automated laboratory diagnostic system, comprising: receiving, at a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload; receiving one or more laboratory targets at a processor executing layout generation software; Identifying, via a processor executing layout generation software, specific types of modules and their redundancies to be included in the preliminary physical layout based on laboratory requirements; placing specific modules within the preliminary physical layout based on laboratory requirements via a processor executing layout generation software; using a sample transport system to connect specific modules located within the preliminary physical layout based on laboratory requirements via a processor executing layout generation software to complete the preliminary physical layout; simulating specimen inspection using the preliminary physical layout; repeating the identifying, locating, and connecting in response to the simulation failing to meet one or more laboratory goals; outputting the final physical layout via a user interface connected to the processor in response to the simulation meeting one or more laboratory goals; The method comprising:

2. The final physical layout is: the physical location of each module; the physical location of each track segment of the sample transport system; connectivity between track segments; The module's interaction point with the sample transport system; and Maximum number of sample carriers handled by the sample transport system The method of claim 1 , comprising at least some of:

3. The method of claim 1 , wherein the sample transport system includes track segments for moving the sample carrier, the track switch, and the sample vessel robotic handler.

4. The method of claim 1 , wherein the module comprises at least one of a clinical chemistry analyzer, an immunoassay analyzer, and a molecular testing analyzer.

5. The method of claim 1 , wherein the modules include at least one of a pre-processing module and a post-processing module.

6. 10. The method of claim 1, wherein, prior to outputting, the method further comprises adding, removing, rearranging, or reconnecting one or more modules in the interim physical layout in response to the repeated identification, placement, and connection.

7. The method of claim 1 , wherein the layout generation software includes a trained reinforcement learning (RL) algorithm.

8. 10. The method of claim 1, wherein the physical space constraints include at least one of available floor space, power availability and location, user access to the modules, temperature requirements, humidity requirements, security requirements, and biosafety requirements.

9. 10. The method of claim 1, wherein the one or more laboratory goals include at least one of sample throughput, sample turnaround time, hardware costs, operating costs, supply costs, reagent replacement rates, module load balancing, fault tolerance, and a weighted combination of any of these.

10. 1. A system for generating a physical layout of an automated laboratory diagnostic system, comprising: A computer including a processor, a memory, and a user interface, the memory storing layout generation software, the processor executing the layout generation software: receiving laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload; receiving one or more laboratory targets; Identifying specific types of modules and their redundancies to be included in the preliminary physical layout based on laboratory requirements; arranging specific modules within the preliminary physical layout based on laboratory requirements; Using a sample transport system, based on laboratory requirements, connect specific modules located within the provisional physical layout to complete the provisional physical layout; simulating specimen inspection using the preliminary physical layout; repeating the identifying, locating, and linking in response to a simulation of a subset of tests performed on the interim physical layout not meeting one or more laboratory goals; outputting a final physical layout via the user interface in response to the simulation meeting one or more laboratory goals; The system is operable to:

11. The final physical layout is: the physical location of each module; the physical location of each track segment of the sample transport system; connectivity between track segments; The module's interaction point with the sample transport system; and Maximum number of sample carriers handled by the sample transport system The system of claim 10, comprising at least some of:

12. The processor running the layout generation software:

11. The system of claim 10, further operable to add, remove, rearrange, or reconnect one or more modules in the interim physical layout in response to repeated identifying, placing, and connecting.

13. The system of claim 10 , wherein the layout generation software includes a trained reinforcement learning (RL) algorithm.

14. 11. The system of claim 10, wherein the physical space constraints include at least one of available floor space, power availability and location, user access to the modules, temperature requirements, humidity requirements, security requirements, and biosafety requirements.

15. 11. The system of claim 10, wherein the one or more laboratory goals include at least one of sample throughput, sample turnaround time, hardware cost, operating cost, supply cost, reagent replacement rate, module load balancing, fault tolerance, and a weighted combination of any of these.

16. 1. A method for generating a physical layout of an automated laboratory diagnostic system, comprising: receiving, at a processor executing layout generation software, a set of predetermined physical layouts for an automated laboratory diagnostic system; receiving, at a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload; receiving one or more laboratory targets at a processor executing layout generation software; simulating a specimen inspection using a physical layout of a set of predetermined physical layouts that includes all modules required to perform the specimen inspection; repeating the simulation of the sample test using a different physical layout of the set of predetermined physical layouts that includes all modules required to perform the sample test in response to the previous simulation not meeting the laboratory requirements and one or more laboratory goals; outputting, via a user interface connected to the processor, one predetermined physical layout in response to a simulation of the predetermined physical layout satisfying the laboratory requirements and one or more laboratory goals; The method comprising:

17. 17. The method of claim 16, wherein each predetermined physical layout includes at least one pre-processing module, at least one analyzer module, and at least one post-processing module.

18. One predetermined physical layout is: the physical location of each module; the physical location of each track segment of the sample transport system; connectivity between track segments; The module's interaction point with the sample transport system; and Maximum number of sample carriers handled by the sample transport system 17. The method of claim 16, comprising at least some of:

19. 17. The method of claim 16, wherein the physical space constraints include at least one of available floor space, power availability and location, user access to the modules, temperature requirements, humidity requirements, security requirements, and biosafety requirements.

20. 17. The method of claim 16, wherein the one or more laboratory goals include at least one of sample throughput, sample turnaround time, hardware costs, operating costs, supply costs, reagent replacement rates, module load balancing, failure tolerance, and a weighted combination of any of these.

21. 1. A method for generating a physical layout of an automated laboratory diagnostic system, comprising: receiving, at a processor executing layout generation software, a set of predetermined physical layouts for an automated laboratory diagnostic system; receiving, at a processor executing layout generation software, laboratory requirements including sample tests to be performed, physical space constraints, and expected sample workload; receiving one or more laboratory targets at a processor executing layout generation software; selecting a physical layout of the set of predetermined physical layouts that includes all modules required to perform the specimen inspection; simulating specimen inspection using the selected physical layout; If the laboratory requirements and one or more laboratory goals are not met, using a reinforcement learning or evolutionary algorithm to select a different physical layout from the set of predetermined physical layouts that includes all modules needed to perform the sample test, and repeat the simulation; outputting the one predetermined physical layout via a user interface connected to the processor if the laboratory requirements and one or more laboratory goals are met by one of the predetermined physical layouts; The method comprising:

22. 22. The method of claim 21, wherein each predetermined physical layout includes at least one pre-processing module, at least one analyzer module, and at least one post-processing module.

23. One predetermined physical layout is: the physical location of each module; the physical location of each track segment of the sample transport system; connectivity between track segments; The module's interaction point with the sample transport system; and Maximum number of sample carriers handled by the sample transport system 22. The method of claim 21, comprising at least some of:

24. 22. The method of claim 21, wherein the physical space constraints include at least one of available floor space, power availability and location, user access to the modules, temperature requirements, humidity requirements, security requirements, and biosafety requirements.

25. 22. The method of claim 21, wherein the one or more laboratory goals include at least one of sample throughput, sample turnaround time, hardware costs, operating costs, supply costs, reagent replacement rates, module load balancing, failure tolerance, and a weighted combination of any of these.

Images