For clinical laboratories

Establishing performance specifications? Analytical specificity is on the list.

For any test you developed in-house — or any FDA-cleared assay you modified — CLIA requires you to establish performance specifications before reporting patient results. Analytical specificity, including interfering substances, is one of them. BLASTseq AI produces that evidence and documents it.

The modification trap

Introducing an FDA-cleared assay unmodified means verifying the manufacturer's specifications — a short list. Developing your own, or modifying a cleared one, means establishing specifications under 42 CFR 493.1253(b)(2), and that list explicitly includes analytical specificity to include interfering substances.

Different specimen type. Different extraction. Different platform. Adjusted cutoff. Each one moves you from verification to establishment, and most labs discover this during inspection prep rather than during validation.

What analytical specificity actually requires for a molecular assay

Demonstrating your assay detects the diversity of what it claims to detect, and doesn't detect what it shouldn't. For a sequence-based assay that means primer and probe coverage across target variation, and discrimination against near neighbors, related species, background flora, or paralogous sequence.

Wet-lab coverage of that space is limited by what you can obtain. Isolates for every clade, every resistance genotype, every near neighbor are not sitting in your freezer — and neither are characterized samples for every population variant your germline assay has to amplify through. In silico analysis against current public sequence data is how the gap gets addressed, and FDA has itself accepted in silico testing as an alternative for inclusivity where strains are difficult to study.

The documentation is the deliverable

CLIA requires the laboratory to document all activities specified in the performance specification standard. Your accreditor will ask to see it. BLASTseq AI generates the analysis and the record in the same run: query sequences, reference-database release, search date, scoring rationale, and the resulting inclusivity and exclusivity calls. Export it to your validation packet and it stays reproducible when someone asks about it two inspection cycles later.

Re-verification without the two-week cycle

Sequence databases grow and recommended variant sets change. The analysis that supported your original validation reflects the data available then. Re-running it should be a scheduled task, not a project.