Traitement en cours

Veuillez attendre...



Aller à Demande


Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique

[ EN ]



[0001] This application is related to previously filed provisional application number

62/607,624 titled Laboratory Instrument selection and configuration filed and provisional patent application 62/770,280 titled Optimizing Operation costs of Laboratory instruments and provisional patent application 62/770,291 titled Scheduling tests in a laboratory environment at the USPTO. This application is also related to and claims the benefit of previously filed provisional application 62/774,929 titled Clinical Laboratory Optimization Framework. This application is also related to previously filed United States non-provisional application 16/468,430 titled Intelligent Handling of Materials. The contents of each of the aforementioned applications are hereby incorporated by reference in their entireties.


[0002] Embodiments of the disclosed technology can be applied to the optimization of clinical laboratories.


[0003] A clinical laboratory is an organization gathering human and machinery resources to analyze human fluid samples like blood. These laboratories are noticed as one of the principal and preliminary blocks in health services where most of the medical diagnoses and treatments depend on. Therefore, efficiency and effectiveness of these organizations have straight impact on the performance of other dependent health sectors. Furthermore, reducing operating costs in laboratories decreases the cost of treatment and eventually increases patient satisfaction.


[0004] Optimization of clinical laboratory design is a complex problem that, in some cases, may be considered to comprise many decision sub-problems in different levels of decision making with different objectives. Accordingly, there is a need for improved technology for the optimization of such designs. It may thus be an object of some embodiments to provide such optimization via a method implemented on a system comprising at least a processing unit. In some such embodiments, such a method may comprise decomposing an identified problem into a plurality of sub-problems, identifying and defining a relationship between the plurality of sub problems in terms of a set of predefined parameters, evaluating the best possible solutions from amongst a possible set of solutions based on the set of predefined parameters, and providing a ranked list of the evaluated possible solutions for an optimized framework the clinical laboratory.


[0005] FIG. 1 summarizes the principal decision problems of clinical laboratory design and planning and their associated decision making level.

[0006] FIG. 2 schematically illustrates steps that may be performed in some embodiments of the described framework for optimizing the design of a clinical laboratory.

[0007] FIG. 3 depicts a diagrammatic view of an exemplary computer system.


[0008] According to a first aspect, some embodiments may provide optimization of a clinical analysis laboratory via a method implemented on a system comprising a processor. In some such embodiments, such a method may comprise decomposing an identified problem into a plurality of sub -problems, identifying and defining a relationship between the plurality of sub problems in terms of a set of predefined parameters, and providing, via a human machine interface, a ranked list of best possible solutions for optimizing the clinical analysis laboratory.

[0009] According to a second aspect, in some embodiments such as described in the context of the first aspect, the method may comprise evaluating best possible solutions from amongst a possible set of solutions generated from at-least one parameter of the set of pre-defined parameters.

[0010] According to a third aspect, in some embodiments such as described in the context of the second aspect may provide a method that comprises creating the ranked list of best possible solutions.

[0011] According to a fourth aspect, in some embodiments such as described in the context of the first aspect, the set of parameters may include at least one of an objective and/or a constraint and/or performance indicators associated with the problem.

[0012] According to a fifth aspect, in some embodiments such as described in the context of any of the first through fourth aspects, a heuristic methodology and/or a simulation methodology and/or a statistical methodology is used to optimize the clinical analysis laboratory.

[0013] According to a sixth aspect, in some embodiments such as described in the context of any of the first through fifth aspects, the best possible solutions are retrieved from a historical repository.

[0014] According to a seventh aspect, in some embodiments such as described in the context of the sixth aspect, the historical repository may comprise at least one of a structured or unstructured data.

[0015] According to an eighth aspect, some embodiments may provide a system comprising one or more computers configured by computer executable instructions to perform a method as described in any of the first through seventh aspects.

[0016] According to a ninth aspect, some embodiments may provide a system configured to perform the method as described in the context of any of the first through seventh aspects.

[0017] In this disclosure, a systematic scientific approach is described which aids designers and decision makers to efficiently design a clinical analysis laboratory. The described approach is made on the basis of decomposing a complex problem into several sub-problems maintaining the relations between problems. In some embodiments, the described approach may include the following main steps:

[0018] 1. Identifying the sub-problems of which clinical laboratory optimization problem is made: In this step, clinical laboratory optimization problem is decomposed into several sub-problems respecting the relations between them. This step also includes description of sub-problems through defining objective(s), constraint(s), and decision making term of each sub-problem.

[0019] 2. Finding solutions for each sub-problem: Generally, each sub-problem is a decision problem. However, regarding the importance of the decision problem, data availability and other issues and limits, each decision problem can be defined as an optimization problem which is supported in this way by a systematic approach to be solved. In general, a systematic optimization approach explores and evaluates numerous diverse solutions to find one or more efficient solutions. Analytical approaches like mathematical modeling as well as heuristic algorithms and simulation modeling are common methods to tackle optimization problems. For those decision problems which are not defined as an optimization problem, solutions are attainable considering expert’s opinion.

[0020] 3. Selecting a solution from possible alternatives for each decision problem: For each decision problem, several alternatives may exist. In this step, a solution is selected by decision maker based on his or her preferences. Normally, for the first iteration of the optimization procedure, the best found solution or the best expected solution is taken. It is worth mentioning that not only solution of a decision problem answers to a part of clinical laboratory optimization problem but also, it might be the input of one or more other decision problems.

[0021] 4. Aggregating solutions of decision problems to create a global solution for clinical laboratory optimization problem: In this phase, selected solution for all detected sub-problems are gathered to build the first thorough solution for the design of a clinical laboratory.

[0022] 5. Defining key performance indicators (KPIs) to analyze and evaluate the obtained solution: To be able to evaluate and analyze the designed system, appropriate performance measures are necessary. In this phase, important KPIs and critical thresholds are specified.

[0023] 6. Analyzing and evaluating the obtained solution for the design of clinical laboratory through the defined KPIs: A need for a comprehensive model is appreciated in this step which incorporates all the main features of the designed system with required level of details to mimic the performance of the system and provide the possibility to analyze and evaluate the designed system.

[0024] 7. Checking design requirements satisfaction and if needed, following an improvement loop through selecting another solution for one or more decision problems: Obtained KPIs through system evaluation performed in the previous step are analysed, which analysis may in some embodiments be by designer and in some embodiments may be by computer, and compared with values of interest and thresholds. If, the critical values are not satisfied, the proposed initial design may undergo a change or several modifications in order to improve the designed system and the modification loop may be iterated until an acceptable solution is found.

[0025] In addition to, or as an alternative to the iteration described above, in some embodiments, a test may be performed to determine if there may not be an acceptable solution, or if, to the extent an acceptable solution exists, further iterations are unlikely to identify it. For example, some embodiments may be configured to identify if proposed solutions are degrading from iteration to iteration, and may cease iterating in this case even if the best solution found to that point is not acceptable according to the originally specified requirements. Similarly, some embodiments may be configured to identify if certain types of requirements are simply impossible to satisfy and adjust what would be defined as “acceptable” accordingly. For example, when the disclosed technology is used in the context of scheduling tests to be performed on various analysers, if it is not possible to satisfy a turnaround time requirement (e.g., because a tube was delivered late), some embodiments may detect this impossibility using rules, and then alter the definition of“acceptable” from one which includes satisfying the turnaround time requirement to one that makes the test possible at all (e.g., scheduling the relevant test so that it would be completed before the sample had degraded such that the relevant test could no longer be performed). Some embodiments may also, or alternatively, apply this type of approach when the disclosed technology is used for tactical decisions, such as how the analyzers in a lab should be configured. For example, if a throughput requirements for an analyzer configuration program cannot be satisfied with the available analysers (e.g., because the demand for services increased since the analyzers were acquired), some embodiments may recognize this and define the“acceptable” solutions as those that come close to meeting the throughput requirements. Additionally, in some embodiments of this type, when solutions are presented that are determined based on a modified definition of“acceptable” those solutions may be presented along with comments on how the unmet requirements could be met. For example, in the case of analyzer configuration, potential analyzer configurations could be presented along with a note or comment that the throughput requirement could not be met without acquiring additional equipment. Accordingly, the discussion above of embodiments in which solutions are iteratively improved until all critical values are satisfied should be understood as being illustrative only, and should not be treated as limiting.

[0026] Considering the following problems as the main decision issues for design and planning of a clinical laboratory, the steps of the described framework are illustrated afterwards.

[0027] Machine selection problem - In order to equip a laboratory, type and quantity of required equipment have to be determined. Machine selection problem deals with the specification of the type and number of required analyzers and non-analytical machines inside the laboratory to satisfy the demand with the aim of optimizing one or more objectives under certain constraints.

[0028] Personnel requirements problem - Along with the laboratory equipment selection problem, employee requirements is essential to be addressed. Determining the number of full-time employees and in the next step, tasks assignment are crucial problems for clinical laboratories.

[0029] Facility layout problem - Specification the location of each instrument in the laboratory is a key design problem. Facility layout problem is defined as the placement of facilities in a laboratory with the aim of determining the most effective arrangement according to one or more objectives under specific constraints.

[0030] Analyzer configuration problem - In clinical laboratories, analyzers require reagent to be able to perform a test. Analyzer configuration problem deals with the specification of the type and quantity of reagent bottles placed into each analyzer with the aim of optimizing one or more objectives under certain constraints.

[0031] Automation configuration problem - In clinical laboratories, Automation systems output are setup to manage all possible tubes destinations. For a given destination one or more rack positions could be defined and used to sort tubes to a given destimation. e.g. 2 specific rack positions in one output drawer are used to sort tubes to one particular instrument. Automation configuration problem deals with the specification of the number of racks per sorting destination with the aim of optimizing one or more objectives under certain constraints.

[0032] Maintenance Scheduling Problem - In clinical laboratories, analyzers require calibration, quality control and regular maintenance. Maintenance scheduling problem deals with when these types of tasks will be performed.

[0033] Assignment and scheduling problem - Normally, there are more than one eligible analyzer to analyze a test of a sample. Efficient assignment of tubes and tests of tubes to the analyzers in a clinical laboratory is known as assignment problem.

Scheduling problem deals with determining the sequence of tubes on different operational processes.

[0034] Aliquoting problem - In clinical laboratories, there is an option to make more tubes out of one which is called aliquoting. In one hand, beside the costs of aliquoting, it generates more tubes in the laboratory which complicates tube handling and can reduce the effective volume of available fluid due to dead space in each tube used to hold individual aliquots; one the other hand, it provides the opportunity to simplify the sample workflow throughout the laboratory by dispatching the primary and its aliquoted tubes to different destinations for analysis simultaneously instead of sending a tube to different destinations sequentially. To characterize and resolve the aliquoting problem following questions must be answered: Which tubes must be aliquoted? How many aliquots must be created from each aliquoting candidate? How many aliquots can be created without additional dead space materially impacting ability to complete tests? How tests must be assigned to the aliquoted tubes?

[0035] Vehicle routing problem - Patient samples are taken in the collection sites and then, delivered to the examination site by special vehicles. Optimal routing and timing of these vehicles is known as vehicle routing problem (VRP). When addressing this problem, one parameter that may be considered in some embodiments is an objective of avoiding tube overload at reception. In a laboratory, when a tube arrives, various tasks may be performed for that tube, such as verifying that its volume is correct and that it is compatible with the types of test(s) required. In some embodiments, these types of tasks may be performed automatically, in which case reception throughput may be determined based on the capacity of the machine(s) used for performing the relevant tasks. In other embodiments, this may be performed manually, in which case historical information may be used to determine the throughput that could be expected from the personnel responsible for tube reception. However, throughput is determined, it may be accounted for in identifying solutions to the vehicle routing problem, such as by delaying departure from a collection point to avoid multiple sets of tubes arriving

simultaneously and swamping the system, or by having vehicles that would not transport all available tubes so that the tubes that were delivered could be effectively processed. In this way, some embodiments may improve the operation of laboratories by, for example, reducing the need for racks and other types of hardware that would otherwise be necessary to store tubes as they waited for the necessary reception resources to be available.

[0036] Turning now to the figures, FIG. 1 summarizes the principal decision problems of clinical laboratory design and planning and their associated decision making level.

[0037] Alongside the aforementioned problems, determining a proper quality control

(QC) policy for analyzers, and a suitable sample drawing policy in collections sites can be considered as other important clinical laboratory decision problems.

[0038] FIG. 2 schematically illustrates steps that may be performed in some embodiments of the described framework for optimizing the design of a clinical laboratory.

Regarding the decision making level of the identified decision problems, problems are tackled one after another starting from strategic level, then tactical and finally operational. For each problem, plenty of solutions may be proposed such as by using various heuristics, by using an optimization method or by turning to expert opinion. Generating several solutions for a problem relies on the method used to deal with the problem. For instance, to select the required machines to equip a laboratory through a mathematical model, someone can overestimate the demand

(as an input parameter), use statistics to determine expected worst case and average demand over a relevant period of time, or involve his or her own knowledge and experience while building the solutions. In FIG. 2, the circles under the names of each problem represent the best possible alternatives from decision maker perspectives. In addition, circles above the “Simulation model of clinical laboratory” block, which correspond to the leftmost circles under the names of the various problems, show the selected solutions for the first iteration of the disclosed optimization procedure. Gathering all these solutions provides the ability of making a complete clinical laboratory. To analyze and evaluate the designed clinical laboratory, simulation modeling is a suitable candidate as it is capable to take into account system’s main characteristics and enable to compute system’s KPIs. This step is presented through the box labelled“simulation model of clinical laboratory” in FIG. 2. System throughput, test turnaround time, number of tardy tests or tubes could be some good examples as clinical laboratory KPIs. These measures are analyzed by designer and in some cases, compared with threshold to decide whether the proposed design is acceptable or not. This step is shown through the diamond shown in FIG. 2. If the design is acceptable from designer perspective, the optimization procedure is terminated, otherwise, modifications in design parameters could be helpful to ameliorate the system design and improve its performance. As an example, someone can propose another scheduling policy that might enhance system performance which finally leads to an acceptable design. As another example, someone might select other type of machines to equip the laboratory. In this case, machine selection problem undergoes a change which impose inevitable changes to the linked problems as well as problems in the lower decision making levels (tactical and operational). Generally, simulation model is able to provide a clear insight to the designed system through presenting the system bottlenecks and its components statistics which all help the decision maker recognizing target problems for making loops and performing better changes to problem solution. The disclosed optimization framework is iterated until achieving a satisfactory design.

[0039] FIG. 3 illustrates an exemplary computer system 49 that may be used in some embodiments. Computer system 49 may include a processor 51, a memory 53, a mass storage memory device 55, an input/output (I/O) interface 57, and a Human Machine Interface (HMI) 59. Computer system 49 may also be operatively coupled to one or more external resources 61 via a network 63 or I/O interface 57. External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud-based network services, or any other suitable computer resource that may used by computer system 49.

[0040] Processor 51 may include one or more devices selected from microprocessors, micro-controllers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, or any other devices that manipulate signals (analog or digital) based on operational instructions that are stored in memory 53. Memory 53 may include a single memory device or a plurality of memory devices including, but not limited, to read-only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or any other device capable of storing information. Mass storage memory device 55 may include data storage devices such as a hard drive, optical drive, tape drive, non-volatile solid state device, or any other device capable of storing information.

[0041] The I/O interface 57 may provide a machine interface that operatively couples processor 51 to other devices and systems, such as network 63 or external resource 61. Application 67 may thereby work cooperatively with network 63 or external resource 61 by communicating via I/O interface 57 to provide the various features, functions, applications, processes, or modules comprising embodiments of the invention. Application 67 may also have program code that is executed by one or more external resources 61, or otherwise rely on functions or signals provided by other system or network components external to computer system 49. Indeed, given the nearly endless hardware and software configurations possible, persons having ordinary skill in the art will understand that different versions of the invention may include applications that are located externally to computer system 49, distributed among multiple computers or other external resources 61, or provided by computing resources (hardware and software) that are provided as a service over network 63, such as a cloud computing service.

[0042] HMI 59 may be operatively coupled to processor 51 of computer system 49 in a known manner to allow a user to interact directly with the computer system 49. HMI 59 may include video or alphanumeric displays, a touch screen, a speaker, and any other suitable audio and visual indicators capable of providing data to the user. HMI 59 may also include input devices and controls such as an alphanumeric keyboard, a pointing device, keypads, pushbuttons, control knobs, microphones, etc., capable of accepting commands or input from the user and transmitting the entered input to the processor 51.

[0043] A database 71 may reside on mass storage memory device 55, and may be used to collect and organize data used by the various systems and modules described herein. Database 71 may include data and supporting data structures that store and organize the data. In particular, database 71 may be arranged with any database organization or structure including, but not limited to, a relational database, a hierarchical database, a network database, or combinations thereof. Further, in some embodiments a database 71 may also, or alternatively, include unstructured data, such as binary large objects (BLOBs). A database management system in the form of a computer software application executing as instructions on processor 51 may be used to access the information or data stored in records of the database 71 in response to a query, where a query may be dynamically determined and executed by operating system 65, other applications 67, or one or more modules.

[0044] To illustrate how a computer system 49 such as depicted in FIG. 3 could be used in implementing the disclosed technology, consider an embodiment in which solutions are generated using a historical repository of potential solutions stored in a database such as the database 71 of the computer system 49 of FIG. 3. In such an embodiment, to generate solutions to a problem, a computer system 49 could initially use a distance metric between the configuration for which the problem was being solved and the configurations in the repository to identify historical configurations that could potentially be applied. For example, in a case where the disclosed technology was being used to determine the placement of instruments in a lab, factors such as square meters of available floor space, shape of instruments, location of entry, and number of instruments could be treated as dimensions, and historical configurations that were closest to the current configuration on each of the dimensions could be treated as being potentially applicable. These potentially applicable solutions could then be evaluated by means of simulation in which each of the potentially applicable historical configurations would be applied in the current circumstances and the simulation would be used to determine how those configurations as applied achieved (or failed to achieve) the relevant KPIs. Based on this determination, a short list of the highest performing solutions that were most different from each other (e.g., as determined using a distance metric as described above) could be presented to a user (e.g., via a HMI 59) so that he or she could make any necessary adjustments to account for issues not addressed in the simulation and decide which of the historical solutions would make the most sense for the current circumstances.