System and method for limiting authority to an electrocardiogram processing system - Patents.com

Abstract

A system and method are provided for analyzing a patient's electrocardiogram (ECG) data using a large amount of ECG data. The system receives ECG data from a sensing device placed on the patient's body surface, e.g., one or more ECG leads / electrodes, which may be integrated into a smart device. The system may include an application that communicates with an ECG platform running on a server, which may process and analyze the ECG data using neural networks or the like to detect and / or predict various abnormalities, conditions, and / or descriptors. The processed ECG data is used to generate a graphic user interface. The generated graphic user interface is communicated from the server to a computer and displayed in a user-friendly and interactive format with greater accuracy. The system may restrict access to the ECG data, analysis results, reports, and / or functions to different entities, devices, and / or users.

Description

[Technical field]

[0001] This application relates to an electrocardiogram processing system.

[0002]

[0002] The present disclosure relates generally to electrocardiogram (ECG) processing systems, for example, ECG systems with artificial intelligence and machine learning capabilities for detecting and / or predicting cardiac events, such as arrhythmias and abnormalities. [Background technology]

[0003]

[0003] An electrocardiogram (ECG) receives cardiac electrical signals from the heart, which are digitized and recorded by a computing device. An ECG is typically generated from cardiac signals sensed by a number of electrodes placed on specific areas of the patient's body surface. It is a simple, non-invasive tool available to most medical professionals.

[0004]

[0004] A cardiac signal is composed of one or more synchronized time signals. FIG. 1A shows a standard 12-lead resting electrocardiogram recording. As shown in FIG. 1A, each lead generates an electrical signal, resulting in 12 electrical signals. The ECG shown in FIG. 1A uses 12 leads, resulting in 12 recordings, although some ECGs may involve fewer leads and result in fewer recordings. As shown in FIG. 1A, cardiac signals typically exhibit a repeating pattern that includes P waves, QRS complexes, and T waves. As the name suggests, the QRS complex includes Q waves, R waves, and S waves. FIG. 1B shows an exemplary P wave, QRS complex, and T wave, focusing on two beats in one lead signal that show one RR interval.

[0005]

[0005] To make a diagnosis, ECG recordings are analyzed by trained medical professionals to identify abnormalities and / or episodes. Currently, it is estimated that approximately 150 measurable abnormalities can be identified in an ECG recording. However, identifying abnormalities from an ECG requires special expertise and / or training. ECG analysis is only available to patients who can afford to pay for medical professionals with the appropriate expertise and who have other access to these professionals.

[0006]

[0006] Teleradiology centers have been developed to provide ECG analysis to patients who are unable to meet with a trained medical professional. Typically, ECG recordings are generated off-site by non-professionals and transmitted to the teleradiology center for analysis by a cardiologist or specialized ECG technician. While the results obtained are generally of high quality, the process can be slow and expensive.

[0007]

[0007] As an alternative to analysis by trained experts, software systems have also been developed. Current software systems provide poor quality interpretations and often produce false positives. Currently, these interpretation systems may generate two types of information about the cardiac signal: (1) information about the time location of each wave (called delineation), and (2) global information (called classification) that provides a classification of the cardiac signal or a labeling of its anomalies.

[0008]

[0008] Regarding contour extraction, two approaches are mainly used to find the waves of the cardiac signal. The first approach is based on multi-scale wavelet analysis. In this approach, wavelet coefficients that reach a certain threshold at multiple specified scales are sought. (See Martinez et al., A wavelet-based ECG delineator: evaluation on standard databases, IEEE transactions on biomedical engineering, Vol. 51, No. 4, April 2004, pp. 570-58; Almeida et al., IEEE transactions on biomedical engineering, Vol. 56, No. 8, August 2009, pp. 1996-2005; Boichat et al., Proceedings of Wearable and Implantable Body Sensor Networks, 2009, pp. 256-261; and U.S. Patent No. 8,903,479, Zoicas et al.). The usual process is to identify the QRS complex, then the P wave, and finally the T wave. This approach is rendered unstable by the use of a threshold and fails to identify multiple or "hidden" P waves.

[0009]

[0009] The second contour extraction approach is based on Hidden Markov Models (HMMs). In this machine learning approach, the current state of the signal is treated as the hidden variable we want to recover (see Coast et al., IEEE transactions on biomedical engineering, Vol. 37, No. 9, September 1990, pp. 826-836; Hughes et al., Proceedings of Neural Information Processing Systems, 2004, pp. 611-618; Trassenko et al., U.S. Pat. No. 8,332,017). This approach is an improvement over the first contour extraction approach described above, but it requires designing a representation of the signal using handcrafted features and fitting a mathematical model to each wave based on these features. Based on a sufficient number of examples, the algorithm can learn to recognize each wave. However, this process can be tedious and inaccurate because it relies on handcrafted features. Specifically, hand-designed features are always suboptimal because they are not trained and important information may be ignored or excluded during the feature design process. Moreover, the models, which are usually Gaussian, are not well adapted. Also, current models cannot take into account hidden P-waves.

[0010]

[0010] With regard to classification, current systems perform analysis only on the QRS complex. For example, ventricular beats or pacemaker beats may be detected by analyzing the QRS complex. Training involves a set of manually designed features and corresponding beat labels (Chazal et al., IEEE Transactions on Biomedical Engineering, vol. 51, pp. 1196-1206, 2004). As mentioned above, manually designed features are always suboptimal because they are not learned and important information may be ignored or excluded during the feature design process.

[0011] To solve the above problems, recent studies (Kiranyaz et al., IEEE Transactions on Biomedical Engineering, 2016, Vol. 63, pp 664-675) have focused on a new architecture called neural networks, which have been intensively studied in the field of imaging with great success (Russakovsky et al., arXiv:1409.0575v3, 30 January 2015). Neural networks learn from raw or lightly preprocessed data and do not require hand-designed features. Although the application of neural networks is an improvement over the above contour extraction and classification approaches, current systems have several shortcomings. For example, current neural networks were developed only for QRS characterization. In addition, current neural networks process information beat-by-beat and therefore cannot obtain contextual information from surrounding beats.

[0012]

[0012] With regard to identifying abnormalities and / or detecting cardiovascular diseases, most algorithms use rules based on temporal and morphological indices (e.g., PR interval, RR interval, QT interval, QRS width, ST segment level, T wave slope) calculated using contour extraction. In many cases, the algorithms are designed by cardiologists (Prineas et al., The Minnesota Code Manual of Electrocardiographic Findings, Springer, ISBN 978-1-84882-777-6, 2009). However, current algorithms do not reflect the way cardiologists analyze ECGs and are crude simplifications. For example, the University of Glasgow algorithm does not reflect the way cardiologists analyze ECGs (Statement of Validation and Accuracy for the Glasgow 12-Lead ECGAnalysis Program, Physio Control, 2009).

[0013]

[0013] More advanced methods using learning algorithms have also been developed. In. Shen et al., Biomedical Engineering and Informatics (BMEI), vol. 3, pp. 960-964, 2010, use support vector machines to detect bundle branch block. However, these methods still require the raw data to be represented in a way that preserves invariance and stability.

[0014]

[0014] More complex neural network architectures have been proposed, but they have limitations when applied to ECG. One team (Jin and Dong, Science China Press, Vol. 45, No 3, 2015, pp 398-416, CN104970789) proposed a binary classification of the complete ECG, thus providing only one classification for the analyzed ECG. The proposed architecture uses convolutional layers that process the leads separately before blending them in a fully connected layer. In contrast to a binary analysis, the authors also mention a multi-class analysis that aims to recover one class among several. However, multi-label classification, where a cardiac signal is assigned multiple labels (e.g., abnormal), is not considered.

[0015]

[0015] Other algorithms and neural network architectures have been proposed for detecting risk of atrial fibrillation. Attia et al., "An artificial intelligence-enabled ECG algorithm for the identification of patients with atrial fibrillation during sinus rhythm: a retrospective analysis of outcome prediction", The Lancet, Volume 394, Issue 10201, pages 861-867, September 7, 2019, the contents of which are incorporated by reference in their entirety, describes the use of artificial intelligence and convolutional neural networks to detect asymptomatic atrial fibrillation.

[0016]

[0016] In view of the above limitations of known systems and methods, it would be desirable to accurately and efficiently process ECG data and present this information in an easy-to-understand manner. For example, it would be desirable to use enhanced computational techniques to analyze ECG data sampled from a patient and accurately and efficiently detect and / or predict cardiac events using artificial intelligence and / or machine learning techniques specifically designed for ECG analysis. Summary of the Invention

[0017]

[0017] Provided herein are systems and methods for analyzing ECG data using machine learning algorithms and medical artificial intelligence with greater accuracy and efficiency. In particular, provided are systems and methods for analyzing a patient's ECG data using artificial intelligence and large amounts of electrocardiogram (ECG) data. The system receives ECG data from a sensing device placed on the patient's body surface, e.g., one or more ECG leads / electrodes that may be incorporated into smart technology (e.g., a smart watch). The system can analyze the ECG data taken from the patient to accurately and efficiently detect and / or predict cardiac-related events, such as arrhythmias and / or abnormalities, such as atrial fibrillation (AFib). The system can include an application that communicates with an ECG platform running on a server, which can process and analyze the ECG data, e.g., using neural networks, to contour the cardiac signal and classify various abnormalities, conditions, and / or descriptors. The ECG platform can be a cloud-based ECG platform that processes and analyzes the ECG data in the cloud. The processed ECG data is communicated from the server and displayed in a user-friendly and interactive format with greater accuracy. The ECG application and ECG platform together implement an ECG processing system that receives the ECG data, processes and analyzes the ECG data, displays the ECG data on a system device, and generates reports comprising the ECG data.

[0018] A computerized method for analyzing electrocardiogram (ECG) data of a patient and restricting access to the analyzed ECG data is provided. The method may include receiving, by a server, an authorization instruction corresponding to a first location on the server. The method may further include receiving, based on the authorization instruction, a patient ECG dataset from a first user account accessed using a first device. The method may further include storing the patient ECG dataset at the first location on the server. The method may further include processing at least a portion of the patient ECG dataset using an algorithm to determine a presence of one or more anomalies, conditions, or descriptors corresponding to cardiac events associated with the patient ECG dataset, the algorithm being trained using a plurality of ECG datasets distinct from the ECG dataset. The method may further include generating output data based on the presence of the one or more anomalies, conditions, or descriptors. The method may further include storing the output data at the first location. The method may further include receiving a request to access the output data from a second user account accessed using the first device or a second device. The method may further include allowing the second user account to access the output data based on the authorization instruction. An authorization instruction is received from the first user account or the second user account, the authorization instruction including at least one of authorization to access the first location, authorization to upload data to the first location, authorization to access files of a first type in the first location, authorization to access or modify the management information, authorization to view the output data, authorization to modify the output data, or authorization to generate reports based on the output data.

[0019]

[0019] The method may further include determining, based on the authorization instruction, that the second user account has authorization to access the patient ECG data set. The method may further include allowing the second user account to access the patient ECG data based on a determination that the second user account has authorization to access the patient ECG data set. The method may further include receiving, from the second user account, a request to process the patient ECG data set using an algorithm. The method may further include receiving, from the first user account, a request to process the patient ECG data set using an algorithm. The method may further include receiving, from the second user account, a request to generate a report based on the output data. The method may further include determining, based on the authorization instruction, that the second user account has authorization to access the report saved at the first location. The method may further include, once the patient ECG data set is received and the patient ECG data is saved at the first location, sending a message to the second user account indicating that the patient ECG data set has been saved at the first location. The computerized method may further include receiving a request from one or more of the first account and the second account to view the output data and granting the request to view the output data based on the approval instruction. The computerized method may further include receiving a request from one or more of the first account and the second account to modify the output data and granting the request to modify the output data based on the approval instruction.

[0020]

[0020] A computerized system is described herein. The computerized system may be used to analyze electrocardiogram (ECG) data of a patient and to restrict access to the analyzed ECG data. The computerized system may be designed to receive, by a server, an authorization instruction corresponding to a first location on the server. The computerized system may further be designed to receive, based on the authorization instruction, a patient ECG dataset from a first user account accessed using a first device. The computerized system may further be designed to store the patient ECG dataset at the first location on the server. The computerized system may further be designed to process at least a portion of the patient ECG dataset using an algorithm to determine the presence of one or more anomalies, conditions, or descriptors corresponding to cardiac events associated with the patient ECG dataset, the algorithm being trained using a plurality of ECG datasets different from the ECG dataset. The computerized system may further be designed to generate output data based on the presence of the one or more anomalies, conditions, or descriptors. The computerized system may further be designed to store the output data at the first location. The computerized system may further be designed to receive a request to access the output data from a second user account accessed using the first device or the second device. The computerized system may further be designed to allow the second user account to access the output data based on an authorization instruction. The authorization instruction is received from the first user account or the second user account. The authorization instruction includes at least one of authorization to access the first location, authorization to upload data to the first location, authorization to access a first type of file in the first location, authorization to access or modify management information, authorization to view the output data, authorization to modify the output data, or authorization to generate a report based on the output data.

[0021] The computerized system may be further designed to determine, based on the authorization instruction, that the second user account has authority to access the patient ECG data set. The computerized system may be further designed to grant the second user account access to the patient ECG data based on a determination that the second user account has authority to access the patient ECG data set.

[0022]

[0022] The computerized system may be further designed to receive a request from the second user account to process the patient ECG dataset using the algorithm. The computerized system may be further designed to receive a request from the first user account to process the patient ECG dataset using the algorithm. The computerized system may be further designed to receive a request from the second user account to generate a report based on the output data. The computerized system may be further designed to determine, based on the authorization instruction, that the second user account has authority to access the report saved in the first location. The computerized system may be further designed to send a message to the second user account indicating that the patient ECG dataset has been saved in the first location once the patient ECG dataset has been received and the patient ECG data has been saved in the first location. The computerized system may be further designed to include receiving a request from one or more of the first account and the second account to view the output data, and granting the request to view the output data based on the authorization instruction. The computerized system may be further designed to include receiving a request to modify the output data from one or more of the first account and the second account, and authorizing the request to modify the output data based on the approval instruction.

[0023]

[0023] A non-transitory computer-readable medium is described herein. The non-transitory computer-readable medium may include computer-executable instructions, which when executed by at least one processor, cause the at least one processor to receive, by a server, an authorization instruction corresponding to a first location on the server. The computer-executable instructions may further cause the at least one processor to receive, based on the authorization instruction, a patient ECG dataset from a first user account accessed using a first device. The computer-executable instructions may further cause the at least one processor to store the patient ECG dataset at a first location on the server. The computer-executable instructions may further cause the at least one processor to process at least a portion of the patient ECG dataset using an algorithm to determine the presence of one or more abnormalities, conditions, or descriptors corresponding to cardiac events associated with the patient ECG dataset, the algorithm being trained using a plurality of ECG datasets different from the ECG dataset. The computer-executable instructions may further cause the at least one processor to generate output data based on the presence of the one or more abnormalities, conditions, or descriptors. The computer-executable instructions may further cause the at least one processor to save the output data to a first location. The computer-executable instructions may further cause the at least one processor to receive a request to access the output data from a second user account accessed using the first device or the second device. The computer-executable instructions may further cause the at least one processor to allow the second user account to access the output data based on an authorization instruction. The authorization instruction is received from the first user account or the second user account.

[0024]

[0024] The above summary is illustrative only and is not intended to be in any way limiting. In addition to the exemplary aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the following drawings and detailed description. [Brief description of the drawings]

[0025] [Figure 1A-1B] FIG. 1A is a standard 12-lead resting ECG electrocardiogram tracing, and FIG. 1B is an exemplary P wave, QRS complex, and T wave tracing. [Diagram 2]

[0026] FIG. 2 illustrates example components for implementing systems and methods according to aspects of the disclosure. [Figure 3A-3B]

[0027] 3A-3B are schematic diagrams of example hardware and software components of an example system device and an example server, respectively. [Figure 4]

[0028] FIG. 4 is a flow chart of an exemplary method for processing, using, displaying, and generating reports that include the ECG data. [Figure 5A-5B]

[0029] 5A-5B are line graphs illustrating an example ECG signal and an example output of the first neural network, respectively, for each waveform analyzed. [Figure 6A-6B]

[0030] 6A-6B are exemplary representations of classification neural networks in the form of a convolutional neural network and a recurrent neural network, respectively. [Figure 7]

[0031] FIG. 7 is an exemplary representation of a variable number of lead entries and a fixed number of outputs. [Figure 8]

[0032] FIG. 8 is an exemplary user interface having a heart rate density plot generated in accordance with an aspect of the recent disclosure. [Figure 9]

[0033] FIG. 9 is an expanded view of the heart rate density plot shown in FIG. [Figure 10]

[0034] FIG. 10 is an exemplary user interface having a heart rate density plot generated in accordance with an aspect of the present disclosure. [Figure 11]

[0035] FIG. 11 is a flow chart illustrating an exemplary approach for generating a beat density plot. [Figure 12]

[0036] FIG. 12 is an example heart rate density plot generated according to an embodiment of the present disclosure. [Figure 13]

[0037] FIG. 13 is an exemplary user interface with an expanded heart rate density plot. [Figures 14A-14E]

[0038] 14A-14E are side-by-side comparisons of various RR plots and heart rate density plots generated from the same cardiac signal. [Figure 15A-15D]

[0039] 15A-15D are example reports generated by an ECG processing system having information corresponding to the patient and the processed ECG data, displaying a heart rate density plot and an ECG strip. [Figure 16]

[0040] FIG. 16 illustrates an example process flow for determining ECG data and associating the ECG data with a user profile. [Figure 17A-17B]

[0041] 17A-17B show example process and data flows for determining ECG data, analyzing the ECG data, and determining a report based on the ECG data. [Figure 18]

[0042] FIG. 18 illustrates an example process flow for determining ECG data, determining a report, prioritizing the report, and signing the report. [Figures 19A-19C]

[0043] 19A-19C show an example of a monthly summary report of ILR events. [Figure 20]

[0044] FIG. 20 shows an example of an ILR event report. [Figures 21A-21C]

[0045] 21A-21C show an example of a monthly report and event list user interface. [Fig. 22A-22B]

[0046] 22A-22B show examples of a user registration interface and a profile interface. [Figure 23A-23B]

[0047] Figure 23A shows an example of an event interface including a recategorization menu, and Figure 23B shows an example of a process for recategorizing an event. [Figure 24]

[0048] FIG. 24 shows the color bands that may be displayed on the event interface. [Figure 25A]

[0049] FIG. 25A illustrates an example of a multi-user device system for analyzing ECG and other data. [Figure 25B]

[0050] FIG. 25B illustrates a process of using a multi-user device to analyze ECG data and other data to determine anomalies, descriptors, or conditions. [Figure 25C]

[0051] FIG. 25C illustrates a process of using a multi-user device to analyze ECG data and other data to determine anomalies, descriptors, or conditions. [Figure 25D]

[0052] FIG. 25D shows a user interface for displaying ECG data and other data. [Figure 25E]

[0053] FIG. 25E illustrates a user interface for displaying additional information associated with individual ECG data points and / or other data points. [Figure 25F]

[0054] FIG. 25F illustrates a user interface for displaying ECG representations corresponding to ECG data points and / or other data points. [Figure 25G]

[0055] FIG. 25G shows an example of a mobile device interface for displaying heart rate and / or ECG data and results. [Figure 26]

[0056] FIG. 26 shows an example of a mobile device interface for presenting ECG data and results. [Figure 27]

[0057] FIG. 27 illustrates an example process for prioritizing certain information for review by healthcare providers based on user direction. [Figure 28]

[0058] FIG. 28 is an example of a process for determining periods of likely arrhythmia and requesting ECG data corresponding to those periods. [Figure 29]

[0059] FIG. 29 is an example of a process for determining periods of likely atrial fibrillation based on PAC burden and determining ECG data during those periods. [Fig. 30A-30B]

[0060] 30A-B show an event report that includes a graphical representation of a detected event. [Fig. 31A-31F]

[0061] 31A-31F show various user interfaces for displaying patients, indications, categories, and / or events. [Diagram 32]

[0062] FIG. 32 is a portion of an ECG report that includes selectable ECG strips and selectable links to redirect to a viewer application. [Diagram 33]

[0063] FIG. 33 shows the viewer interface of the viewer application including a heart rate density plot and an ECG strip. [Diagram 34]

[0064] FIG. 34 illustrates an example process for redirecting a user from a report to a viewer application that includes a viewer interface. [Fig. 35A-35C]

[0065] 35A-35C are a report interface, a patient interface, and an event list interface. [Diagram 36]

[0066] FIG. 36 illustrates example components for implementing systems and methods according to aspects of the disclosure. [Fig. 37A-37B]

[0067] 37A-37B show an example of a process for providing and accessing an ECG analysis. [Fig. 38A-38B]

[0068] 38A-38B are example processes for providing and accessing an ECG analysis. [Figure 39]

[0069] FIG. 39 is an example of a user interface for an account manager. [Diagram 40]

[0070] Figure 40 is an example of a user interface for a report. [Diagram 41]

[0071] FIG. 41 is an example of a user interface for selecting permissions and / or access.

[0026]

[0072] These and other features of the present invention will become apparent from the following description and appended claims, taken in conjunction with the accompanying drawings, which illustrate only certain embodiments of the disclosure and are therefore not intended to limit the scope of the disclosure, but which will be described with more specificity and detail through the use of the accompanying drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027]

[0073] The present invention relates to an electrocardiogram (ECG) processing system with medical artificial intelligence, including an ECG application running on a system device and an ECG platform running on a server. The ECG application and ECG platform implement the ECG processing system by using machine learning algorithms to process and analyze ECG data to detect and / or predict cardiac events, such as arrhythmias and / or abnormalities, such as atrial fibrillation (AFib). The system may provide cardiac signal contouring, as well as classification of various abnormalities, symptoms, and descriptors. The server may be located at a different location than the system device, and the servers need not be located at the same physical location as each other (e.g., the servers may be remote servers). Alternatively, the server and the system device may be located in the same general area (e.g., on a local area network (LAN)). The ECG platform may be a cloud-based ECG platform that can implement the ECG processing system by processing and analyzing ECG data in the cloud.

[0028]

[0074] To implement the ECG processing system, an ECG application running on the system device may receive ECG data (i.e., cardiac signals) from the sensing device and transmit the ECG data to an ECG platform running on a server. The ECG platform may execute a first and a second neural network and apply the ECG data to the first and the second neural networks. The first neural network may be a contour extraction neural network with machine learning capabilities. The second neural network may be a classification neural network with machine learning capabilities. Contouring and classification of the ECG data may be achieved by processing the output of the first and / or the second neural network by the ECG platform. The ECG data, and / or data generated by the ECG platform, may be communicated from the ECG platform to the ECG application. The ECG application may display the ECG data, and / or data generated by the ECG platform in an interactive manner. The ECG platform may generate a report including the ECG data, and / or data generated by the ECG platform, and communicate the same to the ECG application.

[0029]

[0075] 2, there is shown an example of components for implementing an electrocardiogram (ECG) processing system 10. FIG. 2 shows an ECG sensing device 13, a system device 14, a server 15, and a drive 16.

[0030]

[0076] The ECG sensing device 13 is designed to sense the electrical activity of the heart to generate ECG data. For example, the sensing device 13 may be one or more electrodes disposed on one or more leads. The ECG sensing device 13 may be an ECG-only sensing device, such as a traditional 12-lead configuration, or may be a general-purpose device having sensing hardware to sense the electrical activity of the heart for ECG generation, such as the Apple Watch available from Apple Inc. of Cupertino, California. The sensing device 13 may be disposed on the surface of the patient's chest and / or the patient's extremities. The sensing device 13 may be in electrical communication with the system device 14 executing the ECG application 29 to enable the ECG application 29 to receive electrical signals detected by the sensing device 13. The ECG application 29 may include instructions that cause the sensing device 13 to sense or acquire ECG data.

[0031]

[0077] System device 14 is preferably one or more computing devices (e.g., laptop, desktop, tablet, smartphone, smartwatch, etc.) having the components described below with reference to FIG. 3A and the functionality described herein. System device 14 running ECG application 29 may be connected to server 15 running ECG platform 37 via any well-known wired or wireless connection. For example, system device 14 may connect to the Internet using well-known technologies (e.g., WiFi, cellular, cable / coax, and / or DSL) and communicate with server 15 over the Internet.

[0032]

[0078] The server 15 is preferably one or more servers having the components described below with reference to FIG. 3B and the functions described herein. The server 15 preferably has greater processing power than the system device 14, and the server 15 is preferably capable of processing and analyzing cardiac signals having a sampling rate above a predetermined threshold, for example, a sampling rate of at least 20 samples / second, at least 250 samples / second, or at least 1000 samples / second. As will be readily understood by those skilled in the art, the server 15 may include multiple servers located at a common physical location or different physical locations. In a preferred embodiment, the server 15 is located at a remote location (e.g., on a cloud) different from the system device 14. However, the server 15 and the system device 14 may be located at a common location (e.g., on a local area network (LAN)).

[0033]

[0079] Server 15 may optionally communicate with drive 16, which may be one or more drives having dedicated memory for storing digital information specific to a particular patient, professional, facility, and / or device. For example, drive 16 may include, but is not limited to, volatile (e.g., random access memory (RAM)), non-volatile (e.g., read only memory (ROM)), flash memory, or any combination thereof. Drive 16 may be incorporated into server 15 or may exist separately from server 15 and communicate with server 15 via well-known wireless or wired connections.

[0034]

[0080] Aspects of the ECG processing system 10, and / or other ECG processing systems described throughout this application, may be the same as or similar to the ECG processing system described in WO2020161605A1 (corresponding to U.S. Patent Application No. 17 / 390,714), a published application of PCT / IB2020 / 050850, filed February 3, 2020, which claims priority to Li's U.S. Patent No. 10,959,660, the entire contents of each of which are incorporated herein by reference. Additional technology that may be utilized is described in commonly assigned U.S. Patent Application No. 17 / 397,782, the entire contents of which are incorporated herein by reference.

[0035]

[0081] 3A and 3B, there are shown example functional blocks representing hardware and software components of system device 14 and server 15. With reference to FIG. 3A, the hardware and software components of system device 14 may include one or more processing units 21, memory 22, storage 27, communication units 23, power sources 24, input devices 25, and output devices 26.

[0036]

[0082] The processing unit 31 may be one or more processors configured to execute a collaboration operating system 28 and an ECG application 29 and perform the tasks and operations of the system device 14 described herein. The memory 22 may include, but is not limited to, volatile (e.g., random access memory (RAM)), non-volatile (e.g., read-only memory (ROM)), flash memory, or any combination thereof. The communication unit 23 may receive and / or transmit information to other components in the ECG processing system 10, including, but not limited to, the sensing device 13 and the server 15. The communication unit 23 may be any well-known communication infrastructure that facilitates communication over well-known wired or wireless connections, including well-known standards such as the IEEE 802 standard. The power source 24 may be a battery or may connect the system device 14 to a wall outlet or other external power source. The storage 27 may include removable and / or non-removable storage, such as, but not limited to, a magnetic disk, an optical disk, or a tape.

[0037]

[0083] The input device 25 may be one or more devices coupled to or incorporated into the system device 14 for inputting data into the system device 14. The input device 25 may further include a keyboard, a mouse, a pen, a voice input device (e.g., a microphone), a touch input device (e.g., a touchpad or touchscreen), a position sensor, and / or a camera, etc. The output device 26 may be any device coupled to or incorporated into the system device 14 for outputting or otherwise displaying data, and includes at least a display 17. The output device 26 may further include, for example, a speaker and / or a printer.

[0038]

[0084] The ECG application 29 may be stored in the storage 27 and executed on the processing unit 21. The ECG application 29 may be a software application and / or software module having one or more instruction sets suitable for performing the operations of the system device 14 described herein, including facilitating information exchange with the sensing device 13 and the server 15. For example, the ECG application 29 may cause the system device 14 to receive ECG data from the sensing device 13, record the ECG data from the sensing device 13, communicate the ECG data to the server 15, instruct the server 15 to process and analyze the ECG data, receive the processed and / or analyzed ECG data from the server 15, communicate user inputs related to report generation to the server, and generate a graphic user interface suitable for displaying the raw ECG data, the analyzed and / or processed ECG data, and data related thereto.

[0039]

[0085] An operating system 28 may be stored in storage 27 and executed on processing unit 21. Operating system 28 may be adapted to control the general operation of system device 14 and may cooperate with ECG application 29 to implement the functionality of system device 14 described herein. System device 14 may also optionally execute graphics libraries, other operating systems, and / or other application programs. Of course, it will be understood that system device 14 may include more or fewer components than those shown in FIG. 3A and may include multiple of each type of component.

[0040]

[0086] 3B, the hardware and software components of the server 15 may include one or more processing units 31, memory 32, storage 35, power supply 33, and communication unit 34. The processing unit 31 may be one or more processors configured to execute an operating system 36 and an ECG platform 37 and to perform the tasks and operations of the server 15 described herein. Considering the amount of data and processing tasks assigned to the processing unit 31, it will be understood that the processing unit 31 has greater processing capabilities than the processing unit 21.

[0041]

[0087] The memory 32 may include, but is not limited to, volatile (e.g., random access memory (RAM)), non-volatile (e.g., read-only memory (ROM)), flash memory, or any combination thereof. The storage 35 may include, but is not limited to, removable and / or non-removable storage, such as, for example, a magnetic disk, an optical disk, or a tape. The communication unit 34 may receive and / or transmit information to other components of the ECG processing system 10, including, but not limited to, the system device 14 and / or the drive 16. The communication unit 34 may be any well-known communication infrastructure that facilitates communication via any well-known wired or wireless connection. The power source 33 may be a battery, or may connect the server 15 to a wall outlet or other external power source.

[0042]

[0088] An operating system 36 and an ECG platform 37 may be stored in the storage 35 and executed on the processing unit 31. The operating system 36 may be adapted to control the general operation of the server 15. The ECG platform 37 may be a software application and / or software module having one or more instruction sets. The ECG platform 37 may facilitate and oversee the processing and analysis of ECG data received from the system devices 14 and the generation of reports, and may be adapted to perform the operations of the server 15 described herein in other forms.

[0043]

[0089] The ECG platform 37 may include several sub-modules and / or applications such as, but not limited to, a pre-processor 38, a delineator 39, a classifier 41, a clustering unit 42 (which may include an embedding unit 48 and a grouping unit 49), a post-processor 43, a report generator 44, a recalculator 40, and / or a sequence analyzer 50. Each sub-module and / or application may be a software application and / or module having one or more instruction sets. The pre-processor 38 pre-processes the raw ECG data, the delineator 39 executes a first neural network to achieve contour extraction, the classifier 41 executes a second neural network to achieve classification, the clustering unit 42 identifies clusters in the data processed by the first neural network, the post-processor 43 post-processes the data processed by the second neural network, the embedding unit 48 executes one or more algorithms and / or a third neural network to achieve embedding, the grouping unit 49 executes one or more algorithms and / or a fourth neural network to generate cluster groups, the report generator 44 generates a report based on the raw ECG data and the ECG data processed by the ECG platform 37, and the recalculator 40 may recalculate and / or adjust the embedding unit 48 and / or the grouping unit 49 based on user input data. For example, the recalculator 40 may recalculate the episodes based on the corrected wave information. The sequence analyzer 50 may be one or more algorithms and / or a third neural network, which may be a recurrent neural network. The sequence analyzer 50 may analyze the feature map to determine one or more sequence labels, thereby achieving sequence identification, as described below. The ECG platform 37 may also perform various other functions.These other functions may include, but are not limited to, receiving requests from system device 14 to process and / or analyze ECG data, communicating processed and / or analyzed ECG data to system device 14, receiving requests to generate reports, requesting and / or receiving user interaction and / or instructions to / from system device 14, receiving user input data and / or instruction information regarding report generation from system device 14, and / or communicating reports to system device 14.

[0044]

[0090] Server 15 may also optionally run graphics libraries, other operating systems, and / or other application programs. Of course, it will be understood that server 15 may include more or fewer components than those shown in FIG. 3B and may include multiple of each type of component.

[0045]

[0091] 4 illustrates an exemplary process for implementing the ECG processing system 10 to receive and record ECG data, process and analyze the ECG data, and generate a report including the ECG data. FIG. 4 further illustrates the flow of information between a front end 45 and a back end 46 of the ECG processing system 10, as described, for example, in U.S. Patent Application Publication No. 2019 / 0167143, U.S. Patent Application Publication No. 2019 / 0223739, and U.S. Patent No. 10,426,364, the contents of each of which are incorporated herein in their entirety. The front end 45 includes at least an ECG application 29 that executes on the system device 14. The back end 46 includes at least an ECG platform 37 that executes on the server 15.

[0046]

[0092] As shown in FIG. 4, in step 51, the ECG application 29 may cause the system device 14 to receive and / or acquire raw ECG data 52 from the sensing device 13. For example, the ECG application 29 may cause the sensing device 13 to sense a cardiac signal and communicate the cardiac signal sensed by the sensing device 13 to the system device 14. The raw ECG data is the cardiac signal sensed by the sensing device 13. The raw ECG data 52 is not processed or analyzed by the ECG processing system 10. The raw ECG data 52 preferably includes data sampled multiple times per heartbeat over multiple heartbeats. The sensing device 13 may convert the analog cardiac signal to a digital signal, a different component not shown in FIG. 2 may convert the analog cardiac signal to a digital signal, or the ECG application 29 may cause the system device 14 to convert the analog cardiac signal to a digital signal. Both the analog and digital forms of raw ECG data are referred to herein as raw ECG data 52.

[0047]

[0093] Upon receiving the raw ECG data 52, the ECG application 29 may cause the system device 14 to record the raw ECG data 52 and may optionally store some or all of the raw ECG data 52 on the system device 14. As noted above, the signals may correspond to one or more leads. When multiple leads are used, all leads may be processed simultaneously. The cardiac signals generated by each lead may have different lengths. Furthermore, the cardiac signals may be short-term (e.g., 10 seconds for a standard ECG) or long-term (days for a Holter). The system device 14 may optionally display the raw ECG data 52, or a portion thereof, on the display 17.

[0048]

[0094] As shown in FIG. 4 , raw ECG data 52 may be transmitted from the front end 45 to the back end 46. Specifically, the ECG application 29 may cause the system device 14 to communicate the raw ECG data 52 to the ECG platform 37 running on the server 15. Upon receiving the raw ECG data 52, the ECG platform 37 may cause the server 15 to store some or all of the raw ECG data 52 to the server 15. Additionally, after receiving the raw ECG data 52, the ECG platform 37 may pre-process the raw ECG data 52 by a pre-processor 38 at step 54. The pre-processor 38 may be a standalone component of the ECG platform 37 or a sub-component of the delineator 39.

[0049]

[0095] The pre-processor 38 may process the raw ECG data 52 or a portion thereof by removing disturbing elements of the cardiac signal, such as noise, from the raw ECG data. A multivariate function data analysis approach may be used for noise filtering (Pigoli and Sangalli, Computational Statistics and Data Analysis, Vol. 56, 2012, pp 1482-1498). Because the signal sensed by the sensing device 13 may vary due to patient motion, a baseline frequency of the raw ECG data 52 may be removed by the pre-processor 38 and the cardiac signal may be represented at a selected frequency. Frequencies of the signal corresponding to patient motion may be removed using median filtering (Kaur et al., Proceedings published by International Journal of Computer Applications, 2011, pp 30-36). Applying the raw ECG data 52 to the pre-processor 38 produces pre-processed ECG data 55. At this point, the ECG platform 37 can optionally communicate the pre-processed ECG data 55 to an ECG application 29 running on the system device 14 for display on the display 17. The ECG platform 37 may alternatively or additionally cause the pre-processed ECG data 55 to be used as input in a classification step 58, which will be described in more detail.

[0050]

[0096] In step 56, the ECG platform 37 applies the preprocessed ECG data 55 to the delineator 39 for contour extraction. The delineator 39 applies a first neural network, a contour extraction neural network, to the preprocessed ECG data 55. A neural network refers to a mathematical structure or algorithm that takes an object (e.g., a matrix or vector) as input and produces another object as output through a series of linear and nonlinear operations called layers. For example, the input of the first neural network may be one or more multi-lead cardiac signals that have been preprocessed to remove noise and / or baseline fluctuations.

[0051]

[0097] To apply the pre-processed ECG data 55 to the first neural network, the delineator 39 may represent some or all of the raw ECG data 52 as a matrix X, which may be a matrix of real numbers. For example, as described in more detail below, the matrix X may be a matrix of size m×n at the frequency used to train the network. The constant “m” is the number of leads in the sensing device 13, typically 12, although any number of leads may be used. In this example, the number of samples “n” provides a duration of the cardiac signal “n / f”, where f is the sampling frequency of the cardiac signal. The sample rate is above a predetermined rate, and is preferably relatively high, such as at least 20 samples / sec, at least 250 samples / sec, at least 500 samples / sec, or at least 1000 samples / sec. In an embodiment, all sampled ECG data is sent to a server and input to the processing algorithm without filtering the ECG data. The ECG data applied to the first neural network is preferably preprocessed ECG data 55, although non-preprocessed cardiac signals (i.e., raw ECG data 52, or a portion thereof) may also be applied to the first neural network.

[0052]

[0098] The first neural network can provide as output values ​​corresponding to the probability of the presence of one or more waves at multiple time points in the cardiac signal. The time points may be determined by the raw ECG data, selected by a user of the system device 14, or preprogrammed. The first neural network may be a convolutional neural network, preferably a fully convolutional neural network. A convolutional neural network is a particular type of neural network in which one or more matrices to be trained do not encode a full linear combination of the input elements, but rather encode the same local linear combinations at all elements of a structured signal, such as a cardiac signal, through convolution (Fukushima, Biol. Cybernetics, Vol. 36, 1980, pp. 193-202; LeCun et al., Neural Computation, Vol. 1, 1989, pp. 541-551). A network that includes only convolutional networks is called a fully convolutional neural network.

[0053]

[0099] Thus, in step 56, the delineator 39 causes the first neural network to read each time point of the cardiac signal, spatio-temporally analyze each time point of the cardiac signal, and assign each time point a score corresponding to one or more waveforms. In this way, all waveforms in the cardiac signal can be analyzed and their probability of presence at each time point can be quantified in a single step. Each score generated by the delineator 39 thus indicates the probability of the presence of a particular waveform at a given time point of the cardiac signal. The waveforms can be any of the well-known waveforms, such as P waves, Q waves, R waves, S waves, multiple Q waves, multiple R waves, multiple S waves, QRS waves, and / or T waves. In this way, the delineator 39 can process data sampled multiple times per heartbeat over multiple heartbeats.

[0054]

[0100] The output of the first neural network is a matrix Y, which may be a matrix of real numbers. For example, the matrix Y may be a matrix of size p×n. The matrix Y may include a score for each waveform at each time point in the cardiac signal. In the matrix Y, "n" is the number of samples as described above with respect to the matrix X, and "p" is the number of waveforms plus the number of wave characteristics. As described in more detail below, the wave characteristics may correspond to, for example, the conduction, prematurity, ectopic, and / or origin of the waves in the cardiac signal. In one example, the waveforms include (1) P waves, (2) QRS complexes, and (3) T waves, and the wave characteristics include (1) premature waves, (2) paced waves, (3) ventricular QRS complexes, (4) junctional QRS complexes, (5) ectopic P waves, and (6) non-conducted P waves. Thus, in this example, p=3+6=9. Each waveform may be represented according to certain characteristics of that wave, such as its beginning and ending points (ie, onset and offset).

[0055]

[0101] 5A and 5B, exemplary outputs of the first neural network are illustrated for each waveform to illustrate the value of generating scores at each time point for multiple waveforms. Specifically, FIG. 5A shows an example output when the contour extraction neural network processes a normal cardiac signal (no abnormalities), and FIG. 5B shows an example output when the contour extraction neural network processes a cardiac signal having a "hidden" P wave, e.g., due to atrioventricular block.

[0056]

[0102] FIG. 5A shows four line graphs, with the x-axis of each graph representing time. Line graph 71 represents a cardiac signal over multiple beats. The plotted signal reflects the familiar ECG waveform with P waves (point 75), QRS complexes (point 76), and T waves (point 77). Line graph 72 is a graph of the P wave score over the same time point in the cardiac signal. Similarly, line graphs 73 and 74 are graphs of the QRS score and T wave score, respectively, over the same time point. The y-axis of each line graph 72-74 is a score assigned at each time point, ranging from 0 to 1, with 0 indicating that the particular wave is unlikely to be present and 1 indicating that the particular wave is likely to be present. For example, line graph 72 indicates that a P wave is very likely to be present with a score 78, which corresponds to a time point around point 75, line graph 73 indicates that a QRS complex is very likely to be present with a score 79, which corresponds to a time point around point 76, and line graph 74 indicates that a T wave is very likely to be present with a score 80, which corresponds to a time point around point 77.

[0057]

[0103] Similar to FIG. 5A, FIG. 5B shows four line graphs 81-82 similar to line graphs 71-74. Specifically, line graph 81 represents the cardiac signal over several beats, line graph 82 represents the P-wave score over the cardiac signal, line graph 83 represents the QRS score over the cardiac signal, and line graph 84 represents the T-wave score over the cardiac signal. Different from FIG. 5A, the ECG signal of line graph 81 includes hidden P-waves, such as the hidden P-wave shown at point 85. A hidden P-wave is a P-wave that occurs during the period of another wave or group, such as a T-wave. Because the cardiac signal processed by the contour extraction network has a high sample rate and the contour extraction network generates data for each waveform at each time point, the reconstructed output is robust enough (i.e., includes enough sample points) to distinguish two waves occurring at the same time, as is the case for hidden P-waves, for example. For example, line graph 82 shows that there is a very high probability of a P-wave at score 86 corresponding to a time point around point 85. Thus, the contour extraction neural network is not limited to recovering only one wave at each time point, but can identify multiple waves at any time point. Furthermore, signals from one or more leads can be processed simultaneously by the first neural network.

[0058]

[0104] Using the scores assigned to each time point corresponding to each waveform (e.g., P wave, QRS complex, T wave, etc.), the delineator 39 can post-process the cardiac signal. Post-processing includes assigning zero or more waves to each time point, calculating the respective onset and offset of each identified wave, and optionally determining wave characteristics. A wave may be assigned to each time point by determining that a wave is present at that time point if a certain value is reached. Calculating the "onset" and "offset" of each wave includes calculating the start and end time points of each wave in the cardiac signal, where the start is referred to as the "onset" and the end is referred to as the "offset." This may include analyzing the time points corresponding to the start and end of the peak of each waveform. The delineator 39 can perform wave characterization by identifying ectopics, conductances, and ectopics. Wave characterization leverages contextual information between each wave and / or each beat. For example, an ectopic label may be applied to a waveform if a certain threshold is reached at a particular time point or if an average value across multiple time points is reached.

[0059]

[0105] After calculating the start and end of each waveform of the cardiac signal, the delineator 39 may calculate global measures. Global measures may be derived from the start and end of each waveform and relate to features and characteristics of the cardiac signal, such as inter-wave intervals and wave durations. For example, global measures may include, but are not limited to, PR interval, P wave duration, QRS complex duration, QRS axis, QT interval, corrected QT interval (Qtc), T wave duration, JT interval, corrected JT interval, heart rate, ST elevation, Sokoloff index, number of premature ventricular contractions, number of premature atrial contractions (PAC), percentage of non-conducted P waves, and / or percentage of pacemaker waves.

[0060]

[0106] The delineator 39 may further infer labels solely from the information generated by the delineator 39. For example, the delineator 39 may infer labels such as PR shortening (i.e., PR interval < 120 ms), first degree AV block (e.g., PR interval > 200 ms), axis deviation, QTc prolongation, QTc shortening, wide QRS tachycardia, and / or intraventricular conduction block. Labels determined solely from the information generated by the delineator 39 are referred to as contour extraction-based labels.

[0061]

[0107] Returning to FIG. 4 , the ECG platform 37 may communicate or otherwise apply the output of step 56 (e.g., wave information 62) and the pre-processed ECG data 55 to the clustering unit 42 for clustering in step 63. The wave information 62 may include generated scores for PVC and PAC waves, including their onset and end, and associated duration. The clustering unit 42 may process the wave information 62 and identify clusters of PAC or PAV waves during the duration of the cardiac signal. After identification is made, the clustering unit 42 assigns cluster labels 64 to one or more time windows, for each of which either a PVC or PAC cluster is identified. A time window is defined by two time points in the cardiac signal.

[0062]

[0108] Returning to FIG. 4 , the ECG platform 37 may also communicate or otherwise apply the output of step 56 (e.g., wave information 57) and the preprocessed ECG data 55 to the classifier 41 for classification in step 58. The classification in step 58 involves applying a second neural network (i.e., a classification neural network) to the preprocessed ECG data 55. Thus, in one example, the input of the second neural network may be one or more preprocessed multi-lead cardiac signals of variable length. The classifier 41 may also process the wave information 57 and / or other information, such as patient-specific information including the patient's age or relevant clinical information. As noted above, the ECG platform 37 may optionally communicate the preprocessed ECG data 55 directly to and processed by the classifier 41 if contour extraction in step 56 is not required. In this manner, the classifier 41 may process data sampled multiple times per beat over multiple beats.

[0063]

[0109] The second neural network generates an output having a value corresponding to the likelihood of the presence of one or more abnormalities, conditions, and / or descriptors at each time point of the cardiac signal. If a time point or time window is determined to correspond to a particular abnormality, condition, and / or descriptor, a label corresponding to the abnormality, condition, and / or descriptor is assigned to the time point or window. In one example, one or more labels 59 may be assigned to a time point or time window if a score reaches a predetermined threshold. Thus, by generating multiple values ​​at each time point and assigning one or more labels at each time point, multi-label localization of abnormalities, conditions, and / or descriptors can be achieved.

[0064]

[0110] The classifier 41 may recover the output of the classification neural network as a vector of size q. A value in the vector corresponds to the presence of each label at each time point or each time window. For example, the output of the classification neural network may be the vector [0.98:0.89;0.00], and the labels [right bundle branch block; atrial fibrillation; normal ECG] corresponding to each element of the vector. The scores may range from 0 to 1. For the above vector, if the threshold is 0.5, the classifier 41 assigns the labels "right bundle branch block" and "atrial fibrillation" to the time points or time windows corresponding to the scores. The threshold may be preprogrammed and / or selected by the user, and may be adjusted to change the degree of sensitivity and specificity. By assigning one or more labels to each time point, an onset and offset corresponding to each label may be calculated to identify the duration of an episode (e.g., an abnormal episode).

[0065]

[0111] The abnormalities and conditions may include any physiological abnormality or condition that can be identified in a cardiac signal. Currently, approximately 150 measurable abnormalities can be identified in an electrocardiogram signal recording. The abnormalities and conditions may include, but are not limited to, sinus block, paralysis or asystole, atrial fibrillation, atrial flutter, atrial tachycardia, junctional tachycardia, supraventricular tachycardia, sinus tachycardia, ventricular tachycardia, pacemaker, premature ventricular contractions, premature atrial contractions, first degree atrioventricular block (AVB), second degree AVB Mobitz type I, second degree AVB Mobitz type II, third degree AVB, Wolff-Parkinson-White syndrome, left bundle branch block, right bundle branch block, intraventricular conduction delay, left ventricular hypertrophy, right ventricular hypertrophy, acute myocardial infarction, previous myocardial infarction, ischemia, hyperkalemia, hypokalemia, Brugada syndrome, and / or QTc prolongation. Descriptors may include descriptive properties of the cardiac signal, such as "normal" or "noisy ECG."

[0066]

[0112] When the second neural network is applied in step 58, the classifier 41 can read each time point and each global measure of the cardiac signal, analyze each time point and each global measure of the cardiac signal, calculate time windows by aggregating at least two time points, and calculate a score for each time window, the score corresponding to multiple non-exclusive labels.

[0067]

[0113] The classification neural network may be a convolutional neural network or a recurrent neural network. Referring to FIG. 6A, a classification neural network in the form of a convolutional neural network is applied to an ECG signal. Most convolutional neural networks implement a small number of convolutional layers followed by standard layers to provide classification. The ECG signal is given as an input to the network, which locally aggregates the information and combines it layer by layer to generate a high-level multi-label classification of the ECG. Each label is provided with a score. The labels of the convolutional neural network shown in FIG. 6A include atrial fibrillation (AFIB), right bundle branch block (RBBB), and premature ventricular contractions (PVCs).

[0068]

[0114] Referring to FIG. 6B, a classification neural network in the form of a recurrent convolutional neural network is shown. As in FIG. 6A, an ECG signal is provided as an input to the network. A recurrent convolutional neural network refers to a specific convolutional neural network structure that can remember previously applied objects. The recurrent convolutional neural network is composed of two sub-networks: a convolutional neural network that extracts features at all time points of the cardiac signal and on which calculations are performed, and a neural network on top of the first convolutional neural network that aggregates the output of the first convolutional neural network over time to provide a refined output. In this way, the convolutional neural network acts as a pattern detector, whose output is aggregated over time by the recurrent neural network.

[0069]

[0115] As shown in Figure 6B, the output of the convolutional neural network identified four labels at various time points, including premature ventricular contraction (PVC) and normal. These labels were then applied to a second neural network, which produced a refined output, "premature ventricular contraction." In this example, the network correctly identified a premature ventricular contraction (PVC, the fifth largest beat) in the first part of the signal, and the second part of the signal is considered normal. Since it contains an anomaly, the cardiac signal is not considered normal, and the aggregated output is PVC.

[0070]

[0116] To achieve the behaviors and functions described herein, a first neural network (i.e., a contour extraction neural network) and a second neural network (i.e., a classification neural network) need to be trained. In both the contour extraction embodiment and the classification embodiment, the networks can be represented using open software such as Tensorflow, Theano, Caffe, or Torch. These tools provide functions for computing the output of the network and for updating the parameters through gradient descent.

[0071]

[0117] Training the neural network involves applying a number of data sets to the neural network, including cardiac signals and known outputs. A database of data sets including cardiac signals collected from multiple patients using the systems and methods described herein may be stored on the server 15 and / or drive 16 (e.g., in the cloud). The data sets in the database may be used by the server 15 to analyze new cardiac signals input to the system for processing. In a preferred embodiment, the cardiac signals applied to the trained neural network have the same sampling rate and / or frequency as the cardiac signals in the data set used to train the neural network. For example, training of a classification neural network begins with a data set including cardiac signals and their known contour extractions. As noted above, the cardiac signals are represented as a matrix of size m×n at a predefined frequency. For example, the network may be trained at 250 Hz, 500 Hz, or 1000 Hz, although any frequency may be used. The contour extractions are represented in the form of a matrix Y of size p×n, where p is the number of waveforms. Each wave is represented by a start and end point, for example as follows: (P, 1.2 s, 1.3 s), (QRS 1.4 s, 1.7 s), (T, 1.7 s, 2.1 s), (P, 2.2 s, 2.3 s). In this example, the first row of matrix Y corresponds to the P wave and has a value of 1 at 1.2 s and 1.3 s, as well as 2.2 s and 2.4 s, and a value of 0 elsewhere. The second row of matrix Y corresponds to the QRS complex and has a value of 1 at 1.4 s and 1.7 s, and a value of 0 elsewhere. Finally, the third row of matrix Y corresponds to the T wave and has a value of 1 at 2.2 s and 2.3 s, and a value of 0 elsewhere. Next, the parameters of the network may be modified to reduce a cost function that compares the output of the network to the known contour extraction. To allow for multi-labeling (i.e., allowing for multiple waves at a particular time point), a cross-entropy error function is used. This minimization can be performed through a gradient step that repeats the above procedure at least once for each cardiac signal in the data set.A similar approach may be used to train the contour extraction neural network (i.e., the second neural network).

[0072]

[0118] Furthermore, the ECG platform 37 may cause the neural network described herein to process cardiac signals with different numbers of input leads. For example, the neural network may include a series of layers at the beginning of the network to obtain a network that is independent of the number of input leads and thus can process cardiac signals with any number of leads, m. For example, FIG. 7 shows two input leads (m=2) and three output signals (k=3). However, the same structure can process any number of input leads, m, and still provide the same number of output signals. The output signals can be fed to the rest of the network, which requires a fixed number of input signals. Thus, the number of input leads may be variable and does not have to be fixed.

[0073]

[0119] As shown in Figure 7, to obtain k signals from m input leads, the leads may be convolved using per-lead convolution with k filters. Then, the signals may be grouped by the convolution filters to obtain k groups of m leads. Finally, a mathematical function is applied to each group to obtain the k leads. The mathematical function may be the maximum value at each time point, or any other function known to one skilled in the art.

[0074]

[0120] Returning to FIG. 4, in step 61, the ECG platform 37 may aggregate the labels for each time window (i.e., labels) by the post-processor 43 to generate a processed label 60. The labels may be derived from global measurements based on contouring. For example, a label corresponding to first degree AV block may be derived from a PR interval greater than 200 ms. As discussed above, the PR interval is a global measurement based on contouring. The post-processor 43 may also aggregate contouring-based labels corresponding to the same time point with a classification label.

[0075]

[0121] The post-processor 43 may also filter the labels to remove redundant labels, assemble the labels according to a known label hierarchy, or ignore labels known to be less important according to a hierarchy or weighted value. The post-processor 43 may aggregate the labels over time to calculate the start (onset) and end (offset) times of each anomaly. The post-processor 43 may be a standalone component or a subcomponent of the classifier 41.

[0076]

[0122] 4, the information generated at the backend 46 by the ECG platform 37 at steps 54, 56, 58, and 61, and optionally at step 63, may be communicated by the ECG platform 37 to the ECG application 29 on the frontend 45. The ECG application 29 may cause this information to be displayed on the display 17 of the system device 14 at step 65. The information generated at the backend 46 may be automatically transmitted by the ECG platform 37, or the ECG platform 37 may store the information on the server 15 until requested by the ECG application 29. As data is generated, the ECG platform 37 may send a message to the ECG application 29 informing the ECG application 29 that data is available from the ECG platform 37.

[0077]

[0123] As described in U.S. Patent Application Publication No. 2020 / 0022604, the entire contents of which are incorporated herein by reference, ECG application 29 may receive and cause system device 14 to display data (e.g., raw ECG data, preprocessed ECG data, wave information, labels, and other data generated during steps 54, 56, 58, 61, and / or 63). Specifically, the '604 application describes that ECG signals, features of the ECG signals, and / or descriptors of the ECG signals may be displayed in an interactive manner as a multi-field display.

[0078]

[0124] 8, an exemplary display is shown, an interactive display 101. The interactive display 101 includes a first side 102 and a second side 103. The first side 102 further includes a second graphics window 105 and a first graphics window 104 having a plot 110 that includes data corresponding to an ECG signal. The first graphics window 104 includes the plot 110 that provides a global view of the ECG signal.

[0079]

[0125] Referring to FIG. 9, a close-up of the first graphic window 104 is shown. In this exemplary display, the plot 110 is a heart rate density plot (HRDP) that represents RR intervals (the interval between two QRS complexes) over time. As shown in FIG. 9, the upper region of the first graphic window 104 includes a number of label buttons 109. Proximate each label button 109 is text that describes the associated label. Each label button 109 has an associated color, so that when a user selects a label button 109, a graphic portion 111 is displayed on the plot 110 that visually indicates the presence of an episode and / or event that corresponds to the label associated with the label button 109. This provides a visual reference for the user and allows them to easily identify a category of a particular event and / or episode along the cardiac signal. In the exemplary display shown in FIG. 9, secondary labels 112 are included. In this exemplary display, the secondary labels 112 include the pulsatile labels PVC (premature ventricular contraction) and PSVC (premature supraventricular contraction). However, other secondary labels may be included. The points in plot 110 associated with the labels PVC and PSVC are colored, as indicated by the presence of points of a color other than black in FIG.

[0080]

[0126] The first graphic window 104 further includes a time bar 115 parallel to the time axis of the plot 110. The time bar 115 provides a linear representation of the total ECG acquisition time, with periods associated with episodes or events represented as colored segments. As shown in FIG. 9, dark grey zones on the time bar 115 correspond to periods of noisy signals (e.g., when the signal contains too many artifacts for the analysis algorithm to suggest contour extraction and proper detection). The first graphic window 104 further includes an interactive cursor 116. A user using the ECG application 29 can move the interactive cursor 116 along the time bar 115 to navigate within the plot 110 along the total ECG acquisition time. In the lower right corner of the first graphic window 104, a second interactive means 117 is provided, configured to zoom in and out of the plot 110.

[0081]

[0127] Returning to FIG. 8 , the second side 103 includes a plurality of episode plots 106. Each episode plot 106 displays at least one segment of an ECG strip corresponding to a detected episode and may also include text regarding duration (e.g., “Duration: 1 hour 38 minutes”) and / or start time of the episode (e.g., “Day 3 / 09:39:30”). Each episode plot 106 includes a third interactive icon 108 for selecting the corresponding episode plot to be included in the report. Each episode plot 106 further includes a fourth interactive icon 107 that allows the user to remove the respective ECG plot from the interactive display 101. The second side 103 may further include text describing one or more of the episode plots 106.

[0082]

[0128] The interactive display 101 further includes a graphics window 105 that includes an ECG strip 118 within a second time window beginning at a time point selected by the cursor 116. The second graphics window 105 further includes an ECG strip 119 within a third time window having a size equal to or greater than the second time window. The third time window includes a shaded portion that corresponds to the second time window.

[0083]

[0129] 10, a similar display, interactive display 121, is shown. Interactive display 121 includes a first side 122 and a second side 123. First side 122 further includes a first graphic window 124 and a second graphic window 125. Second side 113 has the same functionality as second side 103 described above, and includes an episode plot 126 similar to episode plot 106. Second graphic window 125 further has the same functionality as second graphic window 105, and includes an ECG strip 138 and an ECG strip 139 similar to ECG strip 118 and ECG strip 119.

[0084]

[0130] First graphics window 124 is similar to first graphics window 104 with the exception of plot 130. Like first graphics window 104, first graphics window 124 includes a plurality of label buttons 129 having the same functionality as plurality of label buttons 109, a secondary label 132 having the same functionality as secondary label 112, a time bar 135 and cursor 136 having the same functionality as time bar 115 and cursor 116, and a second interactive means 137 having the same functionality as second interactive means 117. Unlike plot 110, plot 130 is a heart rate density plot, which is a projection of a heart rate density histogram as a function of time onto a bivariate intensity plot.

[0085]

[0131] 11, a procedure is provided for generating and graphing a heart rate density plot, such as plot 130. In step 141, the ECG platform 37 calculates the RR intervals in the cardiac signal (i.e., the ECG data). For example, the ECG platform 37 may apply the cardiac signal to a contour extraction neural network to determine the RR intervals, as described above. In step 142, the ECG platform 37 may generate a heart rate plot over time. An example heart rate plot, HRDP 150, is shown in FIG. 12.

[0086]

[0132] As shown in Figure 12, time is projected along the x-axis and heart rate (e.g., beats per minute) is projected along the y-axis. In one embodiment, both time and heart rate are linearly scaled. However, time and / or heart rate may also be logarithmically scaled or scaled using other well-known scales. For simplicity, only four heart beats are shown in Figure 12.

[0087]

[0133] Returning to FIG. 11, in step 143, the ECG platform 37 divides the y-axis and x-axis into primitives called HR bins and time bins, respectively. For example, FIG. 12 shows HR bin 151 and time bin 152. HR bin 151 is a bin that is used to divide first and second heart rate values ​​(e.g., h b 1 and h b 2 ) Similarly, the time bins 152 are defined by first and second time values ​​(e.g., t b 1 and t b 2 ) The intersection of an HR bin and a time bin is called a bin. That is, a bin is defined by a first and a second heart rate value and a first and a second time value. FIG. 12 shows bin 153 defined by HR bin 151 and time bin 152.

[0088]

[0134] Returning to FIG. 11, in step 144, the ECG platform 37 assigns each heart beat to a bin. Specifically, heart beats (e.g., QRS complexes) occurring during the time window of a given time bin are included in the calculation of the column corresponding to that time bin. Furthermore, the heart rate corresponding to that heart beat determines which HR bin it belongs to within the column defined by the time bin. For example, in FIG. 12, heart beats 154 and 155 have corresponding time and heart rate values ​​that fall within time bin 152 and HR bin 151, respectively. Meanwhile, heart beats 156 and 157 have time values ​​that fall outside time bin 151, and therefore neither falls within bin 153.

[0089]

[0135] Returning to FIG. 11, in step 145, the ECG platform 47 calculates the heart rate density for each time bin. For a given bin, the area defined by the respective time bin and heart rate bin is represented according to the density of heart beats contained in the bin (i.e., the number of heart beats in the bin). Each bin may be colored according to the density. For example, each bin may have a particular shade or pattern, such as a gray level. In the example shown in FIG. 12, the bins may be represented as gray levels that become darker as the density of heart beats increases. As shown in FIG. 12, a bin 153 that contains two heart beats may be represented in a darker gray than a bin that contains only one heart beat and in a lighter gray than a bin that contains three or more heart beats.

[0090]

[0136] In a preferred embodiment, density is calculated as a function of the number of R waves in a bin divided by the heart rate of the HR bin (e.g., the average of the minimum and maximum boundaries of the time window). This preferred density calculation takes into account the time spent in a particular bin. For example, in a 3-minute time bin, if 100 heart beats of 50 bpm (beats per minute) occur in the first HR bin and 100 heart beats of 100 bpm occur in the second HR bin, there will be the same number of heart beats in each bin, but they will spend 2 minutes at 50 bpm and only 1 minute at 100 bpm. Thus, if only the number of beats is considered, the bins will have the same density representation. However, if the number of beats divided by the heart rate is considered, the first bin corresponding to the 50 bpm heart rate bin will be darker than the bin corresponding to the 100 bpm heart rate bin, since dividing by the heart rate gives a higher weight to the lower heart rate values. Therefore, the preferred embodiment captures this time information better than considering only beat count.

[0091]

[0137] 11, in step 146, the ECG platform 37 plots the heart rate density for each bin. By capturing the time information in columns (time bins) in addition to the time information naturally given as a function of the x-axis, the density can be more easily represented in a manner superior to other forms of aggregate representations of the ECG signal, such as the HRDP plot in plot 110.

[0092]

[0138] The x-axis boundaries of the HR density plot may be the start and end of the signal. However, in a preferred embodiment, the x-axis boundaries may change interactively in response to zooming and zooming actions by the user. When this action is performed, the y-axis boundaries remain fixed. Returning to FIG. 10, the plot 130 includes interactive means 137 that can be used to zoom in on the HR density plot. The zooming action may only change the size of the plot display. Alternatively, zooming in and zooming out changes the size of the time window corresponding to the time bins. With the zooming action, the bins represented by the same number of pixels occupy a shorter time window. Thus, when zooming in, a new histogram is calculated at a finer time interval, resulting in finer time information. This allows for a representation of the ECG signal that shows a variable level of information aggregation as a function of the time scale of the display selected by the user, resulting in a histogram that is easy to read and rich in information at any zoom level. Referring to FIG. 13, an interactive display 170 is shown, which is an interactive display similar to the interactive display of FIG. 10. Interactive display 170 has been zoomed in such that a portion 158 of plot 159 is displayed in a magnified manner.

[0093]

[0139] 14A-14E show the superiority of HRDP over a typical RR plot. With reference to FIG. 14A, a signal generated by a Holter with a very large number of PVCs with variable connectivity is shown as RR plot 161 and density plot 162. In density plot 162, the underlying rhythm is clearly displayed as line 171. Additionally, the transfer rest is shown as the bottom line 172. In RR plot 161, this pattern is less clear. With reference to FIG. 14B, a signal generated by a Holter with fewer premature waves than that of FIG. 14A is shown as RR plot 163 and density plot 164. The dominant rhythm is clearly displayed in density plot 164, but is less clear in RR plot 163. With reference to FIG. 14C, a signal generated by a Holter with variable conduction flutter is shown as RR plot 165 and density plot 166. As shown in FIG. 14C, the conduction flutter is highlighted by the four distinct black lines in density plot 166 rather than the four blurry clouds displayed in RR plot 165. Referring to FIG. 14D, the signal generated by a Holter with persistent atrial fibrillation is shown as RR plot 167 and density plot 168. As shown in this figure, density plot 168 provides more accurate information about the heart rate fluctuations during fibrillation. Specifically, the darker lower half 173 indicates that more time is spent at lower heart rates than at higher heart rates. Density plot 168 further shows a slightly darker spike in the upper half corresponding to the increased heart rate. These nuances are not visible in RR plot 167. Referring to FIG. 14E, the signal generated by a Holter with paroxysmal atrial fibrillation but an otherwise regular rhythm is shown as RR plot 174 and density plot 175. The regular rhythm pattern is more noticeable in density plot 175 where the distinct black lines appear. The atrial fibrillation pattern also changes color (the plot becomes lighter with decreasing density), so that density plot 175 has more contrast than RR plot 174.

[0094]

[0140] Returning to FIG. 4 , in step 66, a user using the ECG application 29 can use the input device 25 to interact with the interactive active display to request and / or customize a report. The report typically includes a portion of the cardiac signal and may include information about anomalies and / or episodes (e.g., episode plots) and / or other information generated during pre-processing (step 54), contour extraction (step 56), classification (step 58), clustering (step 63), and / or post-processing (step 61). The report may further include patient-specific medical data, such as the patient's name, age, medical history, and / or other medical information. Personally identifiable health information and / or protected health information may be encrypted when communicated between the ECG application 29 and the ECG platform 37.

[0095]

[0141] As discussed above, the report can incorporate display data and images using interactive icons in the interactive display. For example, a user using the ECG application 29 can select the third interactive icon 108 to include a corresponding episode plot in the report. Thus, in step 66, a user can request a report and select customized features, such as specific data to include in the report (e.g., anomaly data, episode data, episode plot, etc.).

[0096]

[0142] At step 67, the ECG application 29 may send a request for a report and selected customizable features (e.g., ECG data to include in the report) to the ECG platform 37, which may receive the request and information. The ECG platform 37 may log the request and store the information received from the ECG application 29. At step 68, the ECG platform 37 may cause the report generator 44 to generate a report 69 based on the information received from the system ECG application 29.

[0097]

[0143] 15A-15D, an example report generated in step 68 is shown. The first page of the example report is shown in FIG. 15A. The first page may be presented in multiple sections, such as a first section 181, a second section 182, a third section 183, a fourth section 184, a fifth section 185, and a sixth section 186. The first section 181 may include patient specific information, such as, for example, the patient's name, primary indication, whether or not a pacemaker is present, the patient's date of birth, gender, and / or patient ID. The second section 182 may include clinician information, such as, for example, the supervising physician, the name of the laboratory, the date of analysis, and / or a signature.

[0098]

[0144] A third section 183 may include plots of the ECG data. In FIG. 15A, section 183 includes a heart rate density plot similar to that shown in FIG. 12. The time window displayed may be a default time or may be a user-defined time window. As with the heart rate density plot shown in FIG. 12, specific labels may be selected to indicate the occurrence of anomalies on the density plot. The time window is typically selected according to the associated episode and / or event. However, other plots such as RR plots may also be included in the report.

[0099]

[0145] The fourth section 184 may include metrics from the cardiac signal recording. For example, the fourth section 184 may include duration of the recording, maximum heart rate, minimum heart rate, average heart rate, supraventricular extrasystoles, patient triggered events, and / or other metrics related to the cardiac signal. The fifth section 185 may include information corresponding to the detected episodes. For example, the fifth section 185 may include pause information (count and / or longest RR interval), atrioventricular block information, atrial fibrillation / flutter information, ventricular tachycardia information, other supraventricular tachycardia information, and / or other information related to the episode or abnormality. The sixth section 186 may include outcome information, such as, for example, a summary of the episode and / or abnormality, a diagnosis, and / or other information analyzed, aggregated, calculated, determined, identified, or otherwise detected from the cardiac signal. For example, the sixth section 186 may identify a sinus rhythm with paroxysmal atrial fibrillation.

[0100]

[0146] 15B-15D show pages 2, 3, and 4 of an example report. As shown in FIG. 15B-15D, the report may further include ECG strips previously selected by the user or selected by default. For example, the user may select a maximum HR strip 191, a minimum HR strip 192, an atrial fibrillation / flutter strip 193, an other SVT strip 194, a PSVC strip 195, and a PVC strip 196. The maximum HR strip 191 may be an ECG strip indicating the maximum heart rate during a given cardiac signal recording. Similarly, the minimum heart rate strip 191 may be an ECG strip indicating the minimum heart rate during a given cardiac signal recording. The atrial fibrillation / flutter strip 193 may be an ECG strip indicating each episode of atrial fibrillation / flutter. The other SVT strip 194 may be an ECG strip indicating each episode of supraventricular tachycardia. The PSVC strip 195 may be an ECG strip indicating an episode of supraventricular premature contractions. The PVC strip 197 may be an ECG strip indicating episodes of premature ventricular contractions. The ECG strip may be displayed with associated indicators and comments added by the user. The reports shown in Figures 15A-15B are merely examples and the reports generated in step 68 may have a different structure or configuration and / or include different ECG and patient related information as contemplated herein.

[0101]

[0147] 16-21C, the illustrated platform may be used by a user (e.g., a physician, a healthcare provider, a technician) to efficiently determine critical data, identify billable actions, tasks, and / or processes, and to label and / or categorize specific actions, tasks, and / or processes for an electronic medical record (EMR) system. The platform may be used to triage data (e.g., categorize the criticality of data), receive and / or determine clinical decisions (e.g., writing a prescription, making an appointment, etc.), and determine specific billing information corresponding to the data (e.g., whether or not billing requirements for an ILR monthly report have been met). This allows a physician, healthcare provider, and / or technician to bill for time associated with the ILR and / or follow-up of the wearable device. Additionally, the platform may generate reports that may be used to document specific tasks and / or actions for an EMR. The platform and tasks and operations described in connection with FIG. 16-21C may be performed by the ECG platform 37 shown in FIG. 3B.

[0102]

[0148] 16, an example process for associating an implantable loop recorder (ILR) and / or a wearable device (e.g., a smart watch) with a patient profile on a platform is shown. For example, process 801 may be used by the platform to determine ECG data from the ILR and / or wearable device, associate the ECG data from the ILR and / or wearable device with the patient profile, and determine alerts and / or reports corresponding to the data.

[0103]

[0149] At block 802, a patient profile may be determined. For example, a user (e.g., a physician, healthcare provider, and / or technician) may generate a profile for a particular patient. At block 804, the patient's ILR and / or wearable device may be connected and / or associated with the patient profile to periodically transmit data from the ILR and / or wearable device to the platform and / or share such data with the platform.

[0104]

[0150] The platform may receive the data from the ILR and / or wearable device, archive the data on a server, and associate the data with a patient profile in block 806. For example, a server running the platform may receive the data from the ILR and / or wearable device, determine that the device is known and associated with a user profile based on a device identifier or a user identifier, and archive the data in association with the user profile.

[0105]

[0151] In optional block 808, the platform may optionally display a list of the data, as well as alerts and / or reports based on the data. The platform may automatically generate alerts after processing the data using techniques described herein (e.g., contouring, classification, clustering, etc.). The platform may also generate reports corresponding to the data described herein, automatically and / or at the user's direction. In optional block 810, the platform may display options for editing the patient information and / or other information in the patient profile. For example, the user may change the arrangement of the alerts and / or data displayed in optional block 808.

[0106]

[0152] Referring to FIG. 17A, an example of a process for determining data from an implantable loop recorder (ILR) and / or a wearable device (e.g., a smart watch), determining whether the data is critical, and determining to perform a particular action with respect to the data is shown. In block 812, the platform may determine ECG data (e.g., from an implantable loop recorder (ILR) and / or a wearable device (e.g., a smart watch)). This may be the same step as step 806 of FIG. 16. In block 814, the data may be analyzed and / or prioritized. For example, multiple strips of the ECG may be determined and assigned labels as described herein (e.g., using contour extraction, classification, clustering, etc.). As shown in FIG. 17A, the ECG data may be determined to be normal or critical. The normal and / or critical labels may be determined using algorithms and techniques described herein, the patient's medical history, and / or the physician's preferences. In optional block 816, the ECG data may be displayed based on the determination made in block 814. For example, ECG strips may be labeled as either critical or normal, and a user may select to display critical and / or normal ECG strips.

[0107]

[0153] If, at decision 818, the ECG data is not significant, then in optional block 820, the platform may (e.g., automatically and / or at the user's direction) generate a report for the EMR documenting the significant ECG data. This may include generating a report as described herein. In an optional block, the platform may decide to classify the analyzed and / or prioritized ECG data as completed. In optional block 822, the platform may further determine that the ECG data that was initially classified as normal is significant based on feedback from the user. For example, the user may see a displayed ECG strip classified as normal and indicate to the platform that the ECG is significant. In optional block 826, the user may change one or more diagnoses for the ECG data.

[0108]

[0154] On the other hand, if the ECG data is significant at decision 818, then in optional block 828 the platform may (e.g., automatically and / or at the user's direction) generate a report for the EMR documenting the significant ECG data. This may include generating a report as described herein. In optional block 829, the platform may determine (e.g., based on feedback from the user) that the ECG data is not significant. In optional block 830, the platform may further determine to mark the analyzed and / or prioritized ECG data and / or events corresponding to such data as closed. For example, a user may view a displayed ECG strip classified as significant and instruct the platform to mark the events and / or data as closed. In optional block 831, the user may change one or more diagnoses for the ECG data.

[0109]

[0155] Referring to FIG. 17B, an example of a data flow for determining ECG event data, determining alarms, and applying the data to the EMR is shown. As shown in FIG. 17B, the wearable device ECG events and / or ILR ECG events may be communicated to an ECG platform 833. This platform may be the same as the ECG processing system 10 and / or the ECG platform 37. For example, the ECG processing system 10 and / or the ECG platform 37 may include an algorithmic triage module 836 that can determine whether the ECG data and / or events are normal or significant. As discussed above in connection with FIG. 17A, an event may be normal even if there is noise. The ECG platform may process the ECG events (e.g., ECG data) and classify them as significant if they are abnormal (e.g., atrial fibrillation).

[0110]

[0156] Based on the data received by the ECG platform 836, true alarm events 837 and / or false alarm events 838 may be determined. For example, the ECG platform 836 can analyze the wearable device ECG events 831 and / or ILR ECG events 832 using techniques described herein (e.g., contour extraction, classification, clustering, etc.). A true alarm event may correspond to the ECG platform correctly classifying the ECG event and / or data. A false alarm event may correspond to the ECG platform incorrectly classifying the ECG event and / or data (e.g., based on user feedback). The true alarm events and / or false alarm events may be used by the reporting module 839 to update the EMR 841 or have the EMR 841 incorporate this information.

[0111]

[0157] True alarm events may be used by the platform to generate items 834 including event reports and / or clinical action items. For example, the ECG platform 833 may generate a report on significant ECG events. The report may include an ECG strip. Additionally or alternatively, the ECG platform may determine clinically actionable items and / or recommended actions (e.g., in the form of messages and / or alerts). Information in items 834 may be used by and / or incorporated into the EMR 835.

[0112]

[0158] Referring to FIG. 18, an example process for determining, prioritizing, and doctor signing a report from data from an implantable loop recorder (ILR) and / or a wearable device (e.g., a smart watch). In block 852, ECG data (e.g., from the ILR and / or wearable device) may be determined. This may be the same step as step 812 of FIG. 17A. In optional block 854, the ECG data (e.g., from the ILR and / or wearable device) may be archived and / or otherwise stored (e.g., on a server). The data may be associated with a patient profile. In block 862, strips of archived ECG data may be determined. For example, a number of strips over a period of time may be determined (e.g., 30 strips for 30 days). In optional block 864, a report may be generated based on the ECG data (e.g., having a smaller number of FPs).

[0113]

[0159] At block 866, the report generated (e.g., at block 864) may be classified as high or low priority. Priority may be based on the presence or absence of critical information. The report may include billing information and / or requirements, all ECG strips over a given time period, and / or specific trends (e.g., HR trends). Alternatively, or in addition, a physician may review the report and determine a priority designation (e.g., high or low). At optional block 870, the report may be displayed and an instruction to sign the report may be received by the platform. At optional block 872, the platform may determine billing information and / or corresponding EMR information based on the report and / or data within the report. At optional block 874, billing may be performed based on the information in the report and / or the EMR may be updated such that relevant information in the report is applied to or otherwise incorporated into the EMR.

[0114]

[0160] 19A-19C, an example ILR / wearable device event report is shown. As shown in FIG. 19A-19C, the report may include patient information and ECG strips for various events (e.g., atrial fibrillation, sinus rhythm, etc.). The report shows a monthly summary, but other time frames may be included in the report. The physician may add comments and / or sign the report.

[0115]

[0161] 20, an example of an ILR / wearable device event report is shown. The ILR event report may include information such as a patient summary (e.g., primary indication, etc.) and / or an event ECG strip.

[0116]

[0162] 21A-21C, examples of monthly report and event list user interfaces are shown. As shown in FIG. 21A, the monthly report may include a list of reports identified as critical and / or normal. Each event may include the patient's name, date of birth, indication, event classification and / or description, and / or other information (e.g., event data). As described above with respect to FIG. 18, each report may be viewed and / or signed by a user. As shown in FIG. 21B, the platform may display an event list of events classified as critical and / or normal. Each event may include the patient's name, date of birth, indication, event classification and / or description, and / or other information. The invention list may include one or more ECG strips for displaying the events. Each event in the event list may include options to download, archive, and / or change priority of the report. As shown in FIG. 21C, to simplify the display, the event list may optionally include only the patient's name, date of birth, indication, event classification and / or description.

[0117]

[0163] 22A-22B, examples of a user registration interface and a profile interface are shown. As shown in FIG. 22A, the example user registration interface can be used to add a patient and generate a user profile including a user name, date of birth, gender, contact information, medical history, devices, etc. As shown in FIG. 22B, the example user profile can include patient information, medical history information, device information, event history, and report history, etc.

[0118]

[0164] 23A-B, an example of an event interface and an example process for reclassifying the event interface are shown. FIG. 23A shows an event interface 900. The event interface 900 may display a portion of the ECG signal where an event was detected (e.g., using one or more approaches described herein). The event interface 900 may include a heart rate indicator 901 that may display a detected or estimated heart rate corresponding to a point or interval of the ECG signal, or may display an average, minimum, or maximum heart rate. Additionally, the event interface 900 may include an event duration 902 that corresponds to the event onset and event offset. Other relevant information (e.g., QTc) may be displayed within the event interface 900. Such information may be based, for example, on the contour extraction analysis described herein.

[0119]

[0165] FIG. 23A may further include a classification box 904 and a reclassification menu 906. The classification box 904 may display one or more classifications (e.g., status, abnormality, descriptor, etc.) associated with the ECG signal. For example, the classification box 904 may display "Sinus rhythm detected." The reclassification menu 906 may include a menu of selectable options for reclassifying events detected in the ECG signal. For example, the reclassification menu may include one or more of low heart rate, high heart rate, pause, AV block, PSVC, atrial fibrillation, atrial flutter, other SVT, PVC, VT, long QT, or other conditions or abnormalities. The reclassification menu 906 may further include additional classifications such as "inconclusive" and / or "bad reading." Events identified in the event interface 900 may be reclassified by selecting an abnormality, status, or other information in the reclassification menu 906. The reclassified events may be used to train the algorithms, neural network architectures, and models used to originally classify the events.

[0120]

[0166] Referring to Figure 23B, an example process is shown for generating (e.g., by an ECG platform) an event interface that includes a classification of an event and reclassifying the event based on the event interface. Some or all of the blocks of the process in Figure 23B may be distributed and performed among any number of devices (e.g., computing devices and / or servers). Some or all of the operations of the process in Figure 23B may be optional and may be performed in a different order.

[0121]

[0167] In a first step 903 of the process shown in FIG. 23B, ECG data is determined and / or obtained from an ECG sensing device (e.g., an ILR). In step 905, the ECG data may be processed using an algorithm to determine the presence of one or more abnormalities, conditions, or descriptors corresponding to an event (e.g., a cardiac event, an ECG event, and / or other physiological event). In step 907, one or more classifications corresponding to the event are determined using an algorithm. For example, a classification of "sinus rhythm" may be determined based on the presence of one or more abnormalities, conditions, or descriptors.

[0122]

[0168] In step 909, an event interface may be generated that indicates (e.g., displays) the classification determined in step 907 and / or the cardiac event. For example, the event interface may display "sinus rhythm" and may include a representation of an ECG signal corresponding to the event. In step 911, input regarding the classification may be received. For example, a system device (e.g., a healthcare provider's device) may present the event interface, and the healthcare provider may send a message regarding the classification (e.g., a message regarding the accuracy of the classification) to the ECG platform.

[0123]

[0169] In step 913, the cardiac event may be reclassified based on the received input. For example, the input may indicate that the classification determined in step 907 was not accurate and may even identify a new classification. The new classification may be used to reclassify the event. In optional step 915, an event interface may be generated that indicates the reclassification determined in step 913. In optional step 917, the algorithm used to process the ECG data in step 905 may be trained and / or modified based on the reclassification. Event interfaces and reclassification are described in more detail below with reference to Figures 31E-31F.

[0124]

[0170] An example of an ECG signal having color bands is shown in FIG. 24. Specifically, ECG display 910 may be a portion of the ECG signal displayed in the event interface shown in FIG. 23A and / or any other display of an ECG signal and may include color indicators 912, 914, and 916. Color indicator 912 may be any color and / or pattern different from color indicators 914 and 916, for example, may indicate that this portion of the ECG signal corresponds to a p-wave. Color indicator 914 may be any color and / or pattern different from color indicators 912 and 916, for example, may indicate that this portion of the ECG signal corresponds to a QRS complex. Color indicator 916 may be any color and / or pattern different from color indicators 912 and 914, for example, may indicate that this portion of the ECG signal corresponds to a T-wave. Any color or pattern may be used to distinguish the various portions of the ECG signal. Additionally, the color indicators can be used to indicate any portion and / or feature of the ECG signal (e.g., hidden p-waves, QT intervals, ST segments, RR intervals, TP segments, and PR segments). The color indicators can be based on contour extraction analysis and / or other analyses described herein.

[0125]

[0171] 25A-25C, examples of systems and processes for multi-device ECG processing are shown. Referring to FIG. 25A, an ECG processing system 920 may include a server 922, a drive 924, a mobile device 927, a system device 928, a sensing device 930, and a sensing device 932. The server 922 may be the same as or similar to the server 15 described above with respect to FIG. 2 and may run an ECG platform (e.g., the ECG platform 37 described above with respect to FIG. 3A). The drive 924 may be the same as or similar to the drive 16 described above with respect to FIG. 2. The system device 928 may be the same as or similar to the system device 14 described above with respect to FIG. 2. The sensing device 930 and / or the sensing device 932 may be similar to the sensing device 13 described above with respect to FIG. 2. The drive 924 may be incorporated into the server 922 or may be separate from the server 922 and / or may communicate with the server 922 via a well-known wireless or wired connection. The system device 928 may communicate with the server 922, the sensing device 930, and / or the sensing device 932 via any well-known wireless or wired connection. Additionally, the sensing device 930 and / or the sensing device 932 may communicate with the server 922 and / or the system device 928 via any well-known wireless or wired connection. Optionally, the sensing device 930 and the sensing device 932 may communicate with the mobile device 927 via any well-known wireless or wired connection. The mobile device 927 may also communicate with the system device 928 and / or the server 922 via any well-known wireless or wired connection. Any other elements of the ECG processing system 920 may also communicate via well-known wireless or wired connections.

[0126]

[0172] Sensing device 930 and sensing device 932 may be any type of device for sensing cardiac electrical activity, generating ECG data (e.g., ECG signals), and / or generating other biometric or physiological data (e.g., heart rate, temperature, movement, oxygen level (SpO2), respiration rate, humidity, blood pressure, etc.). Sensing device 930 and sensing device 932 may be the same device or different devices. For example, sensing device 930 may be a smart watch worn by user 925, and sensing device 932 may be an implantable ECG recording device (e.g., an ILR). Although only two sensing devices are illustrated in FIG. 25A, processing system 920 may include more than two devices. Sensing devices may include other wearable and / or implantable devices.

[0127]

[0173] The sensing devices 930 and 932 can generate sensed data (e.g., ECG data and / or other biometric or physiological data) and transmit such data directly or indirectly to the server 922. For example, the sensing devices 930 and 932 can transmit data to the mobile device 927, which can transmit data to the server 922. Alternatively, or in addition, the sensing devices 930 and 932 may transmit data directly to the server 922 or transmit data to the server 922 via a computing device, such as the system device 928. Upon receiving the sensed data, the server and / or drive 924 can analyze the data using one or more approaches or techniques described herein (e.g., process the sensed data to determine anomalies, abnormalities, or conditions). The system device 928 can be used to analyze the sensed data on the server 922, as well as to otherwise oversee the processing and analysis of the data.

[0128]

[0174] The mobile device 927 may be any type of device, such as a smartphone (as a non-limiting example). The sensing device 930 and the sensing device 932 may transmit data (e.g., ECG data, heart rate data, and / or other data determined and / or acquired by the sensing device 930 and the sensing device 932) to the mobile device 927 and / or the server 922. The mobile device 927 may execute a mobile application that communicates with an application executed on the server 922, may receive results of an analysis performed by the server 922 or a user associated with the server 922, and / or may present these results through a user interface associated with an application installed on the mobile device. For example, the user's smartphone may receive data from a smartwatch worn by the user. The user's smartphone may transmit data to the server and access data from the server and / or results of the analysis performed on the server. The mobile device 927 may also display other types of information, such as data received from the sensing device 930, the sensing device 932, and / or other sensing devices. Please note that this is just one use case and is not intended to be limiting.

[0129]

[0175] As shown in FIG. 25A, a drive 924, which may be incorporated into the server 922, may maintain a database, such as database 926, to track various types of sensed data received from various sensing devices (e.g., sensing device 930 and sensing device 932). For example, the database 926 may assign a name (e.g., file name) to each data received, associate the file name with a user or user account (e.g., patient number), and identify the device that provided and / or generated the data and the type of data (e.g., heart rate (HR), SpO2, ECG, etc.). The ECG processing system 920 may include one or more sensing devices 930, one or more sensing devices 932, and / or a combination of one or more sensing devices 930 and 932. The sensed data generated by the sensing devices and received by the server may be data other than ECG data, such as heart rate, respiration rate, and other non-ECG data.

[0130]

[0176] Referring to FIG. 25B, a process of analyzing ECG and other data generated by a multi-device system to determine conditions, abnormalities, and / or descriptors is shown. To begin the multi-device process 935 (e.g., on an ECG platform), in step 937, ECG data is acquired and / or determined from a sensing device over a given time period (e.g., at a given sampling rate). In step 939, sensor data is acquired and / or determined from a different sensing device (e.g., a smart watch or other sensing device) over a given time period. The sensor data can be any type of well-known physiological or biometric data (e.g., heart rate, SpO2, respiration rate, etc.). In one example, the sensor data is generated by a photoplethysmogram (PPG) sensor. The sensor data and ECG data may be the same or overlap in time period, even if the sampling rates are different.

[0131]

[0177] In optional step 941, the ECG data and sensor data may be stored in a cataloged or otherwise organized format (e.g., in a database), and the ECG data and sensor data may be associated with the device from which the data originated, the type of data, a file number, and / or other information related to the ECG data and / or sensor data. In step 943, the ECG data and sensor data may be processed using algorithms to determine the presence of one or more anomalies, conditions, and / or descriptors corresponding to events (e.g., cardiac events, ECG events, and / or other types of physiological events). For example, the sensor data and / or ECG data may be analyzed and / or processed using techniques and / or algorithms similar to those described above (e.g., techniques and / or algorithms described above with respect to FIG. 4). The various algorithms, neural networks, and models (e.g., delineators and classifiers) described above may be trained and / or otherwise designed to process both ECG data and other sensor data.

[0132]

[0178] At step 945, information may be generated that indicates the presence of one or more anomalies, conditions, or descriptors corresponding to the event. For example, such information may be used to generate a display on a system device and / or generate a report regarding the one or more anomalies, conditions, or descriptors. At step 947, the information generated at step 945 may be communicated to a system device and displayed. For example, the information may be transmitted to or otherwise accessed by a healthcare provider device and displayed on the healthcare provider device.

[0133]

[0179] Referring to FIG. 25C, a process 2500 is shown for receiving and displaying ECG and / or other data (e.g., heart rate data) generated by one or more devices. To begin process 2500 (e.g., on an ECG platform), optional step 2502 may obtain and / or determine ECG data from a sensing device. Step 2504 may obtain and / or determine sensor data from a different sensing device (e.g., a smart watch or other sensing device) and / or the same sensing device as the sensing device of step 2502. The sensor data may be any type of well-known physiological or biometric data (e.g., heart rate, SpO2, respiration rate, etc.). In one example, the sensor data is generated by a photoplethysmogram (PPG) sensor. Even if the sampling rates are different, the period during which the sensor data is generated and the period during which the ECG data is generated may be the same or overlap.

[0134]

[0180] In optional step 2506, the ECG data and / or sensor data may be cataloged or otherwise stored in an organized format (e.g., in a database). For example, the ECG data and / or sensor data may be associated with the device from which the data originated, the type of data, a file number, and / or other information related to the ECG data and / or sensor data. In step 2508, information corresponding to one or more anomalies, conditions, or descriptors corresponding to the event may be obtained and / or determined from the sensing device. For example, the sensing device may communicate information indicating the presence of atrial fibrillation. Optionally, the sensing device may communicate one or more symptoms or other health-related information corresponding to the patient. For example, the sensing device may communicate information indicating that the patient experienced palpitations.

[0135]

[0181] In step 2510, information may be generated that indicates the presence of sensor data, ECG data, and / or one or more abnormalities, conditions, or descriptors corresponding to the cardiac event. Optionally, information indicative of symptom data may also be generated. For example, such information may be used to generate and / or render a display for presentation on a device based on the information and / or may be used to cause a display to generate and / or render such a display. In step 2512, the information generated in step 2510 may be communicated to a mobile device and / or other computing device for display and / or presentation. For example, the information may be transmitted to a user's smartphone, and the user may view the information through a user interface of an application installed on the mobile device.

[0136]

[0182] Referring to FIG. 25D, a user interface 2520 for displaying ECG data, as well as other sensor and healthcare data, is shown. The user interface 2520 may display one or more plots 2522 including one or more data points 2524. The data points 2524 may be based on or represent heart rate data, ECG data, and / or other types of cardiac and / or healthcare data. For example, the plot 2522 may display data received from a sensing device associated with the user, such as a smartwatch and / or other type of sensing device from which heart rate data can be determined. The x-axis 2528 of the plot 2522 may represent time, and the y-axis 2530 of the plot 2522 may represent values ​​associated with the sensor and / or healthcare data (e.g., heart rate, ECG readings, etc.). The plot 2522 may also be associated with various notifications and / or alerts. Non-limiting examples of alerts include high and low heart rates, irregular rhythm, etc. The data of the plot 2522 may be determined by one or more sensing devices. Alerts and / or notifications may be visually indicated to the user through one or more indicator lines 2526 and / or other well-known visual techniques (e.g., markers, highlighting, symbols, etc.). The indicator lines 2526 may indicate to the user that a particular data point or group of data points indicates an anomaly, condition, or descriptor associated with the event. The color of the indicator line 2526 may correspond to the particular anomaly, condition, or descriptor. Notifications and / or alerts may be displayed in forms other than indicator lines. The data points 2524 of the plot 2522 may be filtered to allow the user to select to view only certain types of data (e.g., heart rate data, PPG data, ECG data, etc.).

[0137]

[0183] Additionally, a user may interact with the plot 2522. For example, a user may be able to zoom in to view a particular portion of the plot 2522 in more detail, select one or more of the data points 2524 to view additional information regarding the individual or group of data points, and / or perform other types of interactions with the plot 2522. For example, selecting a data point corresponding to a heart rate may generate a graphical representation of an ECG signal corresponding to that data point. It may not be necessary for a user to select a data point to display the additional information. For example, a user may simply hover a mouse cursor over a data point to display the additional information in a pop-up window and / or other format. Non-limiting examples of information include medical decisions based on ECG data, average heart rate, and the like. The type of information presented may vary depending on the type of data included in the plot 2522 (e.g., heart rate data, ECG data, and the like). A user may also be able to customize the type of information displayed. A user may also be able to manipulate the indicator line 2526 to view more specific information regarding an abnormality, condition, or descriptor associated with the indicator line 2526.

[0138]

[0184] The user interface 2520 may also present profile information 2532. For example, the profile information 2532 may include personal information associated with the user, medications prescribed to the user, information regarding identified or previously identified abnormalities or other symptoms associated with the user, and / or other types of relevant data as illustrated or otherwise indicated. It should be noted that the illustrated information is merely exemplary and is not intended to be limiting; that is, other relevant information may also be presented in the user interface 2520.

[0139]

[0185] 25E, a user interface 2535 is shown for displaying additional information related to individual ECG data points and / or other data points. The user interface 2520 may be the same as or similar to the user interface 2535. For example, a user may be able to select a data point 2537 (or a group of data points) to see additional information about the data point 2537 (or group of data points). Upon selection, a pop-up box 2539 containing this additional information may be displayed. As a non-limiting example, the pop-up box 2539 may include the time the data point 2537 was acquired and a value associated with the data point 2537 (e.g., if the data point 2537 is related to a heart rate measurement of the user, the pop-up box 2539 may present the numerical value of the heart rate measurement associated with the data point 2537). It should be noted that the information may be displayed in forms other than a pop-up box. It may also be possible that the user does not need to "select" the data point 2537 to display the additional information. For example, a user can simply hover the mouse cursor over data point 2537 to view the information.

[0140]

[0186] Referring to FIG. 25F, a user interface 2536 for displaying a graphical representation of ECG data associated with one or more ECG data points and / or other data points is shown. The user interface 2536 may be the same as or similar to the user interface 2520 of FIG. 25D. For example, a user may select a data point (e.g., an ECG data point) in the user interface shown in FIG. 25D to view additional ECG information related to such data, and a user interface 2536 may be generated to display an ECG representation associated with the selected data. The ECG representation may be generated from the data used to create the user interface shown in FIG. 25D and / or may be received from one or more sensing devices. The user interface 2536 may further include information about the patient (e.g., name, age, sex), identified abnormalities, conditions, events, descriptors, symptoms, heart rate, and other ECG characteristics (e.g., QT value, QTcB value, and / or QRS value for the selected data and / or ECG representation).

[0141]

[0187] 25G, a mobile device 2540 is shown displaying a mobile interface 2542. The mobile device 2540 may be any type of computing device having a processor and a display and in communication with a server running an ECG platform (e.g., ECG platform 37 described above with respect to FIG. 3B). The mobile device 2540 may have the same or similar components as those described above with respect to FIG. 3A. For example, the mobile device 2540 may run an application (e.g., a local application) and display a mobile interface 2542 on the mobile device 2540. The mobile interface 2542 may include, for example, sensing wear information 2544 (e.g., the length of time the user has worn the sensing device), sensing device data 2546, and / or other related information. For example, the wear data 2546 may be used to indicate to the user how long the user has worn the sensing device (e.g., a smart watch or other device). This may encourage the user to wear the sensing device for a longer period of time to obtain more data. Sensing device data 2544 may provide information regarding data acquired by one or more sensing devices, such as plots of acquired data over time, indications of abnormalities or other conditions, averages of data acquired over time, and / or other information. For example, the data may include heart rate data, ECG data, and / or other types of data that may be acquired by a sensing device. This data may be acquired from one or more sensing devices and / or a server running an ECG platform. For example, the data may be acquired by a sensing device and provided to the mobile device 2540 and provided by the mobile device 2540 to a remote location for further processing. A healthcare provider may then analyze the data and provide the analysis results to the mobile device 2540 for display through the mobile interface 2542. The analysis may be facilitated by using any of the algorithms described herein.

[0142]

[0188] 26, a mobile device displaying a mobile interface is shown. The mobile device 930 may be any type of computing device having a processor and a display and in communication with a server (e.g., server 922) running an ECG platform (e.g., ECG platform 37 described above with respect to FIG. 3B). The mobile device 930 may have components the same as or similar to those described above with respect to FIG. 3A. For example, the mobile device 930 may run an application (e.g., a local application) and display a mobile interface 933 on the mobile device 930. The mobile interface 933 may include, for example, patient information 934, ECG information 936, and / or notification information 938.

[0143]

[0189] A server running the ECG platform may communicate all or a portion of the mobile interface 933 to the mobile device 930. For example, the mobile device 930 may communicate patient information 934, ECG information 936, and / or notification information 938 to the mobile device 930, which may be presented by an application running on the mobile device 930. Alternatively and / or additionally, the information presented on the mobile interface 933 may be stored locally on the mobile device 930. The patient information 934 may include information about the patient (e.g., date of birth, gender, indications, etc.). The ECG information 936 may include an ECG representation 936, which may be a representation of an ECG signal, such as a portion of a detected ECG event of the signal.

[0144]

[0190] Optionally, the ECG information 936 may include information regarding detected abnormalities, descriptors, and / or conditions. The notification information 938 may include a notification that the user has received a notification or message (e.g., from a healthcare provider and / or from an ECG platform running on a server). In one example, the notification may be a diagnosis or detected abnormality, condition, and / or anomaly determined by the ECG platform and / or healthcare provider. Alternatively, or in addition, the notification may include a recommended treatment. The information displayed and provided by the ECG platform may need to be reviewed and / or issued by a healthcare professional. Alternatively, the ECG platform may only allow the information to be displayed on the mobile device after it has been reviewed and / or issued by a healthcare professional. Data and / or information different from that shown in FIG. 26 may be presented by the mobile interface 933.

[0145]

[0191] Referring to FIG. 27, an example process for prioritizing certain information for review by a healthcare provider is shown. Because different types of analysis may be performed on different sensor data and different types of results, data, and information may be generated or determined based on the sensed data, it may be useful to prioritize certain results, data, and / or information over other information based on known information about the patient (e.g., indications related to a particular patient). In this manner, data, results, and information that are most important for the relevant indication may be presented to the healthcare provider before other data, results, and information that are less relevant. Some or all of the blocks of the process in FIG. 27 may be distributed and performed among any number of devices (e.g., computing devices and / or servers). Some or all of the operations of the process in FIG. 27 may be optional and may be performed in different orders.

[0146]

[0192] To begin the process shown in FIG. 27 (e.g., on an ECG platform), step 940 may be performed in which a patient account is determined. For example, a user account associated with a particular patient may be identified using the patient's name or identification information. In step 942, indications associated with the patient account may be identified. For example, it may be determined that a particular patient has had a stroke or heart attack. The patient account may include medical history for the patient and / or medical history for the patient's family. The indications may be determined from the medical history or otherwise described in the patient account.

[0147]

[0193] In step 944, the system (e.g., ECG platform) may prioritize certain events, analyses, results, data, or other information determined by the system based on the indication identified in step 942. For example, results, data, and other information determined by the system by analyzing sensed data (e.g., ECG data) may be prioritized and reviewed by a medical professional. The prioritized data, results, and information may be associated with the indication or known by the system as being related to the indication. The system may include a default setting that makes an association between the data, results, identified abnormalities, conditions, and / or events and / or information and the particular indication.

[0148]

[0194] At decision 946, the system may determine whether reprioritization of events, analyses, data, results, and / or information is required. For example, the system may include a reprioritization button on a user interface presenting the events, analyses, data, results, and / or information that the healthcare provider may press to indicate that reprioritization or other modification of their presentation is required. If reprioritization of the data, results, and / or information is not required (e.g., the healthcare provider did not press the button), the default priorities are maintained at step 948. Alternatively, if input from the user indicates that reprioritization of the data, results, and / or information associated with the indication is required (e.g., the button is pressed), then at step 952, the priority of the prioritized data, results, and / or information for the indication should be changed. For example, the healthcare provider may manually change the priority of such data, results, and / or information. Prioritization is described in more detail below with reference to FIG. 31A.

[0149]

[0195] Referring to FIG. 28, a process for determining a period for recording ECG data that is likely to include an arrhythmia event is shown. It may be ideal to record ECG data when one or more events occur. However, it may be difficult to predict when such events will occur. Process 960 is an example of a process for determining a period during which an arrhythmia is likely to occur and requesting ECG data corresponding to that period. Some or all of the blocks of the process in FIG. 28 may be distributed and performed among any number of devices (e.g., computing devices and / or servers). Some or all of the operations of the process in FIG. 28 may be optional and may be performed in different orders.

[0150]

[0196] To begin the process shown in FIG. 28 (e.g., on an ECG platform), in step 961, a history of ECG data corresponding to past arrhythmias may be determined. For example, prior events corresponding to the arrhythmia may be identified. In step 962, the ECG data corresponding to the prior events corresponding to the arrhythmia is processed or analyzed to determine patterns or trends corresponding to the arrhythmia. For example, one or more trained models may be used to detect such patterns and / or trends. In step 964, the patterns and / or trends may be used to determine time periods during which there is a risk and / or likelihood of the arrhythmia occurring. The time periods may correspond to particular times of day, such as, for example, 9:00 AM to 9:30 AM.

[0151]

[0197] In step 966, a message may be sent to the mobile device and / or the sensing device, and the sensing device may generate or obtain ECG data and / or other data related to the arrhythmia at the time period. For example, the message may be sent to the mobile device, and the mobile device may request such data from the sensing device. Alternatively, a request may be sent directly to the sensing device. In yet another example, the user may manually have to cause the sensing device to record ECG data, and the message may instruct the user to start recording the ECG at a particular time point and / or to record for a particular time period. In step 968, the system may receive ECG data and / or other data related to the arrhythmia and corresponding to the time period. In this manner, the system and / or the mobile device may perform ECG recordings at times when the patient is likely to experience arrhythmia.

[0152]

[0198] Referring to FIG. 29, a process is shown for determining a period (e.g., interval) for recording ECG data that is likely to include an atrial fibrillation event based on PAC burden. As discussed above, it may be difficult to predict when such arrhythmias will occur. Process 970 is an example of a process for determining an interval in which an arrhythmia, specifically atrial fibrillation, is likely to occur and requesting ECG data corresponding to that period. Some or all of the blocks of the process in FIG. 29 may be distributed and performed among any number of devices (e.g., computing devices and / or servers). Some or all of the operations of the process in FIG. 29 may be optional and may be performed in different orders.

[0153]

[0199] To begin the process illustrated in FIG. 29 (e.g., on an ECG platform), in step 972, a history of ECG data corresponding to past arrhythmias may be determined. For example, prior events corresponding to the arrhythmia may be identified. In step 974, the prior events corresponding to the arrhythmia are processed or analyzed to determine a total number of premature atrial contractions (PACs) relative to a total number of beats in a period of time (i.e., PAC burden). For example, the techniques described herein may be used to determine PACs in the ECG data and ultimately to determine PAC burden. In step 976, a period during which atrial fibrillation is likely to occur may be determined based on the PAC burden. For example, the techniques described herein may be used to generate an inference regarding the likelihood of atrial fibrillation based on the PAC burden.

[0154]

[0200] In step 978, a message may be sent to the mobile device and / or the sensing device, which may generate or acquire ECG data and / or other data related to the period. For example, a message may be sent to the mobile device, which may request such data from the sensing device. Alternatively, a request may be sent directly to the sensing device. In yet another example, a user may need to have the sensing device record ECG data, and the message may instruct the user to start recording an ECG at a particular time. In step 968, the system may receive ECG data and / or other data related to arrhythmia and corresponding to the period. In this manner, the system and / or the mobile device may perform ECG recordings at times when the patient is likely to experience atrial fibrillation.

[0155]

[0201] 30A-30B, an example event report is shown. As shown in FIG. 30A-30B, the event report 1000 may include patient information (e.g., name, date of birth, indication, etc.), physician information (e.g., name, facility name, address, etc.), data transmission summary (e.g., device, data points transmitted, billing period, etc.), ECG findings summarizing abnormalities, descriptors, and / or conditions, and one or more ECG representations. For example, portions of the ECG strip corresponding to various abnormalities, descriptors, and / or conditions may be included in the event report 1000.

[0156]

[0202] 31A-31F, various user interfaces for displaying patients, indications, classifications, and / or events are shown. The user interfaces shown in FIGURES 31A-31F may be displayed on any computing device described herein, such as system device 14 described above with respect to FIGURE 2.

[0157]

[0203] FIGURE 31A illustrates a patient registration interface 1004. As shown in FIGURE 31A, the patient registration interface 1004 includes fields for input of contact information (e.g., email, phone number, etc.), medical history (e.g., indications, medications, etc.), and may allow the healthcare provider to manually prioritize certain criteria (e.g., conditions, descriptors, abnormalities, other information).

[0158]

[0204] 31B illustrates a patient list interface 1006. As shown in FIG. 31B, the patient list interface 1006 may include a list of patients (e.g., a list of patients associated with a physician and / or institution). The patient list interface 1006 may include the patient's name, the patient's date of birth, an indication associated with the patient, registration data, account status, and / or other relevant information.

[0159]

[0205] 31C shows a registration interface 1010. FIG. 31D shows that the registration interface 1010 may include fields for entering the patient's name, sex, date of birth, email, phone number, and / or medical history. For example, the medical history fields may include fields for entering indications corresponding to the patient and / or one or more medications the patient is taking.

[0160]

[0206] 31D shows a registration interface 1012, which may be the same as registration interface 1010. As shown in FIG. 31E, under a "Medical History" section of registration interface 1012, there may be an indications menu 1014 that includes selectable indications. For example, the indications may include post-atrial fibrillation ablation, palpitations, atrial fibrillation management, and / or no indications. The indications menu 1014 may include any other indications.

[0161]

[0207] An event interface 1018 is shown in FIG. 31E. As shown in FIG. 31C, the event interface may be accessed from an event list (e.g., by selecting the patient's name). The event interface may include the patient's name, the classification of the event (e.g., atrial fibrillation), the portion of the ECG strip corresponding to the event, symptoms, heart rate, and / or other relevant information. The event interface 1018 may further include a "reclassify" button to change the classification of the event. The classification of the event may be determined by the ECG platform and / or by the sensing device (e.g., sensing device 930 of FIG. 25A).

[0162]

[0208] 31F shows an event interface 1020 that may be the same as the registration interface 1018. As shown in FIG. 31F, the event interface may include a reclassification menu 1022 next to the classification in the event interface 1020. For example, the reclassification menu 1022 may include a number of reclassification options such as sinus rhythm, low heart rate, high heart rate, pause, AV block, PSVC, atrial fibrillation, and / or other conditions, abnormalities, and / or descriptors by which the event may be classified. In this manner, a healthcare provider using the ECG platform may change the classification provided by a sensing device (e.g., sensing device 930 of FIG. 25A).

[0163]

[0209] FIG 32 illustrates an ECG report 1050 that may be an example of a portion of a more comprehensive ECG report, such as the reports described above with respect to FIGs. 15A-15D. As shown in FIG 32, the ECG report 1050 may include patient information such as the patient's name, primary indication, presence or absence of a pacemaker, the patient's date of birth, gender, and / or patient ID, and may also include other information such as the supervising physician, institution name, analysis date, etc. The ECG report 1050 may be a digital rendering displayed on a computing device (e.g., laptop, desktop, tablet, mobile device, etc.) and / or may be a physical printout (e.g., printed on paper).

[0164]

[0210] 32, the ECG report 1050 may include various plots (e.g., plot 1052) corresponding to relevant ECG information and / or data. For example, the ECG report 1050 may include ECG plots corresponding to maximum heart rate, minimum heart rate, atrial fibrillation, flutter, and / or other types of ECG, cardiac, physiological, and / or biological information. The plots (e.g., plot 1052) may be any type of plot, such as, for example, ECG strips, RR plots, heart rate density plots, etc. The plots may also indicate, identify, or correspond to medical conditions, events, and / or abnormalities.

[0165]

[0211] The plot 1052 and / or other plots in the ECG report 1050 may be interactive. For example, the plot 1052 may include a clickable portion 1054 and / or a clickable link 1056 that a user can click or otherwise interact with on a computing device. The clickable link 1056 may be text, an image, an icon, and / or the like. In one example, a physician and / or health care provider may receive a digital ECG report 1050, desire to see more of the signal and / or to view the underlying data in greater detail, and may use a computing device (e.g., a touch screen and / or a mouse) to click on the clickable portion 1054 and / or the clickable link 1056 of the clickable ECG plot. Clicking on the clickable portion 1054 and / or the clickable link 1056 may redirect the user to the ECG platform 37, and specifically to a viewer version of the ECG application 29. For example, the user may be redirected to a viewer application (e.g., the viewer application and interface shown in FIG. 33). The ECG report 1050 may include one or more clickable links 1056 and / or clickable portions.

[0166]

[0212] A viewer interface 1060 of the viewer application is shown in FIG. 33. The viewer application may allow a user, such as a user with limited viewing privileges (e.g., a restricted user), to view additional information corresponding to the ECG data and / or other data identified in the report and / or otherwise provide limited access to the ECG platform. For example, the viewer application may generate the viewer interface 1060 to allow the restricted user to view the complete ECG signal and / or additional ECG data beyond that provided in the report. In this manner, the restricted user may interact with the viewer interface 1060 to view the ECG signal, ECG strips, ECG data, and / or other related information. Additionally, a user with full access privileges to the ECG platform may similarly access the viewer application and viewer interface 1060.

[0167]

[0213] As shown in Figure 33, the viewer interface 1060 may be similar to the interactive display 101 described above with respect to Figure 8. For example, the viewer interface 1060 may include three distinct portions: a first portion 1062 including a heart rate density plot, a second portion 1064 including a focused ECG strip 1066 and an expanded ECG strip 1068, and a third portion 1070 including selectable ECG strips organized by identified conditions, events, and / or anomalies.

[0168]

[0214] The heart rate density plot of the first portion 1062 may be similar to plot 110 of FIG. 8 and / or may represent the entire signal or a portion of the signal and may include selectable identifiers for visually identifying events, conditions, and / or anomalies identified in the ECG signal. The focused ECG strip 1066 may be an ECG strip of a particular time frame within the heart rate density plot. The focused ECG strip 1066 may correspond to the location of an interactive cursor along the time axis of the heart rate density plot.

[0169]

[0215] The expanded ECG strip 1068 may similarly correspond to the location of the interactive cursor on the heart beat density plot and may include an ECG strip having a longer time length and including the time frame of the focused ECG strip 1066. The expanded ECG strip 1068 may be smaller in height than the focused ECG strip 1066. The second portion 1064 and the first portion 1066 are linked, such that moving the cursor on the heart beat density plot may change the portion of the ECG signal displayed in the focused ECG strip 1066 and the expanded ECG strip 1068 based on the location of the cursor on the time axis of the heart beat density plot.

[0170]

[0216] The selectable ECG strips in the third portion 1070 may be organized by identified conditions, events, and / or abnormalities. For example, the selectable ECG strips may be organized by, for example, ventricular tachycardia (VT), couplets, bigeminy, or trigeminality. Each selectable ECG strip may be selected using a viewer application, and a selection may cause a portion of the ECG signal corresponding to the selected ECG strip to be displayed on the first portion 1062 and the second portion 1064. Specifically, a cursor on the heart rate density plot may move to a portion of the heart rate density plot corresponding to the selected ECG strip. Additionally, the focused ECG strip 1066 and the expanded ECG strip 1068 display the selected ECG strip and an expanded version of the selected ECG strip, respectively. In one example, the ECG strips in the third portion 1070 may be only those strips included in the ECG report. Alternatively, all ECG strips identified by the ECG system may be included in the third portion 1070.

[0171]

[0217] The viewer interface 1060 may display more or fewer plots than those shown in FIG. 33 and / or may display other plots and / or other ECG, biological, physiological, and / or other related data. Additionally, the viewer interface 1060 may display comments and / or notes corresponding to the ECG data and / or strips, and may optionally enable the restricted user to create comments and / or notes. In yet another example, the viewer interface 1060 may enable the restricted user to provide feedback corresponding to identified events, conditions, and / or anomalies. For example, the restricted user may be able to identify or de-identify ECG strips associated with a given condition, event, and / or anomaly. Additionally and / or alternatively, the restricted user may be able to modify and / or revise the report, add comments to the report, add conclusions to the report, and / or sign the report via the viewer interface 1060.

[0172]

[0218] FIG. 34 illustrates an example process for redirecting a user from a report to a viewer application and viewer interface. To begin the process, the ECG system may generate a report in block 1082 as described above with respect to step 68 of FIG. 4 and FIG. 33. In block 1084, the ECG may receive a request to access the ECG data using a viewer application (e.g., an application on an ECG platform) that may be part of the ECG system. The request to access the ECG data may be an automated request or a message initiated by an individual viewing the report selecting a selectable ECG strip and / or a selectable link. For example, a healthcare provider may view a digital ECG report on a computing device and navigate to the viewer application by selecting a selectable ECG strip and / or link.

[0173]

[0219] In block 1086, the ECG system may request and verify user credentials in response to a request for access to the viewer application. For example, a healthcare provider may be a restricted user registered with the ECG system and have a restricted user profile with corresponding credentials (e.g., username and passcode). Upon receiving a request for access to the viewer application, the ECG system may request credentials from the restricted user and verify those credentials using the user profile.

[0174]

[0220] At block 1088, the ECG system may generate a viewer interface for presenting the ECG plot, ECG data, and / or other data associated with the ECG report via the viewer application. For example, the ECG system may generate a viewer interface similar to the viewer interface 1062 described above with respect to FIG. 33. At block 1090, the ECG system may receive an instruction from the user to perform an action (e.g., a request to add a comment to the ECG platform and / or add a comment (e.g., conclusion) to the ECG report and / or sign the ECG report). For example, the user may use the viewer application to navigate the user within the heart rate density plot to view various portions of the ECG signal, select a selectable ECG strip to view the ECG strip, request to add a comment corresponding to the ECG strip, and / or request a comment and / or signature to the ECG report. At block 1092, the ECG system may cause the viewer application to perform an action based on the received instruction (e.g., sign the report, add a comment to the report, and / or add a comment to the ECG platform).

[0175]

[0221] 35A-35C show a report interface, a patient interface, and an event list interface. As shown in FIG. 35A, the report interface 1095 can provide the status of a report in the ECG system. For example, the report interface 1095 can include columns indicating the patient's name, the status of the report (e.g., in progress, goal reached, goal not reached, monitoring stopped), billing period end date, and / or number of days sent. Additionally, the report interface 1095 can include a search field (e.g., patient name) and a status filter (e.g., filter by in progress).

[0176]

[0222] 35B, the patient interface 1096 may include information related to a patient of the ECG system. The patient interface 1096 may include columns indicating the patient's name, date of birth, indication, enrollment date, and / or status (e.g., active). The patient interface 1096 may include a search field (e.g., patient name) and / or may be filtered.

[0177]

[0223] 35C, the event list interface 1097 may include events related to the patient. For example, the event list interface 1097 may include tabs for major events and / or secondary minor events, and under each tab may include columns indicating patient name, findings (e.g., sinus rhythm, low heart rate), indications (e.g., palpitations), and / or dates. The event list interface 1097 may include a search field (e.g., patient name) and / or may be filtered.

[0178]

[0224] FIG. 36 illustrates an example of a system 1100. The system 1100 may include a first system device 1102 associated with an ECG sensing device 1103, a second system device 1105, and / or one or more servers 1101. The first system device 1102 may be operated by one or more users 1106, the ECG sensing device 1103 may obtain ECG data associated with one or more users 1104, and the second system device 1105 may be associated with one or more users 1107. It should be noted that references to a single element (e.g., the first system device 1102, the ECG sensing device 1103, the second system device 1105, the server 1101, the user 1106, the user 1104, or the user 1107, etc.) are not intended to be limiting, and the same description may be applicable to any number of these and / or other elements. Additionally, references to "analysis" are not intended to be limiting, and analysis may include multiple types of analysis.

[0179]

[0225] The server 1101, the first system device 1102, and / or the second system device 1105 may include any suitable processor-driven device, such as, but not limited to, a mobile or non-mobile device (e.g., a stationary device), a personal computer (PC), a wearable wireless device (e.g., a bracelet, a watch, glasses, a ring, etc.), a desktop computer, a mobile computer, a laptop computer, an ultrabook computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, an Internet of Things (IoT) device, a sensor device, or other well-known computing device.

[0180]

[0226] The first system device 1102 may receive and / or acquire data associated with the user 1104 (e.g., ECG data acquired by the ECG sensing device 1103) and transmit the data to the server 1101 for storage. The user 1107 may receive authorization to access the data via the server 1101 (e.g., using the second system device 1105). The user 1107 may provide instructions to the server 1101 (e.g., using the second system device 1105) to analyze the ECG data (i.e., the server 1101 may perform any analysis at the user 1107's instruction via the second system device 1105). The server 1101 may then perform an analysis on the ECG data and generate a report based on the analysis (e.g., based on a command to generate a report). The report may be sent back to the first system device 1102. Additionally and / or alternatively, the report may be maintained on the server 1101 for access by partner users 1106 and / or third party users 1107. In one example, the first system device 1102 may be a pharmacy that obtains ECG data from a patient and ultimately provides a report to the same patient. In this example, the user 1107 may be a physician and / or healthcare provider who can review the analysis performed by the server 1101.

[0181]

[0227] The ECG sensing device 1103 can be the same as or similar to the ECG sensing device 13 described above with respect to FIG. 2. For example, the sensing device 1103 may be one or more electrodes disposed on one or more leads. The sensing device 1103 may be in electrical communication with the first system device 1102 running an ECG application (e.g., ECG application 29 and / or other ECG applications), and electrical signals sensed by the sensing device 1103 may be received by the ECG application (e.g., running on the first system device 1102). The ECG application may include instructions that cause the sensing device 1103 to sense or acquire ECG data.

[0182]

[0228] The first system 1102 is preferably one or more computing devices (e.g., laptop, desktop, tablet, smartphone, smartwatch, etc.) having the components described below with reference to FIG. 3A and the functionality described herein. The system device 1102, which may run an ECG application, may be connected to a server 1101 (e.g., ECG platform 37) operating via any well-known wired or wireless connection. For example, the system device 1102 may connect to the Internet using well-known technologies (e.g., WiFi, cellular, cable / coax, and / or DSL) and communicate with the server 1101 via the Internet. Other elements of the system 1100 may also communicate with each other using well-known wired or wireless connections.

[0183]

[0229] The first system device 1102 may be associated with a partner user 1106. In some embodiments, the partner user 1106 may be a user with limited privileges with respect to the server 1101. For example, the partner user 1106 may only upload records, request report generation, and / or modify administrative information (e.g., one or more of information about one or more administrative entities, healthcare entities, medical provider information, patient information, patient demographics, etc.), among other types of functions. Unlike other users (e.g., user 1107 and / or other users) who have access to the server 1101, the partner user 1106 may not be able to access analysis results stored within the server 1101. These are merely examples of ways in which the partner user 1106 may be constrained, and are not intended to be limiting.

[0184]

[0230] The server 1101 is preferably one or more servers having the components described below with reference to FIG. 3B (and / or other components described herein) and the functionality described herein. The server 1101 may be the same as or similar to the server 15 described above with respect to FIG. 2. The server 1101 may have greater processing power than the first system device 1102, and the server 1101 may process and analyze ECG data and / or other data received from the first system device 1102 (e.g., the analysis described with respect to FIG. 4 and / or other types of analysis described herein). The server 1101 may also be configured to generate reports based on any analysis of any ECG data. As will be readily understood by those skilled in the art, the server 1101 may include multiple servers located at a common physical location or different physical locations. In one example, the server 1101 may be located at a different remote location (e.g., on a cloud) from the first system device 1102. However, the server 1101 and the first system device 1102 may be located at a common location (e.g., on a local area network (LAN)).

[0185]

[0231] The server 1101 may also include functionality to provide storage for ECG data, analysis data, reports generated related to the ECG data, and / or other types of data. The server 1101 may be associated with one or more user interfaces that may be presented to a user (e.g., user 1106 and / or user 1107) via the first system device 1102, the second system device 1105, and / or other system devices. The user interfaces may enable a user to view data stored on the server 1101 and / or perform other types of functions. For example, the user 1106 (via the second system device 1102) may be able to upload ECG data received from the ECG sensing device 1103 to the server 1101. The user 1106 may provide access to the data to the user 1107, which may enable the user 1107 to instruct the server 1101 to perform analysis of the uploaded data. That is, the analysis is not necessarily performed by the user 1107 and / or the second system device 1105, but rather the user 1107 may be able to control when the server 1101 performs analysis of the ECG data.

[0186]

[0232] In particular, the server 1101 may include one or more folders that may store various ECG data, patient data, or medical data, etc., that may be presented through a user interface. The folders may be accessible only to users that have permission to access the folders. Thus, a first entity may have multiple folders (e.g., containing ECG data of various patients) stored on the server 1101. The first entity may want a second entity to access one of the folders to obtain and analyze ECG information for a particular patient, but may not want the second entity to be able to access the other folders. Thus, the server 1101 may provide the ability to establish permissions such that the second entity can only access the desired folders and not the remaining folders associated with the first entity.

[0187]

[0233] Examples of use may include the following: A user 1106 (e.g., via the first system device 1102) may upload records of ECG data to a user 1107-dedicated folder on the server 1101. The folder may be configured to allow the user 1107 to share patient data (such as name, date of birth, etc.) with the second system device 1105. The user 1107 may not be able to access all records associated with the first system device 1102, but may only be able to see the records in this particular folder. The user 1107 and / or the third party system device 1105 may instruct the server 1101 to perform an analysis (e.g., using any of the analyses described herein) on the ECG data and / or to generate a report. The report may be based on the analysis results generated by the server 1101 (and may optionally be stored in the folder from which the records were obtained and / or in other folders). In one example, the report may be communicated or otherwise accessed by the user 1106.

[0188]

[0234] FIG. 37A illustrates an example of a process 1120 for performing and restricting access to ECG analysis and / or reports. The process 1120 may depict operations performed in connection with an entity that generates ECG data but does not analyze the ECG data itself (e.g., the first system of FIG. 36 may be the first entity 1122 of FIG. 37 and FIG. 38). That is, the data may be outsourced to a third party or other entity that manages or oversees the analysis (e.g., the second system device of FIG. 36 may be the second entity 1126 of FIG. 37 and FIG. 38). In general, the first entity 1122 may generate or obtain ECG data and upload the data to a remote system 1124 (e.g., may be the server 1101 of FIG. 36). The second entity 1126 may then access the uploaded ECG data and instruct (e.g., instruct and / or command) the system 1124 to analyze the data. The system 1124 may generate a report based on the analysis performed. The report may then be accessed by the first entity 1122 and / or the second entity 1126. In some cases, the system 1124 may automatically provide the report to the first entity 1122 upon generation of the report and / or inform the first entity 1122 that the report has been generated. Additionally or alternatively, a notification may be automatically provided to the second entity 1126 that the ECG data has been uploaded.

[0189]

[0235] Returning to process 1120, in operation 1128, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to modify and / or grant access permissions for the first entity 1122 to various folders, data, and / or functions on the system 1124 (e.g., as described below with respect to FIG. 41). Similarly, the system 1124 (e.g., the server 1101 and / or other systems) may receive indications of access modification or grant from the second entity 1126. For example, the second entity 1126 may have the ability to use the system 1124 to indicate which users can upload data and / or perform certain actions with respect to any of the data uploaded to the system 1124 by the first entity 1122. Other types of user permissions may be indicated. For example, the second entity 1126 may have multiple folders contained within the system 1124. The second entity 1126 may grant the first entity 1122 access to the folders associated with the second entity 1126. However, the first entity 1122 may not have permission to access other data on the system 1124. Similarly, the first entity 1122 may also have the ability to use the system 1124 to indicate which users can upload data and / or perform certain actions with respect to any of the data uploaded to the system 1124 by the first entity 1122. Other examples of user permissions may be shown in FIG.

[0190]

[0236] In operation 1130, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to upload ECG data. For example, the first entity 1122 may capture and / or obtain ECG data from a user (e.g., user 1104 of FIG. 36) and upload the captured data to the system 1124. Similarly, the system 1124 may receive uploaded data from the first entity 1122. For example, the data may be uploaded to a first folder that the first entity 1122 has permissions to access. These permissions may be established by the second entity 1126 (e.g., as described with respect to operation 1128), and the second entity 1126 may retrieve the uploaded data for analysis. However, the location where the data is uploaded may be managed by the first entity 1122 rather than the second entity 1126. That is, a first entity 1122 may upload data to a location within the system 1124 that a second entity 1126 is permitted to access based on permissions granted by the first entity 1122 .

[0191]

[0237] In operation 1134, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to send instructions to perform the analysis. For example, the second entity 1126 may instruct the system 1124 to perform an analysis of the uploaded ECG data. Such instructions may be provided, for example, through a user interface associated with the system 1124. Similarly, the system 1124 may receive instructions from the second entity 1126 to perform the analysis from the ECG data. Operation 1134 may be optional, and the system 1124 may initiate operation 1136 automatically.

[0192]

[0238] In operation 1136, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to analyze the ECG data. For example, the ECG data may be analyzed by system 1124 in accordance with ECG processing system 10 described with respect to FIG. 4 and / or based on other types of analyses using other systems and / or devices described herein.

[0193]

[0239] In operation 1137, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to access the uploaded ECG data and / or the analysis of the ECG data. Similarly, the system 1124 may provide a second entity 1126 with access to the uploaded ECG data and / or the analysis of the ECG data.

[0194]

[0240] In operation 1138, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to generate a report based on the analysis of the ECG data performed in block 1134. The report may include any information related to the analysis of the ECG data. For example, the report may indicate whether an abnormality is present in the patient's ECG data. The report may be generated by the system 1124. In one example, the system 1124 may generate the report in response to the second entity 1126 and / or the first entity 1122. Alternatively, the system 1124 may generate the report automatically.

[0195]

[0241] In operation 1139, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to access the report. That is, the second entity 1126 may access the report via the server 1101 (e.g., via a user interface). Further, a notification that the report has been generated may be automatically provided to the second entity 1126 and / or the report itself may be automatically provided to the second entity 1126.

[0196]

[0242] In operation 1140, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to access the report. That is, if the first entity 1122 has permission to access the report, the first entity 1122 may access the report via the server 1101 (e.g., via a user interface). Further, a notification may be automatically provided to the first entity 1122 indicating that the report has been generated and / or the report itself may be automatically provided to the first entity 1122.

[0197]

[0243] FIG. 37B illustrates an example process 1150 for performing ECG analysis and restricting access and / or privileges to an ECG platform. Some or all of the blocks of the process flow of the present disclosure may be distributed and performed across any number of devices (e.g., servers, computing devices, user devices, and / or servers). Some or all of the operations of the process flow may be optional and may be performed in a different order. The process of FIG. 37B may be performed by a server (e.g., server 1101 of FIG. 36) and may be directed to a process for facilitating a third party (e.g., second entity 1126 of FIG. 37A) or other entity to analyze any ECG data (and / or other types of data) uploaded or otherwise provided to the server by a provider (e.g., first entity 1122 of FIG. 37A).

[0198]

[0244] In operation 1151, computer-executable instructions stored in a memory of a device, such as a computing device, are executed to receive instructions to change or grant access permissions. For example, the second entity may have the ability to use the ECG system to indicate which users can perform certain actions with respect to any of the data uploaded to the system by the first entity. Other types of user permissions may be indicated. For example, the second entity may have a particular portion of the system (e.g., one or more folders) that the second entity may use to store data and / or that other entities may use to store data based on permissions provided by the second entity. This portion may be represented, for example, by a number of folders presented via a user interface associated with the system. However, storage may be represented in other forms (i.e., forms other than folders). Thus, references herein to a "folder" merely indicate a location in the system that is reserved for storage by the second entity and other entities that have permission to use that storage space. The second entity may grant the first entity access permissions to the folder, including access permissions to all data in that folder. However, the first entity may not have permission to access other data uploaded to the system (e.g., data in another folder). Other examples of user permissions may be shown in FIG. 41. The second entity may have any number of different folders in the system, and these folders may be intended for any number of different entities. For example, the second entity may facilitate analysis of ECG data received from any number of different entities. A first folder may be reserved for the first entity, a second folder may be reserved for a third entity, and so on.This allows each entity to upload ECG data to a respective folder in the system, allowing a second entity to access the data while preventing third-party entities or other entities from accessing the data uploaded by the first entity, or vice versa.

[0199]

[0245] In some embodiments, data may be uploaded to one or more folders associated with a first entity rather than a second entity, i.e., the first entity may manage one or more folders as an administrator and indicate permissions to access the folders, thereby providing administrative control to the first entity uploading the ECG data rather than the second entity facilitating analysis of the ECG data.

[0200]

[0246] In operation 1152, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to receive uploaded ECG data. For example, a first entity may capture and / or obtain ECG data from a user (e.g., user 1104 of FIG. 36) and upload the captured data to the system. In particular, the first entity may be associated with a first system device that may receive data obtained from the user by an ECG sensing device. The system may receive this uploaded data from the first entity. For example, the data may be uploaded to a first folder that the first entity has permissions to access. These permissions may be established by the first entity and / or the second entity (e.g., as described with respect to operation 1151). The location where the data is stored may be based on approval instructions and / or permissions established by the first entity or the second entity.

[0201]

[0247] In optional operation 1153, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to automatically notify the second entity that the ECG data has been uploaded. That is, the system may be configured to automatically provide a notification to the second entity when new data is uploaded to a folder to which the second entity has access privileges. In some embodiments, these automatic notifications may be configured in settings associated with the system by the first entity and / or the second entity. For example, the second entity may prefer to receive a notification so that the second entity can know that new data has been uploaded that may facilitate analysis via the system (e.g., as described above, in the case where ECG data generated by the first entity is outsourced to the second entity or other entities for analysis). The automatic notification may be provided in any suitable manner, such as by phone call, email communication, and / or text message. The automatic notification may also be provided within the system (e.g., presented via a user interface) and / or through the use of an application programming interface (API).

[0202]

[0248] In operation 1154, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to receive a request to access the uploaded ECG data. For example, the uploaded data may be stored within a system and a second entity may need to access the data to facilitate analysis. The second entity may access this data, for example, via a user interface associated with the system, which may be presented to the second entity in any suitable manner (e.g., a user interface associated with a website, a mobile device application, a desktop software application, and / or any other form in which a user interface may be presented). The second entity may use the user interface to access where the data is stored within the system. The system may verify that the second entity has authorization to view the data and / or any representations of the data (e.g., based on approval instructions provided by the first entity). If it is determined that the second entity has authorization to view the data and / or representations of the data, the data may be presented to the second entity via the user interface. In one example, the second entity may not need to manually take any action to initiate this request. Rather, from the second entity's perspective, it may appear that automatic access to the data is provided.

[0203]

[0249] In act 1155, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to allow access to the uploaded ECG data.

[0204]

[0250] In operation 1156, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to receive instructions to perform an analysis of the uploaded ECG data. For example, a second entity may instruct the system to perform an analysis of the uploaded ECG data. Such instructions may be provided, for example, through a user interface associated with the system. Alternatively, the system may automatically perform an analysis of the ECG data uploaded to the ECG system and / or the ECG data stored in a particular folder. Alternatively, the analysis may be performed automatically by the system without the need for instructions.

[0205]

[0251] In operation 1157, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to perform an analysis of the uploaded ECG data. For example, the analysis may include any of the processes described with respect to FIG. 4 and / or other possible types of analysis of the ECG data described herein. Such analysis may be used, for example, to identify abnormalities and conditions of the patient. The abnormalities and conditions may include, but are not limited to, sinus atrial block, paralysis or asystole, atrial fibrillation, atrial flutter, atrial tachycardia, junctional tachycardia, supraventricular tachycardia, sinus tachycardia, ventricular tachycardia, pacemaker, premature ventricular contractions, premature atrial contractions, first degree atrioventricular block (AVB), second degree AVB Mobitz type I, second degree AVB Mobitz type II, third degree AVB, Wolff-Parkinson-White syndrome, left bundle branch block, right bundle branch block, intraventricular conduction delay, left ventricular hypertrophy, right ventricular hypertrophy, acute myocardial infarction, previous myocardial infarction, ischemia, hyperkalemia, hypokalemia, Brugada syndrome, and / or QTc prolongation.

[0206]

[0252] In operation 1158, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to generate an analysis report and / or output data corresponding to the analysis of the uploaded ECG data. The report and / or output data may include any information related to the analysis of the ECG data. For example, the report and / or output data may indicate whether an abnormality, condition, and / or event is present in the patient's ECG data. The report and / or output data may also include other types of information, such as a diagram of the ECG data, an indication of multiple different points of interest in the data, data classification performed, and / or other information that may be related to the analysis. The report and / or output data may be generated automatically by the system or may be generated at the direction of the first entity or the second entity. The report and / or output data may be stored in the system for later access (e.g., to be accessed by the first entity). In some cases, the report and / or output data may be stored in the same folder that contains the uploaded ECG data. However, the report and / or output data may be stored in other locations. The location where the report is stored may be determined based on the authorization instructions described above. That is, the report may be stored in a folder accessible to the second entity and / or other entities, or the report may not be stored in the system but rather generated and sent to the device only upon request.

[0207]

[0253] In operation 1159, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to receive (e.g., from a first entity and / or a second entity) a request to access the output data and / or an analytical report based on the output data. The request to access the analytical report may include a request to generate the analytical report. In operation 1159, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to determine whether to authorize accessing and / or generating the analytical report based on the authorization instructions. For example, the system may determine whether the first entity or the second entity has permission to access a location in the system where the report is stored. Further authorization may be required to access the report in the location. That is, even if the first entity or the second entity has access to the location itself, the first entity or the second entity may be required to have additional authorization to view the report.

[0208]

[0254] In operation 1160, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to determine whether to authorize accessing and / or generating the analysis report based on the authorization instructions.

[0209]

[0255] In operation 1161, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to provide an analysis report (e.g., to a first entity and / or a second entity). For example, the first entity may be able to view the report via a user interface associated with the system. The system may also allow the first entity to download the report to a local device for local storage and / or viewing. In some cases, however, the system may prevent the user from downloading the report and retain the report within the system for viewing.

[0210]

[0256] In an optional operation 1162, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to automatically provide an analysis report (e.g., to the first entity and / or the second entity). For example, similar to the optional automatic notification provided to the second entity when data is uploaded, an automatic notification may also be provided to the first entity when an analysis report is generated. These automatic notifications may be configured by the first entity and / or the second entity in settings associated with the system (and / or may not require configuration by the first entity and / or the second entity). These automatic notifications allow the first entity to know that the analysis is complete and a report has been generated without having to access the system to see if a report has been generated. The automatic notifications may also be provided in any suitable manner, such as by phone call, email communication, and / or text message. The automatic notifications may also be provided within the system (e.g., presented via a user interface) and / or through the use of an application programming interface (API).

[0211]

[0257] FIG. 38A illustrates an example of a process 1170 for performing and restricting access to ECG analysis and / or reports. The process 1170 may illustrate operations that may be performed for an entity that generates ECG data and interacts with the system 1124 to initiate analysis of the ECG data and generate reports, but sometimes outsources initiation of the analysis to a third party or other entity. Such an entity may outsource data for analysis, for example, when there is a large amount of data that it cannot analyze itself. In such a situation, the entity may analyze a portion of the data and outsource the remaining data to a third party or other entity for analysis. In general, a first entity 1122 (which may be, for example, the first system device 1102 of FIG. 36) may generate ECG data and upload the data to the system 1124 (which may be, for example, the server 1101 of FIG. 36). A second entity 1126 (which may be, for example, the second system device 1105 of FIG. 36) may then access the uploaded ECG data and instruct the system 1124 to perform an analysis of the data. The system 1124 may generate a report based on the analysis. The report may then be accessed by the first entity 1122 from the system 1124. In some cases, the system 1124 may automatically notify the second entity 1126 that the ECG data has been uploaded upon upload and / or automatically provide the report to the first entity 1122. In one example, a pharmacy may obtain ECG data from a patient and provide a report to the patient, although such a pharmacy may rely on a third party or other entity to analyze the ECG data and generate a report to provide to the patient.

[0212]

[0258] Returning to the process 1170, in operation 1171, computer-executable instructions stored in a memory of a device, such as a computing device, are executed to modify and / or access administrative information to modify or grant access permissions and / or authorizations to various folders, data, and / or functions on the system 1124. Similarly, the system 1124 may receive notification of the modification or grant from the first entity 1122. For example, the first entity 1122 may use the system 1124 to indicate which users can perform certain actions with respect to any of the data uploaded to the system 1124. In one example, the system 1124 has multiple folders and the first entity 1122 may grant the second entity 1126 access permissions to one or more folders, data, and / or functions that contain associated uploaded ECG data and / or other data. The second entity 1126 may not have permission to access other data uploaded to the system 1124 by the first entity 1122 and / or other data on the system 1124. For example, there may be a second folder containing ECG data and / or other types of data for other patients. A first entity 1122 may grant a second entity 1126 authority in the first folder but not in the second folder. Other examples of user permissions may be discussed below in connection with FIG. 41.

[0213]

[0259] In operation 1172, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to change or grant administrative information and / or permissions access to various folders, data, and / or functions on the system 1124. Similarly, the system 1124 (e.g., server 1101) may receive a granting or modification instruction from a second entity 1126. The permissions granted by the second entity 1126 may be the same or different from the permissions granted by the first entity 1122.

[0214]

[0260] In act 1173, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to upload the ECG data. For example, the first entity 1122 may capture and / or obtain ECG data from a user (e.g., user 1104 of FIG. 36) and upload the captured data to the system 1124. Similarly, the system 1124 may receive the uploaded data from the first entity 1122. For example, the data may be uploaded to a first folder that the second entity 1126 has permissions to access. These permissions may be established by the first entity 1122 (e.g., as described with respect to act 1171), and the second entity 1126 may obtain the uploaded data for analysis.

[0215]

[0261] In an optional operation 1174, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to send instructions to perform an analysis by the system 1124. For example, the first entity 1122 may instruct the system 1124 to perform an analysis of the uploaded ECG data. The ECG data may be analyzed according to the ECG processing system 10 described with respect to FIG. 4 and / or based on other types of analysis using other systems and / or devices described herein. Similarly, the system 1124 may receive instructions to perform an analysis and perform the analysis. Alternatively, or in addition, in an optional operation 1175, the second entity 1122 may instruct the system 1124 to perform an analysis of the uploaded ECG data. In an optional operation 1175, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to send instructions to perform an analysis of the uploaded ECG data. For example, the second entity 1126 may provide instructions and the system 1124 may perform any analysis based on the instructions. The analysis performed may be performed based on instructions from the first entity 1122 or the second entity 1126 based on whether the analysis is outsourced to the second entity 1126 or remains with the first entity 1122. Operation 1175 may be optional, and the system may automatically initiate operation 1176. In operation 1176, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to analyze the ECG data. That is, the system 1124 may perform any analysis (e.g., based on instructions provided by the first entity 1122 in operation 1174). In operation 1177, the second entity 1126 may access ECG data on the system 1124 (e.g., to which the second entity 1126 has access permissions). For example, the system 1124 may receive a request to access certain data and allow the second entity 1126 to access such data. Operation 1177 may be performed in a different order (e.g., before operation 1176).

[0216]

[0262] In operation 1178, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to prepare a report based on the analysis of the ECG data performed by the system 1124 in block 1176. The report may include any information related to the analysis of the ECG data. For example, the report may indicate whether medical abnormalities, conditions, and / or events are present in the ECG data.

[0217]

[0263] At operation 1179, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to access the report generated by the system 1124, i.e., a first entity 1122 may access the generated report. At operation 1180, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to access the report generated by the system 1124, i.e., a second entity 1126 may access the generated report.

[0218]

[0264] FIG. 38B illustrates an example process 1190 for performing ECG analysis and restricting access to ECG data and / or analysis results. For example, the process 1190 may be directed to a process in which an entity generating ECG data (e.g., first entity 1122 of FIG. 37A ) initiates analysis of the ECG data and generates a report by interacting with a system (e.g., system 1124 of FIG. 37A ) itself, but may sometimes outsource management of the analysis to a third party (e.g., second entity 1126 of FIG. 37A ) or other entity. Some or all of the blocks of the process flows of the present disclosure may be distributed and performed across any number of devices (e.g., servers, computing devices, user devices, and / or servers). Some or all of the operations of the process flows may be optional and may be performed in different orders. The process of FIG. 38B may be performed by a server (e.g., server 1101 of FIG. 36 ).

[0219]

[0265] In operation 1191, computer executable instructions stored in a memory of a device, such as a computing device, are executed and an authorization command indicating access privileges may be received. For example, a second entity may use the system to indicate which users may upload data to a particular location in the system. Other types of user privileges may be indicated. This location in the system may be represented, for example, by multiple folders presented through a user interface associated with the system. However, storage may be represented in other forms. Thus, references to a "folder" herein merely indicate a portion in the system that is reserved for storage by an entity that has the authority to use that storage space. In particular, a second entity may grant a first entity access privileges to a folder in which any ECG data may be included. However, the first entity may not have the authority to access other data uploaded elsewhere in the system. Other examples of user privileges may be illustrated in FIG. 41. A second entity may have any number of different folders in the system, and these folders may be intended for any number of different entities. For example, the system may facilitate analysis of ECG data received from any number of different entities. A first folder may be reserved for a first entity, a second folder for a third entity, etc. This allows each entity to upload ECG data to their respective folders in the system while preventing entities that do not have access permissions from accessing the folder in which the data is stored.

[0220]

[0266] In some embodiments, data may be uploaded to one or more folders associated with a first entity rather than a second entity. That is, the first entity may manage one or more folders as an administrator and indicate permissions to access the folders. This may provide administrative control to the first entity uploading the ECG data rather than the second entity facilitating analysis of the ECG data. For example, the first entity may upload the ECG data to its own folder if it is managing the analysis process itself. In such a situation, the second entity may not be involved in the process and may not need access to the ECG data.

[0221]

[0267] In operation 1192, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to receive uploaded ECG data. For example, a first entity may capture and / or otherwise obtain ECG data from a user (e.g., user 1104 of FIG. 36) and upload the captured data to the system. In particular, the first entity may be associated with a first system device that may receive data obtained from the user by an ECG sensing device. The system may receive this uploaded data from the first entity. For example, the data may be uploaded to a first folder that a second entity has permissions to access. These permissions may be established by the first entity and / or the second entity (e.g., as described with respect to operations 1171 and / or 1172 of FIG. 38A) to allow the second entity to obtain the uploaded data for analysis.

[0222]

[0268] Optional operations 1194-1196 may include operations that are performed when the first entity outsources management of the analysis of the uploaded ECG data to a second entity. In optional operation 1194, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to automatically notify the first entity that the ECG data has been uploaded. That is, the system may be configured to automatically provide a notification to the second entity when new data is uploaded to a folder to which the second entity has access permissions. This notification may be provided when the first entity outsources management of the analysis of the ECG data to the second entity. In some embodiments, these automatic notifications may be configured in settings associated with the system by the first entity and / or the second entity. For example, the second entity may prefer to receive notifications so that it can know that new data has been uploaded that the second entity may begin analyzing via the system (e.g., when ECG data generated by the first entity is outsourced and analyzed by the second entity, as described above). The automated notification may be provided in any well-known manner, such as by telephone, email communication, and / or text message, etc. The automated notification may also be provided within the system (e.g., presented via a user interface) and / or through the use of an application programming interface (API).

[0223]

[0269] In optional operation 1195, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to receive a request to access the uploaded ECG data. For example, the uploaded data may be stored in a system and a second entity may need to access the data to facilitate analysis. The second entity may access this data, for example, via a user interface associated with the system that may be presented to the second entity via the system. The second entity may use the user interface to access where the data is stored in the system. The system may verify that the second entity has authorization to view the data. If it is determined that the second entity has authorization to view the data, the data may be presented to the second entity via the user interface. In optional operation 1196, computer executable instructions stored in a memory of a device, such as a computing device, may be executed to receive instructions to perform an analysis of the uploaded ECG data. For example, the instructions may be received from the second entity.

[0224]

[0270] Alternatively and / or in addition to acts 1194-1196, the first entity that provided the ECG data may send instructions (e.g., requests, instructions, and / or commands) to perform an analysis on the uploaded ECG data. At act 1193, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to receive instructions to perform an analysis on the uploaded ECG data. If the first entity itself is managing the analysis, the first entity sends this request operation. Thus, if the first entity 1122 is managing the analysis, the process 1190 may perform act 1193 instead of optional acts 1194-1196.

[0225]

[0271] In operation 1197, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to perform an analysis of the uploaded ECG data. For example, the analysis may include any of the processes described with respect to FIG. 4 and / or other possible types of analysis of the ECG data described herein. Such analysis may be used, for example, to identify patient anomalies, events, and / or conditions. The abnormalities, events, and / or conditions may include, but are not limited to, sinus block, paralysis or asystole, atrial fibrillation, atrial flutter, atrial tachycardia, junctional tachycardia, supraventricular tachycardia, sinus tachycardia, ventricular tachycardia, pacemaker, premature ventricular contractions, premature atrial contractions, first degree atrioventricular block (AVB), second degree AVB Mobitz type I, second degree AVB Mobitz type II, third degree AVB, Wolff-Parkinson-White syndrome, left bundle branch block, right bundle branch block, intraventricular conduction delay, left ventricular hypertrophy, right ventricular hypertrophy, acute myocardial infarction, old myocardial infarction, ischemia, hyperkalemia, hypokalemia, Brugada syndrome, and / or QTc prolongation.

[0226]

[0272] In operation 1198, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to generate an analysis report and / or output data corresponding to the analysis of the uploaded ECG data. The report and / or output data may include any information related to the analysis of the ECG data. For example, the report and / or output data may indicate whether an abnormality, event, and / or condition is present in the patient's ECG data. The report and / or output data may also include other types of information, such as a graphical illustration of the ECG data, an indication of multiple different points of interest in the data, data classification performed, and / or other information that may be related to the analysis. The report and / or output may be generated by the system. The report and / or output data may be stored in the system for later access (e.g., to be accessed by a first entity). In some cases, the report and / or output data may be stored in the same folder that contains the uploaded ECG data. However, the report may be stored elsewhere.

[0227]

[0273] In operation 1199, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to receive a request (e.g., from a first entity and / or a second entity) to access and / or generate an analytical report. In operation 1200, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to determine whether to authorize access to the analytical report based on the authorization instructions. For example, the system may determine whether the first entity or the second entity has authorization to access a location in the system where the report is stored and / or whether the first entity or the second entity has authorization to generate an analytical report based on the output data. Further authorization may be required to access the report. The report may be stored in the system and / or may be generated and transmitted to another device without being stored in the system.

[0228]

[0274] In operation 1201, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to provide an analysis report (e.g., to a first entity and / or a second entity). For example, the first entity may be able to view the report via a user interface associated with the system. The system may also allow the first entity to download the report to a local device for local storage and / or viewing. In some cases, however, the system may prevent a user from downloading the report and retain the report within the system for viewing.

[0229]

[0275] In an optional operation 1202, computer-executable instructions stored in a memory of a device, such as a computing device, may be executed to automatically provide an analysis report (e.g., to the first entity and / or the second entity). For example, an automatic notification may also be provided to the first entity when an analysis report is generated, similar to the optional automatic notification provided to the second entity when data is uploaded. These automatic notifications may be configured by the first entity and / or the second entity in settings associated with the system (and / or may not require configuration by either entity). These automatic notifications allow the first entity to know that the analysis is complete and a report has been generated without having to access the system to see if a report has been generated. The automatic notifications may also be provided in any suitable manner, such as by phone call, email communication, and / or text message. The automatic notifications may also be provided within the system (e.g., presented via a user interface) and / or through the use of an application programming interface (API).

[0230]

[0276] FIG. 39 is an example of an account manager user interface 1210. The user interface 1210 may present an example of a user interface that may be presented to a user (e.g., user 1106 and / or user 1107 of FIG. 36). The account manager interface may enable an administrator associated with the first entity to manage user permissions on the system. The administrator may configure which users can see and / or access data contained in a particular folder. For example, the account manager interface may include a table that includes username data 1211, role data 1212, access data 1213, and folder data 1214. The username data 1212 may indicate a particular user, and the role data 1212 may provide information about that user (e.g., manager). The access data 1213 may indicate the user's access permissions. The folder data 1214 may indicate one or more folders to which the user has access permissions or permissions.

[0231]

[0277] The illustrated users may be associated with different entities. A first user may be associated with a second entity and may be authorized to access a first folder (not shown). The first entity may then upload data (e.g., a patient's ECG data) to the first folder, and the first user may be able to access the data from the first folder for analysis. The data in this folder may be downloaded by the first user. Alternatively, the first user may not be able to download the data, but may be able to access and view the data. The first user may be restricted from accessing data contained in other folders associated with the first entity. In this way, the first entity may be able to upload data for another entity to access, while still maintaining confidentiality associated with other data not intended for the other entity.

[0232]

[0278] FIG. 40 is an example of a user interface 1220 for displaying report information. For example, the user interface 1220 may show various reports stored and / or uploaded to the server. These reports may be accessed by or provided to the patient and / or other users. As shown in FIG. 40, the user interface 1220 may include file name data 1221, patient data 1222, label data 1223, upload data 1224, and status data 1225. The file data 1221 may include file names of reports stored in the system. The patient data 1222 may include a patient's name and / or identification value. The label data 1223 may include one or more labels identified within each report that correspond to the patient data 1222. The upload data 1224 may indicate upload data for each report. The status data 1224 may include a download status of a given report (e.g., ready for download or downloaded).

[0233]

[0279] It should be noted that any other type of user interface may be presented to the user, and user interface 1210 and user interface 1220 are not intended to be limiting in any way. For example, user 1107 may be shown a user interface that includes a list of folders that user 1107 has permission to access. User 1106 may be shown a user interface that includes all folders associated with user 1106. Other user interfaces may be provided that enable a user to perform any of the functions described herein.

[0234]

[0280] FIG. 41 is an example of a user interface 1230 for granting and / or modifying certain permissions and / or authorizations. The user interface 1230 may illustrate various toggles that an administrator may control to restrict certain permissions of various users (e.g., any users accessing the analysis system, such as server 1101 of FIG. 36 and / or other analysis systems). For example, toggle 1231 may include access permissions to a particular folder, which may be associated with an identifier, such as a folder name or user identification. Toggle 1232 may include upload permissions to a particular folder. Toggle 1233 may include view access permissions to a particular file in any folder. Toggle 1234 may include access permissions to any data analysis (e.g., any data analysis described throughout this application). Toggle 1235 may include access permissions to view any reports. Toggle 1236 may include access permissions to modify and / or comment on any reports. Toggle 1237 may include access permissions to generate any reports. Toggle 1238 may include access permissions to view and / or modify administrator information. The toggles 1238 may include access permissions for users and / or folders based on duration (e.g., access permissions for a user or folder may be based on a set amount of time). For example, a particular user may only be able to access a particular folder for a set period of time. These are merely examples of user permissions that may be restricted, and other types of user permissions may also apply. Furthermore, only one or more of these permissions and / or authorizations may be included in the user interface 1230. Additionally, the use of on and / or off toggles within the user interface is merely an example, and user permissions may be adjusted using other suitable methods (e.g., check boxes, selection of items from a list, etc.).

[0235]

[0281] Any of the computer operations described herein above may be implemented, at least in part, as computer readable instructions stored in a computer readable memory. It will be appreciated that the embodiments described herein are for illustrative purposes only, and that the components can be arranged, substituted, combined, and designed in a variety of configurations, all of which are contemplated and within the scope of the present disclosure.

[0236]

[0282] The above description of the exemplary embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or limited to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the disclosed embodiments. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.

Claims

1. 1. A computerized method for analyzing electrocardiogram (ECG) data of a patient and restricting access to the analyzed ECG data, the method comprising: receiving, by a server, an authorization instruction corresponding to a first location, a first account, and a second account on the server; receiving a patient ECG dataset from the first account; storing the patient ECG dataset at the first location on the server based on the authorization instruction; processing at least a portion of the patient ECG dataset using an algorithm to determine the presence of one or more abnormalities, conditions, or descriptors corresponding to cardiac events associated with the patient ECG dataset, the algorithm being trained using a plurality of ECG datasets different from the ECG dataset; generating output data based on said presence of said one or more anomalies, conditions, or descriptors; storing the output data at the first location based on the approval instruction; receiving a request for access to the output data from the second account; authorizing the second account to access one or more of the patient ECG data set and the output data based on the authorization instruction; A computerized method comprising:

2. The computerized method of claim 1 , wherein the authorization instruction is received from the second account.

3. 2. The computerized method of claim 1, wherein the authorization instructions include at least one of authorization to access the first location, authorization to upload data to the first location, authorization to access a first type of data in the first location, authorization to access or modify administrative information, authorization to view the output data, authorization to modify the output data, or authorization to generate a report based on the output data.

4. The first location is a first digital folder, and the computerized method further comprises: determining, based on the authorization instruction, that the second account has permission to access the first digital folder; and permitting the second account to access the patient ECG data set in the first digital folder based on a determination that the second account has permission to access the first folder.

5. The computerized method further comprises: The computerized method of claim 1 , further comprising automatically processing the patient ECG data set using the algorithm once the patient ECG data set is received.

6. The computerized method further comprises: The computerized method of claim 1 , comprising receiving a request from the second account to process the patient ECG data set using the algorithm.

7. The computerized method further comprises: The computerized method of claim 1 , further comprising receiving a request from the second account to generate a report based on the output data.

8. The computerized method further comprises: The computerized method of claim 7 , further comprising determining, based on the authorization instruction, that the second account has authorization to request generation of the report.

9. The computerized method further comprises:

2. The computerized method of claim 1, further comprising, upon receipt of the patient ECG data set and storage of the patient ECG data at the first location, sending a message to the second account indicating that the patient ECG data set has been stored at the first location.

10. The computerized method further comprises: receiving a request to view the output data from one or more of the first account and the second account; and granting the request to view the output data based on the approval instructions.

11. The computerized method further comprises: receiving a request to modify the output data from one or more of the first account and the second account; and authorizing the request to modify the output data based on the approval instructions.

12. 1. A system for analyzing electrocardiogram (ECG) data of a patient and restricting access to the analyzed ECG data, the system comprising: a memory for storing computer-executable instructions; at least one computer processor that accesses the memory and executes the computer-executable instructions, wherein when the computer-executable instructions are executed, the at least one computer processor: receiving an authorization instruction corresponding to a first location, a first account, and a second account on the at least one computer processor; receiving a patient ECG dataset from the first account; storing the patient ECG dataset at the first location based on the authorization order; processing at least a portion of the patient ECG dataset using an algorithm to determine the presence of one or more abnormalities, conditions, or descriptors corresponding to cardiac events associated with the patient ECG dataset, the algorithm being trained using a plurality of ECG datasets different from the ECG dataset; generating output data based on the presence of the one or more anomalies, conditions, or descriptors; storing the output data at the first location based on the approval instruction; and receiving a request for access to the output data from the second account; authorizing the second account to access one or more of the patient ECG data set and the output data based on the authorization instruction; To run the system.

13. The system of claim 12 , wherein the authorization instruction is received from the second account.

14. 13. The system of claim 12, wherein the authorization instructions include at least one of authorization to access the first location, authorization to upload data to the first location, authorization to access a first type of data in the first location, authorization to access or modify administrative information, authorization to view the output data, authorization to modify the output data, or authorization to generate a report based on the output data.

15. the first location is a first digital folder, and the at least one computer processor further accesses the memory and executes the computer-executable instructions to: determining, based on the authorization instruction, that the second account has authorization to access the first digital folder; and permitting the second account to access the patient ECG dataset in the first digital folder based on a determination that the second account has permission to access the first folder.

16. The at least one computer processor further accesses the memory and executes the computer-executable instructions to: The system of claim 12 , wherein the algorithm is used to automatically process the patient ECG data set once it is received.

17. The at least one computer processor further accesses the memory and executes the computer-executable instructions to: The system of claim 12 , further comprising: receiving a request from the second account to process the patient ECG data set using the algorithm.

18. The at least one computer processor further accesses the memory and executes the computer-executable instructions to: The system of claim 12 , further comprising receiving a request from the second account to generate a report based on the output data.

19. The at least one computer processor further accesses the memory and executes the computer-executable instructions to: The system of claim 18 , further comprising: determining, based on the authorization instruction, that the second account has authorization to request generation of the report.

20. The at least one computer processor further accesses the memory and executes the computer-executable instructions to:

13. The system of claim 12, wherein once the patient ECG data set is received and the patient ECG data is stored at the first location, a message is sent to the second account indicating that the patient ECG data set has been stored at the first location.

Images