The cloud was a reasonable choice for research genomics. Large compute bursts, infrequent access, no real-time requirement — cloud fits all of it. Clinical point-of-care sequencing has none of those properties. It runs continuously, has hard latency constraints, sits inside hospital network architecture, and handles genomic data that is either PHI or directly tied to PHI. The engineering tradeoffs that make cloud pipelines sensible for research make them problematic for clinical deployment.
The latency chain no one draws in the whitepaper
Cloud basecalling advocates often cite GPU throughput numbers — the compute is fast, they argue, so the cloud adds minimal latency. This is true if you measure only the cloud processing step. It is false if you measure the full latency chain from flow cell data generation to pathogen call delivered to the physician.
A realistic latency breakdown for a cloud-based clinical sequencing pipeline looks like this:
- Data staging: Raw POD5 or FAST5 files must accumulate to a batch size before upload is triggered. Typical batch windows: 5–15 minutes.
- Upload: A 30-minute MinION run at 400 bases/second on a 512-pore flow cell generates roughly 1–4 GB of raw signal data. At 50 Mbps sustained hospital uplink (optimistic for a facility sharing bandwidth across many services), this is 3–10 minutes of transfer time per batch.
- Queue time: Cloud processing jobs enter a queue. During business hours or shared-compute periods, queue wait can range from seconds to 20+ minutes depending on the provider's capacity allocation.
- Processing: 2–5 minutes for actual basecalling on cloud GPU.
- Download and parsing: FASTQ results return, pipeline runs alignment and identification, result formatted for LIS output: 3–8 minutes.
Adding conservatively: 5 + 5 + 5 + 3 + 5 = 23 minutes of latency, on top of the sequencing run time itself. Adding aggressively: 15 + 10 + 20 + 5 + 8 = 58 minutes. For a pathogen identification workflow targeting a 45-minute total time-to-result, cloud architecture simply doesn't fit into the budget without radical assumptions about network conditions and zero queue wait.
Hospital network architecture is not a cloud-first environment
Research institutions often have dedicated high-bandwidth connections — a genomics core on university fiber can reliably push large data to cloud without contention. Hospital networks are architecturally different. They are designed for clinical applications, EHR traffic, DICOM imaging, and administrative systems — not for continuous genomics data upload.
Typical constraints seen in hospital network environments include: VLAN segmentation that puts laboratory devices on restricted subnets with limited external routing; proxy inspection and DLP (data loss prevention) systems that scan or buffer outbound traffic; egress bandwidth caps imposed by IT policy; and, in some facilities, air-gapped configurations for clinical systems that explicitly block cloud connectivity.
Even where network connectivity is available, upload reliability matters differently for clinical systems than for research ones. A dropped upload during a research run means you re-run tomorrow. A dropped upload mid-clinical-run means the result doesn't arrive in time for the clinical decision, and the failure mode is not just an inconvenience — it's a gap in the care workflow.
We're not saying cloud infrastructure is poorly engineered — we're saying hospital IT environments were designed for a different threat model and traffic profile than genomics data pipelines require.
PHI attachment: the data governance problem
Nanopore sequencing in a clinical context produces data that is, or is proximately linked to, protected health information under HIPAA. A sequence read from a patient specimen is not de-identified; in many cases it is trivially re-identifiable by matching to a clinical record.
Uploading this data to a cloud processing endpoint introduces HIPAA compliance obligations that many hospital procurement and compliance teams are not equipped to evaluate quickly. A Business Associate Agreement (BAA) is required with any cloud provider that processes PHI. The BAA must be reviewed by legal, countersigned, and integrated into the hospital's compliance documentation. This process can take weeks to months in a large institution.
Local processing bypasses this overhead entirely. The genomic data stays on the hospital network — or more specifically, on the sequencing workstation inside the lab — and never transits to an external system. The compliance posture for on-premises processing is substantially simpler to evaluate and document under HIPAA technical safeguards (45 CFR §164.312).
Compute architecture: what "local" actually requires
The objection to local basecalling has historically been compute — neural network inference for nanopore basecalling is genuinely GPU-intensive. The HAC and SUP models in standard pipelines were designed for high-end workstation GPUs that clinical labs don't typically stock.
This is a real constraint, not a marketing objection. A clinical lab equipped with a MinION or Mk1C needs to pair it with a workstation capable of real-time basecalling, and that workstation must meet the lab's validation requirements, not just the software's minimum spec. The compute hardware decision is as much part of the LDT validation package as the reagents and software version.
The engineering answer is to design basecalling models and inference pathways that run acceptably on mid-tier GPU hardware — something in the NVIDIA RTX 4000 class rather than requiring an A100. This requires both model architecture choices (smaller model footprint, quantized inference) and careful pipeline design (streaming chunk processing rather than batch-accumulate-process patterns). It is achievable, but it requires designing for the clinical compute environment explicitly rather than assuming research infrastructure.
Hybrid architectures: where cloud still makes sense
A local-first architecture doesn't mean cloud has no role. There are specific functions where cloud integration adds genuine value without introducing latency or compliance problems in the critical path:
- Non-urgent reference database updates: Pathogen libraries and AMR gene databases can be updated via scheduled off-hours cloud sync without affecting real-time processing.
- Aggregate reporting: De-identified run statistics, QC metrics, and epidemiological aggregates can be pushed to cloud dashboards for hospital infection control teams.
- Software updates: Model updates and pipeline versions can be delivered through a managed update channel.
- Offline backup: Completed analysis archives can be pushed to secure cloud storage as a secondary backup after the clinical result is delivered.
The design principle is: cloud is available for non-latency-critical functions, but the critical path — from raw read to pathogen identification — runs locally and completes without any cloud dependency. This architecture is more complex to build but it is the only one that reliably meets clinical operational requirements.
The practical engineering question
When evaluating sequencing software for clinical deployment, the relevant question is not "does this pipeline support cloud processing?" — most do. The question is: "Can this pipeline produce a reportable result if the hospital's internet connection is down, congested, or blocked by IT policy at the time the run completes?"
A pipeline designed for local execution answers yes without reservation. A cloud-dependent pipeline answers "no, or not reliably." In a clinical environment where the result is time-sensitive and the network is not guaranteed, that distinction has direct patient care consequences.
Designing for local execution first, with cloud as an optional complement, is not a product limitation — it is the architecturally correct choice for clinical point-of-care settings.