Hospital IT teams evaluating clinical sequencing software often encounter latency as an abstract talking point: vendors say "fast" or "real-time" without giving the specific numbers that matter for an IT architecture decision. This post is written for infrastructure engineers and clinical informatics teams who need to understand what generates latency in a sequencing workflow, how to measure it, and what network and compute architecture decisions determine whether that latency is acceptable for the clinical use case.
Defining the latency budget
A latency budget is the allocation of total acceptable time across the components of a workflow. For a clinical sequencing workflow targeting a 45-minute total time-to-result from sample receipt to result in the LIS, the budget looks roughly like this:
- Sample preparation and library prep: 10–15 minutes
- Sequencing run: 20–30 minutes
- Basecalling and analysis: 5–10 minutes (running concurrently with sequencing)
- Result formatting and LIS delivery: 1–3 minutes
This leaves effectively zero slack for any cloud upload step. Network transit, cloud queue wait, and download collectively consume at minimum 10–15 minutes under favorable hospital network conditions and can easily exceed 30–45 minutes under realistic hospital IT constraints. Cloud architecture fails the 45-minute budget reliably and by a large margin.
Network topology in a hospital environment
Understanding hospital network topology is prerequisite to designing a sequencing deployment. Most large hospital networks are segmented into clinical VLANs by department or function — radiology, pharmacy, clinical laboratory, administrative — each with different firewall rules, different QoS priorities, and different egress routing. The clinical laboratory VLAN is typically treated as a secured clinical network with controlled external egress.
The sequencing workstation will be placed on the clinical laboratory network segment. Relevant questions for IT:
- Does this VLAN have direct internet egress, or does it route through a proxy? If proxy, does the proxy perform TLS inspection of HTTPS traffic? (TLS inspection can break or delay genomics API calls that use certificate pinning.)
- What is the available uplink bandwidth from this segment, and how is it shared with other clinical applications? Peak DICOM imaging traffic from radiology can consume substantial bandwidth on shared hospital uplinks.
- Are there DLP (data loss prevention) rules that scan or buffer outbound traffic for files above a certain size? Raw FAST5/POD5 files are 1–4 GB — DLP scan latency on files this size can be significant.
- Does the facility have any air-gap or explicit outbound block policies for clinical devices? Some hospital security policies explicitly prohibit clinical workstations from making outbound connections to commercial cloud providers.
For a local-execution architecture, most of these concerns are moot for the critical analysis path. The sequencing workstation communicates only with the flow cell (USB/Ethernet local), performs all basecalling locally, and sends the result to the LIS via the internal hospital network — a fully contained clinical network transaction.
The local compute architecture: what "real-time" requires
Real-time basecalling means the basecalling pipeline processes reads at the same rate the flow cell generates them — it does not fall behind. This requires GPU compute on the sequencing workstation. The relevant specifications for IT procurement:
GPU: A mid-tier workstation GPU with 8–16 GB of VRAM is sufficient for real-time basecalling on a single flow cell at standard throughput. An NVIDIA RTX 4080 or equivalent is a reasonable current baseline. Server-class GPUs (A100, H100) provide headroom but are not required for single-flow-cell clinical deployment — they become relevant for multi-flow-cell deployments or research-scale runs.
CPU: The CPU handles data ingestion from the sequencer, preprocessing, file I/O, and result pipeline orchestration. A modern 8–12 core CPU is sufficient. CPU-only basecalling (without GPU) is technically possible but runs significantly below real-time for high-accuracy models — acceptable as a fallback for a small percentage of delayed processing, not as a primary mode.
RAM: The basecalling model and concurrent pore-channel state must be held in memory during a run. 32 GB system RAM is a comfortable minimum; 64 GB provides headroom for concurrent LIS result delivery and OS overhead without memory pressure.
Storage: Raw sequence files (FAST5/POD5) for a clinical run are 1–4 GB. Retention requirements under CLIA suggest keeping raw files for the laboratory's defined retention period (at minimum the duration of the test record). For a clinical lab running multiple samples per day, local storage requirements scale quickly. A minimum of 2 TB NVMe SSD for hot storage, with a planned archive solution (NAS, SFTP to LIS server, or offline archive medium) is appropriate for most clinical deployments.
LIS connectivity: inbound result delivery latency
Result delivery to the LIS introduces its own latency component. The sequencing analysis pipeline formats the result as an HL7 v2 ORU message and transmits it to the interface engine or LIS listener. This transaction happens over the internal hospital network — typically on a standard Ethernet connection between the sequencing workstation and the LIS server or interface engine.
In most hospital IT environments, this inbound result delivery should complete in seconds, not minutes, as long as:
- The interface engine or LIS listener is running and accepting connections at the time of transmission
- The HL7 message validates correctly against the LIS's configured schema
- The result can be matched to an existing order in the LIS (order-result linkage)
Failure in any of these three conditions causes the result to queue or fail silently. The sequencing workstation should implement HL7 acknowledgment tracking (MLLP ACK/NAK handling) and alert on delivery failures. A result that is generated but not delivered is indistinguishable from no result from the physician's perspective — delivery failure handling is a clinical safety requirement, not an edge case.
A realistic latency comparison: local versus cloud
For a hospital clinical laboratory planning a sequencing deployment, the following is a realistic latency comparison under typical hospital network conditions:
| Latency component | Local execution | Cloud execution |
|---|---|---|
| Data staging / batching | 0 min (streaming) | 5–15 min |
| Network upload (1–4 GB) | 0 min | 3–10 min |
| Cloud queue wait | 0 min | 2–20 min |
| Basecalling processing | Concurrent with run | 2–5 min post-upload |
| Results download + parsing | 0 min | 2–5 min |
| LIS delivery | <1 min | <1 min |
| Total post-run latency | <5 min | 14–56 min |
Post-run latency is the time between run completion and LIS result availability. For a 30-minute sequencing run targeting 45-minute total time-to-result, post-run latency of 14–56 minutes makes the 45-minute target statistically unreliable in the cloud architecture. Local execution consistently meets the budget.
Operational monitoring and alerting
IT teams deploying sequencing workstations should plan for operational monitoring appropriate to clinical device infrastructure. Minimum monitoring requirements: disk space utilization alerts (storage fills predictably as runs accumulate); GPU utilization and basecalling throughput monitoring (falling below real-time indicates a hardware or configuration issue); LIS delivery success/failure logging with alerting on delivery failures; and software version tracking with change management integration.
We're not saying cloud architecture cannot work for any sequencing use case — for research, for non-urgent genomics applications, or for batch analysis of stored specimens, cloud processing is entirely appropriate. We're saying that for the specific use case of real-time clinical pathogen identification with a time-sensitive result, the latency budget leaves no room for cloud transit and queue variability, and local-first architecture is the only design that reliably meets the clinical requirement. This is an IT architecture decision with patient care consequences, not a vendor preference.