108, the ECG data is made available for the report platform 112. As will be described in more detail below, the report platform 112 can be accessed by a remote computer 116 (e.g., client device such as a laptop, mobile phone, desktop computer, and the like) by a user at a clinic or lab 118.

In other instances, the cardiac event router 110 is used to determine what platform further processes the ECG data based on the classification associated with the cardiac event. For example, if the identified cardiac event is critical or severe, the cardiac event router 110 can flag or send the ECG data, etc., to the notification platform 114. The notification platform 114 can be programmed to send notifications (along with relevant ECG data and associated metadata) immediately to the patient's physician/care group remote computer 116 and/or to the patient 10 (e.g., to their computer system, e-mail, mobile phone application).

Report Platform

FIG. 2 shows the server 106 communicatively coupled (e.g., via a network) to the remote computer 116. In the example of FIG. 2, the remote computer 116 includes a monitor showing a user interface 122 (hereinafter “the UI 122” for brevity) that displays features of the report platform 112 hosted by the server 106. The UI 122 includes multiple pages or screens for tracking and facilitating analysis of patient ECG data.

In certain instances, the report platform 112 is a software-as-a-service (SaaS) platform hosted by the server 106. To access the report platform 112, a user (e.g., a technician) interacts with the UI 122 to log into the report platform 112 via a web browser such that the user can use and interact with the report platform 112. When the user at the clinic or lab 118 is ready to analyze ECG data of a patient, the user can select a patient's profile through the UI 122.

The server 106 (e.g., via programming associated with the report platform 112) can start a process for sending data to the remote computer 116. This data includes the ECG data and metadata associated with the ECG data. As noted above, once the ECG data from the monitored patients has been collected, the machine learning model 108 may determine certain characteristics of the cardiac activity of the patient 10 based on the ECG data, including estimating that a cardiac event has occurred and associating or generating metadata for the determined events. The metadata can include information about the patient 10, a heart rate of the patient 10 during the cardiac event, a duration of the cardiac event, a beat count of the cardiac event, a confidence level of the machine learning model's identification of the cardiac event, and/or a beat classification (e.g., normal, ventricular, supraventricular, unclassified).

In certain instances, the machine learning model 108 assigns each beat with a beat classification and also assigns, for certain groups and patterns of beats, a cardiac event type (e.g., atrial fibrillation, ventricular tachycardia, flutter). To distinguish among the beats, each individual beat can therefore be assigned a unique identifier (e.g., a unique number).

Accessing, processing, and displaying one or more days' worth of ECG data and metadata can consume a large amount of computing resources, network bandwidth resources, and human resources. To help alleviate burdens on these resources, the server 106 (e.g., via the report platform 112) can selectively transmit packages of ECG data and metadata to the remote computer 116.

The initial packages of data can include: (1) short strips (e.g., 60-second strips) of ECG data surrounding detected cardiac events, (2) metadata associated with the strips, and (3) executable code (e.g., JavaScript code). In certain instances, only the ECG data associated with highest priority cardiac events are initially transferred. After the initial packages of data are transmitted from the server to the remote computer 116, additional packages of data can be transmitted in response to selections made by the user in the U 1122.

Report Build Page

With these initial packages of data, the user has access (via the remote computer 116 and the UI 122) to a report build page 200 shown in FIGS. 4-12B. The report build page 200 facilitates analysis of cardiac events and metadata associated with the cardiac events. The pages are generated at the remote computer 116 based on the packages of data and they are selectively displayed via the UI 122. As will be described in more detail below, as the user interacts with the report build page 200, the metadata is updated in real time at the remote computer 116.

FIG. 4 shows a screenshot of the report build page 200. The report build page 200 is used by a user to review and analyze a patient's ECG data and metadata. The report build page 200 includes multiple windows for displaying data, plots, icons, links, markers, indicators, and the like.

Window 202 displays a heart rate plot of multiple days' worth of ECG data. This window 202 provides an initial visual insight into which periods of time appear to contain abnormal heart rate activity. In the example of FIG. 3, the window 202 displays four days of ECG data, although shorter or longer time periods could be displayed by default or changed by the user.

Window 204 allows the user to view a shorter plot of ECG data. For example, the window 204 may display ECG data associated with a detected cardiac event along with ECG data preceding and following the detected event. This window 204 provides visual insight into the onset of a detected event and whether the detected event is perhaps an artifact, follow-on event, etc. As the user scrolls through the window 204, the window 202 can display an indicator (e.g., a vertical line) showing the location of the ECG data of window 204 within the heart rate plot of window 202.

Window 208 shows a plot of ECG data (e.g., approximately 10 beats) that is shorter than the plots of windows 202 and 204. Window 208 displays a closer-up view of a portion of the ECG data of windows 202 and 204. The user can use window 204 to select which shorter set of ECG data is displayed in the window 208. Each of the windows 202, 204, and 208 can include markers, indicators, icons, etc., to visually note the location of detected cardiac events within the strips of ECG data.

Beat Morphology

To the left of the report build page 200 is a beat morphology window 210 (hereinafter “the morphology window 210”), which includes multiple individual sub-windows that display plots of one or more individual beats. The user can use the morphology window 210 to select beats, which can result in updating the windows 202, 204, and 208. For example, the windows 202, 204, and 208 can be updated to show ECG data surrounding the beat selected in the morphology window 210.

FIGS. 5 and 6 show closer-up views of the morphology window 210. FIG. 5 shows the morphology window 210 as displaying multiple sub-windows. Each sub-window can display multiple plots of beats that have been characterized (e.g., by the machine learning model 108) with the same type of cardiac event. The user can select the type of cardiac event (e.g., atrial fibrillation, ventricular tachycardia) from a menu button 212 to display beats associated with the selected cardiac event in the sub-window.

The user can then select individual or sets of beat plots in the sub-window (or all beats associated with the sub-window) and, if desired, change the beat classification (e.g., from an “S” beat to a “V” beat or an “N” beat). Additionally, instead of selecting individual beats, the user can select all beats associated with a given cardiac event and change the beat classification to a different beat classification. Because the machine learning model 108 assigns each beat with an initial beat classification, the report build page 200 can be used to make mass updates to the metadata associated with similarly characterized beats. For example, in FIG. 6, the cardiac event type associated with the sub-window is shown as being associated with 2,607 beats. Using the morphology window 210 of the report build page 200, the user can recharacterize each of those 2,607 beats in one operation (e.g., change the initial classification of the 2,607 beats to a subsequent beat classification). The user can also merge sub-windows using a merge button 214 such that the beats in the two or more sub-windows are characterized with the same cardiac event type.

FIGS. 7 and 8 show other views of how a user can utilize a UI to make changes to beats. In FIG. 7, the user can select a window showing a grouping of similarly classified beats and then select a dropdown menu of options for reclassifying the selected grouping of beats. As shown in FIG. 7, potential options for classification include normal beats, ventricular beats, supraventricular beats, and unclassified beats. FIG. 8 shows another view where a user can select a beat or set of beats and use buttons to change the classification associated with the selected beat(s).

Using one or more of the approaches described above, metadata for thousands to hundreds of thousands (or millions, for long studies) of beats can be updated en masse through the UI. Because a set of ECG data may represent tens of thousands, hundreds of thousands, or even millions of individual beats, this ability to make mass updates to beats saves the user time in analyzing ECG data and, ultimately, building a report.

Event Reclassification

As noted above, one input to determining the type of cardiac event includes the types or classifications of beats that occurred during the cardiac event. As such, when a user makes mass updates to beat classifications, the initial cardiac event classifications should be reassessed. Instances of the present disclosure describe approaches for reassessing cardiac event classifications when the underlying beat classifications are changed. Because reassessing the ECG data may occur at the remote computer 116 (which may not include a machine learning model or have the computational resources to quickly operate a machine learning model), the approaches described herein can be carried out without using the machine learning model 108 operated at the server 106 or another such machine learning model. For example, the approaches may be carried out on the remote computer 116 by executing code sent to the remote computer 116 by the server 106.

In certain instances, in response to beat reclassifications, the remote computer 116 applies a state machine to determine whether and how the initial cardiac event classifications should be reclassified. Inputs to the state machine include the updated (or subsequent) beat classifications, beat classifications surrounding each detected cardiac event, and the initial rhythm classifications of the detected cardiac events surrounding a given cardiac event. In certain instances, the state machine is only applied to regions of the ECG data (or detected cardiac events) that involve one or more reclassified beats. The state machine outputs an annotation indicating a proposed rhythm classification for an underlying range of beats.

A multi-step algorithm is applied on the output of the state machine to apply the proposed rhythm classification changes to the existing rhythm classifications. The multi-step algorithm considers nearby rhythm classifications as well as heart rate and regularity in the affected regions. In addition to reclassifying cardiac events, in certain instances, the output of the state machine and multi-step algorithm results in adjacent sets of rhythms being merged into a single cardiac event and rhythm classification.

The approaches described above allow a user to make mass changes to ECG data by focusing attention on beat reclassifications. FIGS. 9A-12B provide examples of how changes to beat classifications can affect rhythm classifications.

In each of these pairs of Figures, the top figure shows a strip of ECG data containing a cardiac event with its initial rhythm (or event) classification—if any—and beat classifications, and the bottom figure shows the strip of ECG data with modified (or subsequent) rhythm (or event) and beat classifications. The beat classifications are shown in icons at the top of the strip of ECG data. Beats classified as being normal beats are indicated by the letter “N” in the icons, ventricular beats are denoted with a “V”, and supraventricular beats are denoted with an “S”. The rhythm classifications of the cardiac event are shown in ribbons or bands that extend horizontally at the bottom of the strip of ECG data. The length of the ribbons/band visually shows the length of the cardiac event. As noted above, the initial classifications are based on the metadata generated by the machine learning model 108 at the server 106 and received by the remote computer 116. The strips of ECG data also displays the RR intervals (in terms of milliseconds) for respective pairs of beats.

In the example of FIGS. 9A and 9B, the beat classification for three beats was changed from normal (N) to ventricular (V) in the context of an existing normal sinus rhythm (NSR) classification. Ventricular rhythms will be created where three or more consecutive ventricular (V) beats occur. In the example of FIGS. 9A and 9B, the regularity of the beats qualified the rhythm as either an idioventricular rhythm (IVR) or accelerated idioventricular rhythm (AIVR), and then the average heart rate of the three beats was used to select the label of AIVR. Finally, surrounding rhythm classifications were updated too, including the onset/offset of a surrounding NSR label.

In the Example of FIGS. 10A and 10B, the beat classification for three beats was changed from ventricular (V) to normal (N) in the context of atrial fibrillation (AFIB). Typically, a sinus rhythm classification will be created when three or more consecutive normal (N) beats occur. In this case, however, an AFIB rhythm label was created due to the existing AFIBs on both sides. Finally, surrounding rhythm classifications were updated too, including the merging/joining of the affected regions into a single contiguous AFIB cardiac event.