Systems and methods for analysing electrocardiograms using deep learning

Abstract

Provided is a system and method for detecting cardiac abnormalities from electrocardiogram (ECG) data. The system provides an automated ECG platform comprised of standard medical equipment and modules for data acquisition, processing, analysis, interpretation, and a user interface, which can be integrated into existing clinical contexts. The method includes receiving ECG data from a patient, analyzing the data using a trained convolutional neural network (CNN) model to detect predetermined cardiac conditions, and generating an output indicating the presence of these conditions. The CNN model is developed through a deep learning process that includes collecting ECG-echocardiogram pairs from multiple patients, curating the collected data, training the CNN model with the curated data, validating model performance, testing model generalization, and generating diagnostic predictions with confidence scores.

Description

SYSTEMS AND METHODS FOR ANALYSING ELECTROCARDIOGRAMS USING DEEP LEARNINGBENEFIT CLAIMThis application claims the benefit of provisional application 63 / 555,968, filed February 21, 2024, the entire contents of which are hereby incorporated by reference for all purposes as if fully set forth herein.BACKGROUNDElectrocardiogram (ECG) analysis is performed by recording electrical signals from the heart using electrodes placed on a patient’s body and examining the resulting waveforms for diagnostic purposes. Certain interpretation techniques can be performed manually by cardiologists reviewing printed or digital ECGs. Such ECG analysis can rely on rule-based algorithms with predefined criteria, can generate false positives requiring manual review, and can fail to detect complex or unusual patterns. Furthermore, the interpretation techniques can require extensive training and be time-intensive, potentially delaying critical diagnoses.While experienced cardiologists can achieve high diagnostic accuracy, human fatigue, and inter-observer variability can impact consistency. Additionally, subtle patterns indicating early disease can be missed, particularly when analyzing large volumes of ECG data or continuous recordings.Certain automated algorithms can provide rapid results but can miss subtle abnormalities. For example, an ECG device with digital recording capabilities can suffer from signal quality issues, limited sampling rates, or inadequate noise reduction. Due to these limitations, such devices are not necessarily effective to identify subtle ECG features that can be diagnostically significant, particularly in ambulatory or remote monitoring settings.There is a demand for an integrated system and methods for ECG analysis using deep learning that can provide consistent signal processing, accurate pattern recognition across diverse cardiac conditions, and enhanced detection of subtle abnormalities while reducing the burden on human interpreters and improving diagnostic efficiency.SUMMARYThe disclosed subject matter provides an automated ECG system and methods for detecting and characterizing cardiac abnormalities, e.g., structural heart diseases (SHDs), using deep learning analysis of ECG data, that can be integrated into clinical workflows.In some embodiments, an automated ECG system in accordance with the disclosed subject matter comprises standard medical equipment and modules for data acquisition, processing, analysis, interpretation, and a user interface. In one embodiment, the integrated ECG system can analyze standard 12-lead ECG data to identify various cardiac abnormalities with high accuracy across diverse populations. In some embodiments, a computer-implemented convolutional neural network (CNN) model is applied to train on multi-center ECG data and clinical contexts.An exemplary method of detecting SHDs from ECG data in accordance with the disclosed subject matter comprises collecting ECG data, curating the data, and developing a CNN model through a specialized neural network architecture. Model development can include validating the model, testing a generalization of the model, and generating diagnostic predictions with associated confidence scores.In one embodiment, collecting ECG data includes gathering a large dataset of ECG-echo pairs from diverse patient populations and clinical settings. In one embodiment, curating data includes verifying data completeness, sizing the dataset and preprocessing data for controlling data quality, generating attention maps highlighting relevant ECG regions, verifying echocardiogram measurements to meet clinical guidelines, and generating ECG- echocardiogram pairs. Generating the ECG / echocardiogram pairs can further include matching curated ECG data with corresponding echocardiograms within a predetermined timeframe, verifying echocardiogram measurements as ground truth labels, and creating labeled datasets. In one embodiment, the model can be trained as a multi-task classifier to predict the presence or absence of SHDs.In one embodiment, the model can utilize a CNN with multiple channels, of which one can be applied for each ECG lead. In one embodiment, the model can utilize a Residual Network (ResNet) to incorporate short connections for learning disparate features across network layers. In one embodiment, the model can fuse demographic and ECG- specific tabular data directly thereinto.In one embodiment, the model can preprocess ECG data by excluding data with missing age or sex information, poor quality traces, or measurements during ventricular pacing.In one embodiment, validating the model includes assessing its performance. In one embodiment, the model’s performance is assessed using standard metrics, including an area under the receiver operating characteristic curves (AUROC), and an area under the precision-recall curve (AUPRC).In one embodiment, assessing the model’s performance further includes computing the diagnostic odds ratios (OR). In one embodiment, the model’s performance is assessed and demonstrated by comparing it with cardiologists in accuracy, sensitivity, and specificity of detecting SHDs.In one embodiment, testing a generalization includes testing the model across multiple medical systems to ensure generalizability. For example, testing the model generalization can further include evaluating model performance separately across age groups, sex categories, racial groups, and / or ethnic backgrounds, assessing performance parity between demographic subgroups, monitoring for demographic bias in predictions, and generating demographic-specific confidence intervals.In some embodiments, the method further includes releasing the model and dataset to public communities for further studies and benchmarking and expanding the dataset with additional studies and modalities for enhancing operations and outcomes.BRIEF DESCRIPTION OF THE DRAWINGSThe disclosed subject matter includes various drawings referenced throughout the specification. The drawings are provided to illustrate exemplary embodiments and are not intended to limit the scope of the claims. It should be understood that the illustrated embodiments are merely examples and that various modifications, alterations, and variations may be made without departing from the spirit and scope of the disclosed subject matter. The drawings may not be drawn to scale, and certain features and components may be exaggerated or minimized to better illustrate particular aspects. The drawings are intended to be read together with the specification and claims to provide a complete understanding of the disclosed embodiments.FIG. 1 illustrates an example automated ECG system in accordance with the disclosed subject matter.FIG. 2 illustrates training an example CNN model for detecting cardiac abnormalities in accordance with the disclosed subject matter.FIG. 3 is a schematic diagram illustrating an example method for detecting cardiac abnormalities in accordance with the disclosed subject matter.FIG. 4 is a flowchart depicting the process of data collection and filtering for the development of an example CNN model for a multicenter cohort.FIG. 5, FIG. 5A, FIG. 5B, FIG. 5C, and FIG. 5D present a set of performance curves demonstrating the performance of an example CNN model in the detection of individual and compositive SHDs.FIG. 6, FIG. 6A, FIG. 6B, and FIG. 6C present a diagram illustrating the characteristics of an example mini-model ECG dataset and a set of corresponding performance curves.FIG. 7, FIG. 7A and FIG. 7B present a set of graphs showing the calibration of an example CNN model for the detection of SHD in a multicenter cohort.FIG.8, FIG. 8 A and FIG. 8B present a set of graphs showing the performance metrics and curves of an example CNN model for the detection of severe SHDs.FIG. 9 illustrates an example computer system in accordance with the disclosed subject matter.DETAILED DESCRIPTION1. INTRODUCTIONThe disclosed subject matter provides an automated ECG system integrated with an Al model configured to detect causes of SHDs. The disclosed subject matter was developed utilizing a comprehensive dataset and demonstrated consistent performance remaining stable across various clinical contexts, racial demographics, and ethnic groups.The following description outlines numerous details to provide a thorough understanding of the disclosed subject matter. It will be apparent, however, that the disclosed subject matter can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring the disclosed subject matter.The text of this disclosure, in combination with the drawing figures, is intended to state in prose the algorithms that are necessary to program the computer to implement the disclosed subject matter, at the same level of detail that is used by people of skill in the artsto which this disclosure pertains to communicate with one another concerning functions to be programmed, inputs, transformations, outputs, and other aspects of programming. That is, the level of detail outlined in this disclosure is the same level of detail that persons of skill in the art normally use to communicate with one another to express algorithms to be programmed or the structure and function of programs to implement the disclosed subject matter.2. THE AUTOMATED ECG SYSTEMThe disclosed automated ECG system encompasses an ECG analysis platform and a computer-implemented deep learning platform (e.g., EchoNext platform), engineered to function independently or as an integrated unit, providing increased flexibility for detecting cardiac abnormalities including SHDs across diverse clinical settings including emergency departments, inpatient units, outpatient clinics, and procedural areas. The system can demonstrate consistent generalization capabilities while maintaining calibrated predictions across varying disease prevalence rates and clinical contexts.The ECG analysis platform can provide certain core functionality for medical data acquisition, processing, and visualization. In one embodiment, the ECG analysis platform can conduct ECG data collection from standard 12-lead recordings, comprehensive analysis of waveform data, and result presentation through configurable interfaces. This platform can process both demographic data and ECG-derived measurements, including atrial / ventricular rate, PR interval, QRS duration, and corrected QT interval, and supports both standalone and Al-assisted interpretation workflows. Meanwhile, the computer- implemented deep learning platform implements a CNN model and can be trained using millions of ECG-echocardiogram pairs, validated across multiple healthcare institutions, and deployed for detecting cardiac abnormalities, with consistent performance metrics across geographically distinct sites.While the computer-implemented deep learning platform embedding a CNN model provides continuous model improvement through iterative training and validation, the automated ECG system can ensure consistent integration between platforms or independent functionality when required, which is demonstrated through successful external validation at independent healthcare systems. Additionally, the system can maintain high- performance tracking for individual disease components of a disease composite through a multi-task classifier within the model.FIG. 1 illustrates an example automated ECG system 100, including the ECG analysis platform and the computer-implemented deep learning platform housed in a CNNbased analyzer, for detecting cardiac abnormalities including SHDs across diverse clinical settings. The example system architecture provides the processing of large-scale medical data, which is demonstrated through validation across hospitals and multiple external validation sites and model development of over 1.2 million ECG-echocardiogram pairs.The external device 110 represents the primary interface point for healthcare providers or a user 160, implementing specialized capabilities for clinical workflow integration. In some embodiments, the user 160 can be cardiologists, who are presented with two questions for reviewing each analyzed ECG data: whether the patient was likely to have SHDs. In some embodiments, the user 160 interaction pathway provides both standard and Al-assisted interpretation workflows. For example, a cardiologist survey study was conducted where 13 cardiologists reviewed 150 ECGs. The device can facilitate non-AI- assisted and Al-assisted reviews, presenting cardiologists with ECG waveforms, standard ECG-derived features, and patient demographics. This dual-mode operation provided diagnostic accuracy from 64.0% for unassisted interpretation to 69.2% for Al-assisted interpretation, while maintaining the system’s standalone performance of 77.3% accuracy.This device can include a local processor 112 that manages initial data processing and user interface operations, working in conjunction with local memory 114 for temporary data storage and caching of analysis results. In some embodiments, the ECG waveform data can be abstracted at 250 Hz for all digital-stored 12 ECG leads for a total of 30, 000 data points, which can be all processed and stored in the local memory 114. Additionally, for data to be input into a CNN model, the processor can implement preprocessing, including per-lead median signal filter, truncation of severe outliers beyond 0.1stand 99.9thpercentile, and per-lead normalization based on means and standard deviation.The local memory 114 can handle data storage and caching. For example, the local memory 114 can store data from a multicenter cohort of 1,245,273 distinct ECG- echocardiogram pairs. In some embodiments, the local memory 114 can maintain threshold settings. For example, the local memory 114 can store, process, and maintain a model score cutoff of 0.6 for high-risk classification. In a prospective validation study, 27% (4,135 patients) of the ECG / echocardiogram population were predicted as high-risk using this predefined model score cutoff.Display 116 provides visualization of analysis results with configurable threshold displays. In some embodiments, the digital E CG data can be accessed as a PDF, and the name, date, and clinical interpretation can be cropped out of the image, leaving only the waveform and the ECG measurements (ventricular rate, PR interval, QRS interval, QT interval, and axis). In some embodiments, for Al-assisted reviews, the display can show both the model output (0-1) and model interpretation (<0.6 not consistent with SHD, ^0.6 consistent with SHD).In some embodiments, the display 116 can generate attention maps as part of the quality control and interpretability process during the curating of the collected ECG source data. These attention maps comprise visual representations highlighting specific regions of the ECG signal that the model determines to be most relevant for its predictions. For example, the attention mechanism assigns weights to different temporal regions of the ECG signal, with higher weights indicating areas of greater importance for the model’s decisionmaking process. For example, when detecting left ventricular dysfunction, the attention maps may highlight specific characteristics of the QRS complex or ST segment that influenced the model’s prediction. These attention maps serve multiple purposes: (1) they assist in quality control by identifying regions where signal quality is particularly important for diagnosis, (2) they provide interpretability by showing clinicians which ECG features contributed to the model’s predictions, and (3) they help in verifying that the model is focusing on clinically relevant ECG regions rather than artifacts or noise. The attention weights are computed through dedicated neural network layers that learn to identify salient signal features during the training process.The input device 118 can provide for user 160 interaction and data entry 150. In some embodiments, the input device 118 provides for the user 160 to input data including demographic and ECG-specific tabular information (e.g., age, sex, atrial and ventricular rates, and the PR, QRS, and QT intervals) to modify a CNN model training process. For example, these inputs can be fused directly to the linear layer late in the model to maximize the value of these variables and allow the neural network to focus on learning unique discriminative features from the ECG not well captured by clinical variables such as age.The network 120 can implement secure medical data transmission protocols, managing both incoming new data 150 and processed analyzed data 152. For example, this network architecture handled data transmission across 8 hospitals, 190 clinics, and 6echocardiography labs, processing over 1,245,273 ECG-echocardiogram pairs. Furthermore, the disclosed network architecture can support the real-time processing of clinical data across the ECG analysis platform handling data acquisition and process, and the computer- implemented deep learning platform for training a CNN model.In some embodiments, the network 120 supports this dual-platform architecture to integrate demographic and ECG-specific tabular data directly into the linear layer late in the model, allowing for comprehensive analysis while maintaining real-time processing capabilities. For example, the system processed 124,027 ECGs from 84,875 unique patients between January and September 2023, where the system supported by the network 120 ran automatically in the background, generating and storing predictions for immediate clinical use. Additionally, the network 120 supported the real-world implementation of this dualplatform architecture through the cardiologist survey study, where the system simultaneously presented the raw and newly processed ECG data, measurements, and Al predictions to users 160.In some embodiments, the disclosed network 120 can be extended to process data across multiple hospitals across geographically distinct healthcare systems, while maintaining consistent performance metrics. For example, the network 120 demonstrated geographical scalability through successful external validation at Cedars-Sinai Medical Center (n = 10,177 patients), the Montreal Heart Institute (n = 10,862), and the University of California San Francisco Medical Center (n = 6,106).Likewise, within a single site, the network infrastructure can further provide the simultaneous processing of data from emergency department cases, inpatient cases, and outpatient cases, while maintaining consistent performance metrics across all clinical settings. For example, an example network 120 maintained consistent performance across diverse clinical settings, achieving an AUROC range of 79%-84% across emergency departments (33.1% of cases), inpatient settings (39.0% of cases), outpatient clinics (25.2% of cases), and procedural areas (2.0% of cases).The processor 130, housing a CNN-based analyzer 132, can be configured to develop and implement a CNN model, e.g., a validated neural network architecture, that can demonstrate stable performance across data from diverse patient populations. In some embodiments, the processor 130 and the CNN-based analyzer 132 can maintain separate processing pathways for different demographic groups, achieving consistent performance across age categories, gender, and racial / ethnic groups. For example, a CNN model inaccordance with the disclosed subject matter demonstrated great stability across diverse populations, achieving consistent performance metrics as evidenced by similar AUROC values across demographic groups: Hispanic (85.1%), White (84.8%), Black (85.2%), Asian (84.6%), and Other (85.3%). Additionally, the processor maintains stable performance across age categories (AUROC = 85.7% for ages 18-59, 82.1% for 60-69, 80.5% for 70-79, and 78.9% for 80+) and gender (AUROC 85.6% for females, 84.4% for males).The storage unit 140 can maintain multiple trained CNN models 136 with both composite disease detection and individual component analysis capabilities. In some embodiments, these models can achieve validated performance metrics for multiple predetermined cardiac conditions that can be verified by echocardiograms, including e.g., LV systolic dysfunction (AUROC = 90.4%), RV dysfunction (AUROC = 91%), aortic stenosis (AUROC = 86.4%), and other cardiac abnormalities. The storage unit 140 can also contain programmable instructions 138 governing system operation and stores processed data 142 storing processed results with corresponding confidence metrics. For example, the storage unit 140 contained the programmable instructions 138 that govern the preprocessing including per-lead median signal filter, truncation of severe outliers beyond 0.1stand 99.9thpercentile, and per-lead normalization. The processed data 142 can include confidence metrics that achieved clinically significant results, for example, with a diagnostic OR of 12.8 (95% CI 11.6-14.1) as to SHD composition diagnosis performed on the NYP Multicenter test set.The system 100 can implement comprehensive and continuous data flow pathways, where new data 150 enters through the external device 110, undergoes analysis through the CNN-based analyzer 132, and is accumulated and stored in Storage 140. In one embodiment, the system 100 can run in the background, and processed data 142 can be either used for further training or output as a presentation of analyzed data 152 fed back to network 120 for other processing purposes. For example, the system’s background operation was validated in a prospective cohort where 124,027 ECGs acquired between 1 / 1 / 2023 and 9 / 16 / 2023 from 84,875 unique patients were automatically analyzed. Additionally, the processed data further demonstrated high reliability when used for further training, as evidenced by the successful development of the “Columbia Mini-Model” trained on a subset of 100,000 ECGs, which achieved comparable performance (AUROC=82.0%) to the full model.Overall, the system can maintain calibration and performance monitoring capabilities across all components, as validated through comprehensive calibration curves and performance metrics across multiple validation cohorts, as further discussed herein. The results show internal test data (AUROC=85%), three additional external health systems not included in training (AUROC=78-80%), and temporally-distinct data collected after model development (AUROC=83%), where calibration was specifically monitored through precision-recall metrics (AUPRC=78.5%) and diagnostic OR (OR=12.8). Additionally, the system can maintain stable performance across varying disease prevalence rates (from 36% in the NYP multicenter test cohort to 54%, 52%, and 46% in external validation systems and cohorts) and different clinical settings (emergency AUROC=84.1%, inpatient AUROC=84.1%, outpatient AUROC=84.3%).Furthermore, performance monitoring can also extend to individual disease components using a trained multi-task classifier, with the highest performance in detecting RV dysfunction (AUR0C=91%) and LV systolic dysfunction (90%) while maintaining performance for other conditions such as valvular diseases (AUROC range 77-86%). The system actively tracks performance across demographic subgroups, maintaining consistent metrics across race (AUROC range 84.6-85.3%), gender (female AUROC=85.6%, male AUROC=84.4%), and age categories (AUROC range 78.9-85.7%). The system demonstrated consistent performance through multiple validation approaches. This can provide consistent performance regardless of disease prevalence variations or clinical setting differences.FIG. 2 illustrates an example CNN-based analyzer 132, implementing a deep learning architecture and achieving consistent performance across multiple validation cohorts. The analyzer 132 processes paired input data 152, comprising ECG data 150a and echocardiogram data 150b, for training, validating, and testing CNN models. In one embodiment, this paired data approach can support successful training on 1,245,273 ECG- echocardiogram pairs from 230,318 unique patients.In some embodiments, the computer-implemented deep learning platform, embedding a CNN training architecture for the detection of cardiac abnormalities, including SHDs, implements the created ECG-echo pair through data analyzing component 152. This component 152 can manage the temporal alignment of ECG and echocardiogram data, and ensure proper handling of the data (e.g., one-year maximum time difference) obtained between ECG and echocardiogram studies, as validated in the development cohort. In someembodiments, for using the trained CNN architecture to characterize cardiac abnormalities, including diagnosis of SHDs, a group of ECG data 150a undergoes preprocessing 154 to generate 12-lead ECG data including quality control measures, removing all studies with poor quality traces, or measurements acquired during ventricular pacing.In some embodiments, missing atrial rate or PR intervals were imputed as 0; other ECG-derived measures were imputed with the median value. Additionally, ECGs were preprocessed for input into the model by undergoing a per-lead median signal filter, truncation of severe outliers beyond 0.1st and 99.9th percentile, and per-lead normalization based on means and standard deviation. The output for the model is a number from 0 to 1, with numbers closer to 1 indicating a higher model confidence that the disease is present.In some embodiments, the computer-implemented deep learning platform, embedding a CNN training model 320, implements a sophisticated architecture across multiple healthcare environments. The architecture embedded in the CNN model 320 can employ specific design elements, including 1 -dimensional CNN with twelve channels for processing the combined ECG-echo pairs 152 and ResNet blocks 322 using shortcut connections with validated hyperparameters. In some embodiments, the architecture begins with a 1 -dimensional CNN layer that processes all twelve ECG leads simultaneously, applying the same convolutional filters across each lead to maintain the interpretability of known ECG features like QRS complexes. The input layer accepts standardized data comprising ECG waveforms (12 leads x 2500 timepoints) sampled at 250 Hz and seven clinical variables (age, sex, atrial rate, ventricular rate, PR interval, QRS duration, and corrected QT interval).The ResNet blocks 322 can further provide deep feature extraction capabilities through a series of connected processing stages, implementing the specific architectural details that achieved superior performance metrics. In some embodiments, the ResNet block 322 includes two convolutional layers with batch normalization and Rectified Linear Unit (ReLU) activation, implementing shortcut or skip connections to learn disparate features across many layers of the network. For example, the network architecture comprises four sequential groups of ResNet blocks with increasing filter sizes (16, 32, 64, and 128 filters respectively) with the same time width across all leads at once. In some embodiments, the shortcuts of ResNet blocks 322 can implement identity mappings, allowing unimpeded gradient flow through the network. For example, the architecture can employ 1*1 convolutional layers specifically for dimension matching when the input and outputdimensions of a block differ, enabling flexible feature map transformation while maintaining spatial information. Addition operations can be implemented to combine the shortcut path with the main convolutional path, allowing the network to learn residual functions. This framework enables the training of substantially deeper networks while maintaining model stability and improving gradient flow throughout the network.In some embodiments, the CNN analysis module or the CNN-based analyzer 132 can implement a hierarchical feature extraction architecture through multiple convolutional layers with ReLU activation functions. The first convolutional layer is specifically configured to process the 12-lead ECG input data, with filters designed to capture basic signal patterns across all leads simultaneously. Subsequent convolutional layers are configured to extract increasingly complex and abstract features in a hierarchical manner, with each layer learning to identify more sophisticated ECG patterns based on the features extracted by previous layers. Pooling layers are strategically placed between convolutional layers to perform dimensionality reduction, reducing the spatial dimensions of the feature maps while retaining important information. This reduction in dimensionality through pooling operations helps manage computational complexity while maintaining essential signal characteristics. The combination of ReLU activation functions, hierarchical feature extraction, and strategic dimensionality reduction enables effective learning of ECG signal patterns at multiple scales and abstraction levels.The first block in each group can perform a down sampling using convolutions with various stride sizes. The demographic and ECG-specific tabular data (e.g., the seven clinical variables) are processed separately and concatenated with the flattened output of the final ResNet block before being passed to a fully connected layer with 12 output nodes. This late fusion architecture provides for the convolutional layers to focus on extracting waveform features while preserving the direct influence of clinical variables. For example, the system can fuse demographic and ECG-specific tabular data directly to the linear layer late in the model to maximize the value of these variables and allow the model to focus on learning unique discriminative features from the ECG data that are not well captured by clinical variables, such as age. In some embodiments, these ResNet blocks 320 can process the 12-lead ECG data sampled at 250 Hz, maintaining consistent performance across different ECG acquisition systems.The batch normalization layers 324 can implement feature-wise standardization procedures after each convolutional layer in the network for maintaining consistentperformance across diverse patient populations. For example, the batch normalization layer 324 can calculate running means and variances for each of the 16 feature channels in the first layer, applying learnable scale and shift parameters to normalize activations. These layers support consistency across different hospitals and clinical settings, enabling reliable generalization to new environments, as evidenced by stable AUROC ranges of 80%-87% across eight different hospitals with varying patient populations.The dropout layers 326 can implement regularization with a validated dropout rate by randomly deactivating a certain percentage of neurons during training (e.g., a rate of 0.5 means deactivating 50% of neurons during the training), preventing overfitting while maintaining model generalization capabilities. For example, this dropout strategy proved effective in preventing overfitting, as demonstrated by consistent performance between training (AUROC=85.2%) and external validation cohorts (AUROC=78-80%).The validation pathway 340 can provide continuous performance monitoring during model training, implementing the metrics that demonstrated consistent performance across development and validation cohorts. This component supports the evaluation of both composite disease detection and individual component performance, maintaining separate tracking for each disease category.In some embodiments, the training of the CNN model implements further specific parameter optimization techniques to ensure model stability and prevent overfitting. The training process processes data in batches, with a batch size selected to balance computational efficiency and model convergence. The method utilizes convolutional filters corresponding to the batch size to maintain consistent feature extraction across training iterations. For example, the training process applies weight decay for regularization, with a specific weight decay value of 0.01 found to provide optimal regularization without unduly constraining model capacity. A dropout probability of 0.5 is implemented during training, randomly deactivating half of the neurons to prevent co-adaptation and improve generalization. The model’s weights are optimized and adjusted using the Adam Optimizer, employing a learning rate of 5e-5, which was empirically determined to provide stable convergence while allowing effective learning of complex patterns in the ECG data. This combination of training parameters enables efficient model optimization while maintaining generalization capability across diverse patient populations and clinical settings.During training, it can calculate AUROC, AUPRC, Fl -scores, and diagnostic OR for both the composite SHD prediction and eleven individual disease components. Forexample, it tracks performance ranging from RV dysfunction (AUROC = 91%, AUPRC = 40.8%) to aortic regurgitation (AUROC = 77.7%, AUPRC = 5.8%). The test pathway 360 evaluates model generalization across demographics (age AUROC = 78.9-85.7%, race AUROC = 84.6-86.2%), clinical settings (emergency AUROC = 84.1%, inpatient AUROC = 84.1%, outpatient AUROC = 84.3%), and disease prevalence variations (36% to 54% across validation sites), ensuring stable performance and generalization capabilities across diverse clinical contexts.The output component 380 can implement dual functionality as both a multi-task classifier and an individual component label generator. This flexible output structure can provide both composite disease detection and individual condition assessment for specific conditions, supporting comprehensive cardiac evaluation capabilities. For example, a primary pathway was configured to produce a continuous risk score (0-1) for composite SHD detection with a validated threshold of 0.6, achieving precision and recall of 74% and 53%, respectively, in prospective validation. Simultaneously, it generated individual probability scores for specific conditions using clinically validated thresholds. In some embodiments, the model incorporates specialized processing pathways for severe SHD detection, implementing modified thresholds and classification criteria for critical conditions. For example, the severe disease pathway was configured to implement more stringent criteria, (LVEF35%, LVWT 23 1.6 cm, server valve disease, PASP 2= 60 mmHg), achieving enhanced specificity (AUROC = 87.7%) while maintaining appropriate sensitivity and specificity levels for different clinical contexts.In some embodiments, the CNN analysis module (i.e., the CNN-based analyzer 132) can include specialized output layers configured to process and generate final predictions to the output component 380. These output layers are specifically designed to handle multiple prediction tasks simultaneously while maintaining calibrated outputs. The output layers process extracted features from earlier convolutional and ResNet layers for each specific prediction task, with separate pathways for different cardiac conditions. The architecture implements multitask-specific activation functions to generate probability scores for each condition. For example, using ReLU or sigmoid activation for binary detection tasks and softmax activation applied for multi-class predictions. In some embodiments, the output layers can be further configured to produce calibrated confidencescores, ensuring that the predicted probabilities accurately reflect the model’s uncertainty across different clinical settings and patient populations.Overall, the computer-implemented deep learning platform can maintain flexible and bidirectional connections between components, enabling continuous performance monitoring and model refinement and allowing dynamic information flow in both forward and backward directions. This adaptive connectivity pattern means the layer sequence is not rigidly fixed but can be improved or optimized based on performance requirements. These connections supported the development of calibrated predictions across different disease prevalence rates and clinical settings, as demonstrated in the prospective validation cohort and the examples in the following sections.For example, while the basic structure flows from input through convolutional layers, ResNet blocks, and output layers, the skip connections and shortcut pathways provide direct information transfer between non-adjacent layers. For example, the ResNet blocks can bypass intermediate layers through shortcut connections, while the demographic and ECG-specific tabular data can be directly fused into the linear layer late in the model. This flexible architecture achieved calibrated predictions across varying disease prevalence rates (36-54%) and clinical settings, as validated in the prospective cohort of 124,027 ECGs. The bidirectional nature of these connections provides both forward propagation of predictions and backward propagation of performance metrics, supporting continuous model refinement while maintaining consistent performance (AUROC 78-85%) across diverse healthcare environments. For example, the batch normalization layers 324 and dropout layers 326 can be integrated within ResNet blocks. In some embodiments, a batch normalization layer 324 can be added right after any convolutional layer but before a ReLu activation layer, while a dropout layer 326 can be added right after the convolutional layer.3. METHODS OF DETECTING CARDIAC ABNORMALITIESThe disclosed subject matter provides methods for detecting cardiac abnormalities, including SHDs, which comprises a workflow integrating data processing, quality control, model analysis, and output generation. FIG. 3 is a flowchart of an embodiment of a method 500 for detecting cardiac abnormalities including SHDs. In some embodiments, the method 500 is performed by the processor 112, which executes instructions 138 stored in the storage 140, as shown in FIG. 1. However, method 500 is not limited to being performed by the process 130, as shown in FIG. 1.The example method 500 starts by receiving new ECG data at operation 505. In some embodiments, these new ECG data comprising a standard 12-lead ECG, which is then processed including being sampled at 250 Hz across all leads, generating 30,000 data points per recording. In some embodiment, the process 112 receives the data from an external device 110 or another device associated with a user 160. Alternatively, or additionally the new data may be obtained from a different device connected to the processor 130 through the network 120. Further, the new data may have been previously stored in storage 140.Once the new data is received in operation 505, the method proceeds to quality control operation 510. In operation 510, the local processor 112, implements automated quality control measures to exclude ECG data in storage 140 with poor signal quality or the presence of ventricular pacing. For ECG data passing quality control, the processor 112 processes the waveforms of the ECG data 515a, extract ECG-derived measurements 515b including atrial rate, ventricular rate, PR interval, QRS duration, and corrected QT interval, and extract demographic information 515c such as age and sex. Additionally, the processor 130 can exclude any ECG data (at operation 520) that fail the quality control operation 510.Once the ECG data are processed at operation 510, the method proceeds to operation 525, where the processor 130 of the CNN-based Analyzer 132 (shown in FIG. 2) process this data through a CNN model retrieved from the storage 140. In some embodiments, the retrieved CNN model 320 takes an architecture where ECG waveform data is analyzed through multiple convolutional layers described with regards to FIG. 2, while demographic and ECG-derived measurements are fused at a late-stage linear layer. However, the trained CNN models 320 may take any form appropriate to the input and processed ECG data without departing from the disclosure.Once the CNN models 320 are retrieved and ECG data are processed through the CNN models in operation 525, the method proceeds to operation 530, where the processor 130 implements multiple detection pathways to produce predicted results: one branch predicts the presence of composite structural heart disease, while separate terminal branches detect individual conditions including left ventricular systolic dysfunction (LVEF s£45%), left ventricular hypertrophy (wall thickness ^ 1.3 cm), right ventricular dysfunction, pulmonary hypertension (PASP ^45mmHg or TR jet velocity 5= 3.2 m / s), and various valvular diseases. In some embodiments, the method can process additionalspecialized detection pathways assess severe disease conditions using modified thresholds (e g., LVEF ^35%).At operation 535, the processor 130 can generate both composite and individual component risk assessments, with the output calibrated for consistent performance across different clinical settings. In operation 535, the processor 130 can communicate through the network 120 with the local processor 112 of the external device to display the predicted results to a user 160 to confirm the results via the display device 116 and the input device 118. In some embodiments, the method includes processing the output results in the local processor 112 and the local memory 114 to be validated by a user 160. In some embodiment, the method further includes storing the validated results in storage 140 through the network 120 and causing the processor 130 to train the CNN models 136 using the validated results. In some embodiments, the method further includes updating the CNN models 136 in storage 140 for next processing of input ECG data.In some embodiments, the method incorporates multiple data elements beyond raw waveform analysis are incorporated, including demographic information (age and sex) and ECG-derived measurements (atrial rate, ventricular rate, PR interval, QRS duration, and corrected QT interval). These additional features are assembled and fused with processed waveform data to provide a comprehensive cardiac evaluation.In some embodiments, the methods include detecting cardiac abnormalities using specific detection thresholds for various cardiac conditions, including left ventricular ejection fraction =$45%, maximum left ventricular wall thickness 5= 1.3 cm, moderate or severe right ventricular dysfunction, pulmonary hypertension (PASP ^45mmHg or TR jet velocity 5= 3.2 m / s), and moderate or severe valvular diseases. These detection methods were validated using a dataset of 1,245,273 ECG-echocardiogram pairs from multiple healthcare systems and clinical settings (e.g., 8 hospitals, 190 clinics, and 6 echocardiograph labs).In some embodiments, the disclosed subject matter provides detection capabilities across 11 distinct cardiac conditions with independent detection pathways for each component, while maintaining separate performance metrics for each component. For example, the detection methods demonstrated improved performance in identifying right ventricular dysfunction and left ventricular systolic dysfunction, while maintainingconsistent performance across other conditions, including valvular diseases and pulmonary hypertension, as validated in the aforementioned dataset.In some embodiments, the disclosed subject matter implements automated quality control measures, excluding ECGs with poor signal quality or the presence of ventricular pacing. For example, quality control processes were validated through the successful processing of over 1.2 million ECG-echocardiogram pairs across multiple healthcare systems, as discussed elsewhere in this specification.In some embodiments, the disclosed methods maintain consistent performance across diverse clinical settings, including emergency departments (AUROC 84.1%), inpatient units (AUROC 84.1%), and outpatient clinics (AUROC 84.3%). This validation was performed using dedicated test sets from each clinical environment. This consistency provides reliable deployment across various healthcare environments while maintaining calibrated predictions regardless of clinical context.In some embodiments, the methods include protocols based on specialized detection pathways for severe disease detection. For example, the methods implemented modified thresholds for critical conditions such as LVEF s£35%, severe valvular disease, and severe pulmonary hypertension. These specialized detection pathways can provide appropriate risk stratification for patients with more severe cardiac abnormalities.In some embodiments, the disclosed methods provide both composite disease assessment and individual component analysis capabilities, enabling flexible application based on clinical requirements. This dual-output capability supported improved performance compared to cardiologist interpretation in direct comparison studies (e.g., against 13 cardiologists reviewing 3,200 ECGs), with system accuracy of 77.3% compared to 64.0% for unassisted cardiologist interpretation.4. EXAMPLESThe following examples demonstrate various implementations and aspects of the disclosed subject matter for detecting structural heart disease. These examples are provided to illustrate different features and capabilities of the disclosed subject matter, supported by validation across multiple healthcare institutions and patient populations. Each example describes an embodiment of the disclosed subject matter, with performance metrics and implementation details derived from large-scale clinical studies, and with reference to relevant tables and figures.The examples illustrate various aspects of the disclosed subject matter, such as patient cohort analysis and clinical setting classification, to neural network architecture, external validation, and comparison with expert cardiologist interpretation. These examples are intended to be illustrative rather than limiting, and various modifications and adaptations of the described embodiments can be made while remaining within the scope of the disclosed subject matter.According to one embodiment, FIG. 4 illustrates an example model development cohort derivation process 400 implemented across an eight-hospital system (New York- Presbyterian Hospital) including the complete data flow pathway from initial access through quality control to final cohort establishment. The system implements a two-stream data access approach, simultaneously processing ECG data through the MUSE system at process 410 and echocardiogram data through the hospital system (e.g., Xcelera / Syngo) at process 420. For ECG data processing at process 430, the system implements specific exclusion criteria including removal of ECGs with missing age / sex / patient identifier, poor study designation by machine recommending repeating of ECG, or presence of ventricular pacing. Similarly, for echocardiogram data at process 440, the system excludes patients with repaired or replaced heart valves and uses the eligible echocardiogram data as ground truth labels for training a neural network.Through this systematic processing approach 400, the disclosed example process achieves a final dataset of 1.2 million ECG-echocardiogram pairs from 230,018 unique patients at operation 450. In some embodiments, at process 460, the method proceeds to divide the processed ECG-echo dataset into training, validation, and test sets to provide model development and evaluation. In some embodiments, the method includes allocating approximately 90% of the overall data for training, approximately 5% for validation, and approximately 5% for testing. The validation and test sets are selected to represent diverse patient populations and clinical settings. In some embodiments, the process provides for the development of models capable of generalization across diverse patient populations and clinical settings, as demonstrated through subsequent validation studies.According to one embodiment, an example system for analyzing SHDs comprises a processor 130, as described above in FIG. 1, that is configured to process patient cohort data across multiple demographic categories. The system was trained using a dataset comprising 149,819 patients for training, 35,780 patients for validation, and 44,719 patients for testing, as demonstrated in Table 1 of the implementation data. The processor 130 isconfigured to analyze patient age distributions across four primary categories, with exact distributions validated in Table 1 : e.g., 18-59 years (39.9% in training), 60-69 years (24.1% in training), 70-79 years (20.7% in training), and 80+ years (15.4% in training). The processor 130 analyzes gender distribution data, showing 51.3% of male patients in the training set and 47.9% of male patients in validation and test sets. The processor 130 further analyzes race and ethnicity distributions as detailed in Table 1, including Hispanic (23.1% in training), White (33.9% in training), Black (17.8% in training), Asian (5.5% in training), Other (8.5% in training), and Unknown (11.3% in training). Table 1: Characteristics of NYP Multicenter Cohort used for Model Developmentreduced; {Clinically classified as moderate or large.According to one embodiment, the system comprises modules, as described in FIG. 1, for processing patient data across distinct clinical settings. As validated in Table 1, the processor 130 of the example system is configured to classify encounters into four primary categories except for the unknown data sources: Emergency Department encounters (35.6% in training data), Inpatient encounters (43.6% in training data), Outpatient encounters (18.4% in training data), and Procedural encounters (1.8% in training data). The system maintains consistent classification capabilities across these settings in both validation and test datasets, with emergency cases representing approximately 33%, inpatient cases 39%, outpatient cases 25%, and procedural cases 2% of encounters in these sets.In some embodiments, the processor 130 is configured to implement comprehensive disease prevalence tracking across multiple SHD components. In the training dataset, the system maintains separate counters for each disease category, tracking an overall SHD prevalence of 44.9% (357,726 cases). For example, in the training data, the processor 130 tracks prevalence rates for individual conditions, including left ventricular ejection fraction (LVEF) s£45% affecting 20.4% of cases (162,776 patients), left ventricular wall thickness (LVWT) 5= 1.3cm present in 16.7% of cases (133,026 patients), and pulmonary artery systolic pressure (PASP) ^45mmHg occurring in 19.6% of cases (155,798 patients).In some embodiments, the processor 130 implements tracking for valvular conditions, maintaining separate prevalence calculations for each valve type. For example, in the training dataset, this includes moderate or severe aortic stenosis affecting 4.0% of cases (31,794 patients), moderate or severe aortic regurgitation in 1.9% of cases (15,016 patients), moderate or severe mitral regurgitation in 8.3% of cases (66,084 patients),moderate or severe tricuspid regurgitation in 10.0% of cases (79,907 patients), and moderate or severe pulmonary regurgitation in 0.7% of cases (5,954 patients).In some embodiments, the processor 130 further maintains tracking of additional cardiac conditions in the training dataset, including moderate or severe right ventricular (RV) systolic dysfunction affecting 9.6% of cases (76,827 patients), moderate or large pericardial effusion present in 2.5% of cases (20,047 patients), and elevated tricuspid regurgitation velocity (TR Vmax) ^3.2cm / s occurring in 10.4% of cases (82,893 patients).Overall, the system can ensure consistent prevalence tracking across validation and test datasets, with mechanisms for detecting and accounting for any significant deviations from expected prevalence rates.As shown in Table 2, the example system maintains performance thresholds including AUROC values of 85.7% for ages 18-59, 82.1% for ages 60-69, 80.5% for ages 70-79, and 78.9% for ages 80+. In Table 2, the processor 130 implements separate performance tracking for each racial and ethnic category, maintaining AUROC values between 84.6% and 86.2% across all groups. Furthermore, the system maintains distinct processing pathways for each clinical setting while ensuring consistent performance metrics across all categories, with AUROC values of 84.1% for emergency settings, 84.1% for inpatient settings, and 84.3% for outpatient settings. Procedural settings (N=891, 50.5% prevalence) demonstrate comparable metrics (AUROC of 82.6%) despite a smaller sample size.Table 2: Model Performance by Patient Subgroups from the NYP Multicenter Test SetThe example system also maintains consistent performance across diverse healthcare facilities. For example, at Weill Cornell (N=15,736, 32.5% prevalence), the processor achieves an AUROC of 85.5% (95% CI 84.2-86.7%) and an OR of 13.4 (95% CI 12.3-14.6). CUIMC (N=16,626, 40.9% prevalence) shows an AUROC of 85.1% (95% CI83.9-86.2%) and an OR of 12.4 (95% CI 11.5-13.4). Smaller facilities maintain comparable performance, with Brooklyn Methodist (N=889, 40.4% prevalence) showing an AUROC of 85.4% (95% CI 80.1-90.4%) and an OR of 16.8 (95% CI 11.7-23.6). This consistent performance across facilities of varying sizes and patient populations demonstrates the system’s consistent generalization capabilities.In some embodiments, as validated in Table 3 and visualized in FIG. 5 A and FIG. 5B, the processor 130 of the example system is configured to implement separate classification protocols for severe SHD states. In a test set from the NYP Multicenter Cohort, these severe conditions showed a combined prevalence of 16.1%. The detection methods, when applied to these severe phenotypes, demonstrated enhanced performance metrics compared to moderate or severe SHD detection, achieving an AUROC of 87.7% shown in FIG. 5A and an AUPRC of 60.8% shown in FIG. 5B.Table 3 : Severe SHD Prevalence in the NYP Multicenter CohortIn FIG. 5C, individual disease detection showed varying performance characteristics. The system can maintain highest performance in detecting reduced left andright ventricular systolic function. Performance metrics for individual disease states, as measured by AUPRC and shown in FIG. 5D, showed correlation with the underlying prevalence of each condition in the test dataset. Notably, AUPRC is particularly relevant when the cardiac conditions are rare. In FIG. 5D, that the system maintains a AUPRC of 60.8% for severe SHD with a combined prevalence of 16.1% demonstrates performance metrics comparable to common conditions.In some embodiments, the system implements separate classification protocols for severe disease states as validated in Table 3. The processor is configured to identify severe structural heart disease using modified thresholds, with test set prevalence rates of 7.7% for LVEF s£35%, 2.4% for LVWT^ 1.6cm, 2.5% for severe aortic stenosis, 0.2% for severe aortic regurgitation, and other severe conditions as detailed in the table. The system maintains separate performance metrics for severe disease detection, with modified sensitivity and specificity thresholds appropriate for these lower prevalence rates.According to FIG. 6A and Table 4, the system includes specialized visualization capabilities for analyzing publicly released datasets. For example, the Columbia mini-model as illustrated in FIG. 6, trained on this public dataset, demonstrates performance metrics comparable to the full multiset model, achieving AUROC values similar to the primary analysis.The system can process a dataset comprising 100,000 ECG-echo pairs (operation 600) from Columbia University Irving Medical Center. The system further splits the dataset into training (72,475 pairs), validation (4,626 pairs), and test (5,442 pairs) sets (operation 620) shown in Table 4 and reports the performance of the model within the public dataset shown in Table 5, FIG. 6B and FIG. 6C, including assessment by both AUROC and AUPRC metrics. These results validate the utility of the public dataset for developing effective SHD models while providing a benchmark for future research and development efforts.Table 4: Patient characteristics for the Columbia ECG Cohort

[0001] Furthermore, the system’s performance was additionally assessed in the NYP Multicenter Cohort for direct comparison with the validated model (Table 5). Table 5 shows a multi-task model that predicts both the composite SHD label and a component disease. Performance for each individual disease component is further included in Table 5 and Table6. For example, the system, using the Columbia Mini-Model can track performance metrics for individual disease components as specified in Table 5 and Table 6, maintaining separateAUROC, AUPRC, Fl -score, and OR calculations for each condition in both multicenter and single-center contexts.Table 5: Component label performance of Columbia Mini -Model in NYP Multicenter test setTable 6: Component label performance of the Columbia Mini -Model in the Columbia ECG test setAccording to one embodiment, the system implements prospective analysis capabilities as validated in Table 7. The processor is configured to analyze newly acquired ECGs, maintaining consistent performance metrics. The system implements specific threshold values for risk stratification, with Table 7 detailing the positive predictive values at various sensitivity levels across different disease prevalence scenarios. For example, for a baseline disease prevalence of 0.5%, the system achieves positive predictive values ranging from 27.3% at 10% sensitivity to 1.0% at 90% sensitivity. As disease prevalence increases, the positive predictive values show corresponding improvements. For instance, at 5% disease prevalence, the system demonstrates positive predictive values of 69.6% at 10% sensitivity, decreasing to 9.7% at 90% sensitivity. The highest performance is observed at 15% disease prevalence, where the system achieves positive predictive values of 87.6% at 10% sensitivity, maintaining clinically meaningful performance of 27.4% even at 90% sensitivity.Table 7: Estimates of prospective screening performance using EchoNextTable 7 illustrates utility in real-world screening scenarios, where disease prevalence can vary significantly. For moderately prevalent conditions (if the prevalence of SHDs is 10% prevalence), the system maintains consistent positive predictive values of 83.6% at 10% sensitivity and 46.5% at 50% sensitivity, suggesting practical utility for clinicalscreening applications while balancing sensitivity and specificity requirements. These metrics provide guidance for implementing appropriate screening thresholds in various clinical contexts with different underlying disease prevalence rates.According to one embodiment, the system implements a specific neural network architecture for ECG analysis, as detailed in Supplemental Table 1. The architecture includes an input layer accepting 12-lead ECG data at a 250 Hz sampling rate, formatted as [16, 1, 2500, 12], The network includes a first convolutional layer implementing 16 filters with batch normalization, followed by multiple residual blocks. Each residual block comprises two convolutional layers with ReLU activation and skip connections, as specified in Table 8. The network progressively expands channel dimensions from 16 to 128 channels through successive layers, with exactly 1,046,080 trainable parameters.Referring to Table 8, the model architecture comprises a total of 1,046,080 parameters, all of which are trainable with no non-trainable parameters. The computational requirements include 2.08 billion multiply-add operations. In terms of memory utilization, the model requires 1.92 MB for input data, 95.12 MB for forward / b ackward pass operations, and 4.18 MB for parameter storage, resulting in a total estimated memory footprint of 101.22 MB. These specifications demonstrate the model's efficient architecture, balancing computational complexity with memory requirements while maintaining all parameters as trainable for optimal learning capability.Table 8: EchoNext model architecture and parametersAccording to one embodiment, the system implements external validation protocols across multiple healthcare institutions, as detailed in Table 9. The processor is configured to analyze and validate performance across distinct patient populations from Cedars-Sinai (10,177 patients), Montreal Heart Institute (10,862 patients), and UCSF (6,106 patients). The system handles varying disease prevalence rates of 52.2% at Cedars-Sinai, 54.4% at Montreal Heart Institute, and 45.6% at UCSF while maintaining consistent performance metrics as shown in FIG. 5 A and FIG. 5B. Table 9: Characteristics for external validation cohortsAccording to one embodiment, the system implements a comparative analysis between machine learning predictions and cardiologist interpretations, as demonstrated in the Central Illustration and detailed in Table 10. The processor is configured to analyze performance on standardized test sets of 150 ECGs, with 3,200 total cardiologist interpretations. The system demonstrates accuracy rates of 77.3% for the Al system compared to 64.0% for unassisted cardiologist interpretation and 69.2% for Al-assisted cardiologist interpretation, with specific sensitivity and specificity metrics detailed in Table 10.Table 10: Cardiologist survey resultsAccording to one embodiment, the system implements individual performance tracking for distinct cardiac conditions as detailed in Table 11. The processor can maintain separate performance metrics for each component, with AUROC values of 90.4% for LVEF 77.2% for LVWT 5= 1 ,3cm, 86.4% for aortic stenosis, 77.7% for aortic regurgitation, and corresponding AUPRC, Fl -score, and OR metrics for each condition as specified in the table.Table 11 : Model performance for all component labelsAccording to one embodiment, the system implements validation protocols for individual hospital campuses. As detailed in Table 12, the processor maintains separate performance tracking for different hospital environments, processing distinct patient populations with varying characteristics. For example, there are 407,876 ECGs from East campus hospitals and 469,439 ECGs from West campus hospitals. The system accounts for demographic variations between campuses, such as the differing prevalence of Hispanic patients (12.9% East vs. 31.4% West) and varying clinical setting distributions (Emergency Department: 33.5% East vs. 37.1% West).Table 12: Cohort characteristics by NYP campus (Combined, East, West)** Moderate or severe RV systolic dysfunction ***Moderate or large pericardial effusion In Table 12, for validation and test set, only one ECG per patient was used.Therefore, the total number of ECGs is smaller than the number reported in the results and FIG. 4 (operation 450, N=l,245,273). However, the total number of patients stays the same. Additionally, there is a small percentage of patients who had ECGs from both the East and West campuses, and therefore, the sum of East and West campus patients is greater than the total number of patients. However, there is no patient overlap between the east and west campus test sets. Furthermore, according to Table 13, the system maintains consistent performance despite these variations, with dedicated training and validation cohorts for each campus environment. Table 13: Patient characteristics for internal cross-validation cohorts*Valvular heart disease labels were defined as moderate or severe in severity** Moderate or severe RV systolic dysfunction***Moderate or large pericardial effusionAccording to one embodiment, the system implements cross-campus performance analysis capabilities. As validated in Table 14, the processor maintains consistent performance metrics across different training configurations, including East-only training (AUROC 84.7%), West-only training (AUROC 84.5%), and combined training (AUROC 84.7%). The system compares AUROC, AUPRC, Fl-scores, and OR values across these different training configurations, demonstrating consistent performance regardless of the specific training data source.Table 14: Comparison of results for models with variable training sets (all models are evaluated on a common test set comprising data from East and West campuses)According to one embodiment, the system implements a comprehensive calibration framework for accurate probability estimates. For example, the calibration framework can include calibration approaches comprising temperature scaling, Platt scaling, and isotonic regression. The processor 130 is configured to maintain calibration curves that demonstrate the relationship between predicted probabilities and observed outcomes. In some embodiments, the processor 130 can apply recalibration procedures based on the calibration framework to validate calibration stability through reliability diagrams, calibration curves, and expected calibration error assessment. As validated in FIG. 7, the system achieves a close alignment between predicted and actual probabilities across the full range of model outputs shown in FIG. 7A. The calibration framework further includes automated monitoring of predicted probability distributions and actual outcome rates shown in FIG. 7B, with mechanisms for detecting and correcting any calibration drift over time.According to FIG. 8, the system includes capabilities for analyzing performance across different training data configurations, maintaining consistent metrics regardless of the specific hospital split used for training. The processor implements an automatedcomparison of receiver operating characteristic curves (FIG. 8A) and precision-recall curves across (FIG. 8B) these different model variations.In some embodiments, the system performed sensitivity analyses by generating and comparing multiple models based on different geographic data partitions. In some embodiments, the methods comprise training three distinct models: an “East” model trained exclusively using data from Weill Cornell Medical Center, NYP -Brooklyn Methodist Hospital, NYP-Queens Hospital, and NYP -Lower Manhattan Hospital; a “West” model trained exclusively using data from Columbia University Irving Medical Center, NYP- Westchester Hospital, NYP-CHONY, and NYP -Allen Hospital; and a “Blend” model trained using a subset of combined data from both East and West locations. The methods include creating a single blended test set comprising data from both East and West locations for model comparison.As shown in FIG. 8A and FIG. 8B, the system further compared performance metrics across the different models and assessed external generalizability. The performance comparison demonstrated minimal differences between models, with variations in AUROC and AUPRC of 0.2% (84.7% vs. 84.5%) and 0.1% (77.7% vs. 77.8%), respectively, between West and Blended models. The minimal performance difference between models trained on different geographic subsets supports the generalizability of the detection methods across different healthcare locations and patient populations.According to one embodiment, the system described herein can be implemented by at least one computing device. The techniques can be implemented entirely or partially using a combination of server computers or other computing devices coupled through a packet data network. The computing devices can be either hard-wired to perform the techniques or include digital electronic devices such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs) persistently programmed for this purpose, or can include general-purpose hardware processors programmed according to instructions in firmware, memory, or other storage. These computing devices can combine custom hard-wired logic with custom programming to accomplish the described techniques. The range of computing devices includes servers, workstations, personal computers, portable systems, handheld devices, mobile devices, wearable or implantable devices, smartphones, smart appliances, networking devices, autonomous or semi-autonomous devices, virtual computing instances in data centers, or networks of computers.FIG. 9 is a block diagram showing an example of computer architecture for a device capable of executing program components for implementing the abovementioned functionality. The computer architecture, as shown in FIG. 9, illustrates any type of computer 700, such as a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The Computer 700 can, in some examples, correspond to the processor, e.g., 130, FIG. 1, or any other device, including the external device e.g., 110, FIG. 1, described herein, and can comprise personal devices (e.g., smartphones, tablets, wearable devices, laptop devices) networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, or any other type of computing device that can be running any type of software or virtualization technology.The computer 700 includes a baseboard 702, or “motherboard,” which is a printed circuit board to which a multitude of components or devices can be connected via a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”) 704 operate in conjunction with a chipset 706. The CPUs 704 are standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer 700.The CPUs 704 perform operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states. Switching elements include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gateways. These basic switching elements can be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and similar components.The chipset 706 provides an interface between the CPUs 704 and the remainder of the components and devices on the baseboard 702. The chipset 706 can provide an interface to a RAM 708, which serves as the main memory in the computer 700. The chipset 706 can further provide an interface to a computer-readable storage medium such as a readonly memory (“ROM”) 710 or non-volatile RAM (“NVRAM”) for storing basic routines that help to start the computer 700 and transfer information between the various componentsand devices. The ROM 710 or NVRAM can also store other software components necessary for the operation of the computer 700 in accordance with the configurations described herein.The computer 700 can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network 120 shown in FIG. 1. The chipset 706 can include functionality for providing network connectivity through a Network Interface Controller (NIC) 712, such as a gigabit Ethernet adapter. The NIC 712 can connect the computer 700 to other computing devices over the network 724. Multiple NICs 712 can be present in the computer 700, connecting the computer to other types of networks and remote computer systems.The computer 700 can be connected to computer-readable media 718 or another form of storage device that provides non-volatile storage for the computer 700. The computer-readable media 718 can store an operating system 720, programs 722, and other data. The computer-readable media 718 can be connected to the computer 700 through a storage controller 714 connected to the chipset 706. The computer-readable media 718 can include one or more physical storage units. The storage controller 714 can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.The computer 700 can store data on the computer-readable media 718 by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of the physical state can depend on various factors in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device is characterized as primary or secondary storage, and similar considerations.For example, the computer 700 can store information to the computer-readable media 718 by issuing instructions through the storage controller 714 to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete components in a solid- state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. The computer 700 can further read information from thecomputer-readable media 718 by detecting the physical states or characteristics of one or more locations within the physical storage units.In addition to the computer-readable media 718 described above, the computer 700 can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art should appreciate that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer 500. In some examples, the operations performed by the processor, e.g., 130, FIG. 1, external device, e.g., 110, FIG. 1, or any components included therein can be supported by one or more devices similar to computer 700. Stated otherwise, some or all of the operations performed by the API gateway or any components included therein can be performed by one or more computers 700.By way of example and not limitation, computer-readable storage media can include volatile and non-volatile, removable, and non-removable media implemented in a method or technology. Computer-readable storage media includes but is not limited to RAM, ROM, erasable programmable ROM (“EPROM”), electrically-erasable programmable ROM (“EEPROM”), flash memory or other solid-state memory technology compact disc ROM (“CD-ROM”), digital versatile disk (“DVD”), high definition DVD (“HD-DVD”), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.The computer-readable media 718 stores operating system 720 and programs controlling computer 700 operations. When loaded with specific computer-executable instructions, these transform the general-purpose computer 700 into a specialized machine implementing the described functions. These instructions dictate how CPUs 704 transition between states, enabling all operations described regarding FIG. 1 and FIG. 2.The computer-readable media 718 can store an operating system 720 utilized to control the operation of the computer 700. The computer-readable media 718 can store other system or application programs and data utilized by the computer 700. In one embodiment, the computer-readable media 718 or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer 700, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executableinstructions transform the computer 700 by specifying how the CPUs 704 transition between states, as described above. According to one embodiment, the computer 700 has access to computer-readable storage media storing computer-executable instructions, which, when executed by the computer 700, perform the various operations described above with regards to FIG. 1 and FIG. 2.The computer 700 can also include one or more input / output controllers 716 for receiving and processing input from several input devices, such as a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or another type of input device. Similarly, an input / output controller 716 can provide output to a display such as a computer monitor, a flat panel display, smartphone display, a digital projector, a printer, or another type of output device. It will be appreciated that the computer 700 might not include all of the components shown in FIG. 1 and FIG. 2. Computer 700 can include other components that are not explicitly shown in FIG. 1 and FIG. 2, or can utilize an architecture completely different than that shown in FIG. 1 and FIG.2.The computer 700 can include one or more hardware processors 704 (CPUs) configured to execute one or more stored instructions. The processor(s) 704 can comprise one or more cores. Further, the computer 700 can include one or more network interfaces 712 configured to provide communications between the computer 500 and other devices, such as the communications described herein as being performed by the processor, e.g., 130 FIG. 1. The network interface 712 can include devices configured to couple to personal area networks (PANS), wired and wireless local area networks (LANS), wired and wireless wide area networks (WANs), and so forth. For example, the network interfaces can include devices compatible with Ethernet, WI-FI™, and so forth.The programs 722 can comprise any type of programs or processes to perform the techniques described in this disclosure for annotating documents.While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components can be combined or integrated into another system, or certain features can be omitted or not implemented.In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate can be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other can be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and can be made without departing from the spirit and scope disclosed herein.

Claims

WHAT IS CLAIMED IS:

1. A method for detecting cardiac abnormalities from Electrocardiogram (ECG) data of a patient, comprising: receiving the ECG data comprising 12-lead recordings; preprocessing the ECG data by: sampling the ECG data at 250 Hz across all leads to generate 30,000 data points per recording; extracting ECG-derived measurements from the sampled ECG data comprising atrial rate, ventricular rate, PR interval, QRS duration, and corrected QT interval; and integrating demographic information into the extracted ECG-derived measurements; analyzing the preprocessed ECG data using a trained convolutional neural network (CNN) model to detect a presence of at least one predetermined condition corresponding to the cardiac abnormalities; and generating, using a processor, a risk assessment output indicating the presence of the at least one predetermined condition comprising associated confidence scores for each detected condition and a composite score of a group of the predetermined conditions.

2. The method of claim 1, further comprising training the CNN model, comprising: collecting ECG and echocardiogram source data from diverse patient populations; curating the collected source data; training a CNN model using the curated data; and generating diagnostic predictions with the associated confidence scores.

3. The method of claim 2, wherein the training of the CNN model further comprises: implementing a plurality of CNN channels for processing a plurality of ECG leads; assembling demographic information associated with the ECG data; using echocardiogram data as ground truth labels for training; and constructing a neural network architecture.

4. The method of claim 2, wherein the training of the CNN model further comprises dividing the collected data into: a training dataset comprising a first fraction of the collected data; a validation dataset comprising a second fraction of the collected data; and a test dataset comprising a third of the collected data, wherein the first fraction of the collected data is larger than the second and third fractions of the collected data.

5. The method of claim 2, wherein the training of the CNN model further comprises: processing data in batches; utilizing a convolutional filter corresponding to the batches; applying a weight decay; implementing a dropout probability; and adjusting model weights.

6. The method of claim 2, wherein the training of the CNN model further comprises: applying a weight decay of 0.01 for regularization; implementing a dropout probability of 0.5; and optimizing and adjusting the model’s weights using Adam Optimizer with a learning rate of 5e-5.

7. The method of claim 2, wherein the curating of the collected source data comprises one or more of: verifying data completeness; removing ECGs with missing demographic information; filtering poor quality traces; excluding measurements acquired during ventricular pacing; generating attention maps highlighting relevant ECG regions; verifying echocardiogram measurements meet clinical guidelines; and generating ECG-echocardiogram pairs.

8. The method of claim 7, wherein the generating the ECG-echocardiogram pairs further comprises:matching curated ECG data with corresponding echocardiograms within a predetermined timeframe; verifying echocardiogram measurements; and creating labeled datasets.

9. The method of claim 1, further comprising validating the trained CNN model: conducting validation using a test set; and evaluating model performance on temporally distinct patient cohorts smaller than the cohorts involved in training the CNN model.

10. The method of claim 1, further comprising testing model generalization by one or more of: evaluating model performance separately across age groups, sex categories, racial groups, and / or ethnic backgrounds; assessing performance parity between demographic subgroups; monitoring for demographic bias in predictions; and generating demographic-specific confidence intervals.

11. The method of claim 1, further comprising maintaining consistent performance by: monitoring performance metrics across different clinical settings through measuring performance metrics comprising calculating area under receiver operating characteristic curves (AUROC), area under precision-recall curves (AUPRC), and diagnostic odds ratios (OR); implementing automated recalibration procedures; and validating calibration stability through reliability diagrams, calibration curves, and expected calibration error assessment.

12. The method of claim 1, further comprising implementing a plurality of convolutional layers with (Rectified Linear Unit) ReLU activation functions; incorporating residual network (ResNet) blocks with shortcut connections to skip the plurality of convolutional layers; implementing batch normalization layers; using dropout layers to prevent overfitting; andconfiguring output layers to predict the predetermined conditions verified by echocardiogram data.

13. The method of claim 1, wherein the detecting the cardiac abnormalities comprises detecting presence of one or more structural heart diseases (SHDs), wherein the presence of the SHDs is a composite of the presence of the at least one of the predetermined conditions: an ejection fraction (LVEF) less than or equal to 45%, increased left ventricular wall thickness of at least 1.3 centimeters, moderate or severe right ventricular (RV) dysfunction, a pulmonary artery systolic pressure (PASP) of at least 45 mmHg or a tricuspid regurgitation (TR) jet velocity of at least 3.2 meters per second.

14. The method of claim 13, wherein the presence of the SHDs is a composite of the presence of the at lease one of the predetermined conditions further including: one or more of moderate or severe valve diseases, specifically aortic stenosis (AS), aortic regurgitation (AR), mitral regurgitation (MR), tricuspid regurgitation (TR), and pulmonary regurgitation (PR), as well as the presence of a moderate or large pericardial effusion.

15. The method of claim 1, wherein the detecting cardiac abnormalities further comprises detecting presence of severe structural heart diseases (SHDs) further comprises one or more of: identifying severe left ventricular dysfunction indicated by an ejection fraction (LVEF) less than or equal to 35%; detecting severe left ventricular hypertrophy indicated by wall thickness greater than or equal to 1.6 centimeters; identifying severe valve diseases comprising severe aortic stenosis, severe regurgitation in any valve, severe right ventricular systolic dysfunction; detecting large pericardial effusion; identifying severe pulmonary hypertension through pulmonary artery systolic pressure (PASP) greater than or equal to 60 mmHg, or tricuspid regurgitation (TR) maximum velocity greater than or equal to 3.6 meters per second; andgenerating a composite severe SHD score based on presence of any severe conditions.

16. The method of claim 1, further comprising integrating the risk assessment output with one or more clinical workflows.

17. A system for detecting cardiac abnormalities comprising: a data acquisition module configured to receive ECG data comprising 12-lead recordings; a preprocessing module, coupled to the data acquisition module, configured to sample the received ECG data extract ECG-derived measurements therefrom comprising one or more of an atrial rate, a ventricular rate, a PR interval, a QRS duration, and a corrected QT interval; and integrate demographic information; a convolutional neural network (CNN) analysis module, coupled to the preprocessing module, configured to analyze the preprocessed ECG data to detect a presence of at least one predetermined condition; a processor, coupled to the CNN analysis module and receiving the analysis therefrom, configured to generate a risk assessment output indicating the presence of the at least one predetermined condition, associated confidence scores for each detected condition; and a composite score of a group of the predetermined conditions.

18. The system of claim 17, wherein the CNN analysis module comprises a plurality of CNN channels for processing a plurality of ECG leads.

19. The system of claim 17, wherein the CNN analysis module comprises multiple convolutional layers with Rectified Linear Unit (ReLU) activation functions comprising: a first convolutional layer configured to process the 12-lead ECG input data; subsequent convolutional layers configured to extract hierarchical features; and pooling layers between convolutional layers for dimensionality reduction.

20. The system of claim 17, wherein the CNN analysis module comprises residual network (ResNet) blocks comprising:shortcut connections configured to skip two or more convolutional layers, and identity mappings for gradient flow;1 x 1 convolutional layers for dimension matching; and addition operations to combine shortcut and main paths.

21. The system of claim 17, wherein the CNN analysis module comprises batch normalization layers configured to normalize activations across each batch.

22. The system of claim 17, wherein the CNN analysis module further comprises dropout layers configured to randomly disable neurons during training with a probability of 0.5.

23. The system of claim 17, wherein the CNN analysis module further comprises: output layers configured to: process extracted features for each prediction task; generate probability scores for each condition; apply multitask-specific activation functions; and produce calibrated confidence scores.

24. The system of claim 17, further comprising an integration module configured to integrate the risk assessment output with clinical workflows.