Reading Every ECG Machine's Data Correctly

The expensive mistake in medical-device interoperability is believing that a standard is an agreement. The DICOM standard (NEMA, 2024) says every compliant device produces structured data that any compliant system can read, and that is true in the same way a shared alphabet makes two languages mutually intelligible. A study of vendor-specific DICOM encoding (Scientific Data, 2025) catalogs what actually happens: manufacturers store acquisition parameters in private tags rather than public ones, different manufacturers interpret the same public tag differently, and some vendors simply omit fields that downstream analysis treats as required. The cost of that mistake in cardiology is specific — a parser that treats all compliant files identically does not throw. It produces a clinically incorrect value that looks entirely right.

HeartSciences needed to ingest ECG recordings from every major device manufacturer and run them through one analysis pipeline without paying that cost. ML LABS built the vendor-neutral ingestion layer inside the cloud backend behind their AI-ECG platform: per-manufacturer parsing adapters, measurement normalization that preserves clinical precision, deduplication at the storage layer, and a shared ECG library — including a research SDK — that gives every downstream consumer one representation regardless of which device recorded the study.

What makes this build worth describing is not the architecture, which is unsurprising once stated. It is the catalogue of things that are wrong with real device output, none of which appears in any specification, and each of which was found the only way such things are found.

The Dialects Behind The Standard

The specification leaves room for exactly this. The DICOM Supplement 30 Waveform Interchange specification (NEMA) permits up to five Waveform Sequence Items per study across up to thirteen channels and deliberately accommodates vendor-specific encoding choices, which means two fully compliant files can describe the same heartbeat with different scalar units, different lead labels, and different acquisition templates. Two vendors' files carrying the same clinical recording differ in measurement encoding, waveform byte ordering, and classification conventions. Run them through the same parsing logic and the values that come out look plausible and are wrong — the kind of error that surfaces months later, when a cardiologist notices that the same patient's measurements disagree across two devices.

graph TD
    A["Raw DICOM File"] --> B["Vendor Detection"]
    B --> C["Vendor A Adapter"]
    B --> D["Vendor B Adapter"]
    B --> E["Vendor C Adapter"]
    C --> F["Unified ECG Model"]
    D --> F
    E --> F
    F --> G["Validation &<br/>Storage"]

    style A fill:#1a1a2e,stroke:#e94560,color:#fff
    style B fill:#1a1a2e,stroke:#ffd700,color:#fff
    style C fill:#1a1a2e,stroke:#0f3460,color:#fff
    style D fill:#1a1a2e,stroke:#0f3460,color:#fff
    style E fill:#1a1a2e,stroke:#0f3460,color:#fff
    style F fill:#1a1a2e,stroke:#16c79a,color:#fff
    style G fill:#1a1a2e,stroke:#16c79a,color:#fff

So each manufacturer's DICOM output is treated as a distinct dialect. A shared ECG library holds the common data structures and the normalization utilities; vendor-specific adapters absorb the divergences that matter clinically, and every incoming file is routed to the correct adapter automatically. The unified model is what the AI inference layer, the clinical display, and the research exports all read — which means adding a manufacturer changes one adapter and nothing else.

Normalization Is The Product

The adapters are the cheap part. The normalization layer is where the clinical correctness actually lives, and it solves three problems that a generic DICOM reader cannot see.

Measurement Formatting

One vendor stores an amplitude as 1.200. Another stores the same value as 1.2. In a clinical context trailing zeros can imply measurement precision, so the pipeline normalizes every measurement to a canonical format with explicit precision metadata, letting downstream consumers distinguish genuine precision from a formatting artifact. Amplitude scaling is the same problem with worse consequences: microvolts on one device, millivolts on another, and a difference of three orders of magnitude between a value that is normal and a value that is not.

Classification Mapping

Device manufacturers assign proprietary names to ECG classifications, and a firmware update can rename a standard label to a product-specific one without warning. The pipeline maps every vendor-specific label to a unified clinical meaning, so the same condition produces the same classification regardless of which device recorded it — and a vendor's relabeling becomes a mapping change rather than a redeployment.

Filter Metadata

Signal filters affect waveform morphology and measurement accuracy, and the filter state at acquisition changes how both a model and a clinician should read the trace. Each manufacturer represents filter settings differently: one packs the high-pass cutoff into a private tag as a bitmap, another exposes the same setting as a plain decimal in a sibling tag, and a third leaves the field empty because the filter was applied irreversibly before storage. The pipeline normalizes all of it into one filter record — which filters were active, their cutoff frequencies where available, and whether the state was read from metadata or inferred from device defaults — and that record travels with the waveform through inference, display, and export.

The hardest interoperability problems are not protocol-level. They are the measurement normalization differences between vendors that produce clinically incorrect values when handled generically.

Vendor Drift Signatures

Device dialects are not static. A firmware update that renames a single classification label, or moves an amplitude from millivolts to microvolts inside one private tag, breaks ingestion without tripping any standard DICOM validator — the file remains perfectly compliant, and the pipeline keeps accepting it. That is why the ingestion boundary is instrumented rather than merely tested.

The signals worth watching are concrete: parse-rejection rate per vendor and per firmware version, distribution shifts in normalized measurement values after a vendor update, and any spike in the proportion of recordings whose filter state had to be inferred from device defaults rather than read from metadata. Each is a leading indicator of drift that arrives before a clinician notices a discrepancy on a report. The regulatory frame points the same way — the FDA now expects anticipated model changes to be declared and bounded in advance (FDA, 2025) — and a device fleet whose encoding conventions can move underneath you is exactly the case that rewards declaring your assumptions and monitoring them.

Dedupe At The Storage Layer

A platform that ingests through three parallel paths — web upload, clinic file share, EHR integration — will receive the same recording twice. Without deduplication it stores two copies and shows them as two separate studies, and a clinician reviewing a patient's ECG history has to work out which is which. Downstream, the same duplicate is a second inference call and a second billable event, which is why the inference reliability layer treats a record's identity as a first-class concern rather than a storage detail.

Deduplication is done on clinically meaningful content rather than raw file bytes, so the same recording arriving through different routes resolves to a single stored record: byte-level hashing would fail here precisely because two vendors' encodings of the same signal are not byte-identical. Storage stays immutable and every access traces back to one deduplicated record, which is what the FDA's guidance on cybersecurity in medical devices (FDA, 2025) has in mind when it treats data integrity as a design input rather than an audit artifact. The same unified representation is what makes the research SDK possible at all: loading waveforms from two manufacturers and comparing them requires no format-specific handling in research code, because the normalization pipeline the clinical path uses is the one the SDK uses, with raw DICOM metadata still reachable alongside it for anyone studying format-specific artifacts.

Where Adapters Stop Helping

Vendor-neutral parsing is tractable when the format landscape is bounded — a known set of manufacturers with published conformance statements. It stops being tractable when a new implementation deviates far enough from the standard that the unified model itself has to change, and no adapter boundary can absorb that: the model, the validation ranges, and every downstream consumer move together. The honest test before committing to this architecture is whether the axis is genuinely open. If the platform will only ever ingest one manufacturer's output, the adapter layer is a tax on variability that will never arrive.

Speed through a new vendor comes from prior exposure to undocumented device behavior — trailing zeros in amplitudes, renamed classifications after firmware updates, bitmap filter fields in private tags, lead-order permutations that swap V1 and V4. That is not knowledge a specification transfers. It is the reason the first vendor takes as long as it does and the reason the second one does not.

First Steps

1. Catalog the device landscape first. Every manufacturer, model, and firmware version across sites. This is the parsing scope, and it is also the list of things that can change underneath you.
2. Build one adapter end to end. Take a single vendor's output all the way into the common model with full normalization and filter handling, and validate the result against clinician-reviewed values before adding a second vendor.
3. Test against real device output. Collect anonymized files from every supported device and firmware version. Synthetic files are generated from the specification, which means they contain exactly the quirks the specification knows about — none.

Isolate Vendor Quirks Behind Adapters

The bar for a vendor-neutral ingestion pipeline is not "it parses every file". It is that a clinician can trust the same patient's ECG to produce identical measurements regardless of which device recorded it, and that a new manufacturer lands as an adapter rather than as a migration. Every vendor-specific fact — units, labels, tag layouts, filter encodings, classification vocabularies — lives at the adapter boundary. The clinical data model, the storage layer, and every downstream consumer stay stable while the device fleet underneath them does not. If a platform cannot say where in the code a vendor's quirks are absorbed, they are not absorbed; they are distributed, and they are already in the clinical values.

A build with a defined shape and an undefined enemy is exactly what a production AI workflow engagement is for — one contained workflow taken to production against written targets, with its first 30 days of Operate included, because a device fleet's next firmware release is not going to wait for a support contract to be negotiated. Get the boundary right and vendor neutrality stops being a claim on a marketing page and becomes a property of the parsing layer, which is the only place it was ever going to be true.

References

1. NEMA. DICOM Standard. National Electrical Manufacturers Association, 2024.
2. NEMA. DICOM Supplement 30: Waveform Interchange. DICOM Standard, 2024.
3. Rorden, C., Béranger, B., Cheng, H., et al. DICOM datasets for reproducible neuroimaging research across manufacturers and software versions. Scientific Data, 2025.
4. U.S. Food and Drug Administration. Cybersecurity in Medical Devices. Regulatory Reference, 2025.
5. U.S. Food and Drug Administration. Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices. Regulatory Reference, 2025.