ECG & cardiology signal analysis

Cardiologists and technicians must review huge volumes of ECGs: millions of beats per Holter recording, plus resting 12-lead ECGs in every emergency department and GP practice. Deep learning on ECG waveforms classifies rhythms, pre-selects the relevant strips and, increasingly, detects conditions such as reduced ejection fraction from a routine ECG. The result is faster triage and less manual scrolling, while a clinician still signs off. Because the software is a medical device, certification and clinical validation dominate the effort.

Problem & value

• Today: resting ECGs get a built-in rule-based interpretation (often wrong or over-sensitive) followed by physician over-read. Long-term recordings (24 h to 14 days, patch monitors, implantable loop recorders) are pre-analysed by software and then manually verified by technicians; false alarms and strip review are the main workload.
• AI value: automatic beat/rhythm classification with fewer false positives, prioritised worklists (e.g. suspected STEMI, high-grade AV block first), screening for AF in wearables, and "opportunistic" detection of conditions the ECG was not ordered for.
• Evidence: Anumana's FDA-cleared low-ejection-fraction algorithm works on a standard 12-lead resting ECG and is distributed via the Philips ECG AI Marketplace (launched July 2025); Anumana also received FDA 510(k) clearance in March 2026 for a pulmonary-hypertension ECG algorithm [1][2]. These are US clearances; check CE status per product before EU use.

Variants

• Hospital / emergency 12-lead triage: worklist priority and STEMI/rhythm flags inside the ECG management system.
• Ambulatory monitoring (Holter, patches, loop recorders): cloud-based beat classification with technician review (cardiac-monitoring service providers).
• Primary care and screening: low-cost devices plus AI for AF screening.
• Consumer wearables: single-lead smartwatch ECG and irregular-rhythm notification; see HLTH-007 for the monitoring pipeline. Private users get an alert, not a diagnosis.
• Research / pharma: automated QT-interval and safety ECG analysis in clinical trials.

How it works

1. acquisition (12-lead cart, Holter, patch, wearable)
2. signal QC (lead-off, noise, baseline wander) + filtering
3. R-peak / fiducial detection, beat segmentation
4. model inference (1D-CNN / ResNet / transformer, or ECG foundation model + task head)
5. rhythm / morphology / risk outputs with confidence
6. worklist prioritisation + draft report in ECG management system
7. cardiologist or technician confirmation (human-in-the-loop)
8. EHR

• Models: supervised 1D convolutional or transformer networks on raw waveforms; self-supervised ECG foundation models pre-trained on large unlabelled corpora, then fine-tuned per task. Classical ML on hand-crafted features (HRV, intervals) remains useful for simple rhythm questions and edge devices.
• Human-in-the-loop: every diagnostic output is a suggestion; unconfirmed rhythm alarms and low-confidence segments go to a technician; the physician signs the final report.
• LLM role: only for report drafting and summarising a patient's cardiology history (see HLTH-011, HLTH-018); the waveform diagnosis stays with the dedicated signal model.

Data preparation

The core data are ECG recordings (SCP-ECG, DICOM waveform, HL7 aECG, XML or even PDF printouts), Holter and patch recordings, plus patient context from the hospital information system. In an SMB-sized cardiology practice they typically sit in the ECG management system of the device vendor, partly on the cart's local disk, partly as paper or PDF printouts in the patient file.

Typical gaps: proprietary or inconsistent export formats between device generations, PDF-only legacy ECGs without raw signal, unlabelled or free-text diagnoses, noisy or lead-off recordings, duplicated patient identities and unclear consent for secondary use.

Preparation steps: - Inventory devices and formats; export raw signals via vendor interfaces or HL7/DICOM (see PREP-005). - Convert to one open waveform format (e.g. WFDB or SCP-ECG) and run an automatic signal-quality filter. - Harvest labels from signed cardiologist reports and ECG codes in the record (PREP-020); have a cardiologist review a gold-standard test set (PREP-018). - Pseudonymise before any research use or transfer (PREP-022).

With a certified product, most of the work is the connection to the ECG system and the validation on your own population; for own development the data work easily takes more than half of the total effort, driven by labelling and ethics/consent approval.

Implementation paths

Which path for whom

• enterprise (hospitals, cardiac-monitoring providers): Path A, because only a CE-marked (MDR) ECG product comes with a clinical validation and a manufacturer who carries the product responsibility.
• developer: Path C, because open ECG datasets and open-weight models allow building and validating a research or pre-product prototype locally, without patient data leaving your environment.
• public (university hospitals, municipal clinics): Path A with EU or on-premise hosting, because procurement rules and the medical-device regime favour certified products; self-built models need their own conformity route.

Path A — Buy (recommended)

• ECG management systems with AI: Philips IntelliSpace ECG with its ECG AI Marketplace (third-party algorithms such as Anumana) [1], GE HealthCare MUSE, Hillrom/Baxter (Welch Allyn), Schiller (CH) and Cardiac Science/Spacelabs-class vendors; check EU MDR certificate and local hosting.
• Ambulatory/Holter analysis: iRhythm (US), Bardy/Baxter, Philips, and European providers such as Idoven (ES), Cardiologs (FR, now part of Philips), Medicalgorithmics (PL), Biotricity-class patch vendors; verify current CE-mark status per product with the vendor.
• Choose A when: you need a certified medical device with support; building your own makes you the legal manufacturer.

Path B — Build on cloud APIs

• No general-purpose LLM API is suited to diagnosing from raw ECG waveforms; cloud use is limited to infrastructure (EU-region storage, MLOps, FHIR/DICOM services such as Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake in EU regions) and to LLM report drafting with a data processing agreement. Using these to power a diagnostic function still makes the output a medical device.

Path C — Self-host (open source)

• Data and tooling: PhysioNet's PTB-XL (about 22k 12-lead ECGs, open licence) [3], PhysioNet/CinC challenge datasets [4], wfdb and NeuroKit2 for signal handling, PyTorch for models, ONNX Runtime for edge inference.
• Models: open ECG foundation models and published baselines (ResNet-1D, S4, transformer variants) from academic groups; evaluate on your own population before any use.
• Hardware: HW1 suffices for inference (CPU or small edge accelerator, even on-device in a patch); training a mid-size model needs HW2/HW3.
• Status: suitable for research, retrospective studies and in-house tools under MDR Art. 5(5) health-institution exemption (see Risks); not a shortcut to clinical use.

Path D — Custom training

Worth it for a vendor building a new indication, for hospitals with large local ECG archives linked to echo or outcome labels (e.g. ejection fraction), or to adapt to local devices and populations. Needs tens of thousands of labelled ECGs, ideally with echo/cath confirmed labels, multi-site external validation, and a QMS (ISO 13485, IEC 62304, ISO 14971).

State of the art (2026)

• Deep learning matches or exceeds cardiologist-level performance on defined rhythm classification tasks in retrospective studies; ECG-AI for structural disease (low ejection fraction, pulmonary hypertension, hypertrophy, valve disease) is the growth area and now has regulatory clearances [1][2].
• Foundation models pre-trained with self-supervision reduce labelled-data needs, and marketplaces (Philips) let hospitals add third-party algorithms to one platform [1].
• Limits and failure modes: distribution shift across devices, sampling rates and populations; noisy or paced rhythms; rare rhythms underrepresented; label noise from rule-based interpretations; automation bias (clinicians over-trusting AI over-reads); subgroup performance gaps by age, sex and ancestry. Retrospective accuracy often overstates prospective performance.

Shared resources & combinations

• Same capability stack (time-series, anomaly-detection, edge-runtime): HLTH-007 wearable monitoring, HLTH-035 EEG/sleep studies, HLTH-012 deterioration early warning, ANOM-005 industrial sensor anomalies.
• Downstream: HLTH-011 report generation, HLTH-004 decision support (combining ECG with labs and history), HLTH-001 for imaging correlation (echo/CT).
• Infrastructure: DICOM/FHIR waveform interoperability shared with HLTH-028.

Effort, cost & KPIs

• Path A: weeks to months (integration with ECG management system, MDR/DPIA paperwork, validation on local data); licence per ECG or per recording.
• Path B/C: 6–12 months for research-grade tools; certification adds a year or more.
• Path D: multi-year, QMS and clinical-evaluation heavy.
• KPIs: sensitivity/specificity per rhythm against cardiologist consensus, false-alarm rate per recording, technician minutes per Holter, time-to-first-read for urgent ECGs, override rate, subgroup performance, drift monitoring.

People & change

Involve management and the head of cardiology first (scope, liability, budget), then IT and IT security (interfaces, network segmentation, medical-device networks), the data protection officer and legal/compliance early, because health data are special-category data: a DPIA under Art. 35 GDPR is likely, and every vendor needs an AVV (Art. 28 GDPR). Check the MDR certification and the manufacturer's AI Act obligations (see GUIDE-014).

Works council: depends. If the system only analyses patient signals, co-determination is not automatically triggered, but §87(1) no. 6 BetrVG applies as soon as the software logs which staff member confirmed, rejected or delayed findings; the BAG holds that objective suitability for monitoring suffices. §90(1) no. 3 requires timely information when work processes are planned with AI. In public hospitals the staff council (Personalrat) has comparable rights. Conclude a short works agreement excluding performance evaluation of individual physicians (GUIDE-004).

Support AI literacy (Art. 4 AI Act) with short training for cardiologists and technicians on automation bias, confidence values and error types (GUIDE-006). Start with a pilot group of two or three technicians in shadow mode, comparing AI and human reads. Typical concern: "the AI replaces my judgement". Address it by keeping the physician's signature mandatory and logging overrides as feedback (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: high-risk. Software with a medical purpose that requires third-party conformity assessment under MDR (Regulation 2017/745, Rule 11, typically class IIa or higher) is a high-risk AI system under Art. 6(1) and Annex I; obligations on risk management, data governance, logging, human oversight and accuracy apply [5][6]. Consumer wellness-only features without medical purpose may fall outside.
• MDR: AI diagnostic software is a medical device; in-house development by a health institution is possible only under the Art. 5(5) conditions (no equivalent CE product, QMS, justification). Qualification and classification: MDCG 2019-11 [7].
• GDPR: health data is special-category (Art. 9); needs a legal basis, DPIA, EU hosting, strict access control; research reuse needs pseudonymisation and ethics approval. ECG waveforms can be re-identifying biometric-like signals, so treat them as personal data even without names.
• Risks and mitigations: automation bias (show confidence, require sign-off), device and population shift (local validation, monitoring), missed critical findings (conservative thresholds for urgent rhythms, fallback to standard over-read), cybersecurity of connected devices.

Getting started

1. Define the clinical question (triage, Holter pre-read, screening) and baseline reading times and error rates.
2. Check which certified AI options your ECG management vendor already offers and their CE status.
3. Pilot with retrospective local ECGs to measure performance by device and subgroup, then run a silent prospective trial.
4. Complete DPIA, MDR/AI Act role analysis (deployer vs. manufacturer) and define human-oversight workflow.
5. Monitor override rates and drift after go-live.

Sources

1. Philips ECG AI Marketplace launch (Anumana LEF as first third-party solution), July 2025 — https://www.usa.philips.com/about/news-and-insights/press-release/philips-launches-ecg-ai-marketplace-to-enhance-early-cardiac-diagnosis
2. DAIC — Anumana secures FDA clearance for ECG-AI pulmonary hypertension algorithm, March 2026 — https://www.dicardiology.com/content/anumana-secures-fda-clearance-ecg-ai-algorithm-early-detection-pulmonary-hypertension
3. PhysioNet — PTB-XL, a large publicly available ECG dataset — https://physionet.org/content/ptb-xl/1.0.3/
4. PhysioNet/Computing in Cardiology Challenge 2021 — https://physionet.org/content/challenge-2021/
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
7. MDCG 2019-11 Guidance on qualification and classification of software — https://health.ec.europa.eu/system/files/2020-09/md_mdcg_2019_11_guidance_qualification_classification_software_en_0.pdf