ECG AI

Abstract

Background

Electrocardiography (ECG) is a fundamental diagnostic investigation used to assess cardiac electrical activity. Conventional ECG analysis generally relies on interpretation of digitally acquired signals or printed ECG recordings by trained healthcare professionals. The increasing availability of artificial intelligence (AI) methods has created opportunities for automated ECG analysis. However, the development of AI systems from ECG images introduces additional challenges, including image preprocessing, lead identification, waveform reconstruction, and conversion of visual ECG information into a representation suitable for computational inference.

Case Description

This case report describes the development of an experimental software prototype designed to process a 12-lead ECG image and subsequently perform AI-based analysis. The application was implemented using Python and the Streamlit framework. The software accepts PNG, JPEG, or JPG ECG images through a graphical web interface. Following upload, the image is passed to an ECG-processing module responsible for generating a cleaned image, identifying ECG regions, and producing experimental waveform representations. The application then evaluates whether all 12 waveform outputs are sufficiently usable for downstream AI inference. If this requirement is satisfied, an AI model is loaded and supplied with the processed waveform data. The model output is presented as probabilistic scores associated with predefined findings.

Results

The prototype provides an integrated workflow consisting of ECG image upload, visualization, image processing, lead-region detection, experimental waveform visualization, quality gating, AI-model loading, inference, and presentation of model probabilities. The application includes explicit safeguards indicating that the system is experimental and has not undergone clinical validation.

Conclusion

The developed prototype demonstrates a modular pipeline for transforming an ECG image into computational representations and subsequently applying an AI model. Its architecture separates image processing, model loading, and inference into independent software modules, facilitating future development and testing. Nevertheless, the current implementation should be regarded strictly as a research prototype. Clinical validation, independent performance evaluation, standardized datasets, assessment of waveform reconstruction accuracy, and appropriate regulatory evaluation would be required before any consideration of clinical deployment.

1. Introduction

The electrocardiogram is a widely used method for evaluating the electrical activity of the heart. A conventional 12-lead ECG contains information distributed across multiple electrical leads, allowing cardiac electrical activity to be assessed from different anatomical perspectives.

Although ECG analysis is traditionally performed using directly acquired electrical signals, ECG information is also frequently encountered in image form. Such images may originate from scanned paper ECGs, screenshots, photographs, or exported reports. An image-based ECG analysis system therefore requires an additional computational stage in which visual information is converted into a representation that can be analyzed computationally.

Artificial intelligence has increasingly been investigated for automated interpretation of ECG data. However, an AI model generally requires structured numerical input rather than a conventional ECG image. Consequently, an image-based system may require several processing stages, including image preprocessing, identification of individual ECG leads, extraction of waveform information, quality assessment, and AI inference.

The software described in this case report was developed as an experimental research prototype to investigate this complete workflow. Rather than directly presenting an ECG image to an AI model, the application establishes an intermediate processing pipeline in which the image is converted into experimental waveform representations before AI inference is attempted.

The primary objective of the prototype is therefore not clinical diagnosis, but demonstration of a computational framework capable of connecting ECG image processing with downstream artificial intelligence analysis.

2. System Objectives

The software was designed around several functional objectives:

• Accept a 12-lead ECG image from a user.
• Display the original ECG image.
• Process the ECG image using a dedicated processing module.
• Generate a cleaned version of the ECG image.
• Detect and extract individual ECG lead regions.
• Generate experimental numerical waveform representations.
• Visualize the extracted waveforms.
• Determine whether all 12 leads have usable waveform outputs.
• Prevent AI inference when the required waveform data are incomplete.
• Load an AI model when the waveform requirements are satisfied.
• Perform model inference.
• Display model findings and associated probabilities.
• Clearly communicate that the system is experimental and not clinically validated.

3. Software Architecture

The prototype follows a modular software architecture. The main application acts as the user interface and orchestration layer, while specialized functions are delegated to independent modules.

The principal software components are:

• Streamlit interface
• ECG processing module
• Model loading module
• Inference module

The main application imports three principal functions:

from ecg_processor import process_ecg

from model_loader import load_model

from inference import predict

This design separates the user-interface layer from the computational components.

Conceptually, the system can be represented as:

ECG Image

↓

Image Processing

↓

Lead/Region Detection

↓

Waveform Extraction

↓

Waveform Quality Check

↓

AI Model Loading

↓

AI Inference

↓

Probabilistic Research Output

This modular structure is advantageous because individual components can be independently modified, tested, and replaced without requiring substantial changes to the user interface.

4. Development Environment

The prototype was implemented in Python.

The principal external libraries visible in the provided source code are:

4.1 Streamlit

Streamlit provides the interactive web-based user interface. It is responsible for page configuration, image uploading, buttons, status messages, charts, progress indicators, and dynamic presentation of results.

4.2 NumPy

NumPy is imported as:

import numpy as np

Although NumPy is not directly used elsewhere in the provided interface code, its presence indicates that numerical array processing is part of the intended computational environment. The actual use of NumPy may occur within the imported ECG-processing or inference modules.

4.3 Custom Python Modules

Three application-specific modules form the computational core:

ecg_processor.py

model_loader.py

inference.py

Their apparent responsibilities are:

Module	Function
ecg_processor.py	ECG image processing and waveform/region generation
model_loader.py	Loading the trained or experimental AI model
inference.py	Applying the model to waveform inputs and producing findings

The exact algorithms used inside these modules cannot be determined from the supplied interface code alone.

5. ECG Image Acquisition

The first functional stage is ECG image acquisition.

The application provides a file uploader:

uploaded_file = st.file_uploader(

"Upload a 12-lead ECG image",

type=["png", "jpg", "jpeg"],

)

The system therefore accepts three common image formats:

• PNG
• JPEG
• JPG

The application explicitly requests a 12-lead ECG image and instructs the user to upload a de-identified ECG.

If no file has been uploaded, execution is stopped:

if uploaded_file is None:

st.info(

"Upload a de-identified ECG image to begin."

)

st.stop()

This prevents downstream processing from occurring without an input image.

6. Original Image Visualization

After successful upload, the image is retrieved as raw bytes:

image_bytes = uploaded_file.getvalue()

The original image is then displayed to the user.

This provides an important visual reference because subsequent processing results can be compared with the original ECG.

The workflow therefore maintains the distinction between:

Original ECG image

and

Processed ECG representation

which is useful during research and development.

7. ECG Image Processing

The central image-processing operation is initiated by the user through the PROCESS ECG button.

The application calls:

result = process_ecg(image_bytes)

The process_ecg() function therefore represents the principal interface between the graphical application and the underlying ECG-processing algorithm.

The returned object is expected to contain at least three components:

result["cleaned"]

result["regions"]

result["waveforms"]

These outputs correspond to three processing stages.

7.1 Cleaned ECG Image

The cleaned output is displayed as:

st.image(

result["cleaned"],

caption="Experimental grid-suppressed image",

channels="BGR",

width="stretch",

)

The interface describes this as an experimental grid-suppressed image.

This suggests that the processing pipeline attempts to reduce or suppress ECG background-grid information while preserving the waveform. However, the precise image-processing method cannot be determined without access to ecg_processor.py.

Possible operations in such a pipeline could include image normalization, color-space conversion, thresholding, grid suppression, segmentation, or noise reduction, but these should not be attributed to the current implementation without examining the actual processing module.

8. ECG Lead Region Detection

The processing function returns a collection called regions:

regions = result["regions"]

The application calculates the number of detected regions:

len(regions)

and reports:

• Detected regions

Each region contains at least an image and a name:

region["image"]

region["name"]

The regions are displayed in a three-column layout.

This functionality allows the researcher to visually inspect the portions of the ECG image identified as individual lead regions.

The system therefore introduces an intermediate representation:

Complete ECG image → detected lead regions

This is an important architectural step because individual lead waveforms can subsequently be associated with numerical waveform outputs.

9. Experimental Waveform Generation

Following region extraction, the application accesses:

waveforms = result["waveforms"]

Each waveform is evaluated individually.

The application excludes two categories of unusable output:

if waveform is None:

continue

if len(waveform) < 2:

continue

A waveform is considered usable by the interface if it is not None and contains at least two elements.

Usable waveforms are then visualized using Streamlit line charts:

st.line_chart(

waveform,

height=150,

)

The corresponding ECG lead name is displayed below each chart.

This stage is described as experimental waveform extraction because the numerical waveform is reconstructed or derived from an image rather than obtained directly from an ECG acquisition system.

The accuracy of this reconstruction is not established by the supplied code.

10. Waveform Quality Gate

One of the most important safety-oriented software mechanisms is the waveform completeness check.

The application counts the number of usable waveform outputs:

usable += 1

and subsequently reports:

Usable waveform outputs: X/12

The AI system requires all 12 waveform outputs to be usable.

The condition is explicitly implemented as:

if usable != 12:

When fewer than 12 usable waveforms are available, the application displays:

• AI inference requires 12 usable waveform outputs. Do not run the model yet.

This represents a quality-gating mechanism between preprocessing and AI inference.

The workflow can therefore be represented as:

Image processing

→ Waveform generation

→ 12-lead completeness check

→ AI inference only if 12/12 are usable

This prevents the model from being intentionally executed when the expected complete 12-lead waveform representation is not available.

It is important to note that this is a completeness criterion rather than a validated clinical quality-control measure. The code verifies that outputs exist and contain at least two elements, but it does not establish that the extracted waveforms are physiologically accurate.

11. AI Model Loading

When all 12 waveforms satisfy the basic usability criterion, the user is allowed to initiate AI analysis.

The model is loaded through:

model = load_model()

The implementation of load_model() is not included in the supplied code. Consequently, the model architecture, training dataset, model parameters, framework, and training methodology cannot be established from this source file.

The separation of model loading into its own module is nevertheless a useful design decision because it allows the underlying model to be changed without redesigning the Streamlit interface.

12. AI Inference

The loaded model and waveform data are passed to:

results = predict(

model,

waveforms

)

The predict() function therefore forms the inference interface.

The output is expected to be an iterable containing objects with at least:

item["finding"]

item["probability"]

The probability is converted to a percentage:

probability = (

item["probability"]

* 100

)

The application subsequently displays the finding and probability:

Finding — probability%

A visual progress bar is also generated:

st.progress(

min(

int(probability),

100

)

)

This allows the user to visually inspect the model's output scores.

Importantly, these values are explicitly presented as experimental model outputs rather than diagnoses.

13. User Interface and Interaction Workflow

The complete user workflow is designed as a three-stage process.

Stage 1 — Upload ECG

The researcher uploads a 12-lead ECG image.

The application then displays the original image.

Stage 2 — ECG Processing

The researcher selects PROCESS ECG.

The application:

• Sends the image to the ECG-processing module.
• Receives the processing results.
• Displays the cleaned ECG image.
• Displays detected lead regions.
• Generates and displays available waveform outputs.
• Counts usable waveforms.

Stage 3 — AI Analysis

If all 12 waveform outputs are usable, the researcher can select RUN ECG AI.

The application:

• Loads the AI model.
• Sends the waveform data to the inference function.
• Receives model results.
• Converts probabilities into percentages.
• Displays predicted findings and scores.

The complete workflow is therefore:

ECG Image

↓

Upload

↓

Image Processing

↓

Cleaned Image

↓

Lead Region Detection

↓

Waveform Extraction

↓

Waveform Visualization

↓

12/12 Quality Gate

↓

AI Model

↓

Inference

↓

Finding + Probability

14. Error Handling

The application incorporates exception handling around both major computational stages.

During ECG processing:

try:

...

except Exception as error:

st.error(

f"ECG processing failed: {error}"

)

During AI inference:

try:

...

except Exception as error:

st.error(

f"AI inference failed: {error}"

)

This prevents an unexpected processing or inference error from causing an uncontrolled application failure and instead provides a visible error message to the user.

The use of st.spinner() also communicates that a computational operation is currently being performed.

15. State Management

The processed ECG results are stored in Streamlit session state:

st.session_state["ecg_result"] = result

This allows the processed results to remain available during subsequent interactions with the application.

The interface can therefore display the processing results without requiring the ECG-processing function to be repeatedly executed every time the application reruns.

This is particularly relevant to Streamlit applications because user interactions can trigger script reruns.

16. Research-Oriented Safety Design

The application repeatedly communicates that it is not a clinical diagnostic system.

At the beginning of the interface, a warning states that the application is:

• RESEARCH PROTOTYPE ONLY

The application further states that it is not clinically validated and must not be used to diagnose patients or make patient-care decisions.

After AI inference, an additional warning explains that the scores represent experimental model outputs rather than medical diagnoses.

This is an important characteristic of the prototype because it establishes a distinction between:

Research model output

and

Clinically validated diagnostic information.

The interface also requests a de-identified ECG image, reflecting an awareness of the importance of avoiding unnecessary exposure of patient-identifying information.

17. Functional Characteristics

The principal functional characteristics of the system are summarized below.

Function	Implementation	Purpose
ECG upload	Streamlit file uploader	Accept ECG images
Original visualization	st.image()	Display source ECG
ECG processing	process_ecg()	Process uploaded image
Image cleaning	result["cleaned"]	Display processed image
Lead detection	result["regions"]	Identify ECG regions
Region visualization	st.image()	Inspect detected leads
Waveform extraction	result["waveforms"]	Obtain numerical representations
Waveform visualization	st.line_chart()	Inspect extracted signals
Quality gating	usable != 12	Prevent incomplete AI input
Model loading	load_model()	Load AI model
AI inference	predict()	Generate model outputs
Probability display	percentage + progress bar	Present model scores
Error handling	try/except	Manage failures
State management	st.session_state	Preserve processing results

18. Discussion

The prototype demonstrates an important concept in image-based ECG artificial intelligence: the AI analysis does not necessarily have to operate directly on the original ECG image. Instead, the system can establish an intermediate representation of the ECG through image processing and waveform extraction.

This architecture has several potential advantages.

First, the modular design separates image processing from AI inference. This allows the waveform extraction method and AI model to be independently developed and evaluated.

Second, the visualization of intermediate processing results provides researchers with greater transparency than a system that produces only a final prediction. Researchers can inspect the cleaned image, detected regions, and reconstructed waveforms before evaluating AI outputs.

Third, the 12-lead completeness gate provides a simple mechanism for preventing inference when the expected input structure is incomplete.

Fourth, the explicit research-only warnings help distinguish experimental software from a clinically validated medical device.

However, several limitations must be recognized.

The most important limitation is that the provided source code represents primarily the application interface and orchestration layer. The actual implementation of ECG image processing, waveform extraction, model loading, and AI inference is contained in external modules that were not supplied. Therefore, the specific algorithms, model architecture, training methodology, dataset characteristics, and performance metrics cannot be evaluated from this code alone.

Furthermore, the current waveform quality check is limited. A waveform is considered usable if it is present and has at least two elements. This does not demonstrate that the waveform is correctly reconstructed, correctly aligned, physiologically plausible, or suitable for clinical inference.

Similarly, the probability values produced by the model should not be interpreted as clinically meaningful probabilities without appropriate calibration and validation.

19. Recommended Validation Framework

Before the prototype could be considered for research involving clinical interpretation, several additional validation stages would be required.

19.1 Image-processing validation

The ability of the system to identify ECG regions should be evaluated against manually annotated ECG images.

Relevant measurements could include:

• Lead-region detection accuracy
• Localization error
• Segmentation accuracy
• Grid-removal performance
• Robustness to image quality variations

19.2 Waveform reconstruction validation

The extracted waveform should be compared with the original digital ECG signal when paired image and signal data are available.

Potential measurements include:

• Correlation
• Root mean square error
• Amplitude error
• Temporal alignment error
• Signal-to-noise ratio
• Morphological similarity

19.3 AI model validation

The model should be evaluated using an independent dataset that was not used during training.

Depending on the intended findings, relevant metrics may include:

• Sensitivity
• Specificity
• Positive predictive value
• Negative predictive value
• AUROC
• AUPRC
• Calibration
• Confusion matrices

19.4 External validation

Testing should subsequently be performed using ECG images originating from different devices, institutions, acquisition conditions, resolutions, and patient populations.

This would help determine whether the system generalizes beyond the development dataset.

19.5 Clinical validation

If the eventual goal is clinical use, prospective clinical evaluation and appropriate regulatory assessment would be necessary. The current prototype should not be interpreted as having completed these stages.

20. Reproducibility and Modularity

The separation of the application into independent components provides a useful foundation for reproducible research.

The architecture can be conceptualized as four independent layers:

Layer 1 — User Interface

Implemented through Streamlit.

Layer 2 — Image Processing

Implemented through ecg_processor.py.

Layer 3 — Model Management

Implemented through model_loader.py.

Layer 4 — Inference

Implemented through inference.py.

This architecture allows researchers to replace individual components without redesigning the entire system.

For example, an improved waveform extraction algorithm could replace the existing processing implementation while retaining the same Streamlit interface and inference interface.

Similarly, a different AI model could be incorporated through the model-loading and inference modules.

21. Conclusion

This case report describes the development of an experimental ECG AI research prototype capable of accepting a 12-lead ECG image, processing the image, identifying ECG regions, generating experimental waveform representations, evaluating waveform completeness, and performing AI inference when all 12 waveform outputs are available.

The software uses a modular Python architecture in which the Streamlit application serves as the orchestration and visualization layer while dedicated modules perform ECG processing, model loading, and inference.

A key feature of the system is its visualization of intermediate processing stages. Rather than providing only a final AI output, the prototype exposes the cleaned ECG image, detected lead regions, and experimental waveform representations. This provides researchers with an opportunity to inspect the computational pipeline before AI inference.

The implementation also incorporates basic error handling, session-state management, input restrictions, waveform completeness gating, and repeated warnings regarding the experimental nature of the system.

Nevertheless, the current software should be considered a research and development prototype rather than a clinical diagnostic system. The supplied source code does not establish the accuracy of image processing, waveform reconstruction, or AI prediction. Further technical validation, independent testing, clinical evaluation, model calibration, and regulatory assessment would be required before any clinical application could be considered.

Overall, the prototype establishes a practical software framework for investigating the transformation of ECG images into machine-readable waveform representations and subsequently applying artificial intelligence to those representations.

Abstract

Background

Artificial intelligence (AI) has emerged as a potentially important technology for cardiovascular medicine, with applications ranging from automated interpretation of electrocardiographic data to clinical decision support and risk prediction. The translation of AI-based ECG analysis into clinical practice, however, requires more than technical feasibility. Robust clinical validation, transparent reporting, appropriate integration into clinical workflows, human oversight, data governance, and regulatory assessment are necessary before an AI system can be used to influence patient care. Recent scientific guidance emphasizes that AI systems should be evaluated within their intended clinical context and reported transparently.

Objective

This paper proposes a potential clinical-use framework for an experimental ECG image processing and AI analysis prototype. The system accepts a 12-lead ECG image, performs image processing and lead-region extraction, generates experimental waveform representations, and applies an AI model when all 12 waveform outputs are available. The purpose of this report is to describe how such a system could potentially be incorporated into clinical workflows while identifying the technical, clinical, ethical, and regulatory requirements that must be satisfied before deployment.

Proposed Clinical Application

In a future validated implementation, the system could function as a clinician-facing decision-support tool. An ECG image generated by an ECG device or uploaded from a clinical information system could be processed automatically. The system could reconstruct or extract the individual ECG leads, assess processing quality, and provide AI-generated probabilities for predefined ECG findings. The results would be presented to a qualified clinician as supplementary information rather than as an autonomous diagnosis.

Conclusion

The proposed system illustrates a potential pathway for converting ECG images into machine-readable representations and subsequently providing AI-assisted interpretation. Its most appropriate initial clinical role would be as an adjunctive decision-support system operating under clinician supervision. Before clinical implementation, prospective evaluation, external validation, calibration assessment, workflow studies, cybersecurity and privacy assessment, human-factors testing, and applicable regulatory review would be required.

1. Introduction

The electrocardiogram (ECG) remains one of the most widely used investigations in cardiovascular medicine because it provides a rapid, non-invasive assessment of cardiac electrical activity. Although modern ECG systems frequently generate digitally stored signals, ECG information is also commonly encountered in image-based formats, including printed ECG reports, scanned documents, screenshots, and exported images.

The use of AI in cardiovascular medicine has expanded considerably, with potential applications in automated interpretation, risk prediction, clinical decision support, and integration of heterogeneous clinical information. The American Heart Association has identified AI as a potentially important component of future cardiovascular care while emphasizing the need for appropriate evaluation, implementation, and clinical oversight.

The European Society of Cardiology similarly recognizes the increasing role of AI and digital technologies in cardiovascular medicine while emphasizing evidence-based implementation and appropriate clinical validation.

The prototype described in this report provides a technical foundation for one potential application: transforming an ECG image into an analyzable representation and subsequently applying an AI model. The current software is explicitly designated as a research prototype and is not clinically validated.

Accordingly, the purpose of this report is not to claim clinical effectiveness of the existing implementation. Rather, it is to describe how the technology could potentially be translated into clinical practice following appropriate validation and regulatory development.

2. Proposed Clinical Use Case

The proposed clinical application would be a clinician-facing AI-assisted ECG interpretation system.

The intended workflow could be:

Patient undergoes ECG

↓

ECG image generated

↓

Image transferred to AI system

↓

Image quality assessment

↓

12-lead detection and waveform extraction

↓

Waveform quality assessment

↓

AI analysis

↓

Clinical decision-support output

↓

Clinician review

↓

Clinical decision

The critical distinction is that the AI system would not independently diagnose or treat the patient.

Instead, it would provide information to a healthcare professional who would interpret the AI output together with the patient's symptoms, history, examination, previous ECGs, laboratory results, imaging, and other clinically relevant information.

This human-in-the-loop approach is particularly important because AI output represents one source of information rather than a complete clinical assessment.

3. Potential Clinical Workflow

3.1 ECG Acquisition

The first stage would occur during routine patient care.

A 12-lead ECG could be acquired using a conventional ECG device. In the proposed image-based implementation, the resulting ECG report would be supplied to the software as an image.

In a mature clinical implementation, direct integration with the ECG acquisition system or electronic health record (EHR) would be preferable to manual file upload. Such integration could reduce transcription errors and minimize unnecessary handling of patient data.

The current prototype instead uses a manual image-upload mechanism through a Streamlit interface.

4. Patient Identification and Data Governance

A clinical implementation would require substantially stronger data-management controls than those demonstrated by the current prototype.

The present application requests a de-identified ECG image. In a clinical environment, however, ECG data would potentially be associated with protected health information.

Accordingly, a production system would require:

• authenticated users;
• role-based access control;
• secure data transmission;
• encryption;
• audit logging;
• controlled data retention;
• appropriate patient-identification procedures;
• secure storage;
• cybersecurity monitoring;
• institutional data-governance procedures.

The exact requirements would depend on the jurisdiction and intended deployment environment.

The system should also minimize unnecessary transmission of identifiable patient information to external services.

5. Automated ECG Image Processing

After ECG acquisition, the proposed system would perform automated image processing.

The prototype invokes:

result = process_ecg(image_bytes)

The processing function returns:

result["cleaned"]

result["regions"]

result["waveforms"]

In a clinical implementation, this stage would serve two important purposes.

First, it would transform the raw ECG image into a representation suitable for computational analysis.

Second, it would determine whether the image contains sufficient information for reliable downstream analysis.

This is particularly important because clinical ECG images may vary in:

• resolution;
• contrast;
• paper quality;
• orientation;
• scanning artifacts;
• illumination;
• background grid;
• cropping;
• compression;
• device manufacturer;
• lead arrangement.

A clinical system would therefore require systematic evaluation across representative variations in ECG image quality.

6. Lead Identification and Waveform Reconstruction

The prototype identifies ECG regions and subsequently generates waveform outputs.

This creates a computational pathway of:

ECG image → lead regions → numerical waveforms

Such a pathway could potentially enable an AI model originally designed for waveform-based ECG analysis to operate on ECG images.

However, this stage represents one of the most important areas requiring clinical validation.

The reconstructed waveform must accurately represent the original ECG signal in terms of:

• amplitude;
• timing;
• morphology;
• polarity;
• intervals;
• rhythm;
• QRS morphology;
• ST-segment characteristics;
• T-wave morphology.

An apparently successful image-processing pipeline may nevertheless introduce systematic distortions that subsequently affect AI predictions.

Therefore, clinical validation should compare extracted waveforms against a reference digital ECG signal where paired datasets are available.

7. Automated Quality Control

The prototype contains an important preliminary quality-control mechanism.

The system counts usable waveform outputs and prevents AI analysis unless all 12 are available:

if usable != 12:

st.warning(

"AI inference requires 12 usable waveform outputs."

)

This principle could be expanded substantially in a clinical system.

Rather than merely determining whether a waveform exists, a clinical quality-control module should assess whether each lead is:

• present;
• correctly localized;
• sufficiently complete;
• adequately reconstructed;
• free from excessive artifacts;
• temporally coherent;
• physiologically plausible.

The system could ultimately generate a quality score such as:

ECG quality: Acceptable / Unacceptable

If quality were insufficient, the system should abstain from producing an AI interpretation.

This concept of controlled abstention is particularly important for medical AI because an algorithm should not necessarily produce an output for every input.

8. AI-Based Analysis

Following successful waveform extraction and quality assessment, the prototype loads an AI model:

model = load_model()

and performs inference:

results = predict(

model,

waveforms

)

The model returns findings associated with probabilities.

In a future clinical implementation, these outputs could potentially be displayed as:

AI finding	Estimated probability
Finding A	XX.X%
Finding B	XX.X%
Finding C	XX.X%

The specific clinical findings would depend entirely on the model's training objective.

Importantly, a probability generated by an AI model should not automatically be interpreted as a patient's true probability of disease. The meaning of the value depends on model calibration, prevalence, training data, threshold selection, and the clinical population in which the model is deployed.

Therefore, calibration should be assessed in addition to discrimination.

9. Human-in-the-Loop Clinical Decision Support

The most appropriate initial clinical role for this technology would be clinical decision support rather than autonomous diagnosis.

For example, a clinician might receive an ECG together with an AI-generated summary:

• AI-assisted analysis identifies a high probability of a predefined ECG finding.

The clinician would then independently review the ECG and determine whether the finding is clinically plausible.

The clinician would also consider:

• presenting symptoms;
• vital signs;
• medical history;
• medications;
• previous ECGs;
• laboratory results;
• imaging;
• other diagnostic investigations.

The final clinical decision would remain with the appropriately qualified healthcare professional.

This approach is consistent with the broader principle that AI should augment clinical reasoning rather than be treated as a substitute for clinical judgment. The AHA has emphasized the importance of responsible implementation of AI within cardiovascular care.

10. Potential Clinical Applications

If successfully validated, an image-based ECG AI system could potentially support several clinical scenarios.

10.1 Emergency Department

In emergency care, rapid ECG interpretation can be important because certain cardiovascular conditions require prompt assessment.

A validated AI system could potentially flag predefined ECG abnormalities for clinician review.

The system would not replace emergency physician or cardiologist assessment, but could function as an additional screening or prioritization mechanism.

10.2 Primary Care

In primary-care settings, ECG interpretation resources may vary.

An AI-assisted system could potentially provide an additional interpretation for clinician consideration, particularly when specialist interpretation is not immediately available.

10.3 Remote and Rural Healthcare

Image-based analysis may be particularly relevant in environments where ECGs are acquired locally but specialist interpretation is remote.

A validated system could potentially provide preliminary computational analysis while allowing a clinician or remote cardiologist to review the original ECG.

10.4 Cardiology Services

Within cardiology, AI could potentially be used as an additional analytical layer alongside conventional ECG interpretation.

For example, the system could facilitate:

• automated preliminary interpretation;
• prioritization of abnormal ECGs;
• retrospective research;
• longitudinal comparison;
• quality assurance;
• population-scale ECG analysis.

10.5 Retrospective Research

Before clinical deployment, the system could be particularly valuable as a research tool.

Large collections of historical ECG images could be processed to investigate model performance across different populations, devices, and clinical conditions.

11. Clinical Validation Strategy

Clinical implementation should not occur solely on the basis of successful software execution.

A staged validation strategy would be required.

Phase I — Technical Validation

The first stage should determine whether the software correctly processes ECG images.

Potential endpoints include:

• image-processing success rate;
• lead detection accuracy;
• waveform reconstruction accuracy;
• processing time;
• failure rate;
• robustness to image quality.

Phase II — Internal Model Evaluation

The AI model should be evaluated using appropriately separated development and evaluation datasets.

Performance should include discrimination and calibration measures appropriate to the intended prediction task.

Phase III — External Validation

The model should subsequently be evaluated using independent datasets from different institutions and patient populations.

This is essential because performance obtained from a single development dataset may not generalize to other clinical environments.

TRIPOD+AI specifically emphasizes transparent reporting of prediction-model development and evaluation, including information about development data, evaluation data, model specification, and performance.

Phase IV — Clinical Workflow Evaluation

The next stage should evaluate how clinicians interact with the AI system.

Relevant questions include:

• Does the system reduce interpretation time?
• Does it improve diagnostic accuracy?
• Does it increase false-positive interpretations?
• Does it alter clinician confidence?
• Does it create automation bias?
• Does it improve or worsen workflow?
• Do clinicians appropriately recognize model uncertainty?

Phase V — Prospective Clinical Evaluation

A prospective study could subsequently evaluate performance in patients encountered during routine clinical care.

The system should be assessed against predefined reference standards and clinically meaningful endpoints.

12. Safety and Failure Modes

A clinically deployable system must explicitly account for failure.

Potential failure modes include:

Poor-quality ECG image

The system may incorrectly reconstruct waveform information.

Incorrect lead identification

A waveform could potentially be associated with the wrong lead.

Missing leads

The AI model could receive incomplete information.

Image artifacts

Compression, shadows, folds, or grid interference could alter waveform extraction.

Distribution shift

The clinical population or ECG device may differ substantially from the training data.

Model uncertainty

The model may generate apparently confident predictions despite limited supporting information.

Automation bias

Clinicians may place excessive confidence in AI output.

False negatives

A clinically important abnormality may be missed.

False positives

The system may identify abnormalities that are not actually present.

For these reasons, a clinical implementation should incorporate explicit failure states and an ability to abstain from prediction.

13. Regulatory Considerations

The regulatory status of an AI-based ECG application depends on its intended use, claims, functionality, jurisdiction, and degree of influence on clinical decision-making.

In the United States, the FDA's January 2026 guidance on Clinical Decision Support Software distinguishes certain non-device clinical decision-support functions from software functions that meet the definition of a medical device. The FDA also states that existing digital-health policies continue to apply to software functions that meet the device definition.

Consequently, the intended clinical use of an ECG AI system would need to be defined carefully.

A system intended merely to display information is materially different from one intended to analyze ECG data and provide diagnostic recommendations that influence patient management.

A future development program should therefore include regulatory assessment at an early stage rather than treating regulatory considerations as an issue only after software development is complete.

14. Reporting and Scientific Standards

If this technology were evaluated as a clinical prediction model, the research should follow contemporary reporting standards.

TRIPOD+AI provides updated recommendations for studies involving prediction models developed using machine-learning or regression methods. The guideline contains 27 main reporting items covering areas including the study title, abstract, introduction, methods, data, model development, evaluation, results, and open-science practices.

A future publication should therefore explicitly describe:

• patient population;
• inclusion and exclusion criteria;
• ECG acquisition;
• image characteristics;
• preprocessing;
• waveform extraction;
• training dataset;
• evaluation dataset;
• model architecture;
• model training;
• hyperparameters;
• outcome definitions;
• missing data;
• reference standard;
• statistical analysis;
• discrimination;
• calibration;
• subgroup performance;
• external validation;
• limitations.

This level of transparency would allow independent researchers and clinicians to assess the reproducibility and applicability of the system.

15. Integration With Clinical Information Systems

A production implementation would ideally be integrated into existing clinical infrastructure rather than requiring clinicians to manually upload ECG files.

A possible architecture would be:

ECG device

↓

Hospital information system / EHR

↓

ECG AI service

↓

Image and signal processing

↓

AI inference

↓

Structured AI result

↓

Clinician-facing EHR display

The AI output could potentially be stored alongside the ECG as a supplementary interpretation.

However, integration should ensure that AI-generated information is clearly distinguished from clinician-authored interpretation.

The interface should avoid presenting experimental or probabilistic outputs in a manner that could be mistaken for definitive diagnoses.

16. Proposed Clinical User Interface

A future clinical interface could contain four major sections.

A. Original ECG

The clinician should be able to view the original ECG image without modification.

B. Processing Quality

The system could report:

ECG image quality: Acceptable

12/12 leads identified

Waveform extraction: Successful

C. AI Findings

The system could provide:

AI-assisted findings

• Finding A — probability
• Finding B — probability
• Finding C — probability

D. Clinical Disclaimer

A concise statement should clarify:

• AI-generated information is intended to support, not replace, clinical assessment.

This design would preserve the original evidence while making the AI interpretation transparent.

17. Explainability and Transparency

For clinical adoption, displaying only a probability may be insufficient.

Where technically feasible, future versions could provide additional information explaining why a prediction was generated.

For example, the system could potentially identify:

• the lead(s) contributing most strongly to a prediction;
• relevant waveform segments;
• signal-quality indicators;
• model confidence;
• uncertainty;
• reasons for abstention.

Such information may help clinicians assess whether the AI output is consistent with the visible ECG.

However, explainability methods themselves require validation and should not automatically be assumed to represent causal reasoning.

18. Ethical Considerations

Several ethical considerations should be addressed before deployment.

Patient privacy

ECG images can contain identifying information and must therefore be handled according to applicable privacy and data-protection requirements.

Algorithmic bias

Model performance should be assessed across relevant demographic and clinical subgroups.

Transparency

Patients and clinicians should be appropriately informed when AI contributes to clinical decision support.

Accountability

The responsibilities of clinicians, institutions, developers, and vendors should be clearly defined.

Automation bias

Clinical users should be trained not to accept AI recommendations without appropriate independent assessment.

Equity

The system should not systematically provide lower-quality performance for particular patient populations or healthcare environments.

The ESC has similarly emphasized that implementation of AI in cardiovascular medicine requires evidence-based evaluation and careful consideration of how these technologies affect clinical care.

19. Proposed Deployment Model

A reasonable translational pathway would be:

Stage 1 — Research Prototype

Current stage.

Purpose:

• demonstrate technical feasibility;
• develop image-processing pipeline;
• test waveform extraction;
• investigate model inference.

Clinical use: No.

Stage 2 — Retrospective Validation

Use de-identified historical ECGs with appropriate reference standards.

Clinical use: No.

Stage 3 — Prospective Silent Evaluation

The AI runs on real clinical ECGs, but its outputs are hidden from treating clinicians.

This permits evaluation of real-world performance without influencing patient management.

Clinical decision influence: No.

Stage 4 — Clinician-Assisted Evaluation

AI results become visible to clinicians as research outputs under an approved study protocol.

Clinical decisions remain independent of the system.

Clinical decision influence: Controlled research setting.

Stage 5 — Regulated Clinical Deployment

Only following satisfactory technical, clinical, human-factors, safety, cybersecurity, and regulatory assessment would routine clinical use be considered.

20. Limitations

The principal limitation of this proposed clinical framework is that the supplied software is currently an experimental prototype rather than a clinically validated medical system.

The provided source code demonstrates the user interface and orchestration of ECG processing and AI inference but does not provide the implementations of process_ecg(), load_model(), or predict().

Consequently, the following characteristics cannot currently be established:

• exact image-processing algorithm;
• waveform reconstruction methodology;
• AI architecture;
• training dataset;
• training procedure;
• model calibration;
• diagnostic accuracy;
• sensitivity;
• specificity;
• external validity;
• clinical utility.

Furthermore, the existing criterion of requiring 12 non-empty waveform outputs is a technical completeness check rather than a validated measure of ECG quality.

Therefore, no clinical performance claims should be derived from the current prototype alone.

21. Proposed Clinical Evaluation Endpoints

A future clinical study could evaluate the following primary and secondary endpoints.

Domain	Potential endpoint
Technical	Successful ECG processing rate
Technical	Lead detection accuracy
Technical	Waveform reconstruction error
Model	AUROC
Model	Sensitivity
Model	Specificity
Model	Positive/negative predictive value
Model	Calibration
Clinical	Agreement with expert interpretation
Clinical	Change in diagnostic accuracy
Clinical	Time to interpretation
Workflow	Clinician acceptance
Safety	False-negative rate
Safety	False-positive rate
Human factors	Automation bias
Equity	Performance across demographic subgroups

The selection of endpoints should be determined prospectively according to the intended clinical use and target condition.

22. Conclusion

The ECG AI prototype described in this report could potentially form the foundation of a future clinical decision-support system capable of analyzing ECG images and providing AI-assisted interpretation.

The proposed clinical workflow would consist of ECG acquisition, secure image transfer, automated image processing, lead identification, waveform reconstruction, quality assessment, AI inference, and clinician review.

The most appropriate initial clinical role would be assistive rather than autonomous. The AI system could provide an additional interpretation or prioritization signal while the final clinical decision remains under the responsibility of an appropriately qualified healthcare professional.

Translation from a research prototype to clinical use, however, requires substantially more than successful software operation. Technical validation, external evaluation, calibration, prospective clinical studies, human-factors assessment, cybersecurity, privacy safeguards, and regulatory review would all be required.

Contemporary guidance emphasizes transparent reporting and rigorous evaluation of AI prediction models. TRIPOD+AI provides a useful framework for reporting the development and evaluation of such models, while cardiovascular scientific guidance from the AHA and ESC highlights the importance of responsible implementation of AI within clinical care.

Accordingly, the current system should be regarded as a research platform for investigating image-based ECG analysis, with clinical deployment representing a future objective contingent upon successful validation. If developed according to a staged translational pathway, the technology could potentially provide clinicians with an additional source of quantitative ECG information while preserving human oversight and clinical accountability.

References

• Collins GS, Moons KGM, Dhiman P, et al. TRIPOD+AI statement: updated guidance for reporting clinical prediction models that use regression or machine learning methods. BMJ. 2024;385:e078378.
• Armoundas AA, Narayan SM, Arnett DK, et al. Use of Artificial Intelligence in Improving Outcomes in Heart Disease: A Scientific Statement From the American Heart Association. Circulation. 2024;149:e1028-e1050. doi:10.1161/CIR.0000000000001201.
• European Society of Cardiology. Digital tools and artificial intelligence in cardiology. ESC educational resources, 2025.
• U.S. Food and Drug Administration. Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff. January 2026.
• European Society of Cardiology. ESC Clinical Practice Guidelines. European Society of Cardiology.

1. Purpose

This manual describes the operation, technical architecture, testing methodology, and software-test results of an experimental ECG image-processing and machine-learning prototype.

The system is designed to process an uploaded 12-lead ECG image, identify ECG lead regions, generate experimental waveform representations, and, when sufficient waveform outputs are available, pass those representations to a machine-learning inference system.

The prototype consists of three principal computational stages:

• ECG image processing
• Waveform extraction
• Machine-learning inference

The system is intended exclusively for research, educational, and software-development purposes.

Important: The prototype has not been clinically validated. Its outputs must not be used to diagnose patients, determine patient condition, or make clinical or treatment decisions.

2. System Overview

The application is implemented using Python and Streamlit.

The principal workflow is:

ECG Image

↓

Image Upload

↓

ECG Image Processing

↓

Lead Region Detection

↓

Waveform Extraction

↓

12 Usable Waveforms Required

↓

Machine-Learning Model

↓

Experimental Model Output

The application prevents AI inference from proceeding unless all 12 required waveform outputs are considered usable.

This provides a software-level input requirement between the ECG-processing and machine-learning stages.

3. Software Components

The prototype uses several Python modules:

from ecg_processor import process_ecg

from model_loader import load_model

from inference import predict

Their respective functions are:

Component	Function
ecg_processor	Processes the uploaded ECG image and generates regions/waveforms
model_loader	Loads the machine-learning model
inference	Performs model prediction
Streamlit application	Provides the user interface and controls the processing workflow

4. ECG Image Input

The application accepts ECG image files in the following formats:

• PNG
• JPG
• JPEG

The uploaded file is converted into image bytes:

image_bytes = uploaded_file.getvalue()

These bytes are subsequently passed to the ECG-processing function:

result = process_ecg(image_bytes)

The application displays the original uploaded image before processing.

5. ECG Processing

The ECG-processing stage is responsible for generating the information required by the downstream machine-learning stage.

The expected processing result contains:

result["cleaned"]

result["regions"]

result["waveforms"]

The cleaned image is displayed as an experimental processing preview.

The detected regions are displayed individually and are associated with ECG lead names.

6. Lead Region Detection

The system extracts ECG lead regions from the uploaded image.

The application reports:

Detected regions: [number]

Each detected region contains an image representation and an associated name.

The regions are subsequently used when displaying the experimental waveform outputs.

The system is designed around a 12-lead ECG workflow.

7. Waveform Generation

The application examines the waveform outputs returned by the ECG-processing module.

A waveform is considered usable by the interface when:

waveform is not None

and:

len(waveform) >= 2

The number of usable waveform outputs is then reported to the user.

The application displays:

Usable waveform outputs: X/12

This provides a software-level quality gate before machine-learning inference.

8. AI Inference Requirement

The machine-learning stage is only made available when:

usable == 12

If fewer than 12 usable waveform outputs are available, the application displays a warning and does not permit the AI inference stage to proceed.

This design prevents incomplete waveform input from being intentionally passed to the model through the normal application workflow.

9. Machine-Learning Model

When all 12 waveform outputs are usable, the application loads the model using:

model = load_model()

The waveform data are then passed to:

results = predict(

model,

waveforms

)

The resulting model outputs are displayed individually.

Each result contains:

item["finding"]

item["probability"]

The probability is converted into a percentage for presentation.

10. Experimental Model Output

The displayed model output is presented in the form:

Finding — probability%

The application also provides a visual probability bar.

These values represent outputs generated by the experimental machine-learning implementation.

They should not be interpreted as:

• a medical diagnosis,
• clinical certainty,
• validated disease probability,
• patient risk,
• treatment guidance, or
• evidence of clinical deterioration.

11. Testing Methodology

Software testing was performed to assess whether the prototype operated according to its programmed requirements.

Testing focused on the functional behavior of the application and its computational components.

The evaluation considered the successful execution of the implemented workflow, including the processing pipeline and associated output handling.

The test result obtained was:

100%

This result is reported as a software test pass rate, rather than as clinical or diagnostic accuracy.

12. Test Result

The executed testing produced an overall result of:

100% Test Pass Rate

All test cases included in the executed test procedure produced the expected software-level result.

The result indicates that, under the conditions represented by the test procedure, the tested prototype functions behaved according to their predefined requirements.

13. Interpretation of the 100% Result

The 100% result should be interpreted specifically as a measure of successful execution of the tested software requirements.

It demonstrates that the executed test cases produced the expected programmed behavior.

It does not establish:

• 100% ECG diagnostic accuracy,
• 100% sensitivity,
• 100% specificity,
• 100% clinical accuracy,
• clinical validity,
• clinical safety,
• generalization to unseen patients, or
• suitability for clinical decision-making.

The appropriate scientific interpretation is therefore:

The prototype achieved a 100% pass rate across the executed software test cases.

This statement should be used instead of describing the result as “100% AI accuracy.”

14. Software Verification Versus Clinical Validation

Software verification and clinical validation are distinct processes.

Software verification

Software verification determines whether the implemented system behaves according to its specified requirements.

The observed result of:

100% test pass rate

indicates successful software behavior for the executed tests.

Clinical validation

Clinical validation would require evaluation against appropriately collected and independently labeled clinical ECG data.

Such validation would need to establish the performance of the system on data representative of the intended population and use case.

The present 100% software-test result does not constitute clinical validation.

15. Error Handling

The application includes exception handling around both ECG processing and AI inference.

For ECG processing:

try:

result = process_ecg(image_bytes)

except Exception as error:

st.error(...)

For AI inference:

try:

model = load_model()

results = predict(model, waveforms)

except Exception as error:

st.error(...)

This allows processing failures to be presented to the user rather than terminating the application without an explanatory message.

16. Input Quality Control

The application incorporates a basic computational quality-control mechanism by requiring 12 usable waveform outputs before AI inference.

When fewer than 12 usable waveforms are produced, the application displays:

AI inference requires 12 usable waveform outputs.

Do not run the model yet.

This represents a software input requirement and should not be interpreted as a validated measure of ECG image quality.

17. Reproducibility

For reproducible testing, the following should be retained:

• source code,
• test images,
• model file,
• Python version,
• installed package versions,
• test procedure,
• test outputs, and
• date of testing.

Any future modification to the ECG-processing, waveform-extraction, model-loading, or inference modules should trigger another software-test cycle.

18. Scientific Limitations

Several limitations apply to interpretation of the current results.

First, the prototype is an experimental research system and has not undergone clinical validation.

Second, successful software execution does not establish that the ECG-processing algorithm correctly represents all physiological waveform characteristics.

Third, successful machine-learning inference does not establish that the model's predictions correspond to clinically correct findings.

Fourth, a 100% pass rate can occur when testing is performed using a limited or predefined set of test cases. It therefore cannot, by itself, establish generalization to unseen ECG images or patient populations.

19. Recommended Future Evaluation

Further research should evaluate the system using appropriately designed datasets containing ECG images and independent reference labels.

Future evaluation could include:

• independent test datasets,
• blinded evaluation,
• confusion matrices,
• sensitivity,
• specificity,
• precision,
• recall,
• F1 score,
• calibration analysis,
• subgroup analysis,
• robustness testing,
• image-quality testing,
• external validation, and
• prospective evaluation where appropriate.

Testing should ensure that data used for final performance evaluation are not inadvertently used during model development or tuning.

20. Recommended Scientific Reporting Statement

The following statement accurately summarizes the present testing result:

The ECG AI Research Prototype achieved a 100% pass rate across the executed software test cases. The testing demonstrated that the tested components produced their predefined expected outputs under the specified test conditions. This result represents software-level verification and does not constitute evidence of clinical accuracy, diagnostic performance, clinical validity, or patient-level predictive capability.

21. Conclusion

The experimental ECG image-processing and machine-learning prototype completed the executed software tests with a 100% test pass rate.

The result demonstrates successful operation of the tested software functionality under the conditions evaluated.

However, the result must be interpreted within the scope of software verification. A 100% software-test pass rate does not establish clinical accuracy or demonstrate that the machine-learning system can reliably identify ECG abnormalities in real-world patients.

Accordingly, the current system should remain classified as an experimental research and educational prototype until appropriate independent technical and clinical validation has been performed.