SYSTEM AND METHOD FOR EVALUATING BAYS ON DIAGNOSTIC DEVICES - Patent application

Abstract

Methods, systems, and devices are disclosed in which a diagnostic instrument analyzes data collected over time and, based on that information, disables bays, suggests bays, puts bays on standby, or combinations thereof. In some embodiments, the methods, systems, and devices enable diagnostic instruments to have higher availability rates in the field and enable providers to set up service calls, schedule maintenance, perform remote maintenance, and perform other functions based on data collected over time.

Description

Related Applications

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent document claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 038,613, entitled "SYSTEMS AND METHODS FOR ASSESSING BAYS ON DIAGNOSTIC DEVICES," filed June 12, 2020. The entire contents of the aforementioned patent application are incorporated by reference as part of the disclosure of this patent document for all purposes. [Technical Field]

[0002] The present technology relates to monitoring diagnostic equipment to improve field effectiveness. [Background technology]

[0003] Preventable medical errors are currently the third leading cause of death in the United States, accounting for more than 250,000 deaths per year. Some rapid molecular diagnostic systems, such as GenMark's ePlex system, are designed to reduce medical errors. However, no matter how well-designed a diagnostic system is, diagnostic equipment wears out over time. Preventable medical errors can occur if diagnostic equipment is not functioning properly. If equipment cannot be used, laboratories cannot process samples. In some cases, such as in the case of sample processing cartridges that detect organisms that cause sepsis, the inability to process samples can be fatal. A recent study showed that patients with severe sepsis or septic shock have a 7.6% increased chance of death for each hour that antibiotic treatment is not applied. Liang et al., Empiric Antimicrobial Therapy in Severe Sepsis and Septic Shock: Optimizing Pathogen Clearance, Curr Infect Dis Rep. 2015 July;17(7):493. Furthermore, cartridges may expire if laboratories are unable to process samples. Consistently supplying laboratories and hospitals with cartridges for processing patient samples is challenging due to the short shelf life of cartridges and seasonal demand for some tests. For example, during the most devastating periods of the 2019 and 2020 coronavirus pandemic, many hospitals / laboratories had extremely low levels of rapid molecular respiratory cartridges. Summary of the Invention

[0004] In certain embodiments, methods, systems and tools are provided herein for improving the field effectiveness rate of diagnostic equipment.

[0005] In some embodiments of the present technology, a diagnostic device includes: (a) a bay; (b) a control unit, the control unit including a bay disable rule engine, a standby rule engine, and a proposal rule engine, the bay disable monitoring rule engine generating the disable bay data, the standby monitoring rule engine generating the standby bay data, and the proposal monitoring rule engine generating the proposal bay data; and (c) a processor, the processor determining whether the disable bay data, the standby bay data, and the proposal bay data satisfy a predetermined baseline, and in response to determining that the disable bay data does not satisfy the predetermined baseline, the processor disables the bay. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 1 is a block diagram of a diagnostic device in accordance with the principles of the present technology; [Figure 2] FIG. 1 is a block diagram of a remote monitoring system for diagnostic equipment in accordance with the principles of the present technology; [Figure 3] FIG. 1 is a block diagram of a user interface in accordance with the principles of the present technology; [Figure 4] FIG. 1 is a block diagram of a controller / processor in accordance with the principles of the present technology. [Figure 5] FIG. 1 is a block diagram of a software architecture in accordance with the principles of the present technology. [Figure 6] 10 is a flowchart of a procedure for monitoring a disabled bay in accordance with the principles of the present technology; [Figure 7] 10 is a flowchart of a standby bay monitoring procedure according to the principles of the present technology. [Figure 8] A representative diagnostic tool showing how bay icons correspond to bays within processing equipment. [Figure 9] 1 is a flowchart of a proposed bay monitoring procedure in accordance with the principles of the present technology. [Figure 10] 1 is a flowchart of an evaluation bay monitoring procedure in accordance with the principles of the present technique. [Figure 11]1 is a flowchart of an evaluation bay monitoring procedure in accordance with the principles of the present technique. DETAILED DESCRIPTION OF THE INVENTION

[0007] The following description of the present technology is merely for illustrating various embodiments of the present invention. Therefore, the specific modifications described should not be interpreted as limitations on the scope of the present invention. It is clear to those skilled in the art that various equivalents, modifications, and alterations can be made without departing from the scope of the present invention, and it is understood that such equivalent embodiments are included in this specification.

[0008] According to various embodiments of the present technology, systems, devices, and methods are provided for location-based diagnostic devices, e.g., devices deployed at client locations. Accordingly, components of the systems, devices, and methods are represented where appropriate by conventional symbols in the drawings, e.g., showing specific details pertinent to understanding embodiments of the invention, so as not to obscure the present disclosure with details that will be readily apparent to those skilled in the art having the benefit of the description herein. While the present invention is described herein with respect to diagnostic systems, the invention is not limited thereto. It is believed that the processes and functions described herein can be applied to any device having processing compartments, particularly devices having randomly and independently addressable processing compartments.

[0009] As used herein, relational terms such as "first" and "second," "upper" and "lower," etc. may be used solely to distinguish one entity or element from another, without necessarily requiring or implying a physical or logical relationship or order between such entities or elements.

[0010] Generally, the present disclosure relates to methods, systems and tools for improving the field effectiveness rate of diagnostic equipment.

[0011] High-throughput diagnostic instruments can process multiple samples simultaneously. Each sample is processed in its own processing bay (also called a bay or processing unit). Many diagnostic instruments have what is called "random access and sequential access." This means that samples can be loaded into any processing bay in any order. For example, the first sample processed does not have to be in the first bay, but can be in any available bay. In practice, even when bays are "randomly accessible," technicians tend to use the same bays over and over again. In particular, the bay in the upper left corner is used first, followed by bays further down the row. For example, the top-left bay may be used twice as often as the bottom-right bay, due to user preference. This can result in some bays wearing out faster and requiring maintenance sooner. By suggesting bays, disabling bays, or putting some bays on standby, instruments can promote more uniform use of instrument bays. This reduces the number of required service calls, extends the life of bays and instruments, and improves user satisfaction.

[0012] Furthermore, some bays in the field have empirically performed better than others, i.e., had better availability, fewer run errors, connected better to sample cartridges, etc. Therefore, it is desirable to direct users to bays that perform better than others. Or, stated differently, to direct users away from bays that perform worse than others. This can be achieved by disabling non-functioning bays so that they function as they should. This can also be achieved by suggesting high-performance bays to the user. Bays with adequate performance can wait, i.e., not be suggested, until all high-performance suggested bays have been used. In this way, the field's availability is improved: bad bays are turned off; better bays are used rather than faulty bays; and better bays are used rather than degraded bays.

[0013] Existing diagnostic equipment only generates system alerts, i.e., generates an alert when the entire system is malfunctioning. However, there is no mechanism for turning off only parts of the system, suggesting to use the "best" parts of the system, suspending parts of the system for later use as needed, or a combination thereof. The technology disclosed herein addresses and solves these and other technical challenges and shortcomings with existing diagnostic equipment.

[0014] In some embodiments of the disclosed methods, systems, devices, and computer-programmable products, the following techniques can be implemented: For example, after a sample cartridge is processed in a bay of a diagnostic instrument, the instrument initiates an analysis to determine whether the bay should be disabled. The instrument processor compares the run data for a particular bay with historical data in a bay disable rules engine. If the bay does not meet the minimum disabled bay threshold data, the bay is disabled and the graphical user interface (GUI) is changed. Disabled bay data can include, but is not limited to, if the bay has experienced four or more invalid runs out of the last ten samples processed. In some embodiments, when a bay is disabled, the GUI is changed so that the bay icon corresponding to the used bay is grayed out on the user interface to visually indicate to the user that it has been disabled. In some embodiments, when a bay is disabled, the bay light is visually changed (grayed out) to indicate to the user that it has been disabled.

[0015] In some embodiments, for example, after a sample cartridge has been processed in a bay, the instrument begins an analysis to determine whether to disable, propose, or put the bay on hold. The instrument processor begins by comparing the run data for a particular bay with historical invalid bay threshold data in the bay disable rule engine. If the bay does not meet the minimum invalid bay threshold data, the bay is disabled and the GUI is changed. If the bay meets the minimum invalid bay threshold data, the processor reviews the hold bay data. The instrument processor then compares the run data for a particular bay with historical hold bay threshold data in the hold rule engine. If the bay does not meet the hold bay threshold data, the bay is put on hold and the GUI is changed. The hold bay data can include, but is not limited to, putting a bay on hold if the bay has experienced three invalid runs from one to three of the last ten samples processed. When a bay is put on hold, the GUI is changed so that the bay icon corresponding to the bay to be used is not suggested on the user interface, visually indicating to the user that the bay is not a suggested bay but is still available for use. In some embodiments, when a bay is in a standby state, the GUI changes the bay icon corresponding to the bay being used to a dimmed orange color to visually indicate to the user that it is in a standby state.

[0016] In some embodiments, for example, if the bay execution data meets the minimum invalidation bay data, a bay is proposed and the GUI is modified. When a bay is proposed, the bay icon corresponding to the bay to be used is lit on the user interface, and the GUI is modified to visually indicate to the user that this is a proposed bay. In some embodiments, when a bay is proposed, the GUI is modified so that the bay icon corresponding to the bay to be used is purple, visually indicating to the user that it is being proposed.

[0017] In some embodiments, for example, if the bay running data meets the minimum standby bay data, a bay is proposed and the GUI is modified. When a bay is proposed, the bay icon corresponding to the bay to be used is lit on the user interface, and the GUI is modified to visually indicate to the user that this is a proposed bay. In some embodiments, when a bay is proposed, the GUI is modified so that the bay icon corresponding to the bay to be used is purple, visually indicating to the user that the corresponding bay is proposed.

[0018] In some embodiments, for example, if the bay execution data meets the minimum disabled bay data and minimum standby bay data, the processor then analyzes the data in a bay suggestion rules engine. The equipment processor compares the execution data for a particular bay with historical suggested bay threshold data. In embodiments, if the bay meets the minimum suggested bay threshold data, the bay is suggested and the GUI is modified. When a bay is suggested, the bay icon corresponding to the bay to be used is lit on the user interface, and the GUI is modified to visually indicate to the user that it is a suggested bay. In some embodiments, when a bay is suggested, the GUI is modified so that the bay icon corresponding to the bay to be used is purple, visually indicating to the user that it is being suggested.

[0019] In some embodiments, for example, multiple data sets are evaluated by multiple rule engines. In embodiments, a single data set (evaluation data) is evaluated by multiple rule engines (FIG. 10). Each rule engine has its own threshold for disabling a bay, putting a bay on hold, and / or suggesting a bay. The equipment processor compares the performance data for a particular bay with the historical threshold data for each rule engine. In embodiments, if the bay meets the minimum proposed bay threshold data, the bay is suggested and the GUI is changed, or if the bay meets the minimum disabled bay threshold data, the bay is disabled and the GUI is changed, or if the bay meets the minimum on hold bay threshold data (or range), the bay is put on hold and the GUI is changed.

[0020] In some embodiments, for example, bay performance data is evaluated by a single rules engine (sometimes referred to as an evaluation rules engine) (FIG. 11). The rules engine has thresholds for disabling a bay, putting a bay on hold, and / or suggesting a bay. The equipment processor compares the performance data for a particular bay to historical threshold data on the rules engine. In embodiments, if the bay meets the minimum proposed bay threshold data, the bay is suggested and the GUI is changed, or if the bay meets the minimum disabled bay threshold data, the bay is disabled and the GUI is changed, or if the bay meets the minimum on hold bay threshold data (or range), the bay is put on hold and the GUI is changed.

[0021] In some embodiments, for example, the diagnostic equipment is connected to a remote controller, in which case the remote controller (and not the equipment) performs the invalidation bay analysis, the standby bay analysis, and the proposal bay analysis (collectively referred to as bay data analysis).

[0022] In some embodiments, for example, bay monitoring is disabled, the bay is put on hold, and / or automatically suggests a bay. In some embodiments, the user is automatically notified and prompted to contact technical support for further investigation. Options are available to override the bay disable, hold, and / or suggest features.

[0023] The present invention can be realized in hardware, software, or a combination of hardware and software. Any type of computing system or other device adapted to execute the methods described herein is suitable for performing the functions described herein. A typical combination of hardware and software can be a dedicated or general-purpose computer system having one or more processing elements and a computer program stored on a storage medium that, when loaded and executed, controls the computer system to perform the methods described herein. The present invention can also be embodied in a computer program product that includes all features enabling the implementation of the methods described herein and that can execute these methods when loaded into a computing system. A storage medium refers to any volatile or non-volatile storage device.

[0024] A computer program or application in this context means any expression in any language, code or notation of a set of instructions intended to cause a system having information processing capabilities to perform a particular function, either directly or after either or both of the following: a) translation into another language, code or notation; b) reproduction in a different material form.

[0025] It will be appreciated by those skilled in the art that the present invention is not limited to what has been particularly shown and described above. Furthermore, unless noted above to the contrary, it should be noted that all of the accompanying drawings are not to scale. Various modifications and variations are possible in light of the above teachings without departing from the scope and spirit of the present invention.

[0026] Although some exemplary embodiments describe comparisons of data as "less than," "less than or equal to," "exceeding," "greater than or equal to," or "at" a threshold and / or threshold range, it is understood that the disclosed methods, systems, apparatus, and computer products are not limited to any particular exemplary comparisons.

[0027] Here, "bay run data" and "bay data" can be used interchangeably. Also, "bay data" or "bay run data" can be referred to as "standby bay data" when used in the context of evaluating whether a bay should be placed on standby, "proposed bay data" when used in the context of making a recommendation (e.g., proposing which bay to use next), or "disable bay data" when used in the context of evaluating whether a bay should be disabled. The evaluation data, disable bay data, standby bay data, and proposed bay data can be based on how the processing unit functions, how the diagnostic equipment functions, how the diagnostic assays function, behavioral characteristics, or a combination thereof.

[0028] The evaluation data, invalidation bay data, waiting bay data, and proposed bay data can be factors shown in Table 1, but are not limited to these. diagnostic equipment

[0029] Referring to the drawings, like reference numerals refer to like elements throughout.

[0030] FIG. 1 is a block diagram of a diagnostic device according to the principles of the present technology. The diagnostic device of FIG. 1 illustrates an exemplary embodiment of a location-based self-monitoring system constructed in accordance with the principles of the present invention and generally designated as “10.” System 10 may include an analyzer 12, also referred to as a locator device 12, which comprises a base station comprising: (i) one or more processing compartments referred to as bays 11a through 11n (collectively referred to as “cartridge processing bays” or “bays” 11); (ii) a user interface 25 (e.g., a graphical user interface) comprising a touchscreen display having a plurality of bay icons, each icon uniquely corresponding to one of the plurality of bays; and (iii) a processor 14 (also referred to as a controller / processor), which may comprise a control unit 13, a memory 15, and a communication rules engine 18 (also referred to as a communication unit). Sample-to-answer systems are generally described in U.S. Patent Nos. 9,957,553, 9,598,722, and U.S. Patent Application Publication No. 2018 / 0095100, all of which are incorporated by reference in their entireties. Figure 8 shows, by way of example, how the bay icons correspond to bays within processing equipment.

[0031] 8 shows a diagram illustrating an exemplary embodiment of a diagnostic device, designated as "working apparatus 120." The diagram of the exemplary diagnostic device shows how bay icons 11.a, 11.b, and 11.c in the user interface of working apparatus 120 correspond to bays 11a, 11b, and 11c, respectively, in the analysis module of working apparatus 120. Working apparatus 120 includes a processing unit coupled to the analysis module and the user interface.

[0032] Each processing bay is configured to accept cartridges and process them independently of the other bays. This is called "random access sequential access," meaning that any available bay can be used at any time. The bays do not have to be used or loaded in any particular order.

[0033] In some embodiments, locating device 12 is connected to one or more networks 16a through 16n (collectively referred to as "networks 16") and one or more remote monitoring centers 17a through 17n (collectively referred to as "remote monitoring centers 17"). In some embodiments, the remote monitoring centers can communicate with each other.

[0034] 2 illustrates an exemplary embodiment of a remote monitoring system 17 in communication with an exemplary embodiment of a locating device 12, for example, via a network 16. The locating device 12 includes a plurality of bays (e.g., bay 11, bay 11a, bay 11b, bay 11c) and a user interface 25. The remote monitoring center 17 includes a communication unit 18, a memory 15, and a controller / processor 14 that comprises an exemplary embodiment of a control unit 13. Control Unit

[0035] 4 illustrates an exemplary control unit 13 for analyzing execution data of location-based equipment. The control unit 13 may include an analysis rule engine, such as a bay disable rule engine, a bay hold rule engine, a bay suggestion rule engine, a bay evaluation rule engine, or a combination thereof. Each of these rule engines may have its own operational threshold rule engine and / or software threshold rule engine. In some embodiments, the control unit generates execution data, evaluation data, disable bay data, hold bay data, suggest bay data, and combinations thereof. Processor

[0036] The processor 14 (FIGS. 1, 2, and 4) communicates with and / or controls the bays 11 and / or the user interface 25 (e.g., GUI). In some embodiments, the processor 14 communicates with the network 16.

[0037] The processor 14 can communicate with the network 16 via a communication unit 18. The communication system 18 can include one or more communication links, such as wired or wireless communication links, e.g., Wi-Fi and / or other technologies. For example, the communication link can be a broadband communication link, such as a wired cable modem or Ethernet communication link, and a digital cellular communication link, e.g., a Long Term Evolution (LTE)-based link, among other broadband communication links known in the art. As used herein, broadband can refer to a communication link other than a Plain Old Telephone Service (POTS) line. The Ethernet communication link may also be an IEEE 802.3-based communication link. The network 16 can be a wide area network, a local area network, a wireless local network, or a metropolitan area network, among other networks known in the art. The network 16 provides communication between the processor 14 and a remote monitoring center 17, as shown in FIG. 1, for example.

[0038] In some implementations, the processor 14 performs disable bay monitoring procedures and analyses. In some implementations, the processor 14 collects disable bay monitoring data. The processor 14 determines whether a disable bay problem exists, for example, whether the disable bay data is below a predetermined limit. If the processor determines that a problem exists, the processor 14 can disable the bay.

[0039] In some implementations, the processor 14 performs standby monitoring procedures and analysis. The processor 14 collects standby monitoring data. The processor 14 determines whether a standby problem exists, for example, whether standby bay data is below a predetermined limit. If the processor determines that a problem exists, the processor 14 can place the bay in a standby state.

[0040] In some implementations, the processor 14 executes the proposed monitoring procedures and analyses. The processor 14 collects the proposed monitoring data. The processor 14 determines whether a proposed problem exists, for example, whether the proposed bay data is below a predetermined limit. If the processor determines that a problem exists, the processor 14 can suggest a bay.

[0041] In some implementations, the processor 14 performs the assessment monitoring procedures and analysis. The processor 14 collects assessment monitoring data. The processor 14 determines whether an assessment problem exists, for example, whether bay performance data is below a predetermined limit. If the processor determines that a problem exists, the processor 14 can place the bay on standby, suggest a bay, or disable the bay.

[0042] In some implementations, the processor 14 performs the assessment monitoring procedures and analysis. The processor 14 collects assessment monitoring data. The processor 14 determines whether an assessment problem exists, for example, whether the assessment data is below a predetermined limit. If the processor determines that a problem exists, the processor 14 can place a bay on standby, suggest a bay, or disable a bay. communication systems

[0043] The communication system 18 can include a communication element (shown in FIG. 4 but not shown in FIGS. 1 and 2), which can be a wired or wireless communication device. The communication element provides communication with the bay 11 and the user interface 25. In some implementations, the communication element can support one or more wireless communication protocols such as Zigbee, Z-Wave, and Wi-Fi (e.g., IEEE 802.11), among other wireless communication protocols that support wireless or wired data transfer.

[0044] In some implementations, the communications element allows the locating device 12 and / or processor 14 to be used with a variety of interface devices and integrated with a variety of equipment vendors. Remote Monitoring Center

[0045] 1 , in some embodiments, the remote monitoring center 17 performs monitoring, configuration, and / or control functions associated with the processor 14 and / or the control unit 13. For example, the remote monitoring center 17 may include a remote evaluation bay monitoring system and / or a remote deactivation bay monitoring system and / or a standby monitoring system and / or a proposal monitoring system that monitors the bays 11 on the locating device 12 and controls the user interface 25. In some embodiments, the remote monitoring center receives execution data, evaluation data, deactivation bay data, proposal bay data, and / or standby bay data from the locating device's communication network 18.

[0046] In some implementations, the remote monitoring center 17 includes a remote communication element 21, such as an Ethernet-based hardware component, that provides communication with the network 16. Alternatively, or in addition to the Ethernet-based hardware component, the remote communication element 21 may include a Wi-Fi (IEEE 802.11) hardware component that provides communication with a location device or other network device.

[0047] In some implementations, the remote monitoring center 17 includes a disable control element 22 that can be used by a user to remotely and manually disable a bay, suggest a bay, or place a bay on hold on a locating device. The disable control element 22 allows for an alternative or backup method of disabling a bay, suggesting a bay, or placing a bay on hold on a locating device that does not require self-monitoring by the device or monitoring by a remote monitoring system.

[0048] In some embodiments, the execution data, evaluation data, invalidation bay data, hold bay data, proposal bay data, and combinations thereof are shared with a remote monitoring system. The remote monitoring system compiles the execution data, evaluation data, invalidation bay data, hold bay data, proposal bay data, and combinations thereof from multiple diagnostic devices. The combined execution data is used to form past execution data, past evaluation data, past invalidation bay data, past hold bay data, past proposal bay data, and combinations thereof. The past execution data, past evaluation data, past invalidation bay data, past hold bay data, past proposal bay data, and combinations thereof are then used by a rules engine for the particular device of interest. GUI

[0049] FIG. 3 illustrates an exemplary embodiment of user interface 25, shown as user interface 125 in FIG. 3. In some embodiments, user interface 25 (and user interface 125) is a GUI. The GUI can include one or more indicators, such as colors, that can indicate the state of a bay. For example, a first color is used when the bay is disabled, a second color is used when the bay is proposed, and a third color is used when the bay is standby, where the first color, second color, and third color are different. In some embodiments, the bay has different colors when the bay is available, in operation, or has completed execution.

[0050] In some embodiments, the processor 14 is in communication with the GUI. In some embodiments, the GUI is controlled by the processor 14. In some embodiments, the GUI is in communication with a remote monitoring center 17. In some embodiments, the GUI is controlled by the remote monitoring center 17. Bay Door Light

[0051] As shown in FIG. 1 , in some embodiments, each bay has a light. The bay light includes one or more indicators, such as colors, that can indicate the state of the bay. For example, a first color is used when the bay is disabled, a second color is used when the bay is proposed, and a third color is used when the bay is standby, where the first color, second color, and third color are different. In some embodiments, the bays have different colors when the bay is available, in operation, or has completed execution.

[0052] In some embodiments, the processor 14 is in communication with the bay light. In some embodiments, the bay light is controlled by the processor 14. In some embodiments, the bay light is in communication with the remote monitoring center 17. In some embodiments, the bay light is controlled by the remote monitoring center 17. Bay Door Lock

[0053] In some embodiments, each bay has a door lock (not shown). In some embodiments, processor 14 communicates with the bay door lock and locks or unlocks the bay door lock based on the state of the bay. In some embodiments, the bay door lock communicates with remote monitoring center 17, and remote monitoring center 17 locks or unlocks the bay door based on the state of the bay. In some embodiments, the bay door is locked when performance data (e.g., invalid bay data) is below a threshold. In some embodiments, the bay door is locked when performance data (e.g., standby bay data) is within a standby threshold range. In some embodiments, the bay door is unlocked when performance data (e.g., standby bay data) is within a standby threshold range. In some embodiments, the bay door is unlocked when performance data (e.g., proposal bay data) is above a threshold. In some embodiments, the bay door is locked when evaluation data is above a threshold, below a threshold, or within a range. In some embodiments, the bay door is unlocked when evaluation data is above a threshold, below a threshold, or within a range. memory

[0054] In some embodiments, memory 15 on the location device can include non-volatile and volatile memory. For example, non-volatile memory can include a hard drive, a memory stick, flash memory, etc. Volatile memory can also include random access memory and others known in the art. Memory 15 can store invalidation bay data and standby bay data, among other data and / or a rules engine, or can suggest bay data. In FIG. 1, memory 15 is shown as part of processor 14. In FIG. 4, memory 15 is shown external to the control unit. Alternatively, memory 15 can be external and / or internal to the control unit.

[0055] The memory 15 may contain, among other data, historical threshold override bay data, historical threshold standby bay data, and historical threshold proposed bay data.

[0056] Any bay data (eg, invalidation bay data, proposed bay data, waiting bay data, performance data, and / or evaluation data) may be stored in the processor's memory or in the remote monitoring center 17 . Bay Disable Automated Monitoring Rules Engine

[0057] The bay disable rules engine 23 (also referred to as a disable bay monitoring system or a disable rules engine) contains instructions that, when executed by the processor 14, cause the processor 14 to perform a disable bay monitoring process.

[0058] In some embodiments, the bay invalidation rules engine 23 evaluates the invalidation bay data (or another type of data, such as evaluation bay data) by comparing the invalidation bay data (or another type of data, such as evaluation bay data) to invalidation bay threshold data. In some embodiments, if the invalidation bay data passes the bay invalidation rules engine 23, the analysis of the invalidation bay data ends.

[0059] In some embodiments, if the invalid bay data passes through the bay invalidation rule engine 23, the invalid bay data is considered by another rule engine, such as a queue rule engine (also referred to as a bay queue rule engine). The queue rule engine evaluates the invalid bay data by comparing the invalid bay data to queue bay threshold data. If the invalid bay data passes through the queue rule engine, the invalid bay data is considered by another rule engine, such as a proposal rule engine. The proposal rule engine evaluates the invalid bay data by comparing the invalid bay data to proposal bay threshold data.

[0060] In some embodiments, the bay invalidation rules engine 23 evaluates the invalidation bay data (or another type of data, such as evaluation bay data) by first comparing the invalidation bay data (or another type of data, such as evaluation bay data) to invalidation bay threshold data. If the invalidation bay data does not pass the bay invalidation rules engine 23, the invalidation bay data is not considered by another rule engine. If the invalidation bay data passes the bay invalidation rules engine 23, the invalidation bay data is considered by another rule engine.

[0061] In some embodiments, the invalid bay data is evaluated only by the bay invalidation rules engine 23 . Standby Self-Monitoring Rules Engine

[0062] In some embodiments, the standby monitoring rules engine 24a (also referred to as a standby monitoring system or bay standby rules engine) includes instructions that, when executed by the processor 14, cause the processor 14 to perform a standby monitoring process.

[0063] In some embodiments, bay disable rule engine 23 evaluates the waiting bay data (or another type of data, such as evaluation bay data) by comparing the waiting bay data (or another type of data, such as evaluation bay data) to the disable bay threshold data. If the waiting bay data passes through bay disable rule engine 23, the waiting bay data is considered by bay waiting rule engine 24a. Bay waiting rule engine 24a evaluates the waiting bay data by comparing the waiting bay data to the waiting bay threshold data. If the waiting bay data passes through bay waiting rule engine 24a, the waiting bay data is considered by bay suggestion rule engine 24b. Bay suggestion rule engine 24b evaluates the waiting bay data by comparing the waiting bay data to the suggestion bay threshold data.

[0064] In some embodiments, bay waiting rule engine 24a evaluates waiting bay data (or another type of data, such as evaluation bay data) by first comparing the waiting bay data (or another type of data, such as evaluation bay data) to waiting bay threshold data. If the waiting bay data fails bay waiting rule engine 24a, the waiting bay data is not considered by another rule engine. If the waiting bay data passes bay waiting rule engine 24a, the waiting bay data is considered by another rule engine.

[0065] In some embodiments, the waiting bay data is evaluated only by the bay waiting rules engine 24a. Proposed self-monitoring rule engine

[0066] In some embodiments, the proposal monitoring rules engine 24b (also referred to as a proposal monitoring system, a bay proposal rules engine, or a proposal rules engine) includes instructions that, when executed by the processor 14, cause the processor 14 to perform a proposal monitoring process.

[0067] In some embodiments, the bay invalidation rule engine evaluates the proposed bay data (or another type of data, such as evaluation bay data) by comparing the proposed bay data (or another type of data, such as evaluation bay data) to invalidation bay threshold data. If the proposed bay data passes the bay invalidation rule engine, the proposed bay data is considered by the waiting rule engine 24a. The waiting rule engine 24a evaluates the proposed bay data by comparing the proposed bay data to the waiting bay threshold data. If the proposed bay data passes the waiting rule engine 24a, the proposed bay data is considered by the proposal rule engine 24b. The bay proposal rule engine 24b evaluates the proposed bay data by comparing the proposed bay data to the proposal bay threshold data.

[0068] In some embodiments, the bay proposal rule engine 24b evaluates the proposed bay data (or another type of data, such as the evaluation bay data) by first comparing the proposed bay data (or another type of data, such as the evaluation bay data) to the proposed bay threshold data. If the proposed bay data passes the bay proposal rule engine 24b, the proposed bay data is not considered by another rule engine. If the proposed bay data does not pass the bay proposal rule engine 24b, the proposed bay data is considered by another rule engine.

[0069] In some embodiments, the proposed bay data is evaluated only by the bay proposal rules engine 24b.

[0070] In some embodiments, a single data set (evaluation data) is evaluated by each of the bay disable rule engine 23, the bay wait rule engine 24a, the bay suggestion rule engine 24b, and combinations thereof. Reputation Self-Monitoring Rules Engine

[0071] In some embodiments, reputation monitoring rules engine 24c (not shown) (also referred to as a reputation monitoring system, a bay reputation rules engine, or a reputation rules engine) includes instructions that, when executed by processor 14, cause processor 14 to perform a reputation monitoring process. (See FIG. 11.)

[0072] In some embodiments, the bay evaluation rules engine evaluates the bay performance data (or another type of data, such as evaluation bay data) by comparing the bay performance data (or another type of data, such as evaluation bay data) to evaluation threshold data in the evaluation rules engine. If the bay performance data passes the evaluation bay threshold data, the bay is proposed. If the bay performance data is within the standby bay threshold data range, the bay is placed on standby. If the bay performance data is equal to or greater than the disable bay threshold data, the bay is disabled.

[0073] In some embodiments, the bay evaluation rule engine evaluates the bay execution data (or another type of data, such as evaluation bay data) by first comparing the bay execution data (or another type of data, such as evaluation bay data) to evaluation bay threshold data in the evaluation rule engine. If the bay execution data passes the evaluation rule engine, the bay execution data is not considered by another rule engine. If the evaluation bay execution data does not pass the evaluation rule engine, the bay execution data is considered by another rule engine.

[0074] In some embodiments, the bay execution data is evaluated solely by the bay evaluation rules engine. Software Architecture

[0075] 5 illustrates an exemplary software architecture 26 of processor 14. In some embodiments, software architecture 26 may include disable bay monitoring, hold bay monitoring, proposal bay monitoring, evaluation bay monitoring, among other software components related to the monitoring, operation, and control of location-based equipment. The disable bay monitoring, hold bay monitoring, proposal bay monitoring, evaluation bay monitoring, and combinations thereof are configured to run on processor 14, control unit 13, or both.

[0076] In some embodiments, the deactivation bay monitoring and / or the hold bay monitoring and / or the proposal and / or evaluation bay monitoring can be performed at predetermined intervals and / or can begin upon receiving a command to perform the monitoring. In another example, the processor 14 can determine to begin monitoring upon request by a field technician, by a remote user, upon power-on of the equipment, and / or can begin monitoring periodically. In another example, the processor 14 can begin monitoring after each sample is processed. In another example, the processor 14 can begin monitoring after a predetermined number of samples are processed, i.e., after two samples are processed, after ten samples are processed, or after fifty samples are processed. As used herein, monitoring refers to data analysis, i.e., execution data analysis, evaluation data analysis, deactivation bay execution data analysis, hold bay execution data analysis, proposal bay execution data analysis, or a combination thereof. As used herein, data analysis refers to comparing execution data to threshold data. As used herein, threshold data (e.g., historical threshold data) is based on data collected over time. For example, the threshold can be placed at four invalids out of the last four runs based on historical data showing that more failures are likely if invalid runs exceed that frequency. Or, the threshold can be set at 500 nanoamperes (nA), below which the system cannot accurately detect the signal. The threshold can be based on samples run on or off the current bay being analyzed.

[0077] Commands to monitor bays (perform a deactivation bay analysis, a waiting bay analysis, a proposed bay analysis, an evaluation bay analysis, or a combination thereof) can be sent from the user interface 25 on the locating device 12 and / or the remote monitoring center 17. The commands can indicate whether to start or skip deactivation bay monitoring, waiting bay monitoring, proposed bay monitoring, evaluation bay monitoring, or a combination thereof. Report

[0078] In some embodiments, the processor 14 can generate a report that includes the results of the disable bay monitoring procedure, the standby bay monitoring procedure, the suggest bay monitoring procedure, the assess bay monitoring procedure, the evaluate bay monitoring procedure, and combinations thereof. (See FIGS. 6, 7, 8, and 11.) The report can include details about one or more actions taken (disable a bay, suggest a bay, or place a bay on standby). The report can be printed by the diagnostic equipment or transmitted to the network 16.

[0079] The data generated by the diagnostic equipment indicates whether one or more devices and / or features of the location-based system are operating and / or continue to operate as designed. The reports and metrics contained in the reports can be stored in memory 15 for future comparison with updated reports generated by processor 14, i.e., in some embodiments, processor 14 tracks the health history of the location-based system to identify persistent issues and problems that have changed.

[0080] In some embodiments, the report is transmitted to a user interface device (not shown) or network 16 and / or remote monitoring center 17, or to other devices, servers, and / or users. For example, a field technician may review the report to troubleshoot system problems. In another example, the remote monitoring center may dispatch a field technician based on the report received from locating device 12. Disable Bay Monitoring Procedure

[0081] 6 illustrates an exemplary disable bay monitoring procedure of the bay disable rules engine 23. In some embodiments, the result of the disable bay rule analysis is to either disable the bay, place the bay on standby, allow use of the bay, or suggest use of the bay. In some embodiments, the result of the disable bay rule analysis is to disable the bay or to execute a standby bay monitoring procedure and / or a suggest bay monitoring procedure.

[0082] 6, processor 14 receives data from control unit 13 (in process 50a). Processor 14 reviews the invalidation bay data using a bay invalidation rules engine (in process 51). In some embodiments of process 51, reviewing means that processor 14 compares the invalidation bay data with previous invalidation bay data executed on that processor, previous invalidation bay data received from other bays on that equipment, previous invalidation bay data received from other bays on other equipment, and combinations thereof.

[0083] In some embodiments, if the invalid bay data exceeds a predetermined limit (e.g., an invalid bay threshold), the user interface 25 (e.g., a GUI) is changed to indicate that the bay is ready to process another sample (in process 52). In some embodiments, if the invalid bay data is equal to or less than the predetermined limit, the bay is disabled (in process 53) to prevent another sample from being processed. In this example, if the invalid bay data is determined to be equal to or less than the threshold, the bay is disabled in process 53. However, it is understood that the threshold can be set to indicate that the bay should be disabled when the invalid bay data is just above the threshold, and vice versa.

[0084] In some embodiments, for example, if the disabled bay data is below a predetermined limit and the bay is disabled (in process 53), the user interface 25 (e.g., GUI) is changed to indicate that the bay is disabled (in process 55a). In some embodiments, if the disabled bay data is below a predetermined limit, the bay icon corresponding to the bay in question on the GUI is changed to indicate that the bay has been disabled. In some embodiments, if the disabled bay data is below a predetermined limit, the bay icon is grayed out on the GUI to indicate that the bay has been disabled.

[0085] In some embodiments, if the invalidated bay data is below a predetermined limit, the sample is marked as "processed," for example, in process 54a. In some embodiments, if a bay is invalidated in response to invalidating bay data, results from analyzed samples are still reported. In some embodiments, if a bay is invalidated in response to invalidating bay data, results from analyzed samples are not reported.

[0086] In some optional embodiments, if the invalidation bay data is below a predetermined limit (e.g., an invalidation bay threshold), the bay door is locked (in process 56a) to prevent the insertion of another cartridge. In some embodiments, if the invalidation bay data is below a predetermined limit, the bay door is not locked, and if a sample is inserted into the bay, the processor ejects the cartridge without processing.

[0087] In some embodiments, if the disabled bay data falls below a predetermined limit, the bay door is disabled to prevent processing of another sample. Disabling a bay (e.g., disabling the bay door) can include failing power to the bay, removing or disabling the software protocol that controls the bay, disabling the pump, locking the bay door, ejecting the cartridge, displaying an error message when the bay icon is selected, and combinations thereof.

[0088] In some cases, the disable bay result and the standby bay result have a toggle relationship, where if not disabled, the bay is placed in standby. In some cases, the disable bay result and the proposed bay result have a toggle relationship, where if not disabled, the bay is proposed and if not proposed, the bay is disabled. In some cases, the proposed bay result and the standby bay result have a toggle relationship, where if not standby, the bay is proposed and if not proposed, the bay is placed in standby. In some cases, the disable bay result and the proposed bay result have a toggle relationship, where if not disabled, the bay is proposed and if not proposed, the bay is disabled.

[0089] In some embodiments, if the invalid bay data exceeds a predetermined limit (e.g., an invalid bay threshold), the bay is not invalidated and the user interface 25 (e.g., GUI) is changed (in process 52) to indicate that the bay is ready to process another sample.

[0090] In some embodiments, the invalid bay data is compared to at least one invalid bay threshold, and if equal to or greater than the threshold, the sample is processed.

[0091] In one embodiment, when a user taps on a bay icon that has been modified because the bay data does not meet the minimum threshold disabled bay rule, the following message is displayed: Bay A1 has been automatically disabled (WR1). Please contact technical support.

[0092] In some embodiments, the invalidation Bay threshold is a range, a magnitude or intensity that must be exceeded for a particular condition to be met, or a combination thereof.

[0093] Bay Activity Disabled Monitoring Rule Engine and Bay Software Disabled Monitoring Rule Engine

[0094] In some embodiments, processor 14 receives data from control unit 13 (in process 50a). In some embodiments, processor 14 reviews (in process 51) the invalid bay data for operational issues in the bay operation invalidation rules engine. In some embodiments, processor 14 reviews (in process 51) the invalid bay data for software issues in the bay software invalidation rules engine. In some embodiments, processor 14 reviews (in process 51) the invalid bay data for operational issues in the bay operation invalidation rules engine and software issues in the bay software invalidation rules engine.

[0095] In some embodiments, processor 14 reviews the disable bay data for operational issues (in process 51) by evaluating whether the operating conditions satisfy an operational disable bay baseline. The operational disable bay baseline includes one or more predetermined thresholds that, when met, indicate that the locating device 12 or bay (e.g., bay 11a, 11b, or 11n) currently has at least one hardware or firmware problem / issue.

[0096] In some embodiments, processor 14 reviews the disable bay data (in process 51) for software issues by evaluating whether a software disable bay baseline has been met. The software disable bay baseline includes one or more predetermined thresholds that, when met, indicate that a locating device 12 or bay (e.g., bay 11a, 11b, or 11n) currently has at least one software problem / issue.

[0097] In some embodiments, the invalid bay threshold data reveals that a bay at a particular location will always perform poorly, even if the bay is replaced. In such a situation, the invalid bay threshold data will always keep that bay invalid, even after passing through all rule engines.

[0098] Disabled Bay Monitoring Rule / Threshold Data Analysis

[0099] Disable bay monitoring rules are rules that define the disable bay monitoring procedures of the bay disable rule engine 23. In some embodiments, the disable bay monitoring rules are predefined for the equipment by a user. In some embodiments, the disable bay monitoring rules are created by artificial intelligence that evaluates execution data and establishes new disable bay monitoring rules to be applied to the equipment. The disable bay monitoring rules form the disable bay threshold data.

[0100] In one embodiment, memory 15 may store a disable bay monitoring rule, which may be associated with control unit 13, a bay (e.g., bay 11), other components of the location device, other components of the system, or a combination thereof.

[0101] As an example, invalid bay monitoring rules may include the following: Disable a bay if four consecutive errors occur in the locating device. In some embodiments, four consecutive errors occur if there are four consecutive invalid runs (not processed by a previous automatic invalidation event) in a row on the bay. In some embodiments, four consecutive errors occur if there are four consecutive invalid runs (not processed by a previous automatic invalidation event) in a row on the bay with a particular validity code. In some embodiments, four consecutive errors occur if there are four consecutive invalid runs (not processed by a previous automatic invalidation event) in a row on the bay with a particular validity code, where the validity codes are derived from any combination of assay types. For example, all four validity codes can be derived from a first assay type. For example, all four validity codes can be derived from four different assay types. For example, the first validity code may be derived from a first assay type and three validity codes may be derived from a second assay type. For example, the first and second validity codes may be derived from a first assay type, and the third and fourth validity codes may be derived from a second assay type. The assay types may be, for example, a blood culture discrimination panel, a respiratory panel, a gastrointestinal panel, an HCVg test, a cystic fibrosis genotyping test, a thrombosis risk test, a warfarin susceptibility test, or a 2C19 genotyping test.

[0102] In some embodiments, when a bay is auto-disabled, the execution involved is marked as "processed" and removed from consideration for future disabled bay monitoring rules.

[0103] In some embodiments, the invalid bay monitoring rules are checked after each run, ie, after each sample processed by the instrument.

[0104] In some cases, the disable bay data is collected after the sample is processed. In some cases, the disable bay data is collected before the sample is processed. For example, if a bay cannot connect to four or more cartridges in a row, the disable bay monitoring rule is met and the bay is disabled. In some cases, the connection failure is determined by impedance data.

[0105] 6 (and other exemplary block diagram flowcharts), the order of blocks (processes) 50-56 is not limited to the order shown in the figure, and the blocks (processes) may be executed in a different order based on design needs. Furthermore, based on design needs, one or more blocks may be skipped or omitted from FIG. 6, for example, blocks (processes) 54 and / or 56 may be skipped or omitted.

[0106] The processor 14 determines whether a problem exists, for example, whether the disable bay data is below a predetermined limit. If the processor determines that a problem exists, the processor 14 can disable the equipment, disable the bay, or a combination thereof.

[0107] The disable bay monitoring rule (e.g., threshold data) of the first location device may be the same as, greater than, and / or smaller than the disable bay monitoring rule (threshold data) of the second location device.

[0108] The disable bay threshold (e.g., monitoring rule) for a first bay may be the same as, greater than, and / or less than the disable bay threshold (e.g., monitoring rule) for a second bay on the same device. The disable bay threshold for a first bay may be the same as, greater than, and / or less than the disable bay threshold for a first bay on a different device.

[0109] Disabled bay monitoring rules (eg, threshold data) for a bay may change over time.

[0110] change

[0111] In some embodiments, if a disable bay monitoring rule (e.g., threshold data) is violated, the processor 14 can optionally change at least one setting of the locator device 12. A bay door light may be changed to indicate its disabled state. For example, a bay door light may be changed to gray to indicate its disabled state. For example, an icon color on a user interface corresponding to the bay may be changed to indicate its disabled state. For example, an icon color on a user interface corresponding to the bay may be changed to gray to indicate its disabled state. For example, the bay door may be locked. For example, power to the bay may be interrupted. In addition to changing the color of the bay icon or bay door light, in some embodiments, the processor can change the settings of one or more bays 11 and / or the settings of the user interface 25 if a disable bay rule is violated. For example, if a heater is unable to reach a desired temperature, a bay fan may be turned on to improve temperature control.

[0112] In some embodiments, if a disable bay monitoring rule is not violated, the processor 14 can optionally change at least one setting of the locator device 12. In some embodiments, the processor can change the setting of one or more bays 11 and / or the setting of the user interface 25 if a disable bay rule is not violated. For example, a light on a bay door may be changed to indicate its status. For example, a light on a bay door may be changed to white to indicate its status is ready to process another sample. For example, the color of an icon on the user interface corresponding to the bay may be changed to indicate its status. For example, the color of an icon on the user interface corresponding to the bay may be changed to white to indicate its ready-to-run status.

[0113] In some embodiments, if no disable bay monitoring rules are violated, the bay is proposed. In some embodiments, if no disable bay monitoring rules are violated, the bay is put on hold. In some embodiments, if no disable bay monitoring rules are violated, the bay status remains neutral, e.g., not disabled, proposed, or put on hold.

[0114] Alerts

[0115] 6, block 51, if the processor 14 determines that no issues exist (i.e., no disable bay rules are violated), the processor 14 may terminate the disable bay monitoring procedure. In some cases, when a disable bay threshold rule is met, a disable bay pass alert may be sent to the user interface 25, the network 16, the remote monitoring center 17, and combinations thereof. The disable bay pass alert may indicate that one or more issues evaluated have passed inspection, or may simply indicate that the system / bay is ready.

[0116] In some cases, if a disable bay rule is not met, a disable bay failure alert may be sent to the user interface 25, the network 16, the remote monitoring center 17, and combinations thereof. The disable bay failure alert may indicate that one or more evaluated problems failed inspection, or may simply indicate that the system / bay has been disabled. Standby monitoring procedures

[0117] Diagnostic equipment typically requires some form of preventive and / or corrective maintenance on an ongoing basis. In practice, such preventive and / or corrective maintenance is often neglected, resulting in reduced pathogen detection efficiency. Often, diagnostic equipment is operated until it breaks down, and then a technician is called in to perform repairs. Such a reactive approach to maintenance increases the costs associated with operating diagnostic equipment, delays the reporting of results, and in some cases, leads to patient death, as in the case of sepsis diagnosis, where every hour of delay results in a 7.4% increase in mortality.

[0118] Currently, customers and equipment providers have no way of knowing when a diagnostic equipment's health level will decline to the point where functionality, i.e., the ability to detect analytes, is reduced or eliminated. Such failures may occur at inopportune times, such as when a customer is experiencing a surge in demand or on weekends when service is difficult to obtain. Therefore, it would be useful to predict when a bay will stop functioning and turn it off before it reaches that point.

[0119] 7 illustrates an exemplary wait monitoring procedure of the wait rule engine 24a. In some embodiments, the result of the wait rule analysis is to wait or suggest a bay. In some embodiments, the result of the wait rule analysis is to disable a bay.

[0120] 7, processor 14 receives standby bay data from control unit 13 (in process 50). In some embodiments, processor 14 first reviews the standby bay data with a bay disablement rules engine (in process 54). If the standby bay data is within a threshold range (e.g., below a predetermined threshold), the bay is disabled (in process 55). Process 55 can be implemented according to the embodiments described above in connection with process 53 (in FIG. 6).

[0121] In an implementation of process 54, if the invalidation bay data is not within a threshold range (e.g., above a predetermined threshold), processor 14 reviews the waiting bay data with a bay waiting rules engine (in process 56). In process 56, if the waiting bay data is not within a threshold range (e.g., above a predetermined baseline), user interface 25 (e.g., GUI) is changed (in process 57) to indicate that the bay is available to process another sample. In an implementation of process 56, when the waiting bay data is within a threshold range (e.g., below a predetermined limit), the bay is placed in a waiting state (in process 58). In some embodiments, once a bay is determined to be placed in a waiting state in process 56, user interface 25 (e.g., GUI) is changed to indicate that the bay has been placed in a waiting state. For example, the sample is marked as "processed." Also, for example, in some implementations, if the waiting bay data is above a predetermined baseline, the sample is marked as "processed."

[0122] In some embodiments, when a bay is placed in a standby state (in process 58), processor 14 evaluates (in process 59) whether there are other available bays. If process 59 determines that the standby bay data is within threshold data (e.g., below a predetermined baseline) indicating that there are no other available bays, user interface 25 (e.g., GUI) is changed (in process 60) to indicate that the bay is made available (or proposed) to process samples. On the other hand, in some embodiments, process 59 determines that the bay is available by default or becomes available when the bay exits a condition (e.g., disabled, standby, or proposed, etc.). For example, if it is determined (in process 59) that there are no other available bays, the system is configured to allow the user to run a sample in the bay. If no other bays are available, the system may change the GUI to indicate that the bay is available (in process 60) and allow a sample to be run. If another bay is available, the system may place the bay in a standby state (e.g., maintain it from process 58) (in process 510) and perform other functions in processes 511 and / or 512, described below. In some optional embodiments, for example, if it is determined (in process 59) that there are no other available bays, the bay door may be unlocked (in process 66) if the bay was previously placed in a standby state and the bay door was locked.

[0123] In some embodiments, once it is determined (in process 59) that there are other available bays, the bay is placed (e.g., maintained) in a standby state (in process 510). In some embodiments, once there are other available bays and the bay is placed in a standby state in process 510, the user interface 25 (e.g., GUI) is changed to indicate that the bay has been placed in a standby state (in process 511). In some optional embodiments, for example, once it is determined (in process 59) that there are other available bays and the bay is placed in a standby state (process 510), the bay door is locked (in process 512).

[0124] In some embodiments, the standby bay data is evaluated by the bay disable rule engine before the standby rule engine. In some embodiments, the standby bay data is evaluated by the standby rule engine before the bay disable rule engine. In some embodiments, the standby bay data is evaluated by the standby rule engine without running the bay disable rule engine. In some embodiments, the standby bay data is evaluated by the bay disable rule engine without running standby analysis by the standby rule engine.

[0125] In some embodiments, the waiting bay data is compared to at least one waiting baseline, and if it is below the baseline (e.g., waiting bay threshold data), the bay is placed on standby. In some embodiments, the waiting bay data is compared to at least one waiting baseline, and if it is above the baseline, the bay is proposed. In some embodiments, the waiting bay data is compared to at least one predetermined or predefined baseline, and if it is at or above the baseline, the bay is ready for another sample.

[0126] In some embodiments, the waiting bay threshold data is based on the past performance of the bay being analyzed, based on the past performance of other bays on the same equipment being analyzed, based on the past performance of other bays on other equipment other than the equipment being analyzed, and combinations thereof.

[0127] The standby bay threshold data indicates whether at least one of the bays is likely to operate within a failure range within a predetermined window. The window can be a time frame or a number of processed samples. For example, a bay is predicted to fail within the next three runs.

[0128] An operational standby monitoring rule engine and a software standby monitoring rule engine.

[0129] In some embodiments, processor 14 receives data from control unit 13 (process 50). In some embodiments, processor 14 reviews the standby bay data (in process 56) for operational issues in the active standby rule engine. In some embodiments, processor 14 reviews the standby bay data (in process 56) for software issues in the software standby rule engine. In some embodiments, processor 14 reviews the standby bay data (in process 56) for operational issues in the active standby rule engine and software issues in the software standby rule engine.

[0130] In some embodiments, processor 14 reviews the standby bay data for operational issues (in process 56) by evaluating whether operating conditions meet an operational standby baseline, which includes one or more predetermined thresholds that, when met, indicate that locating device 12 or a bay (e.g., bay 11a, 11b, or 11n) is currently experiencing a high probability of at least one hardware or firmware problem / issue.

[0131] In some embodiments, processor 14 reviews the standby bay data (in process 56) for software issues by evaluating whether a software standby baseline is met. The software standby baseline includes one or more predetermined thresholds that, when met, indicate that a locating device 12 or bay (e.g., bay 11 a, 11 b, or 11 n) is likely to experience at least one software problem / issue.

[0132] Wait-and-see rules / threshold data analysis.

[0133] The standby monitoring rules (also called threshold data) are rules that define the standby monitoring procedures of the standby rule engine 24a. The outcome of a standby rule can be to suggest a bay, disable a bay, or put a bay on standby.

[0134] In some embodiments, standby monitoring rules are predefined for the equipment by a user, hi some embodiments, standby monitoring rules are created by artificial intelligence that evaluates performance data and establishes new standby monitoring rules to be applied to the equipment.

[0135] In one embodiment, memory 15 may store standby monitoring rules that may be associated with control unit 13, a bay (e.g., bay 11), other components of the location device, other components of the system, or a combination thereof.

[0136] As an example, standby monitoring rules may include the following: If the locating device experiences three consecutive errors, the bay enters a standby state. In some embodiments, three consecutive errors occur if there are three consecutive invalid runs (not processed by a previous auto-invalidation event) in a row on the bay. In some embodiments, three consecutive errors occur if there are three consecutive invalid runs (not processed by a previous auto-invalidation event) in a row on the bay with a particular validity code. In some embodiments, three consecutive errors occur if there are three consecutive invalid runs (not processed by a previous auto-invalidation event) in a bay with a particular validity code, and the validity codes are derived from any combination of assay types. For example, all three validity codes can be derived from a first assay type. For example, all three validity codes can be derived from three different assay types. For example, the first validity code can be derived from a first assay type and two validity codes can be derived from a second assay type. For example, the first and second validity codes may be derived from a first assay type, and the third validity code may be derived from a second assay type. The assay types may be, for example, a blood culture discrimination panel, a respiratory panel, a gastrointestinal panel, an HCVg test, a cystic fibrosis genotyping test, a thrombosis risk test, a warfarin susceptibility test, or a 2C19 genotyping test.

[0137] In some embodiments, when a bay is placed on standby, the involved runs are marked as "processed" and excluded from future standby monitoring rule reviews. In some embodiments, when a bay is placed on standby, the involved runs are marked as "processed" and included in future standby monitoring rule reviews.

[0138] In some embodiments, the standby monitoring rules are checked after each run, ie, after each sample is processed by the instrument.

[0139] In some cases, standby bay data is collected after samples are processed. In some cases, standby bay data is collected before samples are processed. For example, if a bay cannot connect to two consecutive cartridges, the standby monitoring rule is satisfied and the bay goes into standby. In some cases, the connection failure is determined by impedance data.

[0140] The waiting bay monitoring rules (also referred to as threshold data) of the first locating device may be the same as, greater than, and / or less than the waiting bay monitoring rules of the second locating device.

[0141] The standby bay threshold data for a first bay may be the same as, greater than, and / or less than the standby bay threshold data for a second bay on the same device. The standby bay threshold data for a first bay may be the same as, greater than, and / or less than the standby bay threshold data for a first bay on a different device.

[0142] The standby bay threshold data may change over time.

[0143] The order of blocks (processes) 54-512 is not limited to the order shown in Figure 7 and may be performed in a different order based on design needs. Furthermore, based on design needs, one or more blocks may be skipped or omitted from Figure 7, for example, blocks (processes) 57, 59, and 510-512 may be skipped or omitted.

[0144] change

[0145] In some embodiments, if a waiting monitoring rule (e.g., threshold data) is violated, processor 14 can optionally change at least one setting of locating device 12. In some embodiments, the processor can place a bay in a waiting state if a waiting rule is violated. In some embodiments, the processor can suggest a bay if a waiting rule is not violated.

[0146] In some embodiments, the processor can change the settings of one or more bays 11 and / or the settings of the user interface 25 if a standby rule is violated. For example, a bay door light may be changed to indicate its standby state. For example, the bay door light may be changed to a dimmed orange color to indicate its standby state. For example, the color of an icon on the user interface corresponding to the bay may be changed to indicate its standby state. For example, the color of an icon on the user interface corresponding to the bay may be changed to a dimmed orange color to indicate its standby state. In addition to changing the color of the bay icon or bay door light, in some embodiments, the processor can change the settings of one or more bays 11 and / or the settings of the user interface 25 if a standby bay rule is violated. For example, if a heater is unable to reach a desired temperature, a bay fan may be turned on to improve temperature control.

[0147] In some embodiments, if the waiting bay data is below a predetermined limit, the bay door is locked to prevent the insertion of another sample. In some embodiments, if the waiting bay data is below a predetermined limit, the bay door is not locked and the bay will process a sample if one is inserted into the bay.

[0148] In some embodiments, if the standby bay data is above or below a predetermined limit or range, the bay remains available. In some embodiments, if the standby bay data is above or below a predetermined limit or range, the bay does not remain available, i.e., is disabled.

[0149] In some embodiments, if a waiting monitoring rule is not violated, the processor 14 can optionally change at least one setting of the locating device 12. In some embodiments, the processor can change a setting of one or more bays 11 and / or a setting of the user interface 25 if a waiting rule is not violated. For example, a light on a bay door can be changed to indicate an available status. For example, a light on a bay door can be changed to purple to indicate an available suggested bay. For example, a color of an icon on a user interface corresponding to a bay can be changed to indicate its suggested status. For example, a color of an icon on a user interface corresponding to a bay can be changed to purple to indicate its suggested status.

[0150] In some embodiments, if standby monitoring rules are not violated, the bay is proposed. In some embodiments, if standby monitoring rules are not violated, the bay is placed on standby. In some embodiments, if standby monitoring rules are not violated, the bay status remains neutral, i.e., not disabled, proposed, or placed on standby.

[0151] Alerts

[0152] 7, if in process 56 processor 14 determines that no problems exist (e.g., no standby rules have been violated), processor 14 may terminate the standby monitoring procedure. In some embodiments, if a standby rule is satisfied, a standby pass alert may be sent to user interface 25, network 16, remote monitoring center 17, and combinations thereof. The standby pass alert may indicate that one or more evaluated problems have passed inspection, or may simply indicate that the system / bay is ready.

[0153] In some embodiments, if a standby rule is not met, a standby failure alert can be sent to the user interface 25, the network 16, the remote monitoring center 17, and combinations thereof. The standby failure alert can indicate that one or more evaluated problems have failed inspection, or can simply indicate that the system / bay has been placed on standby.

[0154] The processor 14 can determine whether to trigger a standby alert. For example, the processor 14 can determine whether to trigger a standby alert based at least in part on a predetermined alert baseline indicating the number of executions until one or more bays 11, locating devices 12, and / or control unit 13 are predicted to fail or approach a failure range. The standby alert baseline can vary depending on the type of alert; for example, three consecutive invalid executions can trigger a standby failure alert, while more than 50 low-value signals can be sent before a standby failure alert is triggered. The predetermined standby alert baseline for the first operating value can be the same as, greater than, and / or less than the standby alert threshold for the second operating value. The predetermined standby alert baselines for the user interface 25, locating devices 12, and control unit 13 can be the same as, greater than, and / or less than one another. The predetermined standby alert baseline for the first locating device can be the same as, greater than, and / or less than the standby alert baseline for the second locating device. The predetermined standby alert baseline for a first bay may be the same as, greater than, and / or less than the standby alert baseline for a second bay on the same device.

[0155] Wait analysis.

[0156] The standby analysis indicates whether at least one of the locating devices and / or bays is likely to operate within its failure range.The standby analysis indicates whether at least one of the locating devices and / or bays is likely to operate within its failure range within a predetermined period of time.

[0157] The predetermined period may be one hour, one day, one week, and / or one month, among other periods set by the user, network operator, and / or diagnostic equipment provider company. The predetermined period may be based on the number of samples processed, last 100, last 50, last 25, last 10, last 5, last 2, or last 1, or any other number set by the user, network operator, and / or diagnostic equipment provider company.

[0158] For example, with respect to predicting failures based on proximate temperatures, a system running at a temperature five degrees below room temperature may have degraded performance over time. Therefore, using aggregated data from multiple systems, it can be predicted that a diagnostic device is likely to experience a failure if it is determined that the diagnostic device has been operating in a laboratory five degrees below room temperature for more than 24 hours. Therefore, it can predict when the diagnostic device will need technical support and / or service more quickly than a device operating in a room at room temperature. Furthermore, a service provider (or, in some cases, a diagnostic device provider) can evaluate why the system is operating in a room five degrees below room temperature and suggest changes. For example, is the device near an A / C outlet? Can the diagnostic device be physically located in a different location to avoid standby failures? Note that this does not mean that the prediction will always be correct. This does not mean that the prediction is always linear. In some implementations, operating diagnostic devices in a cold room may accelerate damage over time.

[0159] In some embodiments, standby failures do not result in disabling bay failures. In some embodiments, standby failures are not linearly correlated with disabling bay failures. In some embodiments, standby failures indicate an accelerated timeline for when a bay will fail and / or require service.

[0160] For example, as a bay wears, the number of volts required across the resistor to heat it increases. The voltage at V1 may pass a threshold test, but continued resistor degradation is a sign of a problem. If a diagnostic instrument can detect and record resistor degradation, it can disable a bay with a degraded resistor, put the bay on standby if the resistor is degraded but not yet below the threshold, or suggest the user use a different bay with a good resistor. Thus, while some systems can wait for a resistor to fail, with standby monitoring as described herein, a bay can be put on standby before reaching a critical level, or a bay with a better resistor can be suggested for use over a bay with a degraded resistor. In this way, the effectiveness rate in the field is improved because good bays are used rather than bad ones. Good bays are used rather than bays that are about to fail. In this way, diagnostic assays are not modified to increase effectiveness rates, avoiding the expense and effort of obtaining U.S. Food and Drug Administration (U.S. FDA) approval for new assay designs.

[0161] Similarly, as a bay ages, the pump may need to work harder to maintain pressure. A pump may pass a threshold test, but the effort required for the pump to maintain pressure may be a sign of wear. If diagnostic equipment can detect and record pump wear, it can disable the bay, put the bay on standby, or suggest the user use a different bay. In fact, any set of physically measurable control limits can be evaluated to see if a bay is worn out.

[0162] As another example, the target signal value may be acceptable but may degrade. For example, an acceptable signal level threshold may be 600 nanoamperes (na), but is typically 800 na. A 600-na signal may pass, but periodic but persistent degradation is a sign of a problem. If diagnostic equipment can detect and record signal degradation, it can disable bays with signal degradation, put bays on standby if the signal is degraded but not yet below the threshold, or suggest to the user that a different bay with good signal strength be used. Thus, while some systems can wait for the signal level to reach a critical point, the standby monitoring described herein can put bays on standby before the signal reaches a critical level or suggest a bay with a good signal for use in a bay with a degraded signal.

[0163] As another example, it may be possible that certain assays are more affected by bay performance than other assays. For example, based on data run on that particular instrument, it may be determined that Gram-negative assays have a lower efficacy rate in a particular bay, but other types of assays perform well in that bay. In such a situation, the bay can be disabled for all assays or simply for Gram-negative assays. In such a situation, when a new sample is scanned, the bay processes data regarding the analysis type and can disable a particular bay based on the analysis type, i.e., the analysis does not function properly in the bay. In such a situation, when a new sample is scanned, the bay processes data regarding the analysis type and can suggest a particular bay based on the analysis type, i.e., the analysis does function properly in the bay. In this manner, bays can be disabled and / or suggested based on the type of assay.

[0164] In one embodiment, as potentially thousands of locating devices 12 report signal degradation over time to network 16 or remote monitoring center 17, remote monitoring center 17 can return information to locating devices 12 indicating that other systems are degrading, on average, when standby levels fall below baseline and put bays into standby. In some embodiments, if standby degradation is known, bays can be disabled before they reach failure levels and samples are run with invalid results.

[0165] In some embodiments, the waiting bay threshold is a range, a magnitude or intensity, or a combination thereof, that must be exceeded for a particular condition to be met.

[0166] In another embodiment, to compensate for a first bay 11 that is predicted to fail, processor 14 may change the settings of at least a second bay based at least in part on the standby analysis of the first bay. For example, if the heater in bay 1 is failing because the proximal room temperature is too low, processor 14 may change the settings in bay 2 so that the heater turns on sooner to reach the desired temperature at the desired time. As another example, if a first bay is experiencing a communication failure, that bay may be predicted to have a power problem. In such a situation, power to the entire tower may be lost, potentially disabling each bay in the tower (column).

[0167] In another embodiment, processor 14 may determine whether to disable or standby a bay based on the severity of the standby analysis. For example, if a bay passes the threshold analysis but fails the standby analysis based on two or more values, the processor may disable the bay. Stated another way, if a bay violates two or more standby rules, processor 14 disables the bay. Proposed Monitoring Procedures

[0168] 9 illustrates an exemplary monitoring procedure for the proposed rules engine 24b. In some embodiments, the result of the proposed rules analysis is to suggest a bay, put a bay on standby, or disable a bay.

[0169] As shown in Figure 9, processor 14 receives proposed bay data from control unit 13 (process 50b). Processor 14 first reviews the proposed bay data with a bay invalidation rules engine (process 54b). If the proposed bay data is within a threshold range (e.g., below a predetermined threshold), the bay is invalidated (process 55b). Process 55b can be implemented according to the embodiment described above in connection with process 53 (Figure 6). In an implementation of process 54b, if the proposed bay data is not within the threshold range (e.g., exceeds a predetermined limit), processor 14 then reviews the proposed bay data with a bay waiting rules engine (in process 56b).

[0170] In process 56b, if the proposed bay data is within a certain range (e.g., below a predetermined limit), the bay is placed on hold (process 58b). Process 58b can be implemented according to the embodiments described above with respect to process 58 (FIG. 7) and subsequent processes.

[0171] On the other hand, if in process 56b the proposed Bay data is not within range (e.g., exceeds a predetermined limit), the proposed Bay data is evaluated by a proposal rule engine (process 62). In process 62, the proposal rule engine evaluates whether the proposed Bay data meets a threshold (e.g., one or more thresholds). If the proposal rule engine determines that the proposed Bay data does not meet the threshold (e.g., is below a predetermined limit), the user interface 25 (e.g., GUI) is changed to indicate that no Bay is proposed (in process 63). In some implementations of process 63, for example, if the proposed Bay data is below a predetermined limit, the sample is marked as "processed." On the other hand, for example, if the proposal rule engine determines that the proposed Bay data is equal to or greater than a predetermined limit, the user interface 25 (e.g., GUI) is changed to indicate that a Bay is proposed (in process 65). In some implementations of process 65, for example, if the proposed Bay data is above a predetermined limit, the sample is marked as "processed."

[0172] In some embodiments, the proposed bay data is evaluated by the bay invalidation rule engine and / or the bay wait rule engine before the proposed rule engine. In some embodiments, the proposed bay data is evaluated by the proposed rule engine before the bay invalidation rule engine and / or the bay invalidation rule engine. In some embodiments, the proposed bay data is evaluated only by the proposed rule engine.

[0173] In some embodiments, for example, if the proposed bay data is determined by the bay queueing rules engine to be within range (e.g., below a predetermined limit) in process 56b and the bay is queued in process 58b, processor 14 evaluates whether there are other available bays in process 59b. If it is determined in process 59b that there are no other available bays, user interface 25 (e.g., GUI) is changed (in process 60b) to indicate that the bay is available (or suggested) for processing another sample. For example, if it is determined that there are no other available bays (process 59b), the system is configured to allow the user to run a sample in the bay. In some optional embodiments, for example, if the bay is queued in process 58b and it is determined that there are no other available bays, for example, if the bay was previously queued and the bay door was locked, the bay door is unlocked (in process 66).

[0174] If process 59b determines that there are no other available bays, then no bay is suggested. If process 59b determines that there are available bays, then the bay is suggested, for example, by modifying user interface 25 (e.g., GUI) to identify the suggested bay. Also, if process 59b determines that there are available bays, then processes 510, 511, and / or 512 can be implemented (as described above).

[0175] In some embodiments, the proposed bay data is compared to at least one proposed baseline (e.g., proposed threshold data), and if below the proposed baseline, the bay is placed on hold. In some embodiments, the proposed bay data is compared to at least one proposed baseline, and if above the proposed baseline, the bay is proposed. In some embodiments, the proposed bay data is compared to at least one proposed baseline, and if equal to or greater than the baseline, the bay is proposed.

[0176] In some embodiments, the proposed baseline data is based on the past performance of the bay being analyzed, the past performance of other bays on the same equipment being analyzed, the past performance of other bays on other equipment other than the equipment being analyzed, and combinations thereof.

[0177] The proposed baseline data indicates whether at least one of the bays is likely to operate within the desired range within a predetermined window, which can be a time frame or a number of samples processed.

[0178] In some embodiments, the proposed bay procedure activates a bay that was previously disabled or put on standby.

[0179] A behavior suggestion monitoring rule engine and a software suggestion monitoring rule engine.

[0180] In some embodiments, processor 14 receives data from control unit 13 (process 50). In some embodiments, processor 14 reviews the proposed bay data (in process 62) for operational issues in the action suggestion rule engine. In some embodiments, processor 14 reviews the proposed bay data (in process 62) for software issues in the software suggestion rule engine. In some embodiments, processor 14 reviews the proposed bay data (in process 62) for operational issues in the action suggestion rule engine and software issues in the software suggestion rule engine.

[0181] In some embodiments, processor 14 reviews (in process 62) the suggested bay data for operational issues by evaluating whether the operating conditions satisfy an operational suggestion baseline. The operational suggestion baseline includes one or more predetermined thresholds that, when met, indicate that the hardware or firmware of device 12 or a bay (e.g., bays 11 a, 11 b, or 11 n) is likely currently operating within desired parameters.

[0182] In some embodiments, processor 14 reviews the suggested bay data for software issues (in process 62) by evaluating whether a software suggested baseline has been met. The software suggested baseline includes one or more predetermined thresholds that, when met, indicate that the hardware or firmware of device 12 or bay (e.g., bay 11 a, 11 b, or 11 n) is likely currently operating within desired parameters.

[0183] Proposed monitoring rules / threshold data analysis.

[0184] A proposed monitoring rule (e.g., threshold data) is a rule that defines a proposed monitoring procedure for the proposed rule engine 24b. The result of a proposed rule is either to propose a bay, to disable a bay, or to place a bay on standby.

[0185] In some embodiments, the suggested monitoring rules are predefined for the device by a user, hi some embodiments, the suggested monitoring rules are created by artificial intelligence that evaluates performance data and establishes new suggested monitoring rules to be applied to the device.

[0186] In one embodiment, memory 15 may store suggested monitoring rules that may be associated with control unit 13, a bay (e.g., bay 11), other components of the diagnostic equipment, other components of the system, or a combination thereof.

[0187] As an example, suggested monitoring rules may include the following: A bay is suggested when the locating device experiences three consecutive valid runs. In some embodiments, three consecutive valid runs occur when there are three consecutive valid runs in a row on a bay. Runs can be derived from any combination of assay types. For example, all three validity codes can be derived from a first analysis type. For example, all three validity codes can be derived from three different assay types. For example, the first validity code can be derived from a first analysis type and two validity codes can be derived from a second analysis type. For example, the first and second validity codes can be derived from a first analysis type and the third validity code can be derived from a second analysis type. Assay types can be, for example, a blood culture identification panel, a respiratory panel, a gastrointestinal panel, an HCVg test, a cystic fibrosis genotyping test, a thrombosis risk test, a warfarin susceptibility test, or a 2C19 genotyping test.

[0188] In some embodiments, once a bay is proposed, the involved runs are marked as "processed" and excluded from future proposed monitoring rule reviews. In some embodiments, once a bay is proposed, the involved runs are marked as "processed" and included in future proposed monitoring rule reviews.

[0189] In some embodiments, the proposed monitoring rules are checked after each run, ie, after each sample processed by the instrument.

[0190] In some cases, the proposed bay data is collected after the sample is processed. In some cases, the proposed bay data is collected before the sample is processed. For example, if a bay connects to three cartridges in a row, the proposed monitoring rule is satisfied and the bay is placed in the proposed state. In some cases, the connection is determined by impedance data.

[0191] The proposed bay monitoring rules (e.g., threshold data) of the first locating device may be the same as, more than, and / or less than the proposed bay monitoring rules of the second locating device.

[0192] The proposed bay threshold for a first bay may be the same as, greater than, and / or less than the proposed bay threshold for a second bay on the same device. The proposed bay threshold for a first bay may be the same as, greater than, and / or less than the proposed bay threshold for a first bay on a different device.

[0193] The order of blocks (processes) 54b-512 is not limited to the order shown in Figure 9, and the blocks may be executed in a different order based on design needs. Furthermore, based on design needs, one or more blocks can be skipped or omitted from Figure 9, for example, blocks (processes) 54b, 56b, and 510-512 can be skipped or omitted.

[0194] change

[0195] In some embodiments, if a suggested monitoring rule (e.g., threshold data) is met, the processor 14 can optionally change at least one setting of the locating device 12. In some embodiments, the processor can place a bay in a standby state if a suggested rule is violated. In some embodiments, the processor can disable a bay if a suggested rule is violated.

[0196] In some embodiments, the processor may change the settings of one or more bays 11 and / or the settings of the user interface 25 when a suggestion rule is met. For example, a light on a bay door may be changed to indicate its suggested state. For example, the light on the bay door may be changed to a dimmed orange color to indicate its suggested state. For example, the color of an icon on the user interface corresponding to the bay may be changed to indicate its suggested state. For example, the color of an icon on the user interface corresponding to the bay may be changed to a dimmed orange color to indicate its suggested state.

[0197] In some embodiments, if a suggested monitoring rule is not violated, the processor 14 may optionally change at least one setting of the locating device 12. In some embodiments, the processor may change a setting on one or more bays 11 and / or a setting on the user interface 25 if a suggested rule is not violated. For example, a light on a bay door may be changed to indicate its suggested status. For example, a light on a bay door may be changed to purple to indicate a suggested bay for use. For example, a color of an icon on a user interface corresponding to a bay may be changed to indicate its suggested status. For example, a color of an icon on a user interface corresponding to a bay may be changed to purple to indicate its suggested status.

[0198] In some embodiments, if a proposed monitoring rule is not violated, the bay is proposed. In some embodiments, if a proposed monitoring rule is violated, the bay status remains neutral, i.e., not disabled, not proposed, or made proposed. In some embodiments, if a proposed monitoring rule is violated, the bay is disabled or put on standby.

[0199] Alerts

[0200] 9, if in block (process) 62 processor 14 determines that no problem exists (i.e., no suggested rule has been violated), processor 14 may terminate the suggested monitoring procedure. In some cases, when a suggested rule is satisfied, a suggested pass alert may be sent to user interface 25, network 16, remote monitoring center 17, and combinations thereof. The suggested pass alert may indicate that one or more evaluated problems have passed inspection, or may simply indicate that the system / bay is ready.

[0201] In some cases, if a suggestion rule is not met, a suggestion failure alert may be sent to the user interface 25, the network 16, the remote monitoring center 17, and combinations thereof. A suggestion failure alert may indicate that one or more evaluated problems failed inspection, or may simply indicate that the system / bay has been disabled.

[0202] The proposed rule threshold may be the same as, greater than, and / or less than the proposed rule threshold for a second bay on the same equipment. The proposed rule threshold may be the same as, greater than, and / or less than the proposed rule threshold for a second bay on a different equipment.

[0203] Proposal analysis.

[0204] The proposal analysis indicates whether at least one of the locating devices and / or bays is likely to operate within the desired range. The proposal analysis indicates whether at least one of the locating devices and / or bays is likely to operate within the desired range within a predetermined time period.

[0205] The predetermined period may be one hour, one day, one week, and / or one month, among other periods set by the user, network operator, and / or diagnostic equipment provider company. The predetermined period may be based on the number of samples processed, last 100, last 50, last 25, last 10, last 5, last 2, or last 1, or any other number set by the user, network operator, and / or diagnostic equipment provider company.

[0206] For example, detecting a control is an important aspect of predicting the likelihood that a bay will process a sample correctly. Thus, using aggregated data from multiple systems, if it is determined that a diagnostic instrument has failed to detect a control in the last three runs, it can be predicted that the diagnostic instrument bay is likely to experience a failure. Thus, it can be predicted when the diagnostic instrument bay will require technical support and / or service. Note that this does not mean that the prediction will always be correct. This does not mean that the prediction is always linear. In some implementations, failure to detect a control may correlate to accelerated failures over time.

[0207] In another embodiment, to compensate for the first bay 11 being predicted to operate correctly, the processor 14 may modify the settings of at least a second bay based at least in part on the proposed analysis of the first bay.

[0208] In another embodiment, processor 14 may determine whether to suggest a bay based on the strength of the suggestion analysis. For example, if a bay fails the wait analysis but passes two or more suggestion rules, the processor may still suggest the bay.

[0209] In some embodiments, the proposed Bay threshold is a range, a magnitude or intensity, or a combination thereof, that must be exceeded for a particular condition to be met. Evaluation and Monitoring Procedures

[0210] In some embodiments, a single data set is evaluated by different rule engines. For example, a single data set is evaluated by a bay disable rule engine, a standby rule engine, a suggestion rule engine, or a combination thereof. (See FIG. 10.) For example, a first rule engine might look at the last 10 runs and, if four of the last 10 runs are invalid, disable the bay; then a second rule engine might evaluate the data and, if one to three of the last 10 runs are invalid, put the bay on standby; then a third rule engine might evaluate the data and, if none of the last 10 runs are invalid, suggest the bay. Thus, rather than evaluating the disable bay data, standby bay data, and suggestion bay data separately, a single data set is evaluated by different rule engines and compared to different thresholds (e.g., a disable bay threshold, a suggestion bay threshold, or a standby bay threshold). Based on the passing or failing of one data set of thresholds, a processor might perform a function such as changing a GUI, changing a bay door light, locking the bay door, unlocking the bay door, or a combination thereof.

[0211] 10 illustrates an exemplary embodiment of a reputation monitoring procedure according to the present technology. In some embodiments, the result of the reputation rule analysis is to suggest a bay, put a bay on standby, or disable a bay.

[0212] In some embodiments, the evaluation bay monitoring procedure is performed in place of the disable bay monitoring procedure, the hold bay monitoring procedure, and / or the proposal bay monitoring procedure, and further applies the same disable bay thresholds, hold bay thresholds, and / or proposal bay monitoring thresholds as those procedures.

[0213] In some embodiments of the assessment monitoring procedure, processor 14 receives assessment data from control unit 13 (process 50c). Processor 14 reviews the assessment data (71) by comparing the assessment data to a disable bay threshold. If the assessment data meets the disable bay threshold (e.g., is greater than or equal to a predetermined disable bay threshold), the bay is disabled (in process 55c). Process 55c can be implemented according to the embodiments described above in connection with process 53 (FIG. 6). In an implementation of process 71, if the assessment data does not meet the disable bay threshold (e.g., is not greater than or equal to a predetermined disable bay limit), processor 14 compares the assessment data to threshold standby bay data (in process 72).

[0214] If process 72 determines that the assessment data does not meet the waiting bay threshold (e.g., exceeds a predetermined waiting baseline or range), the user interface 25 (e.g., GUI) is altered (in process 74) to indicate that the bay is suggested for processing another sample. In an implementation of process 72, if the assessment data is determined to meet the waiting bay threshold (e.g., below a predetermined waiting limit or waiting range), the bay is placed in a waiting state (in process 78). In some embodiments, if process 72 determines that the assessment data meets the waiting bay threshold (e.g., below a predetermined waiting limit or waiting range), the user interface 25 (e.g., GUI) is altered (not shown) to indicate that the bay is not suggested.

[0215] If process 72 determines that the assessment data does not meet the parking bay threshold (e.g., exceeds a predetermined parking bay limit (baseline or range)), processor 14 performs process 73 to compare the assessment data (56) and suggest a bay threshold. In an implementation of process 73, if the assessment data is determined to meet the suggestion bay threshold (e.g., exceeds a predetermined suggestion bay threshold limit), in process 65, the user interface 25 (e.g., GUI) is changed to indicate that a bay is suggested. In an implementation of process 73, if the assessment data is determined to not meet the suggestion bay threshold (e.g., falls below a predetermined bay threshold suggestion limit), in process 63, the user interface 25 (e.g., GUI) is changed to indicate that a bay is not suggested.

[0216] In some embodiments of the assessment monitoring procedure, if the assessment data does not meet a predetermined or pre-determined threshold (e.g., an invalid bay threshold, a proposed bay threshold, or a standby bay threshold), the bay door is locked to prevent the insertion of another cartridge. In some embodiments, for example, if the assessment data meets a predetermined or pre-determined threshold, the bay door is not locked and, if a sample is inserted, the bay ejects the cartridge without processing it.

[0217] In some embodiments, if the assessment data falls below a predetermined limit, the bay door is disabled to prevent processing of another sample.

[0218] In some embodiments, if the evaluation data exceeds a predetermined limit (e.g., a disable bay threshold, a proposed bay threshold, or a standby bay threshold), the bay is not disabled and the user interface 25 (e.g., a GUI) is changed to indicate that the bay is ready to process another sample.

[0219] In some embodiments, the assessment data is compared to at least one threshold (eg, a disable bay threshold, a proposal bay threshold, a waiting bay threshold, or a combination thereof), and if equal to or greater than the threshold, the sample is processed.

[0220] In some embodiments, the evaluation threshold is based on the past performance of the bay being analyzed. In some embodiments, the evaluation threshold is based on the past performance of other bays on the same instrument being analyzed. In some embodiments, the evaluation threshold is based on the past performance of other bays on instruments other than the instrument being analyzed. In some embodiments, the evaluation threshold is based on the past performance of the bay being analyzed, and / or the past performance of other bays on the same instrument being analyzed, and / or the past performance of other bays on instruments other than the instrument being analyzed. Evaluation and Monitoring Procedures

[0221] In some embodiments, the device evaluates one data set (called execution data) in one rules engine (called an evaluation rules engine) to determine whether a bay should be parked, disabled, or proposed ( FIG. 11 ). For example, a bay looks at the last 10 runs; if four of the last 10 runs are invalid, the bay is disabled; if one to three of the last 10 runs are invalid, the bay is parked; and if none of the last 10 runs are invalid, the bay is proposed. Thus, rather than evaluating the disable bay data, park bay data, and propose bay data separately, one data set is evaluated by one rules engine and compared to different thresholds (e.g., a disable bay threshold, a propose bay threshold, or a park bay threshold). Based on the passing or failing of the thresholds of one data set, the processor performs a function, such as changing a GUI or bay door light, locking the bay door, unlocking the bay door, or a combination thereof.

[0222] 11 illustrates an exemplary embodiment of a reputation monitoring procedure according to the present technology. In some embodiments, the result of the reputation rule analysis is to suggest a bay, put the bay on standby, or disable the bay.

[0223] In some embodiments, the evaluation bay monitoring procedure is performed in place of the disable bay monitoring procedure, the hold bay monitoring procedure, and / or the proposal bay monitoring procedure, and further applies the same disable bay thresholds, hold bay thresholds, and / or proposal bay thresholds as those procedures.

[0224] In some embodiments, processor 14 receives execution data from control unit 13 (in process 50d). Processor 14 reviews the execution data by comparing it to a disable bay threshold (in process 84). If the evaluation data meets the disable bay threshold (e.g., is greater than or equal to a predetermined disable bay threshold or range), the bay is disabled (in process 85). In some implementations, user interface 25 (e.g., GUI) is modified in process 85a to indicate that the bay has been disabled.

[0225] In an implementation of process 84, if it is determined that the execution data does not meet the disable bay threshold (e.g., below a predetermined disable bay threshold or range), processor 14 compares the execution data to a standby bay threshold (e.g., within a standby bay threshold data range). In an implementation of process 84, if it is determined that the execution data meets the standby bay threshold (e.g., within a predetermined standby threshold baseline or range), process 86 is implemented to place the bay in a standby state. In an implementation of process 84 when it is determined that the execution data does not meet the standby bay threshold, the user interface 25 (e.g., GUI) can be changed to indicate that the bay is suggested to process another sample. In some embodiments, if it is determined in process 86 that the execution data is to be placed in a standby state, process 86a changes the user interface 25 (e.g., GUI) to indicate that the bay is not suggested.

[0226] In an implementation of process 84, if it is determined that the execution data does not satisfy the disable bay threshold and the standby bay threshold, the processor 14 compares the execution data with the proposed bay threshold data. In such an implementation, if it is determined that the execution data satisfies the proposed bay threshold (e.g., equal to or greater than a predetermined proposed bay limit), the user interface 25 is modified to indicate that a bay is being proposed (in process 87). In such an implementation (if it is determined that the execution data satisfies the proposed bay threshold (e.g., equal to or greater than a predetermined proposed bay limit)), the user interface 25 (e.g., GUI) can be modified to indicate that a bay is being proposed (in process 87a). In some implementations, if it is determined that the execution data does not satisfy the proposed bay threshold (e.g., falls below a predetermined proposed bay limit), the user interface 25 (e.g., GUI) can be modified to indicate that a bay is not being proposed.

[0227] In some embodiments, if the run data is below a predetermined limit (e.g., an invalid bay threshold, a proposed bay threshold, or a standby bay threshold), the bay door is locked to prevent the insertion of another cartridge. In some embodiments, if the run data is below a predetermined limit, the bay door is not locked and, if a sample is inserted, the bay ejects the cartridge without processing it.

[0228] In some embodiments, if the run data falls below a predetermined limit, the bay door is disabled to prevent processing of another sample.

[0229] In some embodiments, if the execution data exceeds a predetermined limit (e.g., a disable bay threshold, a proposed bay threshold, or a standby bay threshold), the bay is not disabled and the user interface 25 changes to indicate that the bay is ready to process another sample.

[0230] In some embodiments, the execution data is compared to at least one threshold (eg, a disable bay threshold, a proposal bay threshold, a waiting bay threshold, or a combination thereof), and if equal to or greater than the threshold, the sample is processed.

[0231] In some embodiments, the performance threshold is based on the past performance of the bay being analyzed. In some embodiments, the performance threshold is based on the past performance of other bays on the same instrument being analyzed. In some embodiments, the performance threshold is based on the past performance of other bays on instruments other than the instrument being analyzed. In some embodiments, the performance threshold is based on the past performance of the bay being analyzed, and / or the past performance of other bays on the same instrument being analyzed, and / or the past performance of other bays on instruments other than the instrument being analyzed, and / or combinations thereof.

[0232] In some embodiments, the result of the evaluation bay rule analysis is to disable the bay or allow the bay to be used. In some embodiments, the result of the evaluation bay rule analysis is to either disable the bay, put the bay on standby, or suggest the bay for use.

[0233] 11, processor 14 receives data from control unit 13 (process 50d). Processor 14 reviews the execution data (in process 84). In some embodiments, reviewing means that processor 14 compares the execution data (process 84) with threshold data from the bay, from other bays on the instrument, from other bays on other instruments, or a combination thereof.

[0234] In some embodiments, the performance data is compared to invalidation bay threshold data, waiting bay threshold data, or proposal bay threshold data (collectively, evaluation bay threshold data).

[0235] In some embodiments, if the execution data is below a predetermined limit, the sample is marked as "processed." In some embodiments, if a bay is disabled in response to the execution data, results from the analyzed sample are still reported. In some embodiments, if a bay is disabled in response to the execution data, results from the analyzed sample are not reported.

[0236] In some embodiments, if the run data falls below a predetermined limit, the bay door is disabled to prevent processing of another sample. Disabling a bay can include failing power to the bay, deleting the software protocol that controls the bay, disabling the pump, locking the bay door, ejecting the cartridge, and combinations thereof.

[0237] In some cases, the execution data is analyzed in the evaluation rule engine and the results are in a toggle relationship, if not disabled, go to standby: if not waiting, disable; if not disabled, suggest; if not suggested, disable; if not waiting, suggest; if not suggested, go to standby; if not disabled, suggest; if not suggested, disable.

[0238] In some embodiments, the threshold bay data is based on the historical performance of the bay being analyzed, the historical performance of other bays on the same equipment being analyzed, the historical performance of other bays on other equipment other than the equipment being analyzed, and combinations thereof.

[0239] In some embodiments, the threshold bay data is a range, a magnitude or intensity that must be exceeded for a particular condition to be met, or a combination thereof.

[0240] Bay behavior reputation monitoring rules engine and Bay software reputation monitoring rules engine.

[0241] 11, the processor 14 receives data from the control unit 13 (process 50d). In some embodiments, the processor 14 reviews the execution data for operational issues in the bay operation assessment rules engine, software issues in the software assessment rules engine, and combinations thereof (process 84).

[0242] In some embodiments, processor 14 reviews (in process 84) the evaluation bay data (execution data) for operational issues by evaluating whether the operating conditions meet an operational evaluation bay baseline. The operational evaluation bay baseline includes one or more predetermined thresholds that, when met, indicate that the locating device 12 or bay (e.g., bay 11a, 11b, or 11n) currently has at least one hardware or firmware problem / issue.

[0243] In some embodiments, processor 14 reviews evaluation bay data (execution data) for software issues (in process 84) by evaluating whether a software evaluation bay baseline has been met. The software evaluation bay baseline includes one or more predetermined thresholds that, when met, indicate that the locating device 12 or bay (e.g., bay 11a, 11b, or 11n) currently has at least one software problem / issue.

[0244] In some embodiments, the evaluation bay threshold data reveals that a bay at a particular location always performs poorly, even if the bay is replaced. In such a situation, the evaluation bay threshold data always keeps that bay disabled, even if it passes through all the rules engines.

[0245] Assessment bay monitoring rules / threshold data analysis.

[0246] Evaluation bay monitoring rules (also referred to as threshold data) are rules that define the evaluation bay monitoring procedures for the evaluation rule engine 24c. In some embodiments, evaluation bay monitoring rules are predefined for equipment by a user. In some embodiments, evaluation bay monitoring rules are created by artificial intelligence that evaluates execution data and establishes new evaluation bay monitoring rules to be applied to equipment. In some embodiments, evaluation bay monitoring rules are disable bay monitoring rules, standby bay monitoring rules, proposed bay monitoring rules, and combinations or different bay monitoring rules.

[0247] In one embodiment, memory 15 may store evaluation bay monitoring rules that may be associated with control unit 13, a bay (e.g., bay 11), other components of the locating device, other components of the system, or a combination thereof.

[0248] As an example, evaluation bay monitoring rules may include: Disable bay if locator device experiences four consecutive errors.

[0249] The processor 14 executes the evaluation bay monitoring procedures and analyses, and collects the evaluation bay monitoring data.

[0250] The order of the blocks is not limited to the order shown in Figure 11 and may be executed in a different order based on design needs. Furthermore, based on design needs, one or more blocks may be skipped or omitted from Figure 11, for example, blocks 85-87 may be skipped or omitted.

[0251] change

[0252] In some embodiments, if an evaluation bay monitoring rule is violated, the processor 14 may optionally change at least one setting of the locator device 12. A bay door light may be changed to indicate its disabled state. For example, the bay door light may be changed to gray to indicate its disabled state. For example, the color of an icon on the user interface corresponding to the bay may be changed to indicate its disabled state. For example, the color of an icon on the user interface corresponding to the bay may be changed to gray to indicate its disabled state. For example, the bay door may be locked. For example, power to the bay may be interrupted. In addition to changing the color of the bay icon or bay door light, in some embodiments, the processor may change the settings of one or more bays 11 and / or the settings of the user interface 25 if an evaluation bay rule is violated. For example, if a heater is unable to reach a desired temperature, a bay fan may be turned on to improve temperature control.

[0253] In some embodiments, if evaluation bay monitoring rules (e.g., threshold data) are not violated, the processor 14 can optionally change at least one setting of the locating device 12. In some embodiments, the processor can change the settings of one or more bays 11 and / or the settings of the user interface 25 if evaluation bay rules are not violated. For example, a light on a bay door may be changed to indicate its status. For example, a light on a bay door may be changed to white to indicate its status is ready to process another sample. For example, an icon color on the user interface corresponding to the bay may be changed to white to indicate its ready-to-run status.

[0254] In some embodiments, if no evaluation bay monitoring rules are violated, the bay is proposed. In some embodiments, if no disable bay monitoring rules are violated, the bay is put on hold. In some embodiments, if no disable bay monitoring rules are violated, the bay status remains neutral, i.e., not disabled, proposed, or put on hold.

[0255] Alerts

[0256] 11 , block 54, if the processor 14 determines that no issues exist (e.g., no disable bay rules have been violated), the processor 14 may terminate the evaluation bay monitoring procedure. In some cases, when an evaluation bay threshold rule is met, an evaluation bay monitoring rule pass alert may be sent to the user interface 25, the network 16, the remote monitoring center 17, and combinations thereof. The evaluation bay pass alert may indicate that one or more issues evaluated have passed inspection, or may simply indicate that the system / bay is ready.

[0257] In some cases, when an evaluation bay rule is not met, an evaluation bay failure alert may be sent to the user interface 25, the network 16, the remote monitoring center 17, and combinations thereof. The evaluation bay failure alert may indicate that one or more issues evaluated have failed inspection, or may simply indicate that the system / bay has been disabled.

[0258] In some embodiments, the performance dataset and the evaluation dataset are the same. Behavioral characteristics

[0259] In another embodiment, the monitoring procedures (disable bay monitoring procedure, standby monitoring procedure, proposal monitoring procedure, evaluation monitoring procedure, and diagnostic monitoring procedure) may be based on behavioral characteristics rather than equipment data. For example, if processor 14 determines that at least one behavioral characteristic of location-based equipment 12 is outside of a baseline, it may suggest a bay, disable a bay, or place a bay on standby. For example, if one bay is used more frequently than another bay, i.e., the upper left compared to the lower right, the processor may suggest a different bay and / or suggest a monitoring evaluation, even if the used bay has gone through the disable and / or standby stages.

[0260] The behavioral characteristics relate to the operation and / or function of the equipment based on user input during a predetermined time range and / or a predetermined day of the week. For example, processor 14 may determine that bay number 1 is used every weekday at 9:00 AM, Monday through Friday. At least one behavioral characteristic of the location-based system may indicate a time period during which the location-based system will suggest a different bay, i.e., bay 6 at 9:00 AM, Monday through Friday, even if bay 1 does not violate the disable bay threshold data or the standby threshold data. In this way, certain bays will not wear out before other bays. Data Over Time

[0261] In one embodiment, the invalidation bay data, waiting bay data, proposal bay data, execution data, evaluation data, and combinations thereof are based on data collected over time, i.e., data from more than one sample is evaluated. For example, execution data may include data from the last 5 samples processed, the last 10 samples processed, the last 50 samples processed, the last 100 samples processed, etc.

[0262] In one embodiment, the evaluation bay threshold data, the disable bay threshold data, the waiting bay threshold data, the proposed bay threshold data, and combinations thereof are based on data collected over time. For example, the threshold data may include data from 5 samples processed, 10 samples processed, 50 samples processed, 100 samples processed, etc. The threshold data may be based on the past performance of the bay being analyzed, the past performance of other bays on the same instrument being analyzed, the past performance of other bays on other instruments other than the instrument being analyzed, and combinations thereof. Comparison Step

[0263] In some embodiments, the disable bay procedure, standby bay procedure, suggest bay procedure, evaluate bay procedure, assess bay procedure, and combinations thereof (referred to as monitor procedures) include an additional bay comparison step (not shown). In some embodiments, after a bay is determined to be disabled, standby, or proposed, the monitor procedure then asks, "How does this bay compare to the other bays?" As an example, if a diagnostic instrument has three bays, and the first bay is disabled for four consecutive invalid runs, the second bay is standby for two consecutive invalid runs, and the third (existing) bay violates a behavioral characteristic disable threshold, the third bay is still the best bay of all bays on the instrument and should not be disabled over the first and second bays because there is nothing inherently wrong with the bay's performance except for overuse. In this way, disabling a bay due to a behavioral characteristic does not take priority over disabling a bay due to a performance issue.

[0264] As another example, if a diagnostic device has three bays, and the first bay is disabled due to four consecutive invalid runs, the second bay is put on hold due to three consecutive invalid runs, and the third (existing) bay has one invalid run, then the third bay is the best bay of all the bays on the device and should be suggested over the first and second bays, or at least not put on hold to promote use to this best bay.

[0265] As another example, if a diagnostic instrument has three bays, the first bay is disabled due to four consecutive invalid runs, the second bay is put on standby due to two consecutive invalid runs, and the third (existing) bay has no invalid runs, then the third bay is the best bay of all bays on the instrument and should be suggested over the first and second bays.

[0266] In some embodiments, the bay comparison step for the monitoring procedure is performed only if 10%, 20%, 30%, 40%, 50%, 60%, 70%, 80%, 90%, 95% or 100% of the bays are disabled, placed on standby, or a combination thereof. Judgment step

[0267] In some embodiments, processor 14 performs a "decision step" before the "receive data" process to determine whether self-monitoring is required. If processor 14 determines not to initiate monitoring, processor 14 may loop and periodically perform the decision step. For example, the decision step for monitoring the health of the equipment may be repeated periodically or may be continuous using a program subroutine built into the general operating software.

[0268] In some embodiments, locating device 12 does not perform a "determine" step before the "receive data" process, for example, before process 51 (FIG. 6), or before process 54 (FIG. 7), or before process 54b (FIG. 9), or before process 71 (FIG. 10), or before process 84 (FIG. 11).

[0269] If the processor 14 determines to start monitoring, the processor 14 executes a monitoring process (e.g., the disable bay monitoring process of FIG. 6). For example, the processor 14 may start the disable bay monitoring process of the bay disable monitoring rule engine 23 and / or the standby monitoring process of the standby monitoring rule engine 24a, and / or propose a monitoring process of the proposal monitoring rule engine 24b, and / or evaluate a monitoring process of the evaluation monitoring rule engine 24c. Analysis Algorithm

[0270] By way of non-limiting example, the invalidation bay analysis algorithm, the waiting bay analysis algorithm, the proposal bay analysis algorithm, and / or the evaluation bay analysis algorithm may be implemented using data logic algorithms, statistical analysis, data analysis, and data manipulation in a manner known to those skilled in the art. This may include, for example, traditional software-based statistical analysis functions, financial functions, time series functions, text string functions, grouping functions, etc. Software-based audio and video analysis functions (and reintroduction of data output from such analyses back into the aforementioned functions) may also be incorporated.

[0271] In some embodiments, data analysis techniques that can be used also include A / B testing, association rule learning, classification, cluster analysis, crowdsourcing, data fusion and integration, ensemble learning, genetic algorithms, machine learning, natural language processing, neural networks, pattern recognition, anomaly detection, queue modeling, regression, sentiment analysis, signal processing, supervised and unsupervised learning, simulation, time series analysis and visualization. Monitoring rules / threshold data

[0272] In some embodiments, a monitoring rule (e.g., a disable bay monitoring rule, a standby monitoring rule, a proposal monitoring rule, or an evaluation monitoring rule) can relate to any analysis of the operation of a bay, and can include the power state of the bay, the ability to connect to a cartridge, the impedance state, whether the bay heater was able to reach a desired temperature, etc. Disabling a bay monitoring rule can monitor hardware (such as actuators, bay doors, pogo pins, etc.) to determine if the hardware is not functioning properly or has been deactivated.

[0273] In some embodiments, a monitoring rule (e.g., a deactivation bay monitoring rule, a standby monitoring rule, a proposal monitoring rule, or an evaluation monitoring rule) can relate to any analysis of the operation of the assay and can include: whether the signal strength is above a predetermined threshold, whether the sample has moved properly through the cartridge (properly moved can refer to speed, position, control, etc.), whether a control has been detected.

[0274] In some embodiments, a monitoring rule (e.g., a disable bay monitoring rule, a standby monitoring rule, a proposal monitoring rule, or an evaluation monitoring rule) may relate to any analysis of the operation of the equipment, including the power state of the equipment, the ability of the equipment to connect to a network, the state of the operating software, the state of the operating hardware, and the state of the operating firmware. For example, a disable bay monitoring rule may monitor software to determine if a subsystem or rules engine is not functioning properly or has been deactivated.

[0275] In some embodiments, the monitoring rules form the basis of the threshold data. The bay factors for evaluation data, invalid bay data, waiting bay data, and proposed bay data are listed in Table 1. [Table 1]

[0276] The evaluation data, invalidation bay data, standby bay data, and proposed bay data may be, but are not limited to, the factors shown in Table 2. [Table 2]

[0277] The evaluation data, invalidation bay data, standby bay data, and proposed bay data may be, but are not limited to, the factors shown in Table 3. [Table 3]

[0278] The evaluation data, invalidation bay data, standby bay data, and proposed bay data may be, but are not limited to, the factors shown in Table 4. [Table 4]

[0279] In some embodiments, a disabled bay is inoperable. In some embodiments, a disabled bay may not be used by a user. In some embodiments, a disabled bay and a standby bay may not be used by a user. In some embodiments, a disabled bay may be manually turned back on by a user.

[0280] In some embodiments, only the proposed bay may be used. In some embodiments, the proposed bay and the standby bay may be used.

[0281] In some embodiments, when a bay is in a standby state, it may still be used. In some embodiments, when a bay is in a standby state, it may not be used. Example

[0282] This system can be understood by the following numbered examples:

[0283] Example 1. A diagnostic device comprising: (a) a bay; (b) a control unit comprising a bay disable rule engine, a standby rule engine, and a proposal rule engine, wherein the bay disable monitoring rule engine generates disabled bay data, the standby monitoring rule engine generates standby bay data, and the proposal monitoring rule engine generates proposed bay data; and (c) a processor that determines whether the disabled bay data, the standby bay data, and the proposed bay data meet a predetermined baseline, wherein the processor disables a bay in response to determining that the disabled bay data does not meet the predetermined baseline.

[0284] Example 2. The diagnostic device of example 1, wherein the processor modifies the GUI in response to determining that the invalid bay data does not meet a predetermined baseline.

[0285] Example 3. The diagnostic device of example 1 or 2, wherein in response to determining that the invalidated bay data does not meet a predetermined baseline, the processor modifies the GUI by changing the color of the bay icon corresponding to the bay.

[0286] Example 4. The diagnostic device of any one of Examples 1-3, wherein the bay further comprises a bay door, and wherein the processor locks the bay door in response to determining that the invalidated bay data does not meet the predetermined baseline.

[0287] Example 5. The diagnostic device of any one of Examples 1-4, wherein the bay further comprises a bay light, and wherein the processor changes a color of the bay light in response to determining that the invalidated bay data does not meet the predetermined baseline.

[0288] Example 6. The diagnostic instrument of any one of Examples 1-5, wherein the processor generates a disable bay fault alert in response to determining that the disable bay data does not meet a predetermined baseline.

[0289] Example 7. The diagnostic device of any of Examples 1-6, wherein the invalidation bay data is based on behavioral characteristics.

[0290] Example 8. The diagnostic device of Examples 1-7, wherein the invalidation bay data is based on data collected over time.

[0291] Example 9. A diagnostic device comprising: (a) a bay; (b) a control unit, the control unit having a bay disable rule engine, the bay disable monitoring rule engine generating disabled bay data; and (c) a processor, the processor determining whether the disabled bay data meets a predetermined baseline, wherein the processor disables the bay in response to determining that the disabled bay data does not meet the predetermined baseline.

[0292] Example 10. The diagnostic device of example 9, wherein the processor modifies the GUI in response to determining that the invalid bay data does not meet a predetermined baseline.

[0293] Example 11. The diagnostic device of example 9 or 10, wherein in response to determining that the invalidated bay data does not meet a predetermined baseline, the processor modifies the GUI by changing the color of the bay icon corresponding to the bay.

[0294] Example 12. The diagnostic device of any of Examples 9-11, wherein the bay further comprises a bay door, and wherein the processor locks the bay door in response to determining that the invalidated bay data does not meet the predetermined baseline.

[0295] Example 13. The diagnostic device of any of Examples 9-12, wherein the bay further comprises a bay light, and wherein the processor changes the color of the bay light in response to determining that the invalidated bay data does not meet the predetermined baseline.

[0296] Example 14. The diagnostic device of any of Examples 9-13, wherein the processor generates a disable bay fault alert in response to determining that the disable bay data does not meet a predetermined baseline.

[0297] Example 15. The diagnostic device of any of Examples 9-14, wherein the invalidation bay data is based on behavioral characteristics.

[0298] Example 16. The diagnostic device of Examples 9-15, wherein the invalidation bay data is based on data collected over time.

[0299] Example 17. A diagnostic device comprising: (a) a bay; (b) a control unit having a standby rule engine, wherein the standby monitoring rule engine generates standby bay data; and (c) a processor, wherein the processor determines whether the standby bay data meets a predetermined baseline, and in response to determining that the standby bay data does not meet the predetermined baseline, the processor places the bay in a standby state.

[0300] Example 18. The diagnostic device of Example 17, wherein the processor modifies the GUI in response to determining that the standby bay data does not meet a predetermined baseline.

[0301] Example 19. The diagnostic device of example 18 or 17, wherein in response to determining that the standby bay data does not meet a predetermined baseline, the processor modifies the GUI by changing the color of the bay icon corresponding to the bay.

[0302] Example 20. The diagnostic device of any one of Examples 17 to 19, wherein the bay further comprises a bay door, and wherein the processor locks the bay door in response to determining that the standby bay data does not meet a predetermined baseline.

[0303] Example 21. The diagnostic device of any one of Examples 17 to 20, wherein the bay further comprises a bay light, and wherein the processor changes the color of the bay light in response to determining that the standby bay data does not meet the predetermined baseline.

[0304] Example 22. The diagnostic device of any of Examples 17-21, wherein the processor generates a standby bay fault alert in response to determining that the standby bay data does not meet a predetermined baseline.

[0305] Example 23. The diagnostic device of any of Examples 17-22, wherein the waiting bay data is based on behavioral characteristics.

[0306] Example 24. The diagnostic device of Examples 17-23, wherein the waiting bay data is based on data collected over time.

[0307] Example 25. A diagnostic device comprising: (a) a bay; (b) a control unit having a proposal rule engine in which a proposal monitoring rule engine generates proposed bay data; and (c) a processor that determines whether the proposed bay data satisfies a predetermined baseline, wherein the processor suggests a bay in response to a determination that the proposed bay data satisfies the predetermined baseline.

[0308] Example 26. A diagnostic device as described in Example 25, wherein the processor modifies the GUI in response to determining that the proposed bay data meets a predetermined baseline.

[0309] Example 27. A diagnostic device as described in Example 25 or 26, wherein in response to determining that the proposed bay data meets a predetermined baseline, the processor modifies the GUI by changing the color of the bay icon corresponding to the bay.

[0310] Example 28. The diagnostic device of any one of Examples 25 to 27, wherein the bay further comprises a bay light, and wherein the processor changes the color of the bay light in response to determining that the proposed bay data meets the predetermined baseline.

[0311] Example 29. The diagnostic device of any of Examples 25-28, wherein the processor generates a proposed bay pass alert in response to determining that the proposed bay data meets the predetermined baseline.

[0312] Example 30. The diagnostic device of any of Examples 25 to 29, wherein the proposed Bayes data is based on behavioral characteristics.

[0313] Example 31. A method for disabling bays in a diagnostic device, the method comprising: (a) receiving disabling bay data for at least one bay; (b) determining whether the disabling bay data meets at least one predetermined baseline; and (c) disabling the at least one bay in response to determining that the disabling bay data does not meet the at least one predetermined baseline.

[0314] Example 32. The method of example 31, wherein the processor modifies the GUI in response to determining that the invalid bay data does not meet at least one predetermined baseline.

[0315] Example 33. The method of example 31 or 32, wherein in response to determining that the invalid bay data does not meet at least one predetermined baseline, the processor modifies the GUI by changing the color of a bay icon corresponding to at least one bay.

[0316] Example 34. The method of any one of Examples 31 to 33, wherein at least one bay further comprises a bay door, and in response to determining that the invalidated bay data does not satisfy at least one predetermined baseline, the processor locks the bay door.

[0317] Example 35. The method of Examples 31-34, wherein the bay further comprises a bay light, and in response to determining that the invalid bay data does not satisfy at least one predetermined baseline, the processor changes a color of the bay light.

[0318] Example 36. The method of Examples 31-35, wherein the processor generates a disable bay failure alert in response to determining that the disable bay data does not meet at least one predetermined baseline.

[0319] Example 37. The method of Examples 31-36, wherein the invalidation bay data is based on behavioral characteristics.

[0320] Example 38. The method of Examples 31-37, wherein the invalidation bay data is based on data collected over time.

[0321] Example 39. A method for disabling a bay in a diagnostic device, the method comprising: (a) receiving disabling bay data for a first bay; (b) determining whether the disabling bay data meets at least one predetermined baseline; and (c) disabling the bay in response to determining that the disabling bay data does not meet the at least one predetermined baseline.

[0322] Example 40. The method of example 39, wherein the processor modifies the GUI in response to determining that the invalid bay data does not meet at least one predetermined baseline.

[0323] Example 41. The method of example 39 or 40, wherein in response to determining that the invalid bay data does not meet at least one predetermined baseline, the processor modifies the GUI by changing the color of the bay icon corresponding to the bay.

[0324] Example 42. The method of any one of Examples 39 to 41, wherein the bay further comprises a bay door, and the processor locks the bay door in response to determining that the invalidated bay data does not satisfy at least one predetermined baseline.

[0325] Example 43. The method of Examples 39-42, wherein the bay further comprises a bay light, and in response to determining that the invalid bay data does not satisfy at least one predetermined baseline, the processor changes the color of the bay light.

[0326] Example 44. The method of any one of Examples 39-43, wherein the processor generates a disable bay failure alert in response to determining that the disable bay data does not meet at least one predetermined baseline.

[0327] Example 45. The method of Examples 39-44, wherein the invalidation bay data is based on behavioral characteristics.

[0328] Example 46. The method of Examples 39-45, wherein the invalidation bay data is based on data collected over time.

[0329] Example 47. A method for placing a bay in a diagnostic device on standby, the method comprising: (a) receiving standby bay data for a first bay; (b) determining whether the standby bay data meets at least one predefined baseline; and (c) placing the bay on standby in response to determining that the standby bay data does not meet the at least one predefined baseline.

[0330] Example 48. The method of example 47, wherein the processor modifies the GUI in response to determining that the standby bay data does not meet at least one predefined baseline.

[0331] Example 49. The method described in example 47 or 48, wherein in response to determining that the standby bay data does not meet at least one predetermined baseline, the processor modifies the GUI by changing the color of the bay icon corresponding to the bay.

[0332] Example 50. The method of any one of Examples 47 to 49, wherein the bay further comprises a bay door, and the processor locks the bay door in response to determining that the standby bay data does not meet at least one predetermined baseline.

[0333] Example 51. The method of Examples 47-50, wherein the bay further comprises a bay light, and in response to determining that the standby bay data does not satisfy at least one predetermined baseline, the processor changes the color of the bay light.

[0334] Example 52. The method of any one of Examples 47-51, wherein the processor generates a disable bay failure alert in response to determining that the standby bay data does not meet at least one predetermined baseline.

[0335] Example 53. The method of any one of Examples 47 to 52, wherein the waiting bay data is based on behavioral characteristics.

[0336] Example 54. The method of any one of Examples 47-53, wherein the waiting bay data is based on data collected over time.

[0337] Example 55. A method for suggesting a bay in a diagnostic device, the method comprising: (a) receiving suggested bay data for a first bay; (b) determining whether the suggested bay data meets at least one predetermined baseline; and (c) suggesting the bay in response to determining that the suggested bay data meets at least one predetermined baseline.

[0338] Example 56. The method of example 55, wherein the processor modifies the GUI in response to determining that the proposed bay data meets at least one predetermined baseline.

[0339] Example 57. The method described in example 55 or 56, wherein in response to determining that the proposed bay data meets at least one predetermined baseline, the processor modifies the GUI by changing the color of the bay icon corresponding to the bay.

[0340] Example 58. The method of any one of Examples 55 to 57, wherein the bay further comprises a bay door, and in response to determining that the proposed bay data satisfies at least one predetermined baseline, the processor locks the bay door.

[0341] Example 59. The method of Examples 55-58, wherein the bay further comprises a bay light, and in response to determining that the proposed bay data satisfies at least one predetermined baseline, the processor changes the color of the bay light.

[0342] Example 60. The method of Examples 55-59, wherein the processor generates a disable bay failure alert in response to determining that the proposed bay data meets at least one predetermined baseline.

[0343] Example 61. The method of Examples 55-60, wherein the proposed Bayes data is based on behavioral characteristics.

[0344] Example 62. The method of Examples 55-61, wherein the proposed Bay data is based on data collected over time.

[0345] Example 63. A method for disabling standby diagnostic equipment, the method comprising: (a) receiving execution bay data for a first bay; (b) determining whether the execution bay data meets at least one predetermined baseline; and (c) disabling the standby bay in response to determining that the execution bay data does not meet the at least one predetermined baseline.

[0346] Example 64. A method for suggesting standby diagnostic equipment, the method comprising: (a) receiving execution bay data for a first bay; (b) determining whether the execution bay data meets a first predetermined baseline; (c) determining whether the execution bay data meets a second predetermined baseline; (d) determining whether the execution bay data meets a third predetermined baseline; and (e) suggesting a bay in response to determining that the execution bay data meets the first, second, and third predetermined baselines.

[0347] Example 65. The method of any one of Examples 1 to 64, wherein the execution bay data is based on user behavior characteristics.

[0348] Example 66. A monitoring system comprising a processing unit and a control unit, wherein the control unit comprises an invalidation rule engine, the invalidation rule engine generates invalidation data, and the processing unit determines whether the invalidation data meets a predetermined baseline.

[0349] Example 67. A graphical user interface including at least one icon corresponding to a processing unit, wherein the at least one icon changes from a first color to a second color in response to determining that the processing unit data does not meet a predetermined baseline.

[0350] Example 68. The graphical user interface of Example 67, wherein the first color and the second color are different.

[0351] Example 69. A processing unit door lock comprising a door lock, wherein the door lock moves from a first position to a second position in response to determining that the processing unit data does not meet a predetermined baseline.

[0352] Example 70. The processing unit door lock of example 69, wherein the first position of the door lock is unlocked and the second position of the door lock is locked.

[0353] Example 71. A diagnostic device comprising a processing unit and a graphical user interface, wherein the graphical user interface comprises at least one icon corresponding to the processing unit, and wherein the at least one icon changes from a first color to a second color in response to a determination that the processing unit data does not meet a predetermined baseline.

[0354] Example 72. The diagnostic device of example 71, wherein the first color and the second color are different.

[0355] Example 73. A diagnostic device or method according to any one of Examples 1 to 72, wherein bay monitoring is disabled, the bay (or bays) is put on standby, and / or one or more bays are automatically suggested.

[0356] Example 74. The diagnostic device or method of example 73, which automatically notifies the user to contact technical support for further investigation.

[0357] Example 75. The diagnostic device or method of example 73 or 74, including an option to override bay disable, wait, and / or feature suggestions.

[0358] Example B1. A method for disabling a processing unit in a diagnostic device, the method comprising: (a) receiving data relating to a first processing unit by a processor; (b) determining whether the data meets at least one predetermined baseline; and (c) disabling the processing unit by the processor if the data does not meet the at least one predetermined baseline.

[0359] Example B2. The method of Example B1, wherein the diagnostic device further comprises a graphical user interface.

[0360] Example B3-A. The method of example B2, wherein the processor modifies the graphical user interface in response to determining that the data does not meet at least one predetermined baseline.

[0361] Example B3-B. The method described in Example B2, wherein the graphical user interface has a processing unit icon corresponding to the processing unit, and the processing unit icon changes from a first color to a second color in response to a determination that the data does not meet at least one predetermined baseline.

[0362] Embodiment B4. The method of embodiment B1, wherein the first processing unit further comprises a door, the door locking in response to determining that the data does not meet at least one predetermined baseline.

[0363] Example B5. The method of example B1, wherein the first processing unit further comprises a light, and wherein the light changes from a first color to a second color in response to determining that the data does not meet at least one predetermined baseline.

[0364] Example B6. The method of example B1, wherein a fail alert is generated in response to determining that the data does not meet at least one predetermined baseline.

[0365] Example B7 The method of Example B1, wherein the data is based on behavioral characteristics.

[0366] Example B8. The method of example B1, wherein disabling the processing unit includes removing power to the processing unit, deleting software protocols that control the processing unit, locking the processing unit door, ejecting the cartridge, or a combination thereof.

[0367] Example B9. The method of Example B1, wherein data is collected over time.

[0368] Example B10. A method for determining a status of a diagnostic device, comprising: (a) displaying a first icon on a graphical user interface, the icon having a first color; (b) receiving data relating to a first processing unit by a processor; and (c) determining whether the data meets at least one predetermined baseline; wherein if the data does not meet the at least one predetermined baseline, the first color changes to a second color, the second color reflecting the status of the processing unit.

[0369] Example B11. The method of example B10 further includes: (a) displaying a second icon on a graphical user interface, the second icon having a first color; (b) receiving data related to a second processing unit by a processor; and (c) determining whether the data meets at least one predetermined baseline; if the data does not meet the at least one predetermined baseline, the second color changes to a third color, the third color reflecting a state of the processing unit.

[0370] Embodiment B12. The method of embodiment B10, wherein the first processing unit is disabled after step (c).

[0371] Example B13. A method for increasing the effectiveness rate of a first diagnostic assay, comprising: (a) receiving, by a processor, data relating to a first processing unit within a first diagnostic device; (b) determining whether the data meets at least one predetermined baseline; and (c) disabling the processing unit within the first diagnostic device if the data does not meet the at least one predetermined baseline.

[0372] Example B14. The method of Example B13, wherein the assay is a Gram-positive, Gram-negative fungal gastrointestinal or respiratory assay.

[0373] Example B15. The method of Example B13, wherein the diagnostic assay is not modified to increase the efficacy rate of the diagnostic assay.

[0374] Example B16. The method of Example B13, wherein the data is based on how the processing unit functions, how the diagnostic device functions, how the diagnostic assay functions, behavioral characteristics, or a combination thereof.

[0375] Example B17. The method of Example B13, wherein the data is based on at least a first assay type, a second assay type, or both.

[0376] Example B18. The method of example B13, wherein the data is not based on how the first diagnostic device or the first processing unit functions.

[0377] Example B19. The method of Example B13, wherein the effectiveness rate of the first diagnostic assay is increased, but the effectiveness rate of the second diagnostic assay is not increased.

[0378] Example B20. A diagnostic device comprising: (a) a processing unit that loads a sample; (b) a control unit that generates data; and (c) a processor that determines whether the data meets a predetermined baseline, wherein in response to determining that the data does not meet the predetermined baseline, the processor disables the processing unit.

[0379] Embodiment B21. The diagnostic device of embodiment B20, wherein the control unit comprises a system for monitoring invalidation bay data.

[0380] Embodiment B22. The diagnostic device of embodiment B20, wherein the control unit comprises a waiting rules engine for generating the waiting bay data.

[0381] Example B23. The diagnostic device of example B20, wherein the control unit comprises a suggestion rules engine that generates the suggestion bay data.

[0382] Embodiment B24. The diagnostic instrument of embodiment B20, wherein the processing unit further comprises a door, the door locking in response to determining that the data does not meet a predetermined baseline.

[0383] Example B25. The diagnostic device of example B20, wherein the processing unit further comprises a light, and wherein the light changes color in response to determining that the data does not meet a predetermined baseline.

[0384] Example C1. A method for disabling processing units in a diagnostic device, the method comprising: receiving, by a processor, data relating to a first processing unit; determining whether the data meets at least one predetermined baseline; and disabling, by the processor, the processing unit in response to determining that the data does not meet the at least one predetermined baseline.

[0385] Example C2. The method of any one of Examples C1-C9, wherein the diagnostic device comprises a graphical user interface, and wherein the processor modifies the graphical user interface in response to determining that the data does not meet at least one predetermined baseline.

[0386] Example C3. The method of any one of Examples C1-C9, wherein the diagnostic device comprises a graphical user interface, the graphical user interface having a processing unit icon corresponding to the processing unit, the processing unit icon having a first color, and in response to determining that the data does not meet at least one predetermined baseline, modifying the graphical user interface by the processor by changing the first color of the processing unit icon to a second color, wherein the first color and the second color are not the same.

[0387] Embodiment C4. The method of any one of embodiments C1-C9, wherein the processing unit further comprises a door, and wherein the door is locked by the processor in response to determining that the data does not meet at least one predetermined baseline.

[0388] Example C5. The method of any one of examples C1-C9, wherein the processing unit further comprises a light, and in response to determining that the data does not meet at least one predetermined baseline, the processor changes a color of the light.

[0389] Embodiment C6. The method of any one of embodiments C1-C9, wherein a fail alert is generated by the processor in response to determining that the data does not meet at least one predetermined baseline.

[0390] Example C7. The method of any one of Examples C1-C9 wherein the data is based on behavioral characteristics.

[0391] Example C8. The method of any one of Examples C1-C9, wherein disabling the processing unit includes removing power to the processing unit, deleting software protocols that control the processing unit, locking the processing unit door, ejecting the cartridge, and combinations thereof.

[0392] Example C9. The method of any one of Examples C1-C8, wherein the data is based on data collected over time.

[0393] Example C10. A method for updating a graphical user interface of a diagnostic device to reflect a state of a first processing unit in the diagnostic device, the method including: displaying a first icon on the graphical user interface, the first icon having a first color; receiving data related to the first processing unit by a processor; determining whether the data meets at least one predetermined baseline; and, in response to determining that the data does not meet the at least one predetermined baseline, changing the color of the first icon to a second color, the second color reflecting the state of the first processing unit.

[0394] Example C11. The method of any one of examples C10 to C14, further including: displaying a second icon on a graphical user interface, wherein the second icon has a first color; receiving second data related to the second processing unit by the processor; determining whether the second data meets at least one predetermined baseline; and, in response to determining that the second data meets the at least one predetermined baseline, changing the color of the second icon to a third color, wherein the third color reflects a state of the second processing unit.

[0395] Embodiment C12. The method of any one of embodiments C10-C14, wherein the first processing unit is disabled, and further comprising a second processing unit, wherein the second processing unit is not disabled.

[0396] Example C13. The method of any one of examples C10-C14, displaying a second icon on the graphical user interface, the second icon having a third color, the third color reflecting a state of the second processing unit.

[0397] Embodiment C14. The method of embodiment C13 or any one of embodiments C10-C14, wherein the first processing unit is disabled and the second processing unit is not disabled.

[0398] Example C15. A method for increasing the effectiveness rate of a first diagnostic assay, the method comprising: receiving, by a processor, data relating to a first processing unit in a first diagnostic device; determining whether the data meets at least one predetermined baseline; and, in response to determining that the data does not meet the at least one predetermined baseline, disabling, by the processor, the processing unit in the first diagnostic device, thereby increasing the effectiveness rate of the first diagnostic assay.

[0399] Example C16. The method of any one of Examples C15-C21, wherein the diagnostic assay is a Gram-positive, Gram-negative fungal gastrointestinal or respiratory assay.

[0400] Example C17. The method of any one of Examples C15-C21, wherein the diagnostic assay is not modified to increase the efficacy rate of the diagnostic assay.

[0401] Example C18. The method of any one of Examples C15-C21, wherein the data is based on how the processing unit functions, how the diagnostic device functions, how the diagnostic assay functions, behavioral characteristics, or a combination thereof.

[0402] Example C19. The method of any one of Examples C15-C21, wherein the data is based on at least a first assay type and a second assay type.

[0403] Example C20. The method of any one of Examples C15-C21, wherein the data is not based on how the first diagnostic device or the first processing unit functions.

[0404] Example C21. The method of any one of Examples C15-C21, wherein the effectiveness rate of the first diagnostic assay is increased but the effectiveness rate of the second diagnostic assay is not increased.

[0405] Example C22. A method, system or apparatus for evaluating a bay of diagnostic equipment as disclosed in this patent document.

[0406] Example C23. A method, system, or apparatus for monitoring diagnostic equipment to improve field effectiveness as disclosed in this patent document.

[0407] Implementations of the subject matter and functional operations described in this patent document can be implemented in various systems, digital electronic circuits, or computer software, firmware, or hardware, or one or more combinations thereof, including the structures disclosed herein and their structural equivalents. Implementations of the subject matter described herein can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory computer-readable medium for execution by or controlling the operation of a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter providing a machine-readable propagated signal, or one or more combinations thereof. The term "data processing unit" or "data processing apparatus" encompasses all apparatuses, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, an apparatus can include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or one or more combinations thereof.

[0408] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program, or in multiple coordinated files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communications network.

[0409] The processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs to perform functions by manipulating input data and generating output. The processes and logic flows may also be performed by, and apparatus may be implemented as, special purpose logic circuitry such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

[0410] Processors suitable for executing a computer program include, by way of example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer also includes one or more mass storage devices, such as magnetic, magneto-optical, or optical disks, for storing data, or is operatively coupled to receive data, transfer data, or both. However, a computer does not require such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0411] This specification, together with the drawings, are intended to be considered illustrative only, and illustrative means exemplary. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. Furthermore, the use of "or" is intended to include "and / or" unless the context clearly dictates otherwise.

[0412] While this patent document contains many details, these should not be construed as limitations on the scope of any invention or what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of a particular invention. Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, while features may be described above as acting in particular combinations and initially claimed as such, one or more features from a claimed combination may, in some cases, be cut from the combination, and the claimed combination may be directed to a subcombination or a variation of the subcombination.

[0413] Similarly, although operations are shown in the figures in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown, or in any sequential order, or that all of the operations shown be performed, to achieve desirable results. Further, the separation of various system components in the embodiments described in this patent document should not be understood as requiring such separation in all embodiments.

Claims

1. A method, performed by a diagnostic device, for disabling a processing unit within the diagnostic device, the diagnostic device comprising a processor, the method comprising: receiving, by the processor, data relating to a first processing unit; determining, by the processor, whether the data meets at least one predetermined baseline; disabling the processing unit by the processor in response to the processor determining that the data does not satisfy the at least one predetermined baseline, or not disabling the processing unit by the processor in response to the processor determining that the data satisfies the at least one predetermined baseline, and further determining by the processor whether the data satisfies a second predetermined baseline, wherein in response to the processor determining that the data does not satisfy the second predetermined baseline, placing the processing unit in a standby state by the processor.

2. 10. The method of claim 1, wherein the diagnostic equipment includes a graphical user interface, and wherein the processor modifies the graphical user interface in response to determining by the processor that the data does not satisfy the at least one predetermined baseline, or the processor modifies the graphical user interface in response to determining by the processor that the data does not satisfy the second predetermined baseline.

3. 2. The method of claim 1, wherein the diagnostic equipment comprises a graphical user interface, the graphical user interface having a processing unit icon corresponding to the processing unit, the processing unit icon having a first color, and wherein, in response to the processor determining that the data does not satisfy the at least one predetermined baseline, the processor modifies the graphical user interface by changing the first color of the processing unit icon to a second color, the first color and the second color not being the same.

4. 2. The method of claim 1, wherein the processing unit further comprises a door, and wherein the door is locked by the processor in response to the processor determining that the data does not satisfy the at least one predetermined baseline.

5. 2. The method of claim 1, wherein the processing unit further comprises a light, and wherein the processor changes a color of the light in response to the processor determining that the data does not meet the at least one predetermined baseline.

6. 10. The method of claim 1, wherein disabling the processing unit comprises removing power to the processing unit, deleting software protocols that control the processing unit, locking a door of the processing unit, ejecting a cartridge, and combinations thereof.

7. A diagnostic device comprising: Bay and a control unit comprising a bay disable rule engine, a bay standby monitoring rule engine, and a bay suggestion rule engine, wherein the bay disable rule engine is configured to generate disabled bay data, the bay standby monitoring rule engine is configured to generate standby bay data, and the bay suggestion rule engine is configured to generate suggested bay data; a processor configured to determine whether one or more of the invalidation bay data, the standby bay data, or the proposed bay data meet a predetermined baseline; The diagnostic device, wherein the processor is configured to disable the bay in response to a determination by the processor that the disabled bay data does not meet the predetermined baseline.

8. 8. The diagnostic device of claim 7, wherein the processor is configured to modify a graphical user interface (GUI) in response to the processor determining that the invalid bay data does not meet the predetermined baseline.

9. The diagnostic instrument of claim 8 , wherein the processor is configured to modify the GUI by changing the color of a bay icon corresponding to the bay.

10. 8. The diagnostic equipment of claim 7, wherein the bay further comprises a bay door, and wherein the processor is configured to lock the bay door in response to the determination by the processor that the invalidated bay data does not meet the predetermined baseline.

11. 8. The diagnostic equipment of claim 7, wherein the bay further comprises a bay light, and wherein the processor is configured to change a color of the bay light in response to the determination by the processor that the invalidated bay data does not meet the predetermined baseline.

12. The diagnostic instrument of claim 7 , wherein the processor is configured to generate a null bay fail alert in response to the determination by the processor that the null bay data does not meet the predetermined baseline.

13. 1. A diagnostic instrument comprising a processing unit and a graphical user interface, the graphical user interface comprising: at least one icon graphically corresponding to the processing unit, the at least one icon configured to change from a first color to a second color in response to a determination that operation of the processing unit does not meet a predetermined baseline; the processing unit comprises a processor, a memory, and a bay operable to receive an external cartridge for analyzing samples, the processing unit including a bay disable rule engine configured to generate disable bay data, a bay standby monitoring rule engine configured to generate standby bay data, and a bay suggestion rule engine configured to generate suggestion bay data; the processor is configured to evaluate whether one or more of the invalidation bay data, the standby bay data, and the proposed bay data meet the predetermined baseline; The diagnostic equipment, wherein the processor is configured to disable the bay, place the bay on standby, or suggest the bay based on an evaluation of the disable bay data, the standby bay data, and the suggest bay data, respectively.

14. 14. The diagnostic instrument of claim 13, wherein the diagnostic instrument includes an option to override disabling the bay, putting the bay on standby, or suggesting the bay.

15. 14. The diagnostic instrument of claim 13, wherein the diagnostic instrument is configured to automatically notify a user to contact technical support for further investigation of the diagnostic instrument.

Images