Omar Chenine
Rank 02CVHealthcareFeatured

ECG image analysis

An ECG image goes in. A digitized signal, rhythm, axis, PR, QRS, and a review flag come out.

A clinical format report generator that digitizes an ECG image and refuses to guess when the signal is weak.

Role
Build and evaluation
Year
Pending
Case study
483 words
Demo
Client side
PythonNumPyImage analysisECG signal digitizationModel evaluation

Result: the app turns an ECG image into a digitized signal, rhythm, axis, PR, and QRS, then produces a clinical format report with a review flag. Validation metrics are add digitization error and flag rate.

Problem

ECG images are easy to share and hard to compute on. A report that looks confident but is wrong is worse than a report that asks for review. The product decision was to make uncertainty a first class output, not an error toast.

Data

The ground truth source is add source and license. The validation set size is add image count and patient count if available. Images must be synthetic or public and de identified. No patient data is used in the demo.

Approach and why

  1. Clean the image and remove text and grid artifacts where possible.
  2. Calibrate the grid so pixel distances can become time and voltage.
  3. Extract the trace, then detect R peaks.
  4. Estimate rhythm, axis, PR, and QRS from the trace and the lead assumptions.
  5. Generate a report with a review flag when signal quality or confidence is low.

The calibration step is explicit because axis and intervals are meaningless without a stated scale. The review flag is the safety valve. It is not a decoration.

Results

CheckResultNotes
Digitization erroradd pixel or millimeter errorAgainst the reference trace
R peak sensitivityadd resultDetection on the validation set
PR interval erroradd result in millisecondsadd tolerance
Review flag rateadd rateOn the validation set

Evaluation

  • Leakage: no patient appears in both the calibration and validation sets. The split is by patient where possible.
  • Baseline: a simple threshold based trace extractor, so the added steps have to earn their place.
  • Validation: held out images with a reference signal or reference measurements.
  • Metric: digitization error, R peak sensitivity, interval error, and flag rate are reported separately. A single accuracy number would hide the failure mode.
  • Reproducibility: fixed image preprocessing settings, a recorded calibration assumption, and a saved validation manifest.

A reviewer should challenge any clinical claim, any accuracy number without a validation set, and any axis value without a stated lead assumption.

Limitations

The app is not a medical device. It does not diagnose. Image quality, cropping, and grid spacing can break calibration. The review flag threshold is add threshold and rationale. The demo uses a synthetic sample and is labeled as such.

Next steps

Build a validation set with a reference signal, calibrate the flag threshold, add a cardiologist review pass, and publish a model card with intended use and out of scope use.

Links

Client side demoNot production output

ECG digitization and review flag

Pick a synthetic trace. The demo detects R peaks, estimates rate, rhythm, axis, PR, and QRS, and decides whether the report needs review. The upload control previews an image only.

Regular rhythm, clean trace, no review expected.

Synthetic trace, 10 seconds at 250 Hz

Synthetic readout

Within demo range
Heart rate
72 bpm
Rhythm
Regular rhythm
Axis
60 deg
PR interval
160 ms
QRS duration
90 ms
Detected peaks
11
Signal quality89 / 100

The demo trace is clean enough to report, but this is still synthetic data, not a diagnosis.

Not a medical device. Do not use for diagnosis or treatment. Synthetic data only.

Synthetic demo: the signal and the interval values are generated from a fixed sample. This is not a measurement of an uploaded image and not a clinical validation.

Headline metrics

Digitization error
See demo readout
Review flag rate
See demo

Case study length

483 / 500