Cloud-based Quality Control Data Management

Abstract

One or more devices generate test result data. The test result data includes patient data and QC data. The test result data is provided to a QC data flow system via a local network, and the QC data flow system filters the test result data (e.g., using a ruleset) to extract the QC data. The QC data is provided to a cloud-based QC data management platform via an external network. The cloud-based QC data management platform analyzes the QC data and returns the results to the QC data flow system. The QC data flow system transfers the results to middleware or a device, and the middleware or device triggers a corrective action based on the results as appropriate. TIFF2025519465000002.tif184170

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 349,805, filed Jun. 7, 2022, which is incorporated herein by reference.

[0002] 1. Technical Field The described subject matter generally relates to managing devices, and more particularly to mediating communication between a management device and a cloud - based quality control (QC) data management system.

Background Art

[0003] 2. Background Information Laboratory equipment (e.g., clinical diagnostic equipment) generates QC data indicating the current operating state of the equipment. QC samples with known expected results are periodically analyzed by the equipment, and the actual results can be monitored over time. Thus, trends or changes in the operating state of the equipment can be detected, predicted, or corrected. For example, calibration drift may be identified and corrected, or used to select the appropriate time to trigger a recalibration procedure. As another example, changes in QC data over time may be used to predict when one or more reagents need to be replaced. It should be understood that a wide range of operations can be performed based on QC data to improve the reliability and functionality of the equipment.

[0004] However, existing methods for QC data management are time-consuming and error-prone. In certain types of existing solutions, a human operator manually transfers QC data from a device to an on-site QC data management system (e.g., by copying the QC data to a USB drive and then uploading it to the QC data management system). This method is prone to human error and is likely to result in the responsible person forgetting to transfer the QC data or editing the QC data before uploading it. In another type of existing solution, the QC data is transferred to the on-site QC data management system via a local network. These methods are problematic because the QC data management software needs to be customized for each site, making it difficult to provide support, maintenance, and updates. SUMMARY OF THE INVENTION

[0005] Summary The above and other problems can be solved by using an on-site QC data flow system in combination with a cloud-based QC data management platform. In various aspects, the QC data flow system receives QC data from one or more devices directly or via a laboratory information system (LIS) or other middleware. The QC data flow system filters the data according to one or more rules and provides the filtered data to a cloud-based QC data management platform. The cloud-based QC data management platform analyzes the received QC data and provides a response to the QC data flow system, and the QC data flow system can transfer the response to the corresponding device. For example, the response may indicate that the device is in a normal working state and no action is required, or that maintenance or other corrective actions are necessary. Since the device itself does not need to interact directly with the cloud, the use of a single QC data flow system can facilitate adoption. Therefore, as long as the QC data flow system is trusted to be secure, the advantages of cloud processing can be realized with fewer security concerns typically associated with such services.

[0006] This architecture enables uniform software and / or hardware to be used on-site, and the associated customization is remotely controlled by a cloud-based QC data management platform. QC data may be uploaded in a format-independent manner, enabling new data formats and devices to be supported without making large on-site changes. Specifically, the user can review and manage QC data using the same browser or custom app across all sites. In some embodiments, the QC data flow system provides two-way communication. Thus, the user may provide configuration updates to the QC data management platform, and the QC data management platform pushes those updates to the QC data management platform to be implemented.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Modes for Carrying Out the Invention

[0008] Detailed Description The figures and the following description are provided by way of example only of particular embodiments. Those skilled in the art will readily appreciate from the following description that alternative embodiments of the structures and methods may be used without departing from the principles described. Whenever possible, similar or like reference numbers are used in the drawings to indicate similar or like functionality. If elements have a common number followed by different letters, this indicates that the elements are similar or identical. When referring only to a number, generally any one or any combination of such elements is meant, unless the context indicates otherwise.

[0009] Exemplary System FIG. 1 illustrates one embodiment of a networked computing environment 100 suitable for providing cloud-based QC data management. In the illustrated embodiment, the networked computing environment 100 includes a local network 110, a QC data management platform 120, and one or more client devices 130. The local network 110 includes one or more devices 112, middleware 114, and a QC data flow system 116. The local network 110 and the client devices 130 communicate with the QC data management platform 120 via an external network (e.g., the Internet). In other embodiments, the networked computing environment 100 includes different or additional elements. Further, the functionality may be distributed among the elements in a manner different from that described.

[0010] The local network 110 is a computer network maintained by a research institute or other entity to provide connectivity between the devices 112, the middleware 114, and the QC data flow system 116. The physical infrastructure of the local network 110 is typically in a single geographical location (e.g., a hospital or a test laboratory), but may span multiple geographical locations (e.g., multiple research institutes connected by a VPN).

[0011] In the aspects described below, device 112 is a clinical diagnostic device that analyzes a patient sample to generate test results, or a laboratory device that analyzes a sample to generate test results, or another device that generates data. The test results typically include patient results obtained from analyzing a patient sample and QC data. The QC data can include data generated from analyzing a QC sample or from operating the device without a sample. Additionally or alternatively, the QC data may include data generated from or derived from the test results. The QC data may include data that the user deems relevant for QC purposes. The QC data may include additional information regarding the operation of device 112. Device 112 may also generate value assignment (VA) data that can be used for device calibration. FIG. 1 shows three devices (112A, 112B, 112N), but it should be understood that local network 110 can include any number of devices 112. Also, in other aspects, it should be understood that other types of devices can be managed using the same or similar techniques as described below.

[0012] Device 112 provides test result data (including QC data) to middleware 114. Middleware 114 provides software functionality within local network 110 and manages the operation of device 112. For example, middleware 114 may be part of a LIS that provides test results from patients to physicians and other operators for display. In the illustrated aspect, middleware 114 provides test result data to QC data flow system 116 and provides (when used) VA data from QC data management platform 120 to relevant device 112 or other laboratory systems. Alternatively, one or more of devices 112 may provide test result data directly to QC data flow system 116. In another alternative aspect, VA data may be disseminated directly from QC data flow system 116 to one or more devices 112.

[0013] The QC data flow system 116 is a field resource that processes test result data and transfers it to the QC data management platform 120. The QC data flow system 116 can be a physical computing system or a virtual machine that functions as an edge node of the local network 110 (e.g., operating on the LIS). In one aspect, the QC data flow system 116 filters the test result data to extract QC data and remove confidential information such as patient test results and other personal data. For example, the QC data flow system 116 may be configured to recognize the format of the test result data and extract the QC data. The QC data flow system 116 may be configured to recognize one or more standardized (or non-standardized) data formats. Additionally, the QC data flow system 116 may be remotely updated to recognize and process new data formats without the need for a technician to visit the laboratory site.

[0014] Regardless of the exact filtering mechanism used, the QC data flow system 116 sends the QC data to the QC data management platform 120. The QC data flow system 116 receives a response and transfers that response to the middleware 114 or the device 112. For example, the response may indicate that the device 112 is operating normally and no action is required, or that maintenance or other corrective action is needed. In some aspects, the middleware 114 or the device 112 may automatically trigger preventive maintenance or another corrective action based on the received response, such as evaluating the device calibration values.

[0015] In some aspects, the QC data flow system 116 enhances network security by disabling all its ports except those used to communicate with the QC data management platform 120 and the middleware 114. Thus, external devices cannot use the QC data flow system 116 as a network entry point to the local network 110. Similarly, the QC data flow system 116 may encrypt some or all of the data sent to the QC data management platform 120 via an external network. Various aspects of the QC data flow system 116 will be described in more detail below with reference to FIG. 2.

[0016] The QC data management platform 120 includes one or more cloud-based computer systems that process QC data and provide corresponding functionality to users. The QC data management platform 120 analyzes the received QC data to determine the operational status of one or more devices 112. In one aspect, the QC data management platform 120 compares the received QC data of the device 112 with the previously received QC data of that device to identify patterns or trends. For example, if the measured value of a QC sample decreases below or increases above a threshold, it may indicate that the reagent supply needs to be replenished or that a component of the device 112 requires replacement. Additionally or alternatively, the QC data management platform 120 may use a machine learning model to identify the operational status of the device 112. The QC data management platform 120 may also provide a user interface (e.g., accessible via the client device 130) through which users can view the results and make configuration updates. Various aspects of the QC data management platform 120 will be described in more detail below with reference to FIG. 3.

[0017] The client device 130 is a computing device through which a user can interact with the QC data management platform 120. FIG. 1 includes three client devices (130A, 130B, and 130N), although the networked computing environment 100 can include any number of client devices 130. In one aspect, the client device 130 has a browser or a dedicated app installed to interact with the QC data management platform 120. By directing the browser to the web portal for the QC data management platform 120 (or opening the dedicated app), a user interface for configuring the QC data flow system 116 can be presented to the user. For example, the user may submit a new data format for the new device 112 in order to enable the QC data flow system 116 to extract QC data from the test result data provided by the new device. The QC data management platform 120 can push a new configuration to the QC data flow system 116 for implementation without the technician having to visit the site where the QC data flow system is located.

[0018] In some aspects, the QC data management platform 120 can also provide reports or notifications to the client device 130 regarding the operational status of the device 112. For example, if a particular device 112 requires maintenance, a notification may be pushed to the client device 130 associated with the user responsible for that device. As another example, the client device 130 may display a report indicating trends regarding the patterns of the QC data of the device 112 for analysis by the user.

[0019] Figure 2 illustrates one aspect of the QC data flow system 116. In the illustrated aspect, the QC data flow system 116 includes an ingestion module 210, a filtering module 220, a platform interaction module 230, a configuration update module 240, and a local data store 250. In other aspects, the QC data flow system 116 includes different or additional elements. Further, the functionality may be distributed among the elements in a manner different from that described.

[0020] The ingestion module 210 receives test result data from one or more devices. In one aspect, the device 112 provides the test data to the middleware 114 (e.g., provided by the LIS), and the middleware 114 pushes the test result data to the ingestion module 210. Alternatively, the ingestion module 210 may pull the test result data from the middleware 114. In either case, the test result data may be provided to the ingestion module 210 when received from the device 112, periodically (e.g., every 5 minutes, assuming there is new available data), when a certain amount of test result data has been generated, or at any other appropriate schedule.

[0021] The filtering module 220 filters the received test result data to extract QC data. In one aspect, the filtering module 220 applies one or more sets of rules to the test result data to identify the QC data. For example, the first rule may identify the format of the test result data (e.g., based on the identifier of the device 112 that generated the test result data or by examining the test result data and comparing it to a set of templates of known data formats). The second rule is selected based on the identified format and can be applied to extract the QC data. The second rule is specific to the data format and identifies which one or more portions of the test result data are the QC data. It should be understood that a wide set of rules can be used to analyze the test result data and extract information of interest. For example, in some aspects, the set of rules can also extract other data in addition to the QC data, such as the extraction and transmission of device diagnostic data to assist in remotely diagnosing the device and the extraction of molecular data for performing molecular diagnostics.

[0022] The platform interaction module 230 manages the interaction between the QC data flow system 116 and the QC data management platform 120. In one aspect, the platform interaction module 230 sends the extracted QC data to the QC data management platform 120, and the QC data management platform processes the QC data in response and sends back the results. The results may indicate the operational status of the device 112 corresponding to the QC data. If the results indicate that the device 112 is in a normal operating state, the platform interaction module 230 sends a confirmation to the device 112 (either via the middleware 114 or directly), and the device can continue to operate normally. In contrast, if the results indicate a problem, the platform interaction module 230 sends a signal to temporarily stop the operation of the device and generate a warning (e.g., for display on the client device 130) indicating that corrective action is required, automatically trigger a corrective action (e.g., preventive maintenance), or both.

[0023] In some embodiments, the platform interaction module 230 sends a notification to the QC data flow system 116 in response to a trigger event. The trigger event can be a loss of connection to the QC data management platform 120 due to an Internet connection failure of the QC data flow system 116, a cloud failure, or any other interruption of the service. Alternatively, the trigger event may be a user input request to store QC data locally for a set period of time. This can be advantageous in situations such as a planned power outage, a closure of the research institute, a weather event that disrupts the Internet, and other anticipated disruptions.

[0024] Regardless of the source of the trigger event, the trigger event causes the QC data flow system 116 to store the QC data locally for a maximum period of time. The maximum period can be user-defined or pre-determined (e.g., 90 days). In one embodiment, the QC data flow system 116 stores the QC data until the connection to the QC data management platform 120 is restored, and when restored, the stored QC data is transferred to the QC data management platform and then deleted from the QC data flow system 116. Alternatively, the QC data flow system 116 may store the QC data until the maximum time period expires or until the user provides input requesting otherwise, and at the time the maximum time period expires or the user provides input requesting otherwise, the QC data can be deleted without being transferred to the QC data management platform 120.

[0025] The configuration update module 240 processes configuration updates received from the QC data management platform 120. In one aspect, the configuration update module 240 receives updated or new rule sets and stores them (e.g., in the local data store 250) for future use. In some aspects, the configuration update module 240 may also distribute software or firmware to other devices within the local network 110. For example, a cloud system manager may securely maintain a list of registered edge devices and allow authorized users to remotely connect to a particular device via a secure connection to update its configuration.

[0026] The local data store 250 includes one or more computer-readable media that store data used by the QC data flow system 116. For example, the local data store 250 may include one or more rule sets for processing QC data. Although the local data store 250 is shown as a single entity that is part of the QC data flow system 116, in some aspects, one or more external devices accessed via the local network 110 may be used as the storage device.

[0027] FIG. 3 illustrates one aspect of the QC data management platform 120. In the illustrated aspect, the QC data management platform 120 includes a QC data processing module 310, a user interface module 320, QC data 330, and VA data 340. In other aspects, the QC data management platform 120 includes different or additional elements. Further, the functionality may be distributed among the elements in a manner different from that described.

[0028] The QC data processing module 310 receives and processes QC data from the QC data flow system 116. In one aspect, the QC data processing module 310 receives new QC data from the device 112, identifies the device (e.g., based on the device ID in the new QC data), and retrieves the historical QC data of the device (e.g., from the QC data 330). The QC data processing module 310 analyzes the new QC data and the historical QC data to determine the operable state of the device 112. For example, if the new QC data includes one or more values that differ from the historical average value or the expected value by more than a threshold amount of percentage, an error state may be triggered. In some aspects, the QC data processing module 310 may be configured to identify a plurality of different error states each indicated by a corresponding pattern or variation from the historical value or the expected value. Conversely, if the QC data is within one or more expected ranges, the QC data processing module 310 determines that the device 112 is in a normal working state. Regardless of how the QC data is exactly analyzed, the QC data processing module 310 sends an indication of the result of the analysis to the QC data flow system 116, and the QC data flow system implements any necessary measures such as halting the operation of the device 112 or triggering preventive maintenance.

[0029] The user interface module 320 provides a user interface that can be accessed by the user via the client device 130. In one aspect, the user interface enables the user to generate a report. The report may display some or all of the QC data 330 of one or more devices 112 in a format that can be easily imported, and for example, data values over time may be plotted on a chart to illustrate a trend that enables the user to predict future needs.

[0030] In some aspects, the user interface enables the user to provide a new configuration for the QC data flow system 116 or the device 112. For example, the user may provide a definition of a new data format to enable the QC data flow system 116 to extract QC data from test result data generated by the new device 112. The user interface may also enable the user to remotely log in to the QC data flow system 116 or the device to provide remote support or maintenance.

[0031] QC data 330 and VA data 340 are stored on one or more computer-readable media. The VA data 340 includes an assignment of values that can be used by software that controls the device 112 for calibration (e.g., to a set range). Although the QC data 330 and the VA data 340 are shown as separate components, in some aspects, they are stored together in a single data store. Further, some or all of the QC data 330 and the VA data 340 may be stored remotely and accessed via a network (e.g., in a distributed database).

[0032] Exemplary method FIG. 4 illustrates a method 400 for providing cloud-based QC data management, according to one aspect. The steps of FIG. 4 are illustrated from the perspective of the QC data flow system 116 that performs the method 400. However, some or all of the steps may be performed by other entities or components. Further, in some aspects, the steps may be performed in parallel, in a different order, or different steps may be performed.

[0033] In the embodiment shown in FIG. 4, method 400 begins at step 410 where QC data flow system 116 receives test result data from device 112. The test result data can include results and QC data generated by analyzing a patient sample. QC data flow system 116 filters the test result data using one or more sets of rules to extract the QC data 420. The QC data is provided to a cloud-based QC data management platform 120 (e.g., via the Internet) 430. Since the test result data has been filtered 420, the patient's personal data and health data remain within the laboratory network 110.

[0034] QC data flow system 116 receives a response to the QC data provided by QC data management platform 120 440. The response indicates the result of the analysis performed on the QC data by QC data management platform 120. For example, the response may indicate whether device 112 is in a proper working condition and whether the analysis of the patient sample can continue, or whether maintenance or other corrective actions should be taken. QC data flow system 116 forwards the response to middleware 114 (e.g., LIS) that takes appropriate actions 450. If the response indicates that device 112 is in a proper working condition, the appropriate action may simply be to enable the device to continue analyzing the sample. Conversely, if the response indicates a problem, the appropriate actions may include one or more of stopping the analysis of the sample on device 112, notifying the responsible user that corrective action is required, or triggering a preventive maintenance operation. It should be understood that other types of corrective actions are possible and may be recommended by middleware 114 or triggered automatically.

[0035] Computing System Architecture FIG. 5 is a block diagram of an exemplary computer 500 suitable for use in the networked computing environment 100 of FIG. 1 according to one aspect. The computer 500 includes at least one processor 502 coupled to a chipset 504. The chipset 504 includes a memory controller hub 520 and an input / output (I / O) controller hub 522. A memory 506 and a graphics adapter 512 are coupled to the memory controller hub 520, and a display 518 is coupled to the graphics adapter 512. A storage device 508, a keyboard 510, a pointing device 514, and a network adapter 516 are coupled to the I / O controller hub 522. Other aspects of the computer 500 have different architectures.

[0036] In the aspect shown in FIG. 5, the storage device 508 is a non-transitory computer-readable storage medium such as a hard drive, a compact disc read-only memory (CD-ROM), a DVD, or a solid-state memory device. The memory 506 holds instructions and data used by the processor 502. The pointing device 514 is a mouse, a trackball, a touch screen, or another type of pointing device and may be used in combination with the keyboard 510 (which may be an on-screen keyboard) to input data into the computer system 500. The graphics adapter 512 displays images and other information on the display 518. The network adapter 516 couples the computer system 500 to one or more computer networks such as a local network 110 or an external network.

[0037] The type of computer used by the entities of FIGS. 1 through 3 can vary depending on the aspects and the processing capabilities required by the entities. For example, the LIS may include multiple blade servers that cooperate to provide the described functionality. Further, the computer may lack some of the above-described components, such as keyboard 510, graphics adapter 512, display 518, etc.

[0038] Additional Considerations Some portions of the above description describe aspects in terms of algorithmic processes or operations. These algorithmic descriptions and representations are commonly used by those skilled in the computing arts to effectively convey the substance of their work to others skilled in the art. These operations are described functionally, computationally, or logically, but it should be understood that they are implemented by a computer program containing instructions for execution by a processor, or by equivalent electrical circuits, microcode, etc. Further, it has also proven convenient at times to refer to the configuration of these functional operations as modules without loss of generality.

[0039] As used herein, a reference to "one embodiment" or "an embodiment" means that a particular element, feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" in various places in this specification are not necessarily all referring to the same embodiment. Similarly, the use of "a" or "an" preceding an element or component is merely for convenience. This description should be understood to mean that one or more of the elements or components are present unless it is clearly stated otherwise.

[0040] When a value is described as "about" or "substantially" (or derivatives thereof), such value should be construed as being accurate to + / - 10% unless another meaning is apparent from the context. For example, "about 10" should be understood to mean within the range of 9 to 11.

[0041] As used herein, the terms "comprises", "comprising", "includes", "including", "has", "having", or any other variation thereof are intended to cover a non-exclusive inclusion. For example, a process, method, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements, and may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Further, unless expressly stated to the contrary, "or" refers to an inclusive OR and not an exclusive OR. For example, condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or absent), A is false (or absent) and B is true (or present), and both A and B are true (or present).

[0042] Upon reading this disclosure, those skilled in the art will appreciate additional alternative structural and functional designs for systems and processes for providing cloud-based QC data management. Accordingly, while specific aspects and applications have been illustrated and described, it should be understood that the subject matter described is not limited to the exact structures and components disclosed. The scope of protection should be limited only by the following claims.

Claims

1. A computer-implemented method for providing cloud-based quality control (QC) data management, comprising the following steps: Receiving test result data for a device, including patient data and QC data, via a local network; Filtering the test result data to extract the QC data; Providing the QC data to a cloud-based QC data management platform via an external network; Receiving, from the cloud-based QC data management platform, a response to the QC data that indicates an operable state of the device; and Providing the response to middleware that manages the device via the local network.

2. The computer-implemented method according to claim 1, wherein a corrective action is triggered in response to the response.

3. The computer-implemented method according to claim 2, wherein the corrective action automatically triggers preventive maintenance.

4. The computer-implemented method according to claim 1, wherein the filtering step is performed using a set of one or more rules.

5. Receiving an updated set of rules from the cloud-based QC data management platform; Receiving additional test result data for the device; and Extracting additional QC data from the additional test result data using the updated set of rules The computer-implemented method according to claim 4, further comprising.

6. The computer-implemented method according to claim 1, wherein the device is a clinical diagnostic device.

7. Identifying a trigger event that indicates that a connection to the cloud-based QC data management platform is unavailable; In response to the trigger event, storing the QC data on the local network for a maximum period of time; and Transferring the stored QC data to the cloud-based QC data management platform in response to receiving an indication that the connection to the cloud-based QC data management platform is available again The computer-implemented method according to claim 1, further comprising.

8. The computer-implemented method according to claim 7, further comprising deleting the QC data from the local network in response to transferring the QC data.

9. The computer-implemented method of claim 7, wherein the trigger event is a user input that instructs a planned downtime of the connected cloud-based QC data management platform.

10. One or more devices that generate test result data including patient data and QC data; An inspection information system (LIS) connected to the one or more devices via a local network; A QC data flow system connected to the LIS via the local network, including one or more computing devices configured to receive the test result data and extract the QC data from the test result data using one or more sets of rules; and A QC data management platform connected to the QC data flow system via the external network, including one or more computing devices configured to process the QC data to generate results and transmit the results to the QC data flow system via the external network comprising wherein the QC data flow system transfers the results to the LIS, and the LIS implements corrective measures for the devices based on the results. A networked computing system for providing management of QC data.

11. The networked computing system of claim 10, wherein the QC data flow system is a computing device located within the geographical space including the devices.

12. The networked computing system of claim 10, wherein the QC data flow system is a virtual machine operating on the LIS.

13. The networked computing system of claim 10, wherein all ports of the QC data flow system are disabled, except for the ports used to receive the test result data and provide the QC data to the QC data management platform.

14. Identifying a trigger event that indicates that a connection to a cloud-based QC data management platform is unavailable; In response to the trigger event, storing the QC data on the local network for a maximum of a set maximum time; and In response to receiving an indication that the connection to the cloud-based QC data management platform is again available, transferring the stored QC data to the cloud-based QC data management platform The networked computing system according to claim 10, further comprising: **Claim 15** The networked computing system according to claim 14, further comprising deleting the QC data from the local network in response to transferring the QC data. **Claim 16** The networked computing system according to claim 14, wherein the trigger event is a user input indicating a planned downtime of the connected cloud-based QC data management platform. **Claim 17** When executed by one or more processors, causing the one or more processors to receive, via a local network, test result data for a device, including patient data and QC data; filter the test result data to extract the QC data; provide the QC data to a cloud-based QC data management platform via an external network; receive, from the cloud-based QC data management platform, a response to the QC data, including an operable state of the device; and provide the response to middleware that manages the device via the local network A non-transitory computer-readable medium configured to store code including instructions for performing a process including the above steps. **Claim 18** The non-transitory computer-readable medium according to claim 17, wherein a corrective action is triggered in response to the response. **Claim 19** receiving an updated rule set from the cloud-based QC data management platform; receiving additional test result data for the device; and extracting additional QC data from the additional test result data using the updated rule set The non-transitory computer-readable medium according to claim 17, further comprising: **Claim 20** identifying a trigger event indicating that a connection to the cloud-based QC data management platform is unavailable In response to the trigger event, storing the QC data on the local network for a maximum time of up to the longest time; and In response to receiving an indication that the connection to the cloud-based QC data management platform is available again, transferring the stored QC data to the cloud-based QC data management platform The non-transitory computer-readable medium according to claim 17, further comprising.

Images