Built in response to HeartBug's scale challenge

10 Million ECG Signals.
Triaged in Real Time.

A working demonstration of the AI pipeline architecture I would build for HeartBug, handling signal ingestion, quality filtering, clinical priority classification, and EP work queue generation at production scale.

▶ Run the PipelineView Architecture
10M+
ECG Signals Per Week
< 2.3ms
Processing Latency
91.5%
EP Workload Reduction
28 Days
Continuous Monitoring Data
Live

Live Signal Ingestion Feed

Real-time view of raw ECG signals arriving from HeartBug patches across Australia. This is unprocessed device data before any pipeline analysis, classification, or triage.

2,980
Active Devices
HeartBug patches transmitting
The number of HeartBug wearable ECG patches currently connected and transmitting data to the ingestion layer. Each device is a single-lead or multi-lead patch worn by a patient, sending continuous ECG waveforms over cellular/WiFi.
0
Signals Today
since midnight AEST
Total raw ECG signal packets received since midnight AEST. Each signal is a short ECG recording segment (typically 10-30 seconds) transmitted by a HeartBug patch. This counter resets daily at midnight Australian Eastern Standard Time.
0
Queued for Analysis
pending pipeline processing
Signals that have been received but not yet processed through the 6-stage pipeline (denoising → QRS detection → feature extraction → classification → triage). This backlog grows during peak hours and clears as the pipeline processes signals.
~16.7K/s
Current Rate
signals per second
The real-time throughput of the ingestion layer — how many signal packets per second are being received right now. This fluctuates based on time of day, patient activity, and device transmission schedules. Measured at the AWS Kinesis stream level.
0.0K/s
Peak Rate Today
maximum throughput recorded
The highest ingestion throughput recorded today. Peak rates typically occur between 8AM-6PM AEST when patient activity is highest. This metric helps capacity planning — the system must handle sustained peak load without dropping signals.
0h
System Uptime
continuous operation
Hours of uninterrupted operation since the last system restart. For a clinical-grade pipeline, 99.9% uptime (< 8.7 hours downtime/year) is the minimum requirement. This tracks the ingestion layer availability, not individual device uptime.
82.4% avg signal quality
Average signal quality score across all received signals, measured as a percentage of waveform fidelity. Factors include electrode contact quality, patient movement, electrical interference, and device battery level. Scores above 80% are considered clinical-grade. Below 60% may require re-recording.
99.7% device connectivity
Percentage of registered HeartBug devices that successfully transmitted at least one signal in the last 5 minutes. A drop below 99% may indicate network issues, device firmware bugs, or regional outages. Each device connects via cellular (4G/5G) or WiFi to the AWS IoT Gateway.
2.1ms avg ingestion latency
Average time from when a signal packet arrives at the AWS Kinesis endpoint to when it is written to the ingestion buffer. This measures infrastructure latency only, not end-to-end processing time. Clinical SLA requires <10ms for real-time monitoring applications.
All signals: Received
At this stage, all incoming signals are marked as "Received" — raw, unprocessed data. No classification, triage, or quality assessment has been applied yet. Signals are simply buffered for the pipeline. Classification into Critical/Review/Normal happens in Stage 4-6 of the pipeline.

24-Hour Signal Arrival Pattern

Signal volume by hour, AEST timezone • Current hour highlighted

Hourly distribution of incoming ECG signals over the current AEST day. The pattern reflects real-world patient activity — lower volumes overnight (11PM-5AM) when patients are sleeping, ramping up in the morning, and peaking during daytime hours (9AM-5PM) when patients are most active. Red bar = current hour, pink = completed hours, grey = upcoming hours (no data yet). This pattern is critical for auto-scaling decisions — the pipeline provisions more compute capacity during peak hours.
Current Hour Past Hours Upcoming

Device Distribution

by Australian state

Geographic distribution of active HeartBug patches across Australian states. NSW and VIC have the highest device counts due to larger populations and earlier HeartBug rollout. This distribution affects regional Kinesis shard allocation — states with more devices get more dedicated ingestion capacity to maintain low latency.

ECG Lead Distribution

active lead configurations

Distribution of ECG lead types across incoming signals. Each HeartBug patch records from a specific lead position: MLII (Modified Lead II — standard monitoring lead), V1 (right sternal — best for bundle branch blocks), V5 (left chest — ST segment analysis), aVF (inferior lead — detects inferior MI), II (limb lead — P-wave visibility). The mix reflects the clinical configuration assigned to each patient by their electrophysiologist.
Lead MLII
21.1%
Lead V1
20.0%
Lead V5
18.9%
Lead aVF
17.9%
Lead II
22.1%

Raw Signal Ingestion Stream

A real-time, chronologically ordered log of every ECG signal packet arriving at the ingestion layer. Each row represents a single transmission from a HeartBug patch — showing the timestamp, patient ID, device ID, ECG lead configuration, geographic region, heart rate, signal quality score, and device battery level. All signals enter as "Received" (unprocessed raw data). This stream is persisted to Supabase and runs 24/7 via a background generator, even when the browser is closed.
0 signals logged Received
Time
Patient
Device
Lead
Region
HR
Quality
Battery
Status

Raw signals streamed from HeartBug ECG patches via AWS Kinesis Data Streams • Secure TLS 1.3 encrypted transmission • No classification or triage applied at this stage

Pipeline Execution

Step through each stage of the 10-stage ECG processing pipeline. Click each button sequentially or use "Run All Stages" to process signals end-to-end.

Pipeline Configuration

Configure the parameters for the 10-stage ECG processing pipeline. Choose a preset for common scenarios or customise individual settings. Simulation Parameters control the input data characteristics (volume, noise, arrhythmia mix). Clinical Thresholds control how the pipeline makes decisions (quality gates, confidence routing, model selection). Changes here directly affect all downstream stage results.
1D CNN 44.8K paramsSimulation Mode
Simulation Parameters
Total number of ECG signal packets to process in this pipeline run. Higher volumes stress-test throughput and scaling. 100K is a quick test (~5 seconds), 10M simulates a full day of production data across all active HeartBug devices. Each signal is a 10-30 second ECG recording segment.
Simulates real-world signal degradation. Low (5%) = clinical-grade recordings with minimal interference. Medium (15%) = typical ambulatory conditions with some motion artifacts and baseline wander. High (30%) = challenging conditions — active patients, poor electrode contact, heavy EMG interference. Higher noise means more signals rejected or requiring denoising.
Percentage of signals containing arrhythmias (abnormal heart rhythms). 1% = healthy population screening. 5% = general cardiac monitoring cohort. 10% = standard clinical mix (HeartBug default). 15% = high-risk patient cohort (post-MI, heart failure). Higher prevalence generates more Critical and Review queue entries for the EP team.
Clinical Thresholds
Minimum Signal-to-Noise Ratio (in decibels) a signal must have to pass quality assessment. 12dB = lenient, accepts more borderline signals but risks noise-induced misclassification. 15dB = standard clinical threshold. 18-20dB = strict, rejects more signals but ensures high-fidelity input to the ML model. Signals below this threshold are either sent for denoising or rejected entirely.

Reject signals below this SNR

The ML model confidence threshold for routing a signal to the CRITICAL queue. Only arrhythmias classified above this confidence level trigger immediate EP alerts (pager, SMS, dashboard). 95% = production default (very few false positives). 80% = more sensitive, catches more true positives but increases false alarm rate. Life-threatening arrhythmias (VT, VF, CHB, ST Elevation) are routed here.

Route to CRITICAL above this

Confidence threshold for routing signals to the EP REVIEW queue. Arrhythmias above this threshold but below the Critical threshold are flagged for electrophysiologist review within 24 hours. 85% = standard. Lower values catch more borderline cases but increase the EP team's review workload. Conditions like AF, SVT, PVC, and bundle branch blocks are routed here.

Route to EP REVIEW above this

The trained ML model used for ECG classification. ECG-CNN-v1 = production 1D convolutional neural network (44.8K params, ~3ms inference). ECG-CNN-v2 = improved architecture with residual connections (Beta, ~4ms). ECG-Transformer-v1 = attention-based model for complex arrhythmias (Experimental, ~8ms inference, higher accuracy on rare conditions). Model choice affects classification accuracy, latency, and false positive rates.

Trained model for inference

Pipeline Run History

Previous Pipeline Runs

View, compare, and export results from all previous pipeline executions. Click any run to expand its stage details.

Always On

Ingestion & Processing Metrics

Real-time performance metrics for the ECG signal processing pipeline. Monitoring throughput, latency, and system health around the clock.

Data Flow Pipeline

+12.4%
0
Signals Processed Today
via stream ingestion layer
stable
16.2K/s
Current Throughput
real-time processing rate
-0.3ms
2.1ms
Avg Latency
end-to-end processing
+2.1%
87.3%
Auto-Resolved
no EP attention required
99.95% SLA
99.97%
System Availability
last 30 days SLA
offline
—
ECG Records in DB
PhysioNet MIT-BIH + pipeline

Live Throughput

signals/second over last 60 seconds

16.2K/s

Pipeline Summary

cumulative metrics

Total Pipeline Runs47
Signals Classified4.72M
Critical Detections33.0K
Avg Processing Speed44.8K/s
Model Accuracy94.2%
False Positive Rate1.8%
Always On

Stage 1 — Signal Quality Filter

Not all signals are worth analysing. The first layer eliminates noise and corruption before any ML inference runs — saving compute and EP time.

0
signals assessed
Clean: 0.0% Noisy: 0.0% Corrupted: 0.0%

Clean Signals

0(0.0%)

Passed quality threshold -- advancing to clinical classification

Noisy Signals

0(0.0%)

Elevated noise floor detected -- routed to signal processing layer

Corrupted / Unusable

0(0.0%)

Auto-rejected -- electrode disconnect or corrupt transmission. Never reaches EP queue.

Signal Quality Trend

clean % vs noise floor % over last 72 seconds

Clean %
Noise Floor %
+0.3 dB
18.4 dB
Avg SNR
nominal
96.2%
Electrode Contact
+1.2%
96%
Filter Efficiency
0

signals eliminated before reaching your EPs

Real Clinical Signal Classification

Live TensorFlow.js inference on real ECG waveform data from the MIT-BIH Arrhythmia Database — classified directly in your browser.

Loading TensorFlow.js model and ECG data...
Clinical Classification Active

Stage 2 — Clinical Priority Classification

Clean signals are classified by urgency. Only what matters reaches your Electrophysiologists.

CRITICAL

Immediate EP Attention

0

VT, VF, Complete Heart Block, ST Elevation

Alert Sent Immediately

REVIEW REQUIRED

Scheduled EP Review

0

AF, SVT, PACs, PVCs, Bundle Branch Block

Added to EP Queue

NORMAL

Auto-Archived

0

Normal Sinus Rhythm — within expected parameters

Auto-Archived

Classification Distribution

0.0%
Critical (0.0%)
Review (0.0%)
Normal (0.0%)

Response Metrics

Critical Avg Response
< 2 min
Review Queue Depth
3
EP Utilisation
34.2%
Alerts Sent Today
0

Classification Confidence

Model Confidence94.2%
False Positive Rate1.8%
Sensitivity (Critical)99.1%
Specificity97.8%
0.0%

of signals require zero EP involvement

Your team focuses only on what matters

Live Queue

EP Work Queue Output

Signals flagged as critical or requiring review are routed here in real time. This is what lands on your Electrophysiologists' screens.

Export EP DataDownload for clinical review or integration
PriorityPatient IDSignal TimeClassificationConfidenceDurationAction
Waiting for incoming signals...
0signals in queue

Production Architecture

How this pipeline would be deployed at HeartBug's scale in production on AWS. Each layer is shown with its technical configuration and data flow.

HeartBug Devices

Continuous ECG patch monitoring, worn on-body for up to 28 days

Signal Specs
Sampling Rate360 Hz
Resolution12-bit ADC
Voltage Range+/- 5 mV
Lead ConfigMLII, V1, V5, aVF, II
Segment Length10s (3,600 samples)
Transmission
ProtocolBLE 5.0 / LTE-M
RelayPhone app or direct
Payload Size~7.2 KB per segment
Upload IntervalEvery 10 seconds
EncryptionAES-256 in transit
Device Profile
Wear DurationUp to 28 days
Battery Life30+ days
Active Devices~3,000 concurrent
Signals/Week10,000,000+
RegionsNSW, VIC, QLD, WA, SA, TAS

AWS Kinesis Data Streams

High-volume signal ingestion, buffering millions of events/sec

Stream Configuration
Stream Nameheartbug-ecg-ingest
Shard Count8 shards (auto-scale)
Write Capacity8 MB/s (1 MB/shard)
Read Capacity16 MB/s (2 MB/shard)
Records/sec8,000 per shard
Retention7 days
Partitioning Strategy
Partition Keydevice_id + region
OrderingPer-shard FIFO
Consumer Groups3 (Lambda, Archive, Monitor)
Enhanced Fan-OutEnabled
CloudWatch MetricsIteratorAge, GetRecords
Dead Letter QueueSQS (failed records)

Why Kinesis? At 10M+ signals/week arriving in bursts, a direct database write would cause connection pool exhaustion and dropped records. Kinesis acts as a durable buffer, absorbing any traffic spike and releasing records at a controlled rate to downstream consumers. Nothing is lost even during peak load.

AWS Lambda — Preprocessing Pipeline

Serverless compute, auto-scales to match Kinesis throughput

Signal Parsing
Format Validation
Noise Detection
Quality Score

1. Signal Parsing

  • *Decode raw byte stream to float32 array
  • *Normalise voltage to standard mV scale
  • *Verify 360Hz sampling rate, resample if needed
  • *Attach metadata (patient_id, device_id, lead, timestamp, region)

2. Format Validation

  • *Confirm 3,600 samples per 10s segment
  • *Validate timestamp within expected range
  • *Verify device_id exists in device registry
  • *Check patient consent status is active

3. Noise Detection

  • *Baseline wander detection (high-pass filter)
  • *50/60Hz powerline interference check
  • *Muscle artifact / motion detection
  • *Electrode disconnect (flat-line detection)

4. Quality Score

  • *Compute SNR (signal-to-noise ratio)
  • *Assign quality score 0-100
  • *Route: Clean (>70), Noisy (30-70), Corrupted (<30)
  • *Corrupted signals rejected, never reach ML
512 MB
Memory per function
~45ms
Avg execution time
1,000
Concurrent executions
~18%
Signals rejected here

Amazon SageMaker — ML Inference

Real-time classification of clean ECG signals using trained neural networks

Model Architecture
ModelECG Arrhythmia Classifier v1
Architecture1D CNN (13 layers)
Parameters44,800
Input Shape360x1 @ 360Hz
Output6 classes + confidence
FrameworkTensorFlow / Keras
Training DataMIT-BIH Arrhythmia DB
Inference Performance
Instance Typeml.g4dn.xlarge (GPU)
Latency P502.1 ms
Latency P953.4 ms
Latency P995.8 ms
Throughput~44,800 signals/sec
Model Accuracy94.2%
False Positive Rate1.8%
Classification Output Classes

Critical (Immediate Alert)

Ventricular Tachycardia (VT)
Ventricular Fibrillation (VF)
Complete Heart Block (CHB)
ST Elevation (STEMI)

Review (EP Queue)

Atrial Fibrillation (AF)
Supraventricular Tachycardia (SVT)
Premature Ventricular Contractions (PVCs)
Bundle Branch Block (BBB)

Normal (Auto-Archived)

Normal Sinus Rhythm (NSR)
Sinus Bradycardia
Sinus Tachycardia
Premature Atrial Contractions (PACs)

Routing Thresholds: confidence ≥ 95% + critical class = Immediate SNS alert + RDS store | confidence ≥ 90% + review class = EP queue + RDS | Normal class at any confidence = DynamoDB archive only. Signals below 85% confidence on any class are flagged for manual review regardless of classification.

Results Router

Routes classified signals to the appropriate destination based on priority and confidence

CRITICAL (VT, VF, CHB, STEMI @ ≥95% confidence)
RDS + SNS + EP Queue
REVIEW (AF, SVT, PVCs, BBB @ ≥90% confidence)
RDS + EP Queue
NORMAL (NSR, sinus variants @ any confidence)
DynamoDB only
LOW CONFIDENCE (any class @ <85% confidence)
Manual Review Queue

Amazon RDS (PostgreSQL)

Primary store for critical + review cases

EnginePostgreSQL 15
Instancedb.r6g.xlarge
Storage500 GB gp3
Tablespipeline_runs, ep_queue, classified_signals
RetentionIndefinite (compliance)
BackupDaily snapshots, 35-day
In demo: Supabase PostgreSQL

DynamoDB

Archive for all signals (including normal)

Table ModeOn-Demand (auto-scale)
Partition Keypatient_id
Sort Keycreated_at
Write CapacityUnlimited (on-demand)
TTLDisabled (legal retention)
StreamsEnabled (model retraining)
In demo: signal_feed + ecg_signals tables

SNS Alert System

Immediate notification for critical findings

Topicheartbug-critical-alerts
SubscribersOn-call EP team
ChannelsSMS, Email, Push, PagerDuty
Target Latency< 2 min to EP
EscalationAuto-escalate @ 5 min
Dedup Window5 min per patient
In demo: Critical alerts in EP Work Queue

React Clinical Dashboard

What the Electrophysiologist sees on their screen

Live Signal Feed
Real-time stream from devices
Pipeline Operations
Run configuration + status
Signal Quality Filter
Clean / Noisy / Corrupted view
Clinical Priority
Critical / Review / Normal
EP Work Queue
Priority-sorted, actionable list
Data Export
CSV / JSON download for EPs
FrameworkNext.js 14 (App Router)
LanguageTypeScript
DatabaseSupabase PostgreSQL
RealtimeSupabase Realtime (WebSocket)
In-Browser MLTensorFlow.js (1D CNN)
ChartsRecharts
AnimationsFramer Motion
StylingTailwind CSS v3

Security & Compliance Considerations

Data Protection

AES-256 encryption at rest and in transit

VPC-isolated compute (no public endpoints)

IAM role-based access per service

Healthcare Compliance

TGA (Therapeutic Goods Administration) aligned

Australian Privacy Act 1988 compliant

Full audit trail on all signal access

Operational

CloudWatch monitoring + alarms

99.95% uptime SLA target

Blue/green deployment for model updates

PythonTensorFlow / PyTorchTensorFlow.js (In-Browser)AWS SageMakerAWS KinesisAWS LambdaAmazon RDSDynamoDBSNSApache KafkaSupabase (PostgreSQL + Realtime)React / Next.jsTypeScript

Pipeline Performance Summary

The numbers that matter for HeartBug's operations.

0
Total Signals Processed
0.0%
Auto-Resolved (No EP Needed)
0.0%
Referred to EP Queue
—
Average Processing Latency
~0 hours/week
EP Hours Saved Per Week
—
Estimated Annual Saving

HeartBug processes millions of signals.
Your EPs should only see the ones that matter.

How This Was Built

And why.

During my interview with Srikanth, Yijie and the HeartBug team on Thursday 12 March 2026, Srikanth described the volume problem HeartBug faces: more than 10 million ECG signals per week, needing intelligent triage to identify what requires clinical attention and what doesn't.

He asked me how I'd architect a solution.

I went home and built it.

This pipeline was built using real clinical ECG data from the MIT-BIH Arrhythmia Database. It runs a TensorFlow.js neural network directly in your browser to classify arrhythmias, connects to a Supabase PostgreSQL database for persistent storage, and uses Supabase Realtime for live EP queue updates. This demonstrates the exact architecture I would propose for HeartBug's production environment.

If something doesn't work the way you need it to, come back to me. Tell me exactly what needs to change. I will modify it. That is not a problem. That is how I work.

Data Sources

  • •MIT-BIH Arrhythmia Database, PhysioNet
  • •PhysioNet Computing in Cardiology Challenge
  • •PTB-XL 12-Lead ECG Database

Built With

Next.js 14 (App Router)TypeScriptTensorFlow.js (1D CNN)Supabase (PostgreSQL + Realtime)Tailwind CSS v3RechartsFramer MotionMIT-BIH ECG Data

Built by Bernard Adjei-Yeboah

AI Engineer | Machine Learning & Healthcare Technology

Master of IT (Artificial Intelligence), APIC, Dec 2025

Important Notice

Prototype Disclaimer

This is a portfolio prototype built by Bernard Adjei-Yeboah as part of a job application to demonstrate technical capability in handling large-scale ECG signal processing pipelines.

1

This application is NOT the official HeartBug platform and is NOT affiliated with, endorsed by, or produced in partnership with HeartBug Pty Ltd.

2

All statistics, patient data, device identifiers, and signal metrics displayed are entirely fictional and simulated for demonstration purposes only. No real patient data is used or stored.

3

ECG waveform data is sourced from the open-access PhysioNet MIT-BIH Arrhythmia Database for educational and demonstration purposes under the Open Data Commons Attribution License.

4

This prototype must NOT be used for clinical, diagnostic, or medical decision-making purposes. It does not represent, replicate, or reflect actual HeartBug systems, data, or capabilities.

5

The AI classification model shown is a lightweight demonstration model and does NOT provide medically accurate arrhythmia detection.

For official HeartBug information, visit:

heartbug.com.au

© 2026 Bernard Adjei-Yeboah. All rights reserved. This prototype is for demonstration purposes only.