Genomics

How a public health LIMS interfaces with bioinformatics pipelines

Why running sequence assembly inside a LIMS fails, and how clean JSON metric ingestion preserves CLIA lineage and CDC reporting.

JIL Sovereign Technologies, Inc.6 min read All articles

Instruments, assemblers, and LIMS: Understanding operational boundaries

State public health laboratories frequently face confusion during genomics procurements when vendor marketing blurs the line between physical instruments, bioinformatic algorithms, and the laboratory information system.

An instrument such as an Illumina MiSeq, NextSeq, or Oxford Nanopore sequencer is physical benchtop hardware. It fragments nucleic acid chemically and generates millions of short, raw sequence reads stored in text files (FASTQ).

A bioinformatic assembler (such as SPAdes, Unicycler, or Flye) is pure computer software. It executes complex graph mathematics on high-performance compute clusters to solve a digital jigsaw puzzle: piecing millions of short reads back together into reconstructed chromosomes and consensus genomes (FASTA).

A LIMS (such as Salus Agentic) is the regulatory software of record. It manages patient and isolate identity, CLIA chain of custody, specimen accessioning, Westgard quality control gating, LOINC and SNOMED CT pathogen coding, and multi-destination electronic reporting to state epidemiologists and the CDC.

The monolithic trap: Why in-LIMS bioinformatic assembly fails

Legacy LIMS vendors routinely attempt to sell all-in-one genomics modules that promise to run raw read alignment and genome assembly directly inside the LIMS database.

This approach breaks down during state laboratory implementation. Graph assembly algorithms require heavy CPU and memory resources that degrade database responsiveness. Furthermore, bioinformatic algorithms evolve rapidly; when a state laboratory needs to update its pipeline for a new pathogen variant or CDC PulseNet protocol, monolithic LIMS require expensive, six-month custom software change orders.

Bioinformaticians end up abandoning the vendor's clunky in-LIMS tools and running open-source pipelines on side laptops or Linux workstations, leaving genomic findings disconnected from the primary patient accession.

The Salus Agentic architecture: The metric ingest API

Salus Agentic respects the expertise of public health bioinformaticians by maintaining a strict separation of concerns through an open ingest interface.

The laboratory runs its validated bioinformatic pipelines (Nextflow, Snakemake, nf-core, or Terra) on its preferred Linux high-performance computing (HPC) environment or cloud infrastructure.

Once the pipeline completes read quality trimming, de novo assembly, variant calling, and lineage prediction, it posts a compact, structured JSON summary back to Salus Agentic via our secure Ingest API.

The payload transmits essential quality control and clinical markers: mean read depth, Q30 percentage score, N50 contig length, identified pathogen species, predicted serotype, genotypic antimicrobial resistance (AMR) markers, and lineage designations.

From metric ingest to public health action

Upon receiving the JSON run summary, Salus Agentic binds the genomic metrics directly to the accession record, ensuring CLIA-compliant traceability from specimen collection to final sequence.

Conrad evaluates the run metrics against pre-configured Westgard and CDC quality control rules. If coverage depth or Q30 falls below validation thresholds, the specimen is flagged for supervisor review before release.

When the laboratory director authorizes release, Salus Agentic automatically codes the findings using standard LOINC and SNOMED CT terms and generates compliant electronic feeds: CDC PulseNet, CaliciNet, ARLN, electronic laboratory reporting (ELR HL7 v2.5.1 / FHIR), and CDC NNDSS case notifications.

See it in your laboratory's context.

Explore the live demo, no login and no request form.