Three Ways An ECG Reaches The Cloud

A capture device in a clinic exam room writes an ECG to a network file share in chunks. A watcher polling that share sees the file appear and enqueues it on the spot. The file opens cleanly, parses partially, and then fails inference deep in the pipeline with an error message that names none of that — because the device was still writing when the watcher fired. SMB has no notion of "done", so nothing in the protocol will ever tell you this is what happened.

That failure mode is one of the reasons the ingestion layer, not the model, is where a clinical AI platform is won or lost. HeartSciences needed ECG recordings to travel from clinic exam rooms into a cloud AI system through three different paths at once — clinician web uploads, SMB file shares on clinic networks, and EHR integration triggers — and to arrive as the same thing on the other side. ML LABS built the device-to-cloud pipeline that unified all three onto a single processing queue, enforced per-organization data isolation at the storage layer, and replaced manual operational scripts with event-driven scheduling, deployed across test, US production, and UK production environments. It is one layer of the cloud backend behind HeartSciences' AI-ECG platform, and the constraints it operates under are not the ones a standard data pipeline faces.

Clinic networks expose SMB file shares as the only programmatic interface. Devices write files with no notification mechanism. Network interruptions produce partial uploads that look like complete ones. The same recording can arrive through more than one path. And a single configuration error that routed one organization's clinical data into another's storage would be a compliance violation and a contractual breach in the same instant — which is why the HIPAA Security Rule implementation guidance (NIST, 2024) frames access control and audit as standards to be evaluated against the specific ePHI flows of the entity, not as boxes to tick once.

When a single misconfiguration can leak clinical data across organizations, the ingestion pipeline is the compliance boundary, not just a data pipe.

Each path existed because it mapped to a clinical workflow the platform could not ask clinics to abandon. Web uploads served sites operating outside an EHR-driven workflow that needed a direct route to submit recordings for AI interpretation. SMB shares existed because the capture devices write files to a clinic-side share with no API. EHR integration existed because larger sites want recordings to flow through their own order-management workflow so results return to the patient record the order came from. Consolidating onto one path would have forced every clinic to change how it works — a non-starter for a platform whose adoption depends on minimal disruption to clinic operations. The architectural problem was never eliminating paths. It was making them indistinguishable downstream.

One Queue, One Message Shape

Web uploads and EHR integrations already ran through separate code paths before the SMB work began. Adding SMB as a third parallel system would have tripled the surface area for processing bugs, produced three inconsistent audit trails, and made cross-path deduplication intractable — the bugs of that shape only appear when the same recording arrives twice by different routes, which is exactly the case nobody tests.

graph TD
    A["Web Upload"] --> D["Unified Ingress<br/>Queue"]
    B["SMB File Share"] --> D
    C["EHR Integration"] --> D
    D --> E["Serverless<br/>Processing"]
    E --> F["AI Model<br/>Inference"]
    F --> G["Clinical Results"]

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

Every path now produces an identical message on a single processing queue, and the downstream processor handles a recording the same way regardless of where it came from. Every file entering the system gets a log entry carrying its ingestion source, timestamp, and processing outcome. That uniformity is what makes deduplication a property of the queue rather than a per-path reconciliation strategy: a clinician records an ECG, the device writes it to the clinic share, the watcher enqueues it, and the same clinician then uploads a local copy through the web interface. Both messages reach the queue with identical content hashes scoped to the same organization, the second is dropped before storage, and the audit log retains both ingestion events with the second marked as a deduplication match. Three independent pipelines would have written the recording twice, produced two AI results, and handed a clinician a conflict with no way to decide which result was canonical.

Failure Modes SMB Hides

The chunked-write problem has a mechanical answer: read file size at two successive polls, confirm stability across a defined quiet period, and only then enqueue. Skip that check and retries cascade while the queue fills with malformed records that each fail somewhere different. It is a small piece of code and it is the difference between a pipeline that runs unattended and one that pages someone.

Silent loss is the harder one. A device writes a file, overwrites it on a retry, and moves on; a watcher that crashed in between sees only the final state and has no way to know a recording ever existed. The pipeline records every file event with its source path, observed size, and hash at ingestion, then reconciles that log against device-side inventory on a schedule. A recording present on the device and absent from the log raises an alert — not a discovery weeks later when a clinician asks why a result never came back. Treating absence as a signal, rather than as the default state of the world, is what separates an ingestion layer you can leave alone from one that depends on a person noticing.

The reconciliation job is also the piece that makes an ingestion failure diagnosable at all. In a clinical system a silent failure is a patient-safety event rather than a logging inconvenience, which is why the FDA's guidance on cybersecurity in medical devices (FDA, 2025) treats these properties as design inputs rather than as a release checklist, and why the guiding principles for good machine learning practice in medical devices (FDA, 2021) put data management in the same category. The ingestion layer got alarms instead of a dashboard for the same reason.

Isolation At Provisioning Time

Storage, credentials, and processing configuration are scoped per organization at the infrastructure layer, and onboarding a new organization is an automated provisioning step rather than a manual checklist. That is the design decision that removes the class of configuration errors that produce isolation gaps: an isolation boundary that depends on someone completing a runbook correctly is not an isolation boundary, it is an intention. The downside risk is not abstract — the cost of a healthcare data breach (HIPAA Journal, 2024) still runs to eight figures per incident. The same discipline shows up one layer down in the clinic-side security pipeline, where the clinic network is the part of the system ML LABS does not control.

A systematic scoping review of FHIR-based implementations (JMIR Medical Informatics, 2024) catalogs scalability gaps at tenant onboarding as one of five recurring failure categories in health-data integration, alongside manual ETL with information loss and hard-coded mappings that drift. Provisioning is where a platform decides which side of that finding it will be on. Environment-specific configuration carries the regional differences across test, US production, and UK production, so data residency separation is a property of the infrastructure rather than a convention the deploy script is trusted to respect — and backups, sync monitoring, and deployments run on schedules that no person has to remember to start, with failures routed to alarms rather than to nobody.

Where This Architecture Stops

This architecture is tractable when the device population is bounded and the format landscape is known. It gets categorically harder when device types multiply across sites with different firmware behavior, or when regulatory requirements span jurisdictions with incompatible data-residency rules — each new jurisdiction is a second copy of the infrastructure story, not a config flag. The vendor-format side of that problem is a build of its own, and the multi-vendor ingestion pipeline is where it lives.

The harder gap is not architectural at all. It is the distance between "we have a working pipeline" and "the pipeline runs unattended". The unattended bar requires that every routine operation — backup, sync verification, error recovery — runs without a person remembering to start it, and that every non-routine condition produces an actionable alert instead of a silence that reads exactly like success. A team that can build the first cannot necessarily staff the second, and the second is what a clinical deployment actually requires.

First Steps

1. Unify the ingress queue before adding the third path. Converge every ingestion route onto one queue with one canonical message shape. Path-specific processing branches are where the untested combinations fail.
2. Make org provisioning a script, not a checklist. Storage, credentials, and configuration for a new organization should be one automated step. One missed manual step is an isolation gap.
3. Reconcile against the source of truth. Compare an inventory of what the devices hold against what the pipeline logged. A recording that exists in one and not the other is the alert you most need and are least likely to have.

Unify Before Adding A Path

Build the device-to-cloud pipeline so that every ingestion path produces an identical message on a single queue, with per-organization storage isolation enforced at provisioning time and event-driven automation in place of operational scripts. Ingress unification removes the path-specific branches that diverge and fail in combinations nobody tested; automated provisioning removes the human configuration error that produces isolation gaps; and reconciliation against device-side inventory turns silent loss into an alert. None of the three is expensive to build first. All three are expensive to retrofit into a live clinical system, because a retrofit in a regulated deployment is a change-control event rather than a routine deploy.

When one contained workflow like this needs to become production software — an ingestion path that runs unattended, in a regulated environment, with the isolation boundary verifiable per organization — that is a production AI workflow build, and it includes its first 30 days of Operate — run by the person who built it, because ownership of a live clinical ingestion path is not a job separable from having designed one. Get the queue, the provisioning, and the reconciliation right, and the exam-room device becomes a boring part of the system — which, for the clinician waiting on a result, is precisely the point.

References

1. Marron, J. Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide. NIST Special Publication 800-66 Revision 2, 2024.
2. U.S. Food and Drug Administration. Cybersecurity in Medical Devices. Regulatory Reference, 2025.
3. Tabari, P., Costagliola, G., De Rosa, M., Boeker, M. State-of-the-Art FHIR-Based Data Model and Structure Implementations: Systematic Scoping Review. JMIR Medical Informatics, 2024.
4. U.S. Food and Drug Administration, Health Canada, and MHRA. Good Machine Learning Practice for Medical Device Development: Guiding Principles. Regulatory Reference, 2021.
5. HIPAA Journal. Cost of a Healthcare Data Breach Falls to $9.77M in 2024. HIPAA Journal, 2024.