When a CLIA-certified laboratory uses sequencing software to generate results that inform patient care, that software — combined with the laboratory's specimen processing and reporting workflow — constitutes a laboratory-developed test. The LDT framework means that the laboratory, not the software vendor, is responsible for demonstrating that the test performs as intended. This is a regulatory posture many laboratories are unfamiliar with when they first evaluate sequencing software, and it has concrete implications for how the software must be architected to support that laboratory's compliance responsibilities.
What CLIA requires and what the LDT framework means
The Clinical Laboratory Improvement Amendments (CLIA) of 1988 establish federal standards for clinical laboratory testing. Under 42 CFR Part 493, laboratories certified for high-complexity testing must establish and document performance specifications for tests they develop. For a sequencing-based pathogen identification test, these performance specifications include: analytical sensitivity (minimum detectable input), analytical specificity (absence of cross-reactivity with non-target organisms), precision (repeatability across replicates and days), and reportable range (the range of inputs over which the test produces a valid result).
The laboratory-developed test framework — distinct from FDA-cleared or FDA-approved in vitro diagnostics (IVDs) — allows CLIA laboratories to develop and validate their own tests without FDA premarket review, provided those tests are used only in that laboratory's own testing services for patients. The FDA has historically exercised enforcement discretion over LDTs, though regulatory discussion in this space evolves. As of the current regulatory environment, a CLIA laboratory deploying sequencing software for clinical pathogen identification is operating in LDT space, not IVD space.
This distinction matters practically: the laboratory cannot rely on the software vendor's claims alone. The laboratory must independently validate the system as implemented in their specific workflow, with their specific specimen types, on their specific hardware configuration.
What "LDT-compatible architecture" means for software design
An LDT-compatible software architecture is one designed to enable — not obstruct — the laboratory's validation obligations. Several specific properties follow from this:
Version determinism
The laboratory's validation is performed on a specific version of the software, with specific versions of the basecalling model, pathogen database, and AMR gene reference library. Any update to any of these components potentially invalidates the prior validation. LDT-compatible software must therefore: clearly version all analytical components separately (not just the software release version), make version information retrievable in run logs, and allow the laboratory to pin to a validated version while evaluating updates separately before deploying them clinically.
A software architecture that silently updates pathogen databases or model weights in the background — acceptable for a cloud research tool — is incompatible with CLIA validation documentation requirements.
Audit trail and run reproducibility
CLIA requires documentation of quality control activities and the ability to review and reconstruct analytical results. For a sequencing software system, this means: complete run logs with input file hashes, software versions, processing parameters, and result outputs; QC metrics for each run (read count, mean quality, coverage metrics) retained in a retrievable format; and the ability to re-analyze stored reads with the same software version to verify result reproducibility.
This last requirement — re-analysis for verification — has a specific implication: the raw sequence data (FAST5 or POD5 files) must be retained for the laboratory's defined retention period, and the software must support re-processing of stored files rather than treating each run as a one-time ephemeral analysis.
Result traceability
Every result delivered to the LIS must be traceable to a specific run, specific input files, and specific software version. When a result is questioned or a physician requests clarification, the laboratory must be able to pull the complete analytical record. This requires the software to generate and store machine-readable run reports that link the result to all upstream analytical artifacts.
What the laboratory is responsible for that software cannot provide
It's worth being specific about where the software vendor's responsibility ends and the laboratory's begins. The software vendor can provide:
- Internal performance characterization data (error rates, detection limits, tested organism panel) generated under controlled conditions
- Analytical validation protocol templates designed for CLIA compliance
- Reference datasets of characterized clinical isolates for use in the laboratory's own validation studies
- Technical documentation of the basecalling model, alignment methodology, and result confidence scoring algorithm
The software vendor cannot provide: validation data specific to the laboratory's specimen types, collection protocols, extraction methods, flow cell lot-to-lot variation, and local clinical case mix. Only the laboratory can generate that data, and only the laboratory can sign the validation study report that CLIA requires.
We're not saying vendors have no responsibility — we're saying there is a clear boundary, and laboratories that expect a vendor to hand them a turnkey CLIA-validated system are misunderstanding the regulatory framework. The LDT framework places validation responsibility with the laboratory precisely because laboratory-specific conditions are what matter for patient care.
CAP accreditation and molecular pathology checklist requirements
Laboratories accredited by the College of American Pathologists (CAP) face additional requirements through the Molecular Pathology checklist. Relevant checklist items for a nanopore sequencing deployment include requirements around: bioinformatics pipeline validation and documentation, reference database currency and version tracking, result interpretation criteria, and variant/resistance interpretation criteria for reportable findings.
CAP inspectors evaluating a high-throughput sequencing pipeline expect to see documented validation of the complete analytical process — from nucleic acid extraction through final result interpretation. A laboratory deploying nanopore-based metagenomics for clinical use should review the most current CAP Molecular Pathology and NGS-specific checklists before designing their validation study, to ensure the validation scope covers all required performance characteristics.
A practical validation approach for a sequencing LDT
A representative validation approach for a nanopore metagenomic pathogen identification LDT at a hospital microbiology laboratory might involve: a characterized panel of clinical isolates (or spiked specimens) covering the primary intended-use pathogens; comparison of sequencing identification results against culture-based gold standard; determination of minimum input DNA required for identification at the target confidence level; repeatability testing (same specimen, multiple runs, same day); reproducibility testing (same specimen, multiple runs, different days and operators); and cross-reactivity assessment against organisms likely to be present in relevant specimen types as background flora.
This is standard analytical validation methodology — not unique to sequencing. What is unique to sequencing is the complexity of documenting and version-controlling the analytical pipeline components. That documentation burden is where LDT-compatible software architecture makes the biggest practical difference for the laboratory's compliance team.