System and method for scalable ECG analysis

Abstract

Effective utilization is provided in a cloud computing environment in which a master plane executing on a master node controls startup and shutdown of working nodes in which a working node that outputs necessary for operation of other working nodes is started prior to the working node that requires that output. By specifying available computing resources to earlier launched working nodes, these working nodes can process a larger amount of monitoring data. Once the outputs of these working nodes are ready, available resources will be reallocated to working nodes that use earlier launched working node outputs. Additional control of heart monitoring may be provided by communicating with the monitor to increase the rate at which the monitor transmits the collected data and suspend alarm generation based on the monitored data if such alarms may be inaccurate.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Application No. 63 / 441,915, filed on January 30, 2023, entitled SYSTEM AND METHOD FOR SCALABLE ECG ANALYSIS, the disclosure of which is incorporated herein by reference in its entirety and relied upon. Field of the Invention

[0003] The present application relates generally to cardiac monitoring, and more particularly to systems and methods for scalable ECG analysis. Background Art

[0004] Patient physiology is one of the four cornerstones of modern diagnostic medicine. It defines a structured process that physicians and other medical professionals (hereinafter referred to as "physicians") frequently use to determine the nature and cause of patients' health concerns and problems, and physicians need timely, accurate and reliable patient physiology data to provide effective medical care. Through the diagnostic medical process, physicians will discover possible diagnostic results that can explain or match the patient's signs and symptoms in terms of disease or medical conditions, which enables physicians to formulate plans for treatment and follow-up care. In the case of cardiac conditions, the determination of patient physiology is particularly important, where electrocardiogram ("ECG") monitoring can provide a wealth of valuable diagnostic information about the presence and severity of cardiac conditions, including rhythm disorders (such as atrial fibrillation and ventricular tachycardia), electrolyte imbalances (such as hypokalemia and hyperkalemia), coronary blood flow disorders (such as myocardial infarction and myocardial ischemia), heart block, and structural abnormalities.

[0005] While the final diagnosis is typically made by a physician, analysis of the data generated from ECG monitoring on which the physician's diagnosis is based is often automated to increase the rate of patients who can be diagnosed. However, the use of computer-based ECG data processing faces multiple challenges that affect processing efficiency. First, as the number of patients requiring a single ECG data processing system for cardiac diagnosis grows, the system's available computing resources may be insufficient to process all of the patient's monitoring data simultaneously, resulting in diagnostic delays, which can be particularly detrimental when the patient is experiencing an acute cardiac condition. The shortage of computing resources can be further exacerbated when the ECG data requires multiple types of analysis, each of which requires computing resources. While one way to address this challenge is to purchase additional computing resources, this approach can take a significant amount of time to implement and is also accompanied by non-negligible costs, thereby increasing the barriers to receiving cardiac care.

[0006] Another challenge facing computer-based ECG data processing solutions is particularly evident when they are used to analyze data collected through ambulatory ECG monitoring. Although inpatient ECG monitoring is typically performed over a short period of time and by trained medical personnel who can adjust monitoring parameters as needed, inpatient monitoring often fails to capture incidental cardiac conditions that are not apparent at the time of monitoring. Instead, ambulatory monitors, such as skin or implantable cardiac monitors, are used to diagnose such conditions. However, the operating parameters of outpatient monitors are typically preset before or at the same time as they are sent to the patient, and data is received from these monitors at any interval pre-programmed into those monitors. For some monitors, data is received only after monitoring is complete, making real-time assessment of the patient while monitoring is useless. For monitors that unload data before monitoring is complete, ambulatory data is unloaded at a predefined frequency. This frequency may not be low enough when the patient is experiencing an acute cardiac condition for the monitoring data to be useful in diagnosis. On the other hand, when the patient's physiological abnormality is due to an activity the patient is performing (such as physical exercise) rather than experiencing a heart attack, the predefined frequency may generate false alarms that continue to require the attention of medical personnel, thereby increasing the time required for these medical personnel to provide diagnoses for other patients.

[0007] Therefore, a method is needed to effectively manage computing resources used to process cardiac monitoring data and to adjust for inadequacies in the preset data transmission rate of the cardiac monitor. Summary of the Invention

[0008] By effectively utilizing computing resources, the number of patients whose monitoring data is processed simultaneously can be expanded. Efficient utilization is provided in a cloud computing environment, where a master plane executed on a master node controls the startup and shutdown of worker nodes, where worker nodes whose outputs are necessary for the operation of other worker nodes are started before the worker nodes that need the outputs. By dedicating available computing resources to worker nodes that were started earlier, these worker nodes are able to process a larger amount of monitoring data within a certain period of time. Once the outputs of these worker nodes are ready, the available resources are reallocated to the worker nodes that use the outputs of the worker nodes that were started earlier, also allowing these nodes to process a larger amount of monitoring data within a certain period of time. Additional control of cardiac monitoring can be provided by communicating with the monitor to increase the rate at which the monitor transmits collected data to the cloud computing environment, as well as to suspend the generation of alarms based on monitoring data if such alarms are likely to be inaccurate.

[0009] According to the disclosure herein, and without limiting the present disclosure in any way, in a first aspect of the present disclosure, which may be combined with any other aspect or portion thereof, a system for scalable ECG analysis is provided. The system includes a plurality of nodes. One or more nodes are executed by at least one of one or more CPUs and one or more GPUs.

[0010] The plurality of nodes further includes a plurality of worker nodes and a master node. Each of the plurality of worker nodes includes at least one pod associated with an address. Each pod includes one or more containers. Each container includes a runtime environment in which one or more ECG analysis applications are executed and associated with computing resources.

[0011] The master node includes a control plane configured to start and shut down worker nodes, where starting worker nodes consumes computing resources. The master node is also configured to coordinate the instantiation and lifecycle of pods, which includes coordinating the execution of ECG analysis applications associated with the worker nodes. This includes starting nodes whose outputs are needed before starting other nodes that require the outputs, receiving notifications regarding the completion of the outputs, and starting the other nodes that require the outputs. Starting other nodes after starting the nodes that produce the outputs conserves computing resources and allows for an increased number of nodes that can be started to produce the outputs.

[0012] In a second aspect of the disclosure, which may be combined with any other aspect or a portion thereof, nodes associated with those of an ECG analysis application utilizing artificial intelligence are executed by one or more of the GPUs.

[0013] In a third aspect of the disclosure, which may be combined with any other aspect or a portion thereof, the pods communicate with each other via a queue service.

[0014] In a fourth aspect of the disclosure, which may be combined with any other aspect or a portion thereof, shutting down one of the pods includes leaving a node associated with the pod connected to a GPU or CPU executing the node.

[0015] In a fifth aspect of the present disclosure, which may be combined with any other aspect or a portion thereof, the ECG analysis application includes a heart beat detector application, a noise detection application, an atrial fibrillation detection application, a ventricular premature contraction detection application, a file conversion application for a third-party analysis application, and a file combination application that combines the outputs of other applications in the application.

[0016] In a sixth aspect of the present disclosure, which may be combined with any other aspect or part thereof, nodes associated with a heart beat detector application and a noise detection application are initiated before nodes associated with an atrial fibrillation detection application, a premature ventricular contraction detection application, a file conversion application, and a file combination application.

[0017] In a seventh aspect of the present disclosure, which may be combined with any other aspect or a portion thereof, the system further comprises a cardiac monitor having at least one pair of ECG sensing electrodes; an ECG front-end circuit interfaced with a microcontroller and configured to capture cardiac action potentials sensed by the ECG sensing electrode pair and output as ECG signals; a wireless transceiver interfaced with the microcontroller; and a memory interfaced with the microcontroller. The microcontroller is operable to execute under microprogrammable control and is configured to sample the ECG signal, store each sample in the memory, and transmit those samples that have not been previously transmitted to the server to the server using the wireless transceiver at a predefined frequency.

[0018] The system also includes one or more applications on one or more worker nodes configured to receive a request to view samples in real time from a third-party computing device, send a command to the microcontroller via the wireless transceiver to increase a predefined frequency, and output the received samples to the third-party computing device after receiving the samples from the cardiac monitor. The microcontroller increases the transmission frequency after receiving the command.

[0019] In an eighth aspect of the disclosure which may be combined with any other aspect or a portion thereof, the predefined frequency comprises at least one of a time interval and a number of samples recorded since a previous transmission.

[0020] In a ninth aspect of the disclosure which may be combined with any other aspect or a portion thereof, outputting the sample includes creating a graphical representation of the sample.

[0021] In a tenth aspect of the present disclosure which may be combined with any other aspect or a portion thereof, the cardiac monitor transmits each of said samples at an increased frequency after recording the sample.

[0022] In an eleventh aspect of the present disclosure which may be combined with any other aspect or a portion thereof, the cardiac monitor does not perform any rhythm or heart beat detection analysis on the sample before transmitting the sample to the server.

[0023] In a twelfth aspect of the present disclosure, which may be combined with any other aspect or portion thereof, one or more applications on one or more working nodes are configured to receive a series of values, each value representing a time difference between when a cardiac monitor records a heart beat of a patient and when the cardiac monitor records a previous heart beat of the patient; maintain a plurality of coding tables, each coding table comprising a plurality of codes, each code associated with an upper threshold and a lower threshold; process some of the codes in the sequence, comprising the steps of: selecting one of the tables for encoding the value based on the first two codes assigned; and encoding the value with one of the codes in the selected table; and storing the encoded data in a memory.

[0024] In a thirteenth aspect of the present disclosure, which may be combined with any other aspect or portion thereof, one or more applications on one or more of the nodes are further configured to receive cardiac data of the patient that is contemporaneous with the cardiac data; analyze the received cardiac data and generate one or more alerts about the patient based on the analysis; identify the alert as a false alarm based on user input associated with the cardiac data; and suspend analysis of additional cardiac data of the patient for a predetermined amount of time.

[0025] In a fourteenth aspect of the present disclosure, which may be combined with any other aspect or a portion thereof, there is provided a method for scalable ECG analysis, wherein the method comprises maintaining a plurality of worker nodes and executing a control plane on a master node to start and shut down the worker nodes.

[0026] One or more of the nodes are executed by at least one of one or more CPUs and one or more GPUs, each of which includes at least one pod. Each pod is associated with an address and includes one or more containers. Each container includes a runtime environment in which one or more ECG analysis applications are executed and associated with computing resources.

[0027] Starting a worker node to use the computing resources also includes coordinating the instantiation and lifecycle of the pod, which includes coordinating the execution of the ECG analysis application associated with the worker node, including starting nodes whose outputs are required by the other nodes before starting other nodes that require the outputs, receiving a message regarding the completion of the outputs, and starting the other nodes that require the outputs. Starting other nodes after starting the node that produces the outputs saves computing resources and allows an increase in the number of nodes that can be started to produce the outputs.

[0028] In a fifteenth aspect of the present disclosure, which may be combined with any other aspect or a portion thereof, worker nodes associated with those of an ECG analysis application utilizing artificial intelligence are executed by one or more of the GPUs.

[0029] In a sixteenth aspect of the present disclosure, which may be combined with any other aspect or a portion thereof, the pods communicate with each other via a queue service.

[0030] In a seventeenth aspect of the present disclosure, which may be combined with any other aspect or a portion thereof, shutting down one of the pods includes leaving a node associated with the pod connected to a GPU or CPU executing the node.

[0031] In an eighteenth aspect of the present disclosure, which may be combined with any other aspect or portion thereof, the ECG analysis application includes a heart beat detector application, a noise detection application, an atrial fibrillation detection application, a ventricular premature contraction detection application, a file conversion application for a third-party analysis application, and a file combination application that combines the outputs of other applications in the application.

[0032] In a nineteenth aspect of the present disclosure, which may be combined with any other aspect or part thereof, working nodes associated with the heart beat detector application and the noise detection application are started before nodes associated with the atrial fibrillation detection application, the premature ventricular contraction detection application, the file conversion application, and the file combination application.

[0033] In a twentieth aspect of the present disclosure, which may be combined with any other aspect or a portion thereof, the method further comprises providing a cardiac monitor. The cardiac monitor comprises at least one pair of ECG sensing electrodes; an ECG front-end circuit interfaced with a microcontroller and configured to capture cardiac action potentials sensed by the ECG sensing electrodes and output as ECG signals; a wireless transceiver interfaced with the microcontroller; and a memory interfaced with the microcontroller.

[0034] the microcontroller being operable to execute under microprogrammable control and configured to sample the electrocardiogram signal to store each sample in said memory and to transmit those samples not previously transmitted to the server to said server using said wireless transceiver at a predefined frequency;

[0035] The method also includes receiving a request to view samples in real time from a third-party computing device via one or more applications; sending a command to a microcontroller via a wireless transceiver to increase a predefined frequency, wherein the microcontroller increases the transmission frequency after receiving the command; and after receiving the samples from the cardiac monitor, outputting the received samples to the third-party computing device.

[0036] Additional features and advantages of the disclosed devices, systems, and methods are described in and will become apparent from the following detailed description and accompanying drawings. The features and advantages described herein are not all-inclusive, and in particular, many additional features and advantages will become apparent to one of ordinary skill in the art in view of the drawings and description. Moreover, any particular embodiment need not have all of the advantages listed herein. Furthermore, it should be noted that the language used in the specification is selected for readability and instructional purposes and is not intended to limit the scope of the present subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Understanding that the drawings depict only typical embodiments of the invention and are not to be considered limiting of the scope of the disclosure, the disclosure will be described and explained with additional specificity and detail through the use of the accompanying drawings, which are listed below.

[0038] Figure 1 The figure shows a system for scalable ECG analysis according to one embodiment.

[0039] Figure 2 The flowchart of FIG. 1 illustrates a method for scalable ECG analysis according to one embodiment.

[0040] Figure 3 The flowchart shows a method for Figure 2 The control routine in the method monitors the frequency of data transmission.

[0041] Figure 4 The flowchart shows a method for Figure 2 The method controls the alarm handling routine during monitoring.

[0042] Figure 5 According to one embodiment, Figure 2 The monitoring data processing routine in the method.

[0043] Figure 6 The flowchart of FIG. 1 shows a subroutine for compressing a detected heartbeat according to one embodiment, which is referred to as Figure 5 The routine described in Startup Heartbeat Detection Application is executed. DETAILED DESCRIPTION

[0044] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. Exemplary embodiments are provided to make this disclosure thorough and to fully convey the scope to those skilled in the art. Many specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that the exemplary embodiments can be embodied in many different forms, and that none should be construed as limiting the scope of the present disclosure. In some exemplary embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail.

[0045] The terms used herein are only used for the purpose of describing specific exemplary embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "a", "an", and "the" used herein may also be intended to include plural forms. The terms "comprises", "comprising", "including", and "having" are inclusive and therefore specific to the presence of the features, integers, steps, operations, elements, and / or parts, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, parts, and / or groups thereof. Unless specifically identified as an execution order, the method steps, processes, and operations described herein should not be interpreted as necessarily requiring them to be performed in the specific order discussed or described. It should also be understood that additional or alternative steps may be adopted.

[0046] When an element or layer is referred to as being “on,” “engaged to,” “connected to,” or “coupled to” another element or layer, it can be directly on, engaged to, connected to, or coupled to the other element or layer, or intervening elements or layers may be present. In contrast, when an element is referred to as being “directly on,” “directly engaged to,” “directly connected to,” or “directly coupled to” another element or layer, there may be no intervening elements or layers. Other words used to describe the relationship between elements should be interpreted in a similar manner (e.g., “between” versus “directly between,” “adjacent” versus “directly adjacent”). As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0047] Although the terms first, second, third etc. can be used in this article to describe various elements, components, regions, layers and / or parts, these elements, components, regions, layers and / or parts should not be limited by these terms. These terms may only be used to distinguish an element, component, region, layer or part from another region, layer or part. Unless the context clearly indicates, terms such as "first", "second" and other numerical terms do not imply order or sequence when used in this article. Therefore, without departing from the teachings of exemplary embodiments, the first element, component, region, layer or part discussed below can be referred to as the second element, component, region, layer or part.

[0048] For ease of description, spatially relative terms may be used herein, such as "inner," "outer," "beneath," "below," "lower," "above," "upper," etc., to describe the relationship of an element or feature to one or more other elements or one or more features as shown in the figures. In addition to the orientations described in the figures, spatially relative terms may be intended to cover different orientations of the device in use or operation. For example, if the device in the figure is turned over, then the elements described as "below" or "beneath" other elements or features will be oriented "above" the other elements or features. Thus, the exemplary term "below" can include both above and below orientations. The device can be oriented in other ways (rotated 90 degrees or in other orientations), and the spatially relative descriptors used herein may be interpreted accordingly.

[0049] Efficient use of computing resources can be achieved by launching an ECG analysis application whose input is necessary for subsequent applications to work. Figure 1' shows a system 10 for scalable ECG analysis according to one embodiment. The system includes a cloud computing environment 11, within which a cluster of nodes 12-14 are located. In one embodiment, the cloud computing environment 11 can be implemented as part of the Azure Kubernetes service provided by Microsoft Corporation of Redmond, Washington, but in another embodiment, other implementations of the cloud computer environment are also possible. Each node 12-14 can be a physical computing machine, such as a server. In another embodiment, each node 12-14 can be a virtual computing machine. The processing in each node 12-14 can be implemented using one or more graphics processing units ("GPUs"), central processing units ("CPUs"), or a combination of GPUs and CPUs. Therefore, in one embodiment, node 13 is implemented using one or more CPUs, and node 14 is implemented using one or more GPUs. Node 12 can be implemented using any CPU, but in another embodiment, other types of processors for implementing node 12 are also possible. Nodes 13 and 14 are referred to as "worker nodes," while node 12 is referred to as a "master node." Each node 12-14 also includes one or more pods 15, each pod including an independently addressable address that is a collection of one or more containers 16, wherein each container is a runtime environment that executes an application 17-25. Each container 16 can be independently addressed by the pod 15, and because a pod 15 can include multiple containers, multiple copies of the same application 17-25 can be executed simultaneously within a single pod 15. Although reference Figure 1 Only a single CPU node 13 and a single GPU node 14 are shown, but the cloud computing environment may include multiple GPU nodes 14 and CPU nodes 13. Furthermore, while applications 17-22 are shown as all being executed by a single CPU node 13, a single node 13 may only execute one or a few of these applications 17-22, with multiple nodes 13 being necessary to execute all of the applications 17-22. Similarly, applications 22-23 may be executed on one or more GPU nodes 14. The GPU nodes 14 and the CPU nodes 13 are interfaced to a secure database 36, in which the results of the physiological monitoring data 33 being analyzed and reports 34 generated based on the analysis of the monitoring data 33, as well as the output of the applications executed in the container 16, may be stored. The monitoring data 33 being processed may include cardiac (such as electrocardiogram data) and other physiological (such as patient temperature, oxygen saturation, respiration, and blood glucose data) and non-physiological (such as actigraphy) data collected during the monitoring period.

[0050] The execution of applications 17-24 on nodes 13-14 is controlled by a control plane 25 application executing on the master node 12. In particular, when the execution of applications 17-24 on worker nodes 13-14 is necessary to process incoming monitoring data 33, the master node 12 controls the startup and shutdown of those worker nodes 13-14, thereby also controlling the instantiation and lifecycle of pods. Starting a node 13-14 involves providing the node 13-14 with access to computing resources in the cloud computing environment 11, such as the memory necessary to support the computation of the node 13-14, the specific GPU or CPU on which the node is to execute, or, in the case of a node 13-14 that includes a virtual machine, the instantiation of the virtual machine. When a particular node 13-14 is temporarily not needed and is being shut down, the node 13-14 enters a "sleep state" instead of disconnecting from the allocated resources. In the "sleep state", the node 13-14 remains connected to the allocated resources (including the GPU or CPU executing the node 13-14) to reduce the time required to start the node again, even if the resources are used for some other purposes during the period when the node is "sleeping".

[0051] The control plane 25 starts and shuts down the nodes 13-14 based on the order in which the outputs 35 of the nodes 13-14 are needed to process the monitoring data 33. Thus, the applications executing within the containers 16 in the pods 15 on the nodes 13-14 may include a heart beat detector application 19 ("BDBD") that determines which digitized heart signals in the monitoring data 33 correspond to heart beats, derives the patient's heart rate, and compresses the heart beats for storage, as described below with reference to Figure 6 further described; a noise detection application 23; an atrial fibrillation detection application ("afynd") 24 that detects patients experiencing atrial fibrillation based on the monitoring data; a ventricular premature contraction detection application ("PVC PAC") 20 that detects ventricular premature contractions in the monitoring data; a file conversion application that converts the processing results (such as output 35) of other applications into a format suitable for third-party analysis (LXA cnvrtr.) 21; and a file combination application that combines the output 35 of other applications into a single report 34 (report GNTR) 22 that can be stored in a database 36. It should be understood that these examples are non-limiting, and thus, for example, one can Figure 1 Additional processes and algorithms are added to the illustrated embodiment. Additional algorithms can be added to detect arrhythmias, asystole, tachycardia, and ventricular tachycardia.

[0052] The application also includes an input service 17 that handles communication with devices performing monitoring (such as devices 43, 45 described further below) and third-party devices to receive monitoring data 3: and change monitoring parameters if necessary. The input service 17 can further suspend the processing of monitoring data 33 before monitoring is completed based on monitoring data 33 that triggers a false alarm alarm, as described further below. The input service 17 can also communicate with a computing device that executes ECG reading software, such as the software described in U.S. Patent No. 9,408,551 issued on August 9, 2016, the disclosure of which is incorporated herein by reference. The application also includes a main service application 18, which includes a queue service that enables data to be transferred between different pods 15 on the same node 12-14 or on different nodes 12-14, allowing different applications to exchange their processing results 35, and allowing the command panel 25 to provide commands to other nodes 13-14 and receive responses. Other applications are also possible.

[0053] The control panel 25, input service 17, and main service 18 applications are all required for the overall processing of monitoring data 33 and are therefore launched before other applications. Nodes 13-14 for other applications are launched in the order in which the applications on those nodes 13-14 are required for processing the data. Thus, because the output 35 of the heartbeat detector application 19 and the noise detection application 23 are required for the operation of the afynd application 24, the PVC PAC application 20, the file conversion application 21, and the file assembly application 22, the nodes 13-14 required for executing the heartbeat detector application 19 and the noise detection application 23 are launched before the nodes 13-14 associated with the afynd application 24, the premature ventricular contraction detection application 20, the file conversion application 21, and the file assembly application 22. As a result, the computing resources required by these applications 24, 20, 21, and 22 are not exhausted before they are actually able to perform their functions. Instead, computing resources are allocated to applications 19 and 23, allowing an increase in the number of instances of applications 19 and 23 that can simultaneously process incoming monitoring data 33, and thereby maximizing the number of users whose monitoring data 33 can be processed simultaneously. Once the initial processing of applications 19 and 23 is complete, nodes 13-14 for those applications are shut down, allowing the computing resources previously dedicated to applications 19 and 23 to be reallocated to applications 24, 20, 21, and 22, which can now complete their analysis of monitoring data 33. Thus, system 10 can scale the number of patients whose monitoring data can be analyzed simultaneously without adding computing infrastructure.

[0054] While in the above description, the output 35 of the application analysis is mentioned as being used to create reports, other uses are possible. For example, the output 35 may include an alert provided to relevant medical personnel who review the monitoring results and, if necessary, can take the necessary actions to help the patients 41, 42. For example, the output 35 of the BDBD application 19 may be an alert that the patient's heart rate exceeds a predefined threshold (such as 90 beats per minute) and that the patient is experiencing a potentially dangerous tachycardia event. Similarly, the afynd application may similarly generate an alert that the patient is experiencing atrial fibrillation. Other alerts for other applications in the cloud computing environment 11 are possible.

[0055] Furthermore, while the above description mentions applications with specific functions, in other embodiments, other applications whose processing of outputs 35 is necessary for the operation of the other applications may be activated before the application utilizes that output. In particular, while the above description describes applications processing cardiac monitoring data, the activation and deactivation of applications involved in processing other types of physiological data may be performed based on the order in which the outputs 35 of those applications are used.

[0056] The monitoring data 33 processed by the cloud computing environment 11 can be obtained using a skin physiological monitor 43 or an implantable monitor 45 implanted in the patient 41, 42. The monitors 43, 45 that collect the data do not perform substantial analysis of the ECG sample data, such as any rhythm or heartbeat detection analysis, before transmitting the data to the cloud computing environment 11; all of these analyses are performed within the cloud computing environment 11. Both types of monitors 43, 45 can be located at the midline 44 of the patient's 41, 42's sternum, but other types of locations are also possible. In one embodiment, the skin monitor can be a skin ECG monitor described in U.S. Patent No. 9,700,227, issued on July 11, 2017, the disclosure of which is incorporated herein by reference. In short, in this embodiment, the monitor 43 components, a flexible, extended wearable electrode patch, and a reusable monitor recorder that snaps detachably into a socket on the electrode patch. The wearable monitor 43 is located in the center of the patient's chest (in the midline) from top to bottom along the sternum. The ECG electrodes on the electrode patch are custom-positioned axially along the midsternal line to capture action potential propagation in an orientation corresponding to the aVF lead used in conventional 12-lead ECGs for sensing positive or upright P waves. The operation of the monitor recorder circuitry is managed by a microcontroller, which includes a program storage unit containing readable and writable internal flash memory and operates under the control of a modular microprogram specified in firmware stored in the internal flash memory. The microcontroller is connected to the recorder's ECG front-end circuitry, which measures raw electrodermal signals via the electrodes provided on the disposable patch and measures ECG signal samples acquired by the front-end circuitry. The microcontroller acquires, samples, digitizes, processes, and stores the digitized ECG data in an available memory location within the monitor recorder. The monitor circuitry also includes a wireless transceiver interfaced with the microcontroller, through which the microcontroller can offload collected data 33. The skin monitor can record ECG data, other physiological data, and non-physiological data, such as actigraphy data. In alternative embodiments, other types of skin monitors 43 are also possible.

[0057] In one embodiment, the implantable monitor 45 can be an implantable medical device described in U.S. Patent Publication No. 2021 / 0000345A1, published on January 7, 2021 and issued as U.S. Patent No. 11,696,681, the disclosure of which is incorporated herein by reference, but in other embodiments, other implantable monitors are possible. Briefly, the housing of the implantable medical device includes a hollow body that forms a first electrode on an outer surface, with end caps fixed to opposite ends, one such end cap forming a second electrode on the outer surface. A microcontroller circuit (also referred to as a microcontroller) is arranged circumferentially within the housing and includes a microcontroller that is operable under program instructions stored in a non-volatile memory device. An analog front end is electrically connected to the first and second electrodes and is operable to sense electrocardiogram signals. The transceiver circuit is operable to wirelessly communicate with an external data device such as a cloud computing environment 11. The program instructions define instructions for the microcontroller to continuously sample the ECG signal into a non-volatile memory device and to offload the non-volatile memory device to an external data device via the transceiver circuit. The receiving coil and charging circuit are operable to charge an onboard power supply of the microcontroller circuit. The implantable monitor can record ECG data, other physiological data, and non-physiological data, such as actigraphy data. In other embodiments, other types of implantable monitors 45 are also possible.

[0058] The monitors 43, 45 can communicate with the cloud computing environment 11 via a network 53, such as the Internet or a cellular network. Communication between the monitors 43, 45 and the network 53 can be direct if the wireless transceivers of the monitors 43, 45 are capable of direct network access, such as if the wireless transceivers include a cellular chipset as described in U.S. Patent No. 10,667,711, issued June 2, 2020, the disclosure of which is incorporated herein by reference. Alternatively, the wireless transceivers of the monitors 43, 45 can offload the monitoring data 33 to an intermediary device, such as a mobile phone 46 executing a mobile application (although other intermediary devices are also possible), which in turn provides the monitoring data 33 to the cloud computing environment via the network 53.

[0059] In most cases, monitors 43, 45 offload monitoring data 33 to cloud computing environment 11 using a wireless transceiver with a predefined frequency. This frequency can be defined based on either time (such as transmitting all collected data 33 within the last minute, hour, day, or another time interval) or the amount of data 33 recorded since the last transmission to the cloud computing environment (such as the number of electrocardiogram samples), such as after a certain number of electrocardiogram samples have been recorded since the last transmission. The transmission frequency is limited by the power consumption of such transmission, where the higher the transmission frequency, the faster the power draw of monitors 43, 45. Before monitoring begins, the predefined frequency can be preprogrammed into the microcontroller of monitors 43, 45 as part of the firmware executed under the microcontroller's control. However, if an alarm generated as part of the output 35 based on the processing of monitoring data 33 indicates that the patient is experiencing a heart attack, and a medical professional (such as a physician, although other medical professionals are also possible in other embodiments) wishes to review the data at more frequent intervals (such as in near real time, although other frequencies are also possible), the frequency of data 33 transmission can be increased. Alternatively, even if no alert is generated, the healthcare professional can initiate a request to increase the frequency of data transmission. Thus, upon receiving a request from a computing device 39 associated with the healthcare professional reviewing the results of processing data 33, the input service 17 can send a signal via network 53 to the wireless transceiver of the monitor 43, 45, which provides the signal to the microcontroller of the monitor 43, 45. The signal instructs the microcontroller to increase the frequency of offloading the monitoring data 33 to the cloud computing environment 11. In one embodiment, the signal instructs the microcontroller of the monitor 43, 45 to increase the rate of offloading the monitoring data 33 to a near real-time level, where a sample of the monitoring data 33 is offloaded as soon as the sample is written to the memory of the monitor 43, 45 (or every second). In other embodiments, other increased frequencies at which the monitor 43, 45 provides data 33 to the cloud computing environment are possible. The monitor 43, 45 continues to provide monitoring data 33 at the increased frequency until another signal is received from the input service 17 via network 54 to return to the previous frequency of data 33 transmission. In response to receiving a message from a computing device 39 associated with a medical professional that an increase in the data transmission rate is no longer required (which may be based on a specific command from the medical professional or the medical professional simply shutting down the application 49 to process the data), the input service 17 sends a signal to return the transmission of data 33 to the preset frequency. In other embodiments, if no signal to return to the previous transmission frequency is received from the input service 17, the monitors 43, 45 may automatically return to the preset frequency of providing data 33 to the cloud computing environment 11 upon expiration of a predefined period of time since receiving the signal to increase the transmission frequency.When the increased transmission level is no longer needed, restoring the data 33 transmitted to the cloud computing environment 11 to a preset lower level helps conserve power on the monitor 33 .

[0060] After input service 17 receives data 33, it outputs the data 33 in graphical form to the medical professional who requested the data via a computing device 39 associated with the medical professional. In one embodiment, upon receiving the data 33, input service 17 can create an electrocardiogram or another graphical representation of the data 33 and provide the graphical representation to an application 49 running on the computing device 39 associated with the medical professional via network 53. Thus, if monitors 43, 45 transmit recorded data 33 every second, input service 17 generates a portion of the graphical representation corresponding to the newly received data and transmits the graphical representation to computing device 39 via network 53, where application 49 on the device displays the newly received graphical representation along with at least a portion of the graphical representation of the data 33 received earlier. Thus, the medical professional is provided with a view of the patient's physiology (such as an electrocardiogram) over time that updates in near real time, allowing the medical professional to observe the patient's condition as it evolves over time. In other embodiments, the input service 17 does not generate a graphical representation, but rather simply forwards the received monitoring data 39 to an application 49 running on the computing device 39, where the application 49 generates and outputs a graphical representation of the received data on the computing device 39. In other embodiments, in addition to the graphical representation of the received data, the input service 17 may also provide outputs 35 of other applications in the cloud computing environment to the application 49 on the computing device 39 as those outputs become available.

[0061] While in the aforementioned scenario, when patients 41, 42 are experiencing a cardiac condition, the medical professional needs to see the graphical representation of data 33 as soon as possible, in other cases, an alert as part of output 35 regarding a patient experiencing a cardiac condition, such as tachycardia, may be generated for non-medical reasons, such as the patient engaging in strenuous exercise. If the non-medical reason persists for an extended period, as is often the case when someone is exercising, repeated alerts may be generated and provided to the medical professional, unnecessarily distracting the medical professional and delaying their evaluation of the patient's condition who is actually experiencing a cardiac condition. Therefore, to prevent this, cloud computing environment 11 performs a secondary analysis of the monitoring data 33 upon which the alert was generated to verify that the alert is not false. In one embodiment, the secondary analysis is performed by input service 17, but in other embodiments, another application within cloud computing environment 11 may perform the analysis. Since monitoring data 33 may include actigraphy data, the secondary analysis may include identifying the actigraphy data that coexists with the physiological data upon which the alert is based to determine whether a non-medical reason (such as the patient exercising) exists for the alert to be false (not indicating that patient 41, 42 is experiencing a medical condition). For example, if the secondary analysis indicates that patients 41, 42 were exercising while recording physiological data indicative of a medical condition (such as tachycardia), the output of the secondary analysis would be that the alarm was false. In one embodiment, the output of the secondary analysis by one of the applications is sufficient to declare the alarm false. In another embodiment, the cloud computing environment requires receiving confirmation from a medical professional that the alarm is false before declaring the alarm false. Although actigraphy data is described above as being used to declare an alarm false, in other embodiments, other types of non-physiological data may be used to declare an alarm false based on contemporaneous physiological data.

[0062] Once input service 17 (or another portion of cloud computing environment 11) identifies an alert as false, input service 17 (or another portion of cloud computing environment 21) sends a message to the remaining applications analyzing patient data 33 to stop generating further alerts for a predefined "pause" period, such as one to three hours, though other time intervals are possible in alternative embodiments. In other embodiments, during the pause period, alerts may still be generated by the relevant applications in cloud computing environment 11 but will not be forwarded to any healthcare professionals (although they may be available for later review). In one embodiment, if the recording time of the data 33 based on which the alert was generated is available, the pause period runs from the time the data 33 was recorded. Alternatively, or if the recording time of the data is not available, the pause period runs from the time the alert was generated. By setting a pause period after a false alarm, cloud computing environment 11 conserves the computing resources required to generate and deliver the alert and avoids unnecessarily distracting the healthcare professionals to whom the alert was provided.

[0063] Efficient utilization of computing resources and improved control over the frequency with which monitoring data 33 is provided and the frequency with which the data is processed allow for increased speed and quality of analysis of ECG and other physiological data. Figure 2 The flowchart of FIG. 1 shows a method 100 for scalable ECG analysis according to one embodiment. The method 100 may be used Figure 1 Optionally, as described below with reference to Figure 3 As further described, the frequency of transmission of monitoring data 33 is controlled (step 101). Optionally, alarm processing during monitoring is controlled, as described with reference to Figure 4 (Step 102) is further described. Figure 5 As further described, the monitoring data 33 is processed (step 103), ending the method 100. Although step 103 is shown as occurring after steps 101 and 102, step 103 may also occur before and simultaneously with steps 101 or 102.

[0064] Controlling the frequency with which the monitors 43, 45 perform transmissions of the monitoring data 33 to the cloud computing environment 11 allows the physician evaluating the patient's condition to be provided with the latest information when the information is most needed. Figure 3 The flowchart shows a method for controlling the Figure 2A routine 110 for adjusting the frequency of transmission of monitoring data 33 used in method 100 is provided. Input service 17 of cloud computing environment 11 receives a request for near real-time viewing of monitoring data 33 from a computing device 39 associated with a medical professional evaluating a patient (step 111). In one embodiment, the request may be received based on an alert generated as part of an output 35 of one of the applications of cloud computing environment 11. Alternatively, the request may be initiated by the medical professional without any alerts being generated by the applications of cloud computing environment 11. In other embodiments, the medical professional may request a different update frequency for the data displayed on application 49 of computing device 39, rather than near real-time viewing.

[0065] After receiving the request from the computing device 39, the input service 17 of the cloud computing environment 11 provides a command to the microcontroller of the monitor via the network 53 and the wireless transceiver of the monitor 43, 45 to increase the transmission frequency of the monitoring data 33 to a near real-time level (or another level specified in the request), wherein each sample of the data 33 is transmitted to the cloud computing environment 11 immediately (or at another frequency specified by the request) after the data sample 33 is recorded in the memory of the monitor 43, 45 (step 112).

[0066] The monitoring data 33 received from the monitors 43, 45 is output by the input service 17 to the computing device 39 via the network 53 (step 113). As described above, the output of the data can be done in graphical form, where a graphical representation of the data 33 is prepared by the input service 17 or the application 49.

[0067] Optionally, the input service 17 sends a command to the monitors 43, 45 via the network 53 to revert to transmitting data 33 at the earlier preset frequency (step 114), ending the routine 110. The input service 17 may send the revert command after receiving a message from the computing device 39 indicating that near real-time viewing is no longer required. Alternatively, the input service 17 may send the command after a predefined period of time has expired after the initial command to increase the frequency of data 53 was sent to the monitors 43, 45. In other embodiments, the revert command is not sent to the monitors 43, 45, and the monitors 43, 45 automatically revert to the preset frequency of data 33 transmission upon expiration of a period of time after receiving the command to increase the frequency, wherein the length of the period of time is predefined in the firmware of the controlling microcontroller.

[0068] While alerts can initially increase the frequency of monitoring data, false positive alerts can also consume the computing resources necessary to generate and send this data. Figure 4 The flowchart shows a method for Figure 2A routine 120 for controlling alarm processing during monitoring in method 100 is provided. This routine occurs before the cloud computing environment 11 receives all of the monitoring data 120 from a particular physiological monitor of a patient, wherein the data 33 is partially received. Initially, a portion of the monitoring data 33, including physiological (such as electrocardiogram) data and actigraphy data, is received from monitors 43, 45 via the cloud computing environment 11 (step 121). If, based on the received data 33, it is determined that an alarm is necessary regarding a patient experiencing a potentially dangerous condition (step 122), an alarm is generated by the application making that determination (step 123). If an alarm is not necessary (step 122), the routine 120 moves to step 127. Whether via the input service 17 or another application, the alarm is analyzed to determine whether it is false, using the actigraphy data as described above, and possibly by requesting a user confirmation that it is false. If the alarm is false (step 124), alarm generation is suspended for a predefined period of time (step 126), and the routine 120 moves to step 127. If the alarm is not false (step 124 ), an alarm is provided to the medical professional monitoring the condition of the patient 41 , 42 (step 125 ), and the routine 120 moves to step 127 .

[0069] If additional monitoring data 33 is received for the patient 41, 43 (step 127), and the alarm generation pause period is still in effect, no alarm is generated for the newly received data 33, and the routine 120 returns to step 127 to check whether additional data 33 has been received. If additional monitoring data 33 is received for the patient 41, 43 (step 127), and the alarm generation pause period is not in effect, the routine 120 returns to step 122. If no additional data 33 is received (step 127), the routine 120 ends.

[0070] As mentioned above, in alternative embodiments, during an alarm pause period, an alarm may still be generated, but will not be provided to a medical professional reviewing the data. Furthermore, while the data 33 that triggers the alarm pause period must include actigraphy (or some other data that can provide context for physiological data based on which an alarm can be declared false), subsequent data that may not generate an alarm due to the alarm pause period can only include physiological data that can be used as a basis for an alarm.

[0071] Starting those nodes 13-14 whose outputs 35 are needed by other nodes 13-14 before those nodes requiring output 35 allows the amount of monitoring data 33 that can be processed in a particular time period to be increased without having to increase the amount of computing resources allocated to such processing. Figure 5 According to one embodiment, a method for monitoring data processing for Figure 2Routine 130 of method 100. Monitoring data is received by cloud computing environment 11 (step 131), and control plane 25 executing on node 12 starts worker nodes 13-14 whose output is necessary for other worker nodes 13-14 to perform analysis (step 132), which starts the execution of applications on those nodes 13-14. Such nodes 13-14 may include nodes 13-14 necessary to execute heartbeat detection application 19 and noise detection application 23, wherein the function of the heartbeat detection application includes performing heartbeat compression, as described below with reference to Figure 6 As further described. The control plane 25 detects the completion of the outputs 35 of these applications (step 133) and shuts down the nodes 13-14 of these initial applications (step 134), thereby allowing the computing resources dedicated to these nodes 13-14 to be reallocated. Worker nodes 13-14 requiring the outputs 35 of the applications launched in step 132 are launched (step 135). Such nodes 13-14 may include the nodes 13-14 on which the atrial fibrillation detection application 24, the PVC PAC application 20, the file conversion application 21, and the file assembly application 22 are executed. The master plane 25 detects the completion of the outputs 35 of the applications executed on the nodes launched in step 135 (step 136), and the master plane 25 shuts down the nodes 13-14 launched in step 135 (step 137). If no more monitoring data 33 remains unprocessed (step 138), the routine 130 ends. If additional monitoring data 33 remains (step 138), the routine 130 returns to step 132.

[0072] As mentioned above, once the control panel 25 begins execution, and before monitoring data is received, the control panel 25 starts the nodes 13 necessary to execute the input service 17 and the main service application 18 .

[0073] Compression of the detected heartbeats allows saving memory space and reducing data transmission costs within the cloud computing environment 11 and allows this memory space to be used for the functionality of the nodes 12 - 15 . Figure 6 The flowchart of FIG. 1 shows a subroutine 140 for compressing a detected heartbeat according to one embodiment, which is referred to as Figure 5The heartbeat detection application 19 is executed as described in the routine 130. The heartbeat detection application 19 obtains a series of values ​​(step 141), such as by previously processing the monitoring data 33, each value representing the time difference between when the heart monitor 43, 45 recorded the patient's heartbeat and when the heart monitor recorded the patient's previous heartbeat. A plurality of code tables are maintained by the application 19 (such as in a database 36 or another memory within the cloud computing environment 11), each code table including a plurality of codes, each code being associated with an upper threshold value and a lower threshold value (step 142). An iterative processing loop (steps 143-147) is initiated (step 143) to process each value in turn, proceeding as follows: one of the tables for encoding the value is selected based on the combination of the first two values ​​processed in the sequence (step 144); a table exists for each possible combination, but to reduce the number of tables required, the first two values ​​are divided by a quantization factor before being used to select a table; the current value is then encoded with one of the codes in the selected table, which falls between the upper and lower thresholds for the code encoding the value (step 145); the value is encoded into the database 36 as part of the output 35 of the application 19 (step 146), and the loop moves on to the next value (step 147). Once all values ​​in the sequence have been processed, subroutine 140 terminates. For the first two values ​​in the sequence (where the first value lacks two previous values ​​and the second value lacks a single previous value), the non-existent previous value required as input to step 144 is treated as zero, but in alternative embodiments, other values ​​may be used as long as they are used consistently across different iterations of subroutine 140.

[0074] The description of the above embodiments is provided for the purpose of illustration and description. It is not intended to be exhaustive or to limit the present disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but where applicable, they are interchangeable and can be used in selected embodiments even if not specifically shown or described. The same situation may also differ in many aspects. These variations should not be regarded as departing from the present disclosure, and all such modifications are intended to be included within the scope of the present disclosure.

Claims

1. A system for scalable ECG analysis, comprising: A plurality of nodes, one or more of the nodes being executed by at least one of one or more CPUs and one or more GPUs, the plurality of nodes further comprising: a plurality of worker nodes, each comprising at least one pod, each pod being associated with an address and comprising one or more containers, each container comprising a runtime environment in which one or more ECG analysis applications are executed and being associated with a computing resource; and A master node, the master node including a control plane configured to start and shut down the worker nodes, wherein starting the worker nodes uses computing resources, and the master node is further configured to coordinate the instantiation and lifecycle of the pods, which includes coordinating the execution of the ECG analysis application associated with the worker nodes, including starting nodes whose outputs are required by the other nodes before starting other nodes in the nodes that require the outputs, receiving messages about the completion of the outputs, and starting the other nodes that require the outputs, wherein starting the other nodes after starting the nodes that produce the outputs saves the computing resources and allows an increase in the number of nodes started that produce the outputs.

2. The system according to claim 1, wherein: Nodes associated with those of ECG analysis applications utilizing artificial intelligence are executed by one or more of the GPUs.

3. The system according to claim 1, wherein: The pods communicate with each other via the queue service.

4. The system according to claim 3, wherein: Shutting down one of the pods includes leaving the node associated with the pod connected to the GPU or CPU executing the node.

5. The system according to claim 1, wherein: The ECG analysis applications include a heart beat detector application, a noise detection application, an atrial fibrillation detection application, and a ventricular premature contraction detection application, a file conversion application for third-party analysis applications, and a file combination application that combines outputs of other applications in the application.

6. The system according to claim 5, wherein: The nodes associated with the heartbeat detector application and the noise detection application are initiated before the nodes associated with the atrial fibrillation detection application, the premature ventricular contraction detection application, the file conversion application, and the file combination application.

7. The system of claim 1 , further comprising: A heart monitor, comprising: at least one pair of ECG sensing electrodes; an ECG front-end circuit interfaced with the microcontroller and configured to capture cardiac action potentials sensed by the ECG sensing electrode pair and output as ECG signals; a wireless transceiver interfaced with the microcontroller; a memory interfaced with the microcontroller; and the microcontroller being operable to execute under microprogrammable control and configured to sample the electrocardiogram signal to store each sample in the memory and to transmit those samples not previously transmitted to the server to the server using the wireless transceiver at a predefined frequency; One or more applications on one or more of the worker nodes, configured to: receiving a request to view the sample in real time from a third-party computing device; sending a command to the microcontroller via the wireless transceiver to increase the predefined frequency, wherein the microcontroller increases the frequency of the transmission upon receiving the command; and After receiving the sample from the cardiac monitor, the received sample is output to the third-party computing device.

8. The system according to claim 7, wherein: The predefined frequency comprises at least one of a time interval and a number of the samples recorded since a last transmission.

9. The system according to claim 7, wherein: Outputting the sample includes creating a graphical representation of the sample.

10. The system according to claim 7, wherein: The heart monitor transmits each of the samples at an increasing frequency after recording the sample.

11. The system according to claim 10, wherein: The cardiac monitor does not perform any rhythm or beat detection analysis on the samples before transmitting the samples to the server.

12. The system of claim 1 , wherein the one or more applications on one or more of the worker nodes are configured to: receiving a series of values, each of the values ​​representing a time difference between when a heart monitor records a heart beat of a patient and when the heart monitor recorded a previous heart beat of the patient; maintaining a plurality of code tables, each code table including a plurality of codes, each of the codes being associated with an upper threshold value and a lower threshold value; Some code in the processing sequence includes the following steps: Based on the first two codes assigned, one of the tables is selected for coding the value; and encoding the value using one of the codes in the selected table; and storing the encoded data in a memory.

13. The system of claim 1 , wherein the one or more applications on one or more of the nodes are further configured to: receiving cardiac data of the patient contemporaneously with the cardiac data; analyzing the received cardiac data and generating one or more alerts for the patient based on the analysis; identifying the alarm as a false alarm based on user input associated with the cardiac data; as well as Analysis of further cardiac data of the patient is suspended for a predetermined amount of time.

14. A method for scalable ECG analysis, comprising: maintaining a plurality of worker nodes, one or more of the nodes being executed by at least one of the one or more CPUs and the one or more GPUs, each comprising at least one pod, each pod being associated with an address and comprising one or more containers, each container comprising a runtime environment in which one or more ECG analysis applications are executed and associated with the computing resources; and A control plane is executed on the master node to start and shut down the worker nodes, wherein starting the worker nodes to use the computing resources also includes coordinating the instantiation and lifecycle of the pods, which includes coordinating the execution of the ECG analysis application associated with the worker nodes, including starting a node whose output is required by the other nodes before starting other nodes in the node that require the output, receiving a message about the completion of the output, and starting the other nodes that require the output, wherein starting the other nodes after starting the node that produces the output saves the computing resources and allows an increase in the number of nodes started to produce the output.

15. The method according to claim 14, wherein The worker nodes associated with those ECG analysis applications utilizing artificial intelligence are executed by one or more of the GPUs.

16. The method according to claim 14, wherein The pods communicate with each other via the queue service.

17. The method according to claim 16, wherein Shutting down one of the pods includes preserving a connection between the node associated with the pod and a GPU or CPU executing the node.

18. The method according to claim 14, wherein The ECG analysis applications include a heart beat detector application, a noise detection application, an atrial fibrillation detection application, and a ventricular premature contraction detection application, a file conversion application for third-party analysis applications, and a file combination application that combines outputs of other applications in the application.

19. The method according to claim 18, wherein Working nodes associated with the heartbeat detector application and the noise detection application are started before nodes associated with the atrial fibrillation detection application, the premature ventricular contraction detection application, the file conversion application, and the file combination application.

20. The method of claim 14, further comprising: A cardiac monitor is provided, the cardiac monitor comprising: at least one pair of ECG sensing electrodes; an ECG front-end circuit interfaced with the microcontroller and configured to capture cardiac action potentials sensed by the ECG sensing electrode pair and output as ECG signals; a wireless transceiver interfaced with the microcontroller; a memory interfaced with the microcontroller; and the microcontroller being operable to execute under microprogrammable control and configured to sample the electrocardiogram signal to store each sample in the memory and to transmit those samples not previously transmitted to the server to the server using the wireless transceiver at a predefined frequency; receiving, via one or more applications, a request from a third-party computing device to view the sample in real time; sending a command to the microcontroller via the wireless transceiver to increase the predefined frequency, wherein the microcontroller increases the frequency of the transmission upon receiving the command; and After receiving the sample from the cardiac monitor, the received sample is output to the third-party computing device.

Images