Method and system for design and maintenance of complex, multimodule, random access, clinical laboratory automation systems

Abstract

A method for designing an automation system having a plurality of nodes in an IVD environment is provided. The method can include receiving system requirements, receiving node requirements, receiving node information for at least one of the nodes, and determining a number of modules that together can achieve the node requirements based on the node information for the at least one of the nodes. At least one of the node requirements is based at least in part on one of the system requirements.

Description

METHOD AND SYSTEM FOR DESIGN AND MAINTENANCE OF COMPLEX, MULTIMODULE, RANDOM ACCESS, CLINICAL LABORATORY AUTOMATION SYSTEMSCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 637,862, entitled “A METHOD TO ENSURE DESIGN AND MAINTENANCE OF COMPLEX, MULTI-MODULE, RANDOM ACCESS, CLINICAL LABORATORY AUTOMATION SYSTEMS ACHIEVE OPERATIONAL PERFORMANCE REQUIREMENTS” filed April 23, 2024, the disclosure of which is hereby incorporated by reference in its entirety for all purposes.TECHNICAL FIELD

[0002] The present disclosure relates generally to the design and maintenance of complex multi-module, random access, laboratory automation systems (which may be referred to herein as “complex laboratory automation systems”) and, in particular, methods for designing and maintaining these systems to achieve operational performance requirements.BACKGROUND

[0003] Due to the criticality of timely diagnosis and treatment of patients, a primary goal of any clinical laboratory is completion of quality patient sample results within a defined timeframe. Historical practice within the clinical diagnostics community has been to require a supplier meet requirements based on uptime of the equipment, with the logic that, given the advertised or actual throughput capabilities, a system that is not down for receiving and processing patient sample tubes (hereafter “tubes”), should meet their needs. They often choose a single arbitrary goal that is not based on data linked to their primary goal. For example, a customer may contractually require a vendor to supply a piece of equipment that operates with at least a 98% uptime over an established period of time. In addition, uptime itself can be defined in various ways, making for some difficulty in measurement. An insufficient system design based on assumptions and arbitrarily chosen performance criteria can result in failure to meet the primary goal of timely completion of patient test results for the customer and the physicians they support, and financial penalties for the supplier.

[0004] Despite the importance of performance requirements, historical convention is that system design is non-rigorous and does not utilize reliability engineering principles. For example, historically during system design the number of modules required to meet a capacity requirement is determined and then typically an additional module is added to ensure that the customer uptime requirement is achieved. This conventional approach can result in over capitalization of a system (i.e., more redundant modules than necessary) or under capitalization (i.e. , fewer redundant modules than necessary). An over capitalized system increases both the system’s upfront and life-cycle support costs, making it less competitive in the market. An under capitalized system decreases the system’s cost upfront but compromises on the system’s ability to meet the customer’s required uptime performance. Classical Reliability Engineering analysis can be employed to address the shortcomings of historical, conventional design, of complex laboratory automation systems, but requires some novel adaptations to address the specific needs of a complex laboratory automation system. Through the appropriate adaptations the system analysis can ensure adequate production capacity exists (i.e., enough modules of each type are included), while simultaneously avoiding over capitalization of the system (i.e., more modules of the same type than required), and while taking into account the uptime of each module type.

[0005] Once a complex laboratory automation system is installed and operational, conventional methods typically monitor system performance by reporting the average uptime of each system node over a period of time and assessing it against the single performance requirement, e.g., 98% or greater uptime used as a design requirement. However, given that a complex laboratory automation system leverages a high number of similar modules to work efficiently, even when some modules are in an error state, that each type of module provides a different contribution to the overall system performance, and that there are several contributors to module uptime that are not related to a module failure; a single performance requirement used for all modules is not sufficient to have an accurate understanding of the complex laboratory automation system’s performance or to appropriately prioritize interventions. For example, conventional methods can misidentify problem areas, which can cause wasted time and effort for both production and maintenance staff.

[0006] The present disclosure is directed to overcoming these and other problems of the prior art.SUMMARY

[0007] Embodiments of the present invention address and overcome one or more of the above shortcomings and drawbacks, by providing methods for designing and maintaining a complex laboratory automation system having multi-modules.Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying drawings.

[0008] In an exemplary embodiment, a method for designing an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment is disclosed. The method includes receiving system requirements; receiving node requirements, where at least one of the node requirements is based at least in part on one of the system requirements; receiving, for at least one of the nodes, node information; and determining, for the at least one of the nodes, a number of modules that together can achieve the node requirements based on the node information.

[0009] In another exemplary embodiment, a method of maintaining an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment, wherein at least one of the plurality of nodes has a plurality of modules is provided. The method includes determining that an actual node performance of the at least one of the plurality nodes is unacceptable based at least in part on a comparison, for at least one of the plurality of modules, an actual module performance to an historic module performance; and performing a corrective action on the at least one module of the plurality of modules.

[0010] In yet another exemplary embodiment, a method of maintaining an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment is provided. The method includes determining for each of the plurality of nodes, that a respective actual performance is unacceptable; calculating, for each of the plurality of nodes, a respective weighted score based at least in part on a respective load share; prioritizing one or more corrective actions for each of the plurality of nodes based on the respective weighted scores; and performing the one or more corrective actions for one of the plurality of nodes according to the prioritization.

[0011] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additional features and advantages of the disclosed technology will be made apparent from the following detailed description of illustrative embodiments that proceeds with reference to the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The foregoing and other aspects of the present invention are best understood from the following detailed description when read in connection with the accompanying drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments that are presently preferred, it being understood, however, that the invention is not limited to the specific instrumentalities disclosed. Included in the drawings are the following Figures:

[0013] FIG. 1 is a diagram of a complex laboratory automation system, according to an embodiment of the disclosure;

[0014] FIG. 2 is a flow chart illustrating a method of designing a complex laboratory automation system, according to an embodiment of the disclosure;

[0015] FIG. 3 is a diagram of a system with N modules in series, according to an embodiment of the disclosure;

[0016] FIG. 4 is a diagram of a node with N modules in parallel, according to an embodiment of the disclosure;

[0017] FIG. 5 is a table showing the inputs to and results of using the method described with reference in FIG. 2, according to an embodiment of the disclosure;

[0018] FIG. 6 is a flow chart illustrating a method for performance monitoring of a complex laboratory automation system, according to an embodiment of the disclosure;

[0019] FIG. 7 is an example of using an Unavailability KPI contrasted against conventional system monitor to show the superiority of the Unavailability KPI, according to embodiments of the disclosure;

[0020] FIG. 8 is a flow chart illustrating a method of prioritizing remedial, corrective and preventive actions of nodes, according to an embodiment of the disclosure,;

[0021] FIG. 9A is a table showing system compliance to availability requirements using the Unavailability KPI, according to an embodiment of the disclosure; and

[0022] FIG. 9B is a table showing a rank ordered list of non-compliant system nodes for corrective action prioritization, according to an embodiment of the disclosure.DETAILED DESCRIPTION

[0023] Independent of the grammatical term usage, individuals with male, female or other gender identities are included with this term.

[0024] The methods described herein are practical applications of the concept for applying reliability engineering principles to designing complex laboratory automation systems, including, for example, high availability factory laboratory automation systems, and performing performance monitoring and maintenance of those systems. They are comprehensive approaches to designing and monitoring multimodule equipment, like clinical laboratory diagnostics automation systems, to ensure customer design requirements for, e.g., capacity and availability, are achieved. The methods described rely on applications of reliability engineering principles for the analysis of complex systems consisting of both parallel and series nodes.

[0025] The methods disclosed herein can be used to design a complex laboratory automation system to meet a performance requirement, to assess the performance of a complex laboratory automation systems, and to prioritize maintenance of nodes of multi- complex laboratory automation systems. They can account for difficult to predict environmental impacts of the operational environment by the use of historical field performance data; provide an easy to understand, actionable, performance indicator; account for random access workflows allowing the various pre-analytical, analytical, and post-analytical process steps to be uniquely tailored for a specific customers’ need. With respect accounting for random access workflows, complex laboratory automation systems can be customized to meet the specific workflow needs of a customer. The workflows are not forced into a discrete single process configuration, the configuration is based on an amalgamation of random processes configured specifically for a customer’s specific need. To illustrate, compare an automated factory that is not random access (e.g., filling a beverage container) to an automated factory that is random access. Filling a beverage container is constrained sequential process. Every container goes through the same defined set of processsteps. Such a process could be multi-module, bottle washing module, bottle filling module, bottle capping module, bottle labeling module, bottle crating module, etc. The random access situation is different. A patient goes in for an annual physical, and the doctor orders a CMP (Comprehensive Metabolic Panel), a CBC (Complete Blood Count), and a Thyroid Panel. These tests would likely be run on the different analyzers, the CMP on a chemistry analyzer, the CBC on a Hematology analyzer, and the Thyroid panel on an Immunoassay analyzer. Where a patients tube gets routed depends on what the doctor ordered. T ubes that enter the system sequentially may take very different paths through the system and exit at different times.

[0026] It can be important to use an appropriate performance requirement for a variety of reasons. For example, it can be important from a service efficiency standpoint because tracking and reporting a system’s performance relative to a performance requirement can drive service and other related efforts. It can also be important because there may be financial penalties when the complex laboratory automation system fails to achieve the performance requirement. However, while a single performance requirement may be effective for simple configurations of standalone or non-modularized systems, it may not be effective for an accurate understanding of a complex laboratory automation system or be a good predictor of its ability to meet the workload completion target.

[0027] As mentioned above, a single arbitrarily chosen performance requirement used for all modules may not be effective to appropriately prioritize interventions of complex laboratory automation systems. One purpose of an effective performance requirement is to identify underperforming nodes (whether the node be a single- or multi-module node) that need to be addressed in order for the primary goals to be achieved. If a node fails to achieve its performance requirement, it may trigger maintenance to be performed on the node, as applicable. However, there can be some situations where a node could achieve the performance requirement in theory, but does not due to external or human induced factors (e.g., delayed actions, poor quality samples) that can impact its performance. Thus, even though the node does not achieve the performance requirement, an intervention (e.g., redesign or maintenance investigation) may not solve the problem.

[0028] The opposite can also be true. A node that achieves an arbitrarily chosen performance requirement may not trigger any maintenance activities or otherremedial efforts. This is even the case if the node’s performance is deteriorating or is lower than assumed at design. In this way, using a single arbitrary performance requirement can hide performance of a module and / system node that could later negatively impact production capability, trigger financial penalty or lead to a more serious issue with prolonged downtime.

[0029] As described in above, the historical practice in the clinical diagnostics community has been to specify an uptime performance requirement, often without clearly defining what is meant by uptime. The present disclosure uses “availability” rather than “uptime” as the preferred reliability requirement. For clarity the present disclosure uses “uptime” to mean a composite measure of operation availability and dependability that includes the combined effects of item design, quality, environment, operation, maintenance, repair, and logistic support. “Availability” is defined here as uptime minus planned and scheduled downtime (e.g. facility closed on Sundays), planned preventive maintenance, planned updates and upgrades. Both uptime and availability can be influenced by a variety of factors, including, for example, proper maintenance (including the timely analysis and fix of recurring issues), waiting time (i.e., unattended time before starting the recovery), proper recovery execution (i.e., correct and timely), external factors (e.g. use of unapproved tube types, improper attachment of patient identification labels, and tubes where serum or plasma has been spilled on the tube exterior making it sticky), and module failures.Conventionally, a single performance requirement, e.g., 98% uptime, is compared to either the average of each system node’s uptime or the entire complex laboratory automation system’s uptime.

[0030] The present disclosure describes methods to design a complex laboratory automation system to meet a performance requirement, to assess the performance of a complex laboratory automation system versus requirements, and to prioritize maintenance of nodes to ensure performance requirements are achieved. In some embodiments, the methods described herein can be used, for example, to design and maintain an in vitro diagnostics (“IVD”) system. For example, in some embodiments, the methods described herein can be used to design IVD systems that include instrumentation such as automated clinical chemistry, immunoassay, hematology and urinalysis analyzers. These analyzers can process millions of human sample diagnostic tests per year with the largest processing millions of tests per year. These tests can be prescribed to a patient by a - Primary Care Physician,PCP (e.g., general health checkup), a specialist (e.g., Cardiologist, Oncologist, etc.), or in a hospital setting (e.g., prior to treatment or surgery).

[0031] FIG. 1 is a diagram of a complex laboratory automation system 100, according to an embodiment of the disclosure. A complex laboratory automation system can include several modules. A module can be a piece of equipment that is designed to perform one or more processes. In FIG. 1 , each block with an alphanumeric designator represents a module. The one or more processes that the module can perform defines its “type.” The following are illustrative examples of module types in an IVD environment: tube sorter, tube loader, tube cap remover, tube storage, bar code reader, centrifuge, and analyzer.

[0032] Each module may be in series with or in parallel with another module. For example, in FIG. 1 , modules A1 , A2, and A3 are in parallel with each other, and modules D1 , D2, and D3 are in series with each other.

[0033] Each complex laboratory automation system has one or more system nodes. A system node can be a single module when modules are arranged in series, or two or more modules of the same type that are in parallel with each other. Referring to FIG. 1 , modules A1 , A2, and A3 are the same type. Because they are the same type and they are in parallel with one another, together, they form a system node. Modules D1 , D2, and D3 are each distinct system nodes.

[0034] FIG. 2 is a flow chart illustrating a method 200 of designing a complex laboratory automation system, according to an embodiment of the disclosure. The method 200 described with reference to FIG. 2 is a robust approach to designing a complex system like a complex laboratory automation system around one or more performance requirements, workload definition, and production timeframe. This approach can be used to design a complex laboratory automation system with the appropriate level of redundancy (i.e. , to yield a system design that is not over capitalized or under capitalized) to achieve the required workload and availability during a defined production period. As will be described with reference to FIG. 6 below, these same performance requirements can later be used to monitor performance of the system.

[0035] The method 200 described herein with respect to FIG. 2 begins with the customer’s requirements, followed by receiving relevant engineering data from suppliers of the various system modules. In some embodiments, this engineering data is supplemented by actual historic performance data (e.g. historic uptime)where such data is available. From these input parameters and data the number of modules required for each system node is calculated to ensure that the system capacity requirement is achieved. Next, the reliability analysis is performed to determine if the availability requirement is met. Typically, it is necessary to add redundant (i.e. , spare) modules to each system node to achieve the availability requirement. This allows for the completion of a proposed system design such that the initial capital cost and life-cycle support costs can be estimated and reviewed with the customer.

[0036] At step 201 the method 200 can include receiving the customer requirements for system capacity, availability, desired daily production hours, and workflow distribution. Also determined from customer data is the workload distribution that comprises the required system capacity. In some embodiments, system capacity can be stated as the number of tubes to be processed each production day, e.g., 100,000 tubes / production day. Availability can be generally stated as the overall effective availability of the entire system. For example, a required capacity can be 100,000 tubes in a 12 hour production day. The customer can also specify a required overall availability of the system so that the customer can meet their Service Level Agreements (“SLA”) with physicians or hospitals. For example the SLA may be to provide testing results on > 98% of all patient samples submitted by 20:00 the prior day no later than 08:00 the following morning. In this example, assuming the customer loads 100,000 tubes by 20:00, an availability of 98% or greater is required to meet the SLA. Daily production hours are the customer’s planned hours for running the system at or near its stated capacity.Customers may run the system additional hours each day, at a substantially reduced capacity, to process STAT tubes where the result is needed immediately for medical reasons. Workflow distribution refers to how the capacity requirements are spread across the system nodes and time.

[0037] As described above, a clinical diagnostics laboratory automation system can be comprised of a variety of analyzer types such as clinical chemistry, immunoassay, hematology and urinalysis analyzers, for example. Most tubes will not require tests performed by all of these analyzer types. For example 80% of tubes may need to be presented to a clinical chemistry analyzer, 60% to an immunoassay analyzer, 20% to a hematology analyzer, and 10% to a urine analysis system. These percentages can vary widely depending on the patient populationbeing served, for example is the served group the general population of healthy people having a routine physical, a primary care hospital, or a tertiary care hospital specializing in a dialysis, cardiology and oncology care. It should also be recognized that since the system allows random access to processing steps as required by each individual tube it happens that system operators can create unexpected workflows in an ad hoc fashion, fortunately these ad hoc workflows are typically small and less than 1 % of the total tubes processed. In addition to specifying how the workload is distributed across analyzer types the customers can also specify how they expect the system workload to vary over the production day. For example in the prior example of a 12 hour production day and a workload of 100,000 tubes, the customer may expect to load 8,333 tubes each hour for 12 hours or the workload could be weighted toward the beginning, end, or middle of the production day.

[0038] At step 202 the method 200 can including receiving engineering data from, for example, the suppliers of each system module. These data can include module capacity (typically stated at a theoretical uptime of 100%) and claimed module uptime (third-party suppliers of system modules typically specify an uptime claim, as an availability claim depends on the specific production schedule that applies to a system).

[0039] At step 203 the method 200 can include receiving historic module availability data from the existing installed base of each module type are considered (these data are typically not available from third-party suppliers of modules and as such are limited to internally collected data). In some embodiments, the method 200 can use the average historic availability of all like modules in a similar installed base during production timeframes, without removal of any factors that cause unscheduled downtime. This approach yields an average availability of a module that is burdened with the various real-world factors that serve to reduce availability while in production use. This means that factors such as quality of tubes provided by the customer’s phlebotomy and transport processes, wait time to address an unscheduled maintenance issue, typical repair times during production, environmental and people impacts are built into the expected availability of the module providing a more realistic assessment of expected performance. If no historic module availability data is available because, for example, the module is new, design data be used instead.

[0040] At step 204 the customer requirements from step 201 and the engineering data from step 202 are used to calculate the minimum number of modules (N-K) required in each system node to deliver the stated system capacity when also considering the workflow distribution across the node and the historical availability of each module. The following equation can be used:(Equation1) whereSysCap = system capacity requirement (tubes / day)Production = production day requirement in (hrs / day)NodeLoadShare = node load share as a % of total System Capacity(%)A= historic module availability (%)ModCap = module capacity (tubes / module / hr)Fractional results should be rounded up to the next higher integer.

[0041] As used herein, “N” refers to the total number of modules in a system node and “K” refers to the number of redundant, or spare, modules in a system node. A redundant module is a module that can fail without causing the system node to fail to achieve its capacity and availability requirements. For example, a complex laboratory automation system cannot achieve a 98% availability unless all of its system nodes can achieve that availability. However, as one of ordinary skill in the art will appreciate, not all modules in a system node need to achieve a 98% availability in order for the system node as a whole to achieve a 98% availability. Instead, one system node may have an availability less than 98% while another may have an availability greater than 98% or more commonly redundant modules are employed to achieve the required availability requirement.

[0042] At step 205, the method can include determining the number of redundant modules to include in the system node. When a system node includes an appropriate number of redundant modules, K (i.e. , without over or under capitalization), the system node can continue to meet its availability requirement even if K modules are unavailable. It is important to note that the modules themselves are not categorized as either “required” or “redundant.” Instead, any of the modules in the node can be redundant. Consider the following example: If N-K was calculated to be eight and one spare module (M) was needed to achieve theavailabi lity requirement, N is now nine. Any one of the 9 can fail and the node will still achieve its required availability.

[0043] In some embodiments, step 205 can include assessing the reliability of series and parallel system modules. This provides the designer with the information needed to assess the need for redundant modules (K) and select the appropriate number of redundant modules needed to ensure the system’s ability to deliver the required capacity and workflow distribution in the scheduled production hours while achieving availability requirements, and without over capitalizing the system. Special consideration can be given to the level of redundancy in a system node based on the system node’s residual capacity, weighted availability (i.e., the system node’s influence on the complex laboratory automation system based on workload distribution percentages), and the system node’s impact on other system nodes. To illustrate, in some embodiments, redundancy may not be warranted for a module that has a high expected availability (i.e., equal to or greater than the availability requirement) and / or processes a small load share of tubes presented to the complex laboratory automation system. Alternatively, for customers looking to lower cost, a lower level of availability with less redundancy may be an acceptable design. This is especially true for a module with post analytic capability and a small load share of tubes. The specific calculations involved are described below.

[0044] At step 206 the method can include documenting the number of modules required in each system node and the expected availability. In many cases the expected design availability will be greater than the customer requirement and can be used as a KPI to identify system degradation before the customer becomes aware of a problem. Furthermore the designer can simultaneously ensure that system cost is optimized by neither under- or over-capitalizing the system. Going forward the method 200 can be used to revise or expand existing systems when capacity needs, availability requirements, workload distribution, or production timelines change.

[0045] In some embodiments, the methods disclosed herein operate under the theory that all ways that a module is used by a laboratory customer will be similar, that no operation of a system will be perfect, that human error exists and cannot be controlled, and that labor will never be able to address an issue exactly when it occurs, so there will always be delays in correcting them. By using historicavailability, one can understand true expected availability based on typical use scenarios.

[0046] The average historic availability measured across a large installed module base, and where all downtime events, repair and unscheduled maintenance time during production hours are included reflects the average “real-world” performance of the module. In other words, historic availability may include misuse that are typical of the laboratory environment. Thus, historic uptimes may be quite lower than what one might consider optimal because no disparaging data is removed. Not having to parse out data from a data set is an advantage because it can be difficult to go back later through a data set and remember what occurred and if the data surrounding an incident should be included. This also can become a point of contention between the customer and the vendor.

[0047] When historic uptimes are determined or baselined periodically the disparate numbers get lost in the averages. Too significant a negative change in the historic averages would warrant an investigation. As this metric is an average it is possible that in a specific system embodiment performance can vary from the average. As the installed base of a module grows to be large enough to calculate a standard of deviation, standard statistical techniques can be applied to construct a confidence interval on the modules performance. It is also important to take into consideration continuous improvement efforts that improve module performance over time. For this reason historic availability should be evaluation periodically, e.g. annually to ensure its validity for ongoing use.

[0048] A complex laboratory automation system can be analyzed by breaking it down into a combination of series and parallel modules and including redundancies in nodes to ensure the required availability is achieved, as is described in the following paragraphs.

[0049] FIG. 3 is a diagram of a system 300 with / V modules or nodes in series, according to an embodiment of the disclosure. The following equation can be used to calculate the availability of the system diagramed in FIG. 3, where i = 1 , 2, 3, . . . N:(Equation2) where Asystem is the availability of the system shown in FIG. 3, N is the number of modules in a system, and A is the historic availability of a module.

[0050] FIG. 4 is a diagram of a node 400 with N modules in parallel, according to an embodiment of the disclosure. The following equation can be used to calculate the availability of the node diagramed in FIG. 4: tionwhereAnode is the availability of the node shown in FIG. 4 N is the total number of modules in the system node K is the number of modules that can fail, by operating at an availability less than the historic availability (A), with the node still able to meet its workload and availability requirements.

[0051] Referring back to FIG. 1 , FIG. 1 is a diagram of a complex laboratory automation system 100, according to an embodiment of the disclosure.

[0052] In some embodiments, a complex laboratory automation system 100 can have multiple workflows that are tailored to the needs of the specific testing required for, e.g., a patient sample workload. In some embodiments, the complex laboratory automation system 100 can process the workload through customized workflows on a random-access basis. To assess the impact of these random-access workflows, the methods disclosed herein consider the aggregate number of tubes following a given workflow over a specified period of time (e.g., an hour or day). For example, in the simplified system shown in FIG. 1 (actual large systems can have hundreds of nodes and 20 or more workflows), some portion of the workload can flow through nodes A, B, C, D, E, F, G, H and J. The impact of each branch on the complex laboratory automation system’s availability can be the ratio of the branch’s workload to total workload. Referring still to FIG. 1 , the availability of node (A, B, E, H, J) or multi-node branch (CD and FG), can be calculated using Equations 2 and 3, above.

[0053] FIG. 5 is a table showing the inputs to and results of using the method described with reference in FIG. 2, according to an embodiment of the disclosure. In FIG. 5, the following key applies: information in bolded text is an input, information in italicized text is calculated from the inputs, and information in normal text is calculated using both input data and the italicized calculated values. As illustrated in FIG. 5, given the inputs (module / node type, node load share, historic module availability, and the module capacity) the minimum number of modules required (N-K) can be calculated from Equation 1. Using Equation 2 for modules ornodes in series and Equation 3 for an node with modules in parallel the predicted availability and be calculated, and if needed redundant modules (K) added to achieve the required availability.

[0054] In some embodiments, the number of redundant modules (K) can be calculated by iteratively calculating the availability of a node with a certain number of redundant modules, comparing that calculated value to the desired availability, and adjusting the number of redundant modules to calculate availability. If calculated availability is greater than the desired availability, the process can be performed again with a lower number of redundant modules, and if the calculated availability is lower than the desired availability, the process can be performed again with a larger number of redundant modules. This calculation can be repeated iteratively until the appropriate number of redundant modules is determined, i.e., the lowest number of redundant modules necessary to meet the desired availability.

[0055] Returning to FIG. 2, at step 206, the method 200 can further include providing the number of modules each system node needs in order to meet its workload and availability requirements. In some embodiments, the method 200 can optionally include determining that the system node has more additional modules than is needed its workload and availability requirements, and removing those excess modules from the system node. In some embodiments, the method 200 can further include using the complex laboratory automation system with the provided modules to perform a workload.

[0056] The methods disclosed herein were validated using data collected from large factory-scale automated clinical laboratory sites. The validation showed that the methods herein provided a truer measure of module performance for each module than conventional methods and therefore result in a more robust system design.

[0057] In some embodiments, complex laboratory automation system designed in accordance with the method 200 is provided.

[0058] FIG. 6 is a flow chart illustrating a method 600 for performance monitoring of a complex laboratory automation system, according to an embodiment of the disclosure. Instead of using a single performance requirement, in the method disclosed herein with reference to FIG. 6, each system node has its own performance requirement to which its actual performance is compared. In some embodiments, the performance requirement may be one of the system node’sdesign requirements, for example, availability. As one of ordinary skill in the art will appreciate, one or more system nodes may have the same or different performance requirements. This method can allow a user to identify those system nodes that are not performing up-to design specification (e.g., the historic availability) and provides an easy-to-understand indicator that highlights problem areas that need attention to improve overall system performance.

[0059] In some embodiments, the complex laboratory automation system and its nodes may be designed a least in part based on historic availabilities, as described above with respect to FIG. 2. In such embodiments, the expectation can be that that newly designed system nodes will perform at least at the historical level and likely better than historical due to continuous improvement efforts. As one of ordinary skill in the art will appreciate, if a system node will meet its availability requirement when it performs at least at its historic availability (as is the case if it is designed in accordance with the method of FIG. 2), it may not meet its availability requirement when it performs at a level less than its historic availability. Thus, it can be desirable to know when a system node’s actual availability does not achieve its historic availability so that corrective action can be taken to restore the system node to at least its historic availability. Therefore, in some embodiments, the system node’s performance requirement can be the system node’s historic availability. By using the system node’s historic availability, non-module related contributors (e.g., misuse) need not be filtered out as they represent how a system will more realistically need to function in the laboratory working environment. Use of this method can inform a user whether, during production / operation, system performance is degrading and at some point may fail to complete the daily workload during normal production hours, unless corrective action is taken to restore system performance.

[0060] At step 601 , the method 600 can include measuring the system node’s actual availability. The system node’s actual availability can be the system node’s recent availability over a period of time. For example, in some embodiments, the system node’s actual availability may be its availability during the previous month. Typically the period of time over which the historic availability is determined is longer than the period of time over which the actual availability is determined. For example, the historic availability may be determined over a year or longer, while the actual availability may be determined over a month or less.

[0061] To further explain this point, it can be desirable to have a large data set for historical availability, whereas for actual current availability the time interval may be kept small enough to allow the user to react to system degradation before failure occurs. For example, in some embodiments, historic availability should have at least a quarter of data and up to a year. Actual should likely be measured weekly or daily, or both.

[0062] In some embodiments, the average availability per module can reported by the system software. As described earlier error states are not filtered so that any module in an error state (regardless of the type of error state) is considered down, and any module online is considered up. For example, referring to FIG. 5., node F has 6 modules (N=6), these are F1 , F2, F3, F4, F5, and F6. The current availabilities measured are as follows: F1=98%, F2=94%, F3=90%, F4=91 %, F5=93%, and F6=92%.

[0063] At step 602, the method 600 can include rank orders all N modules of a system node by the actual current availability as obtained in step 701 . Using the example from the preceding paragraph, a rank ordering yields: F1=98%, F2=94%, F5=93%, F6=92%, F4=91%, and F3=90%.

[0064] At step 603, the method 600 the method can include removing K modules having the lowest availability from the module data set. Referring to node F in FIG.5, K=2. Therefore, the two modules having the lowest availability (F3 (90%) and F4 (91%)) are removed from the data set. The logic here is that K=2 means that two redundant modules exist and are allowed to fail (in this case failure means having an availability less than the historic module availability of 93%).

[0065] At step 604, the method 600 can include determining the system node’s “Unavailability KPI”. This can be done by comparing the actual current availability of the remaining N-K modules to the historic availability used to design the system. Mathematically the comparison is stated below in Equation 4. If the actual current availability, Ac, is less than the historical availability, A, then the equation reports A- Ac. If the actual current availability, Ac, is greater than the historical availability, A, then the equation reports 0. tion

[0066] Referring back the example of node F, for which historical availability is A=93%, each node has the following Unavailability KPI:F1 , A (93%) <Ac (98%) Unavailability KPI= 0%F2, A (93%) <Ac (94%) Unavailability KPI= 0%F5, A (93%) >Ac (93%) Unavailability KPI= 0%F6, A (93%) >Ac (92%) Unavailability KPI = 1%

[0067] The unavailability for node F is the sum of the unavailabilities of each of its modules, a total of 1 %.

[0068] An advantage of using the Unavailability KPI can be demonstrated by looking at the example shown in FIG. 7. FIG. 7 presents two simple nodes, ALPHA and BETA, each having three modules arranged in parallel, according to embodiments of the disclosure. Using the traditional approach of averaging the module availabilities gives 98.0% for ALPHA and 97.7% for BETA. The conclusion would be that ALPHA was performing well with no maintenance required and that BETA was performing below expectation and a maintenance technician would be deployed to address the problems. Using the Unavailability KPI provides the opposite conclusion. Using the Unavailability KPI, it is ALPHA that needs maintenance as only one of the two required modules is performing at the requirement of 98.0% or greater. BETA is performing acceptably. The maintenance technician will be deployed to address the performance of modules 2 and 3 on ALPHA. In some embodiments, when the APLHA problems are resolved, the technician can be assigned to work on BETA as module 3 is performing below target. While these conclusions are easy to see in a three-modules example, complex systems can have 100 or more modules so having automated tools to highlight problem areas is helpful to rapid resolution.

[0069] FIG. 8 is a flow chart illustrating a method 800 of prioritizing remedial, corrective and preventive actions of system nodes, according to an embodiment of the disclosure. Corrective action efforts require a prioritization schema as multiple nodes may have non-zero unavailabilities and require corrective action. FIG. 8 presents an approach for prioritizing corrective action effort. In some embodiments, the method 800 uses the Unavailability KPI of method 800 and Equation 4 along with each system node’s share of the workload in a prioritization schema for remedial and corrective action.

[0070] Conventional methods monitor system performance by reporting the average uptime of each system node and assessing the average performance against a single performance requirement, e.g., 98% or greater uptime. However,given that a laboratory automation system is a complex system that leverages a high number of similar modules to work efficiently and at a high level of reliability, even when some modules are in an error state, and that each type of module provides a different contribution to the overall system performance, and that there are several contributors to module availability that are not related to a module failure; a single performance requirement used for all modules is not sufficient to appropriately prioritize any interventions, e.g., daily interventions.

[0071] Instead of using a single performance requirement, in the method 800 described herein with respect to FIG. 8, remedial actions can be prioritized based on the degree to which a system node failed to achieve its system-node-specific performance requirement (e.g. its Unavailability KPI) and its share of the complex laboratory automation system’s workload. This is based on the idea that remediation efforts should first be focused on non-complaint modules that manage the largest share of tubes. In some embodiments, this method 800 can provide a daily monitoring capability for focused service efforts.

[0072] At step 801 , the method 800 can include identifying poorly performing nodes. In some embodiments, this can include determining that the performance of two or more of the system nodes is non-compliant versus the relevant requirement such as availability, see FIG. 9A. In some embodiments, this determination is made using the method described with reference to FIG. 6.

[0073] At step 802, the method 800 can include calculating a weighted score for each of the poorly performing system nodes, see Fig. 9B. In some embodiments, calculating the weighted score can include calculating the system node’s Unavailability KPI and weighting it based on the system node’s load share. A load share can be, for example, a percentage of the complex laboratory automation system’s workload that is processed by the system node or reflective of the number of tubes processed by the system node. Mathematically the weighted Unavailability KPI can be calculated as follows:(Equation6) where the system consists of n nodes, 1 to nW(UKPI) = the weighted Unavailability KPI of node / IIKPI = the Unavailability KPI of node / LS = the Load Share of node i

[0074] In some embodiments, due to the random access nature of these systems the workload share data and the unavailability data should be from the same time period.

[0075] At step 803 the method 800 can including ranking the non-compliant nodes for remedial, corrective, or preventive actions based on the weighted scores. FIG. 9B is a table showing a rank ordered list of non-compliant nodes for corrective action prioritization, according to an embodiment of the disclosure.

[0076] At step 804 the method 800 can include prioritizing remedial actions of the poorly performing system nodes based on a system node’s weighted score (e.g., weighted Unavailability KPI). In some embodiments, a system node with a higher score can be prioritized over a system node with a lower score. In some embodiments, the method 800 can optionally include creating a ranked list of the poorly performing bides based on the weighted scores and prioritizing remedial actions of the poorly performing nodes based on the ranked list.

[0077] At step 805, the method 800 can include taking a remedial action on one or more of the poorly performing nodes in accordance with the prioritization. A remedial action can be any action taken to improve the system node’s availability including, for example, investigation, maintenance, repair, and redesign. Triggering of a remedial action can occur on a daily basis or over a longer evaluation of system performance compliance such as a week, month, or even years. In some embodiments, a remedial action is not taken until the number of times the system node’s actual availability is determined to be unacceptable, exceeds a predefined threshold.

[0078] The following example is provided to illustrate the advantages of using the method disclosed herein with reference to FIG. 8 over conventional methods using a single performance indicator. Note that each table in FIGS. 9A and 9B refer to the same complex laboratory automation system shown in FIG. 1 , having design data as shown in FIG 5. FIG. 9A shows the actual unavailability per Equation 4 for the relevant monitoring period, according to an embodiment of the disclosure. In FIG. 9A, nodes A, D, F, G, and J are non-compliant because they have non-zero unavailabilities, this happens when the node availability falls below the system historical availability of the module.

[0079] To create the rank order prioritized list of nodes for corrective action, such as the one shown in FIG. 9B, the load share weighted unavailability is calculated to each node by the node as described above. The result of the prioritization in rank order is D, A, F, G, J. It can readily be seen that node D has by far the biggest contribution to the risk of not meeting the daily workload requirements due to a lack of node availability.

[0080] While various illustrative embodiments incorporating the principles of the present teachings have been disclosed, the present teachings are not limited to the disclosed embodiments. Instead, this application is intended to cover any variations, uses, or adaptations of the present teachings and use its general principles. Further, this application is intended to cover such departures from the present disclosure that are within known or customary practice in the art to which these teachings pertain.

[0081] In the above detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the present disclosure are not meant to be limiting. Other embodiments may be used, and other changes may be made, without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that various features of the present disclosure, as generally described herein, and illustrated in the Figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein.

[0082] Aspects of the present technical solutions are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the technical solutions. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0083] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actsspecified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0084] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0085] A second action can be said to be “in response to” a first action independent of whether the second action results directly or indirectly from the first action. The second action can occur at a substantially later time than the first action and still be in response to the first action. Similarly, the second action can be said to be in response to the first action even if intervening actions take place between the first action and the second action, and even if one or more of the intervening actions directly cause the second action to be performed. For example, a second action can be in response to a first action if the first action sets a flag and a third action later initiates the second action whenever the flag is set.

[0086] The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various features. Many modifications and variations can be made without departing from its spirit and scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. It is to be understood that this disclosure is not limited to particular methods, reagents, compounds, compositions or biological systems, which can, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting.

[0087] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0088] It will be understood by those within the art that, in general, terms used herein are generally intended as “open” terms (for example, the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” et cetera). While various compositions, methods, and devices are described in terms of “comprising” various components or steps (interpreted as meaning “including, but not limited to”), the compositions, methods, and devices can also “consist essentially of” or “consist of” the various components and steps, and such terminology should be interpreted as defining essentially closed-member groups.

[0089] As used in this document, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art. Nothing in this disclosure is to be construed as an admission that the embodiments described in this disclosure are not entitled to antedate such disclosure by virtue of prior invention.

[0090] In addition, even if a specific number is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (for example, the bare recitation of “two recitations,” without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, et cetera” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (for example, “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, et cetera). In those instances where a convention analogous to “at least one of A, B, or C, et cetera” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (for example, “a system having at least one of A, B, or C” would includebut not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, et cetera). It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, sample embodiments, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.”

[0091] In addition, where features of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0092] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, et cetera. As a non-limiting example, each range discussed herein can be readily broken down into a lower third, middle third and upper third, et cetera. As will also be understood by one skilled in the art all language such as “up to,” “at least,” and the like include the number recited and refer to ranges that can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 components refers to groups having 1 , 2, or 3 components. Similarly, a group having 1-5 components refers to groups having 1 , 2, 3, 4, or 5 components, and so forth.

[0093] Various of the above-disclosed and other features and functions, or alternatives thereof, may be combined into many other different systems or applications. Various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art, each of which is also intended to be encompassed by the disclosed embodiments.NON-LIMITING ILLUSTRATIVE EMBODIMENTS

[0094] The following is a list of non-limiting illustrative embodiments disclosed herein:

[0095] Illustrative embodiment 1 . A method for designing an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment, the method comprising: receiving system requirements; receiving node requirements, where at least one of the node requirements is based at least in part on one of the system requirements; receiving, for at least one of the nodes, node information; and determining, for the at least one of the nodes, a number of modules that together can achieve the node requirements based on the node information.

[0096] Illustrative embodiment 2. The method of illustrative embodiment 1 , wherein one or more of the plurality of nodes comprises a plurality of modules of a common type in a parallel workflow.

[0097] Illustrative embodiment 3. The method of any one of illustrative embodiments 1-2, wherein the system requirements comprise an availability requirement and a workload requirement.

[0098] Illustrative embodiment 4. The method of illustrative any one of embodiments 1-3, wherein the workload requirement comprises a number of processes during a time period and the availability requirement comprises a percentage of time the system is capable of performing a process during the time period.

[0099] Illustrative embodiment 5. The method according to any one of the preceding embodiments, wherein the node information comprises a workload capacity and an historic availability.

[0100] Illustrative embodiment 6. The method according to any one of illustrative embodiments 1-5, wherein the workload capacity comprises a number of processes during a time period and the historic availability comprises availability of the at least one of the nodes at a location of the automation system.

[0101] Illustrative embodiment 7. The method according to any one of the preceding embodiments, wherein determining the number of modules that together can achieve the node requirements comprises: determining a number of required modules comprising determining a minimum required number of modules necessaryto achieve the node requirements based on the node information; and determining a number of redundant modules based on the node information.

[0102] Illustrative embodiment 8. A method of maintaining an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment, wherein at least one of the plurality of nodes has a plurality of modules, the method comprising: determining that an actual node performance of the at least one of the plurality nodes is unacceptable based at least in part on a comparison, for at least one of the plurality of modules, an actual module performance to an historic module performance; and performing a corrective action on the at least one module of the plurality of modules.

[0103] Illustrative embodiment 9. The method of any one of the preceding embodiments, wherein the corrective action comprises maintenance of the at least one module of the at least one of the nodes.

[0104] Illustrative embodiment 10. The method of any one of the preceding embodiments, wherein the actual module performance comprises actual module availability and the historic module performance comprises historic module availability.

[0105] Illustrative embodiment 11. The method of any one of the preceding embodiments, wherein determining that the actual node performance of the at least one of the plurality nodes is unacceptable further comprises: receiving, for each of the plurality of modules, a respective actual module performance; identifying a subset of the plurality of modules by identifying n number of modules having the greatest actual module performance, wherein n is the number of modules required to meet the at least one of the plurality of node’s workload requirement; receiving, for each of the modules in the subset, a respective historic performance; comparing, for each of the modules in the subset, a respective actual performance to a respective historic performance; calculating a node availability indicator based at least in part on the comparisons; and determining that the actual node performance is unacceptable based on the node availability indicator.

[0106] Illustrative embodiment 12. The method of any one of the preceding embodiments, further comprising designing the system by: receiving system requirements; receiving node requirements, where at least one of the node requirements is based at least in part on one of the system requirements; receiving, for at least one of the nodes, node information; and determining, for the at least oneof the nodes, a number of modules that together can achieve the node requirements based on the node information.

[0107] Illustrative embodiment 13. The method of any one of the preceding embodiments, wherein determining the number of modules that together can achieve the node requirements comprises: determining a number of required modules comprising determining a minimum required number of modules necessary to achieve the node requirements based on the node information; and determining a number of redundant modules based on the node information.

[0108] Illustrative embodiment 14. The method of any one of the preceding embodiments, wherein the system requirements comprise an availability requirement comprising a percentage of time the system is capable of performing a process during a time period and a workload requirement comprising a number of processes during the time period.

[0109] Illustrative embodiment 15. A method of maintaining an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment, the method comprising: determining for each of the plurality of nodes, that a respective actual performance is unacceptable; calculating, for each of the plurality of nodes, a respective weighted score based at least in part on a respective load share; prioritizing one or more corrective actions for each of the plurality of nodes based on the respective weighted scores; and performing the one or more corrective actions for one of the plurality of nodes according to the prioritization.

[0110] Illustrative embodiment 16. The method of any one of the preceding embodiments, wherein prioritizing the one or more corrective actions further comprises: prioritizing a node having a greater load share over a node having a lesser load share.

[0111] Illustrative embodiment 17. The method of any one of the preceding embodiments, wherein the respective load share comprises a percentage of the system’s total workload that is processed by the respective node.

[0112] Illustrative embodiment 18. The method of any one of the preceding embodiments, wherein the respective load share reflects a number of one or more carriers or samples handled by the respective node.

[0113] Illustrative embodiment 19. The method of any one of the preceding embodiments, wherein at least one of the plurality of nodes has a plurality of modules, wherein determining that the respective actual performance of the at leastone of the plurality of nodes is unacceptable comprises: receiving, for each of the plurality of modules, an actual module performance; identifying a subset of the plurality of nodes by identifying n number of nodes having the greatest actual module performances, wherein n is the number of modules required to meet the at least one of the plurality of node’s workload requirement; receiving, for each of the modules in the subset, an historic performance; comparing, for each of the modules in the subset, a respective actual availability to a respective historic availability; calculating a node availability indicator based on the comparisons; and determining that actual node performance is unacceptable based on the node availability indicator.

[0114] Illustrative embodiment 20. The method of any one of the preceding embodiments, wherein actual module performance comprises actual availability and the historic performance comprises historic module availability.

Claims

CLAIMSW / e claim:

1. A method for designing an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment, the method comprising: receiving system requirements; receiving node requirements, where at least one of the node requirements is based at least in part on one of the system requirements; receiving, for at least one of the nodes, node information; and determining, for the at least one of the nodes, a number of modules that together can achieve the node requirements based on the node information.

2. The method of claim 1 , wherein one or more of the plurality of nodes comprises a plurality of modules of a common type in a parallel workflow.

3. The method of claim 1 , wherein the system requirements comprise an availability requirement and a workload requirement.

4. The method of claim 3, wherein the workload requirement comprises a number of processes during a time period and the availability requirement comprises a percentage of time the system is capable of performing a process during the time period.

5. The method of claim 1 , wherein the node information comprises a workload capacity and an historic availability.

6. The method of claim 5, wherein the workload capacity comprises a number of processes during a time period and the historic availability comprises availability of the at least one of the nodes at a location of the automation system.

7. The method of claim 1 , wherein determining the number of modules that together can achieve the node requirements comprises: determining a number of required modules comprising determining a minimum required number of modules necessary to achieve the node requirements based on the node information; and determining a number of redundant modules based on the node information.

8. A method of maintaining an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment, wherein at least one of the plurality of nodes has a plurality of modules, the method comprising: determining that an actual node performance of the at least one of the plurality nodes is unacceptable based at least in part on a comparison, for at least one of the plurality of modules, an actual module performance to an historic module performance; and performing a corrective action on the at least one module of the plurality of modules.

9. The method of claim 8, wherein the corrective action comprises maintenance of the at least one module of the at least one of the nodes.

10. The method of claim 8, wherein the actual module performance comprises actual module availability and the historic module performance comprises historic module availability.11 . The method of claim 8, wherein determining that the actual node performance of the at least one of the plurality nodes is unacceptable further comprises: receiving, for each of the plurality of modules, a respective actual module performance; identifying a subset of the plurality of modules by identifying n number of modules having the greatest actual module performance, wherein n is the number of modules required to meet the at least one of the plurality of node’s workload requirement; receiving, for each of the modules in the subset, a respective historic performance; comparing, for each of the modules in the subset, a respective actual performance to a respective historic performance; calculating a node availability indicator based at least in part on the comparisons; and determining that the actual node performance is unacceptable based on the node availability indicator.

12. The method of claim 8, further comprising designing the system by:receiving system requirements; receiving node requirements, where at least one of the node requirements is based at least in part on one of the system requirements; receiving, for at least one of the nodes, node information; and determining, for the at least one of the nodes, a number of modules that together can achieve the node requirements based on the node information.

13. The method of claim 12, wherein determining the number of modules that together can achieve the node requirements comprises: determining a number of required modules comprising determining a minimum required number of modules necessary to achieve the node requirements based on the node information; and determining a number of redundant modules based on the node information.

14. The method of claim 13, wherein the system requirements comprise an availability requirement comprising a percentage of time the system is capable of performing a process during a time period and a workload requirement comprising a number of processes during the time period.

15. A method of maintaining an automation system having a plurality of nodes in an in vitro diagnostics (“IVD”) environment, the method comprising: determining for each of the plurality of nodes, that a respective actual performance is unacceptable; calculating, for each of the plurality of nodes, a respective weighted score based at least in part on a respective load share; prioritizing one or more corrective actions for each of the plurality of nodes based on the respective weighted scores; and performing the one or more corrective actions for one of the plurality of nodes according to the prioritization.

16. The method of claim 15, wherein prioritizing the one or more corrective actions further comprises: prioritizing a node having a greater load share over a node having a lesser load share.

17. The method of claim 15, wherein the respective load share comprises a percentage of the system’s total workload that is processed by the respective node.

18. The method of claim 15, wherein the respective load share reflects a number of one or more carriers or samples handled by the respective node.

19. The method of claim 15, wherein at least one of the plurality of nodes has a plurality of modules, wherein determining that the respective actual performance of the at least one of the plurality of nodes is unacceptable comprises: receiving, for each of the plurality of modules, an actual module performance; identifying a subset of the plurality of nodes by identifying n number of nodes having the greatest actual module performances, wherein n is the number of modules required to meet the at least one of the plurality of node’s workload requirement; receiving, for each of the modules in the subset, an historic performance; comparing, for each of the modules in the subset, a respective actual availability to a respective historic availability; calculating a node availability indicator based on the comparisons; and determining that actual node performance is unacceptable based on the node availability indicator.

20. The method of claim 19, wherein actual module performance comprises actual availability and the historic performance comprises historic module availability.

Images