Work Instruction: Bioinformatics Pipeline Version Lock and Reprocessing Control for Sequencing-Based Results

This is a ready-to-use work instruction for the step that sits between raw sequencing reads and a reportable result: locking the pipeline, its parameters, and its reference database version before the result is generated, and knowing exactly what to do when a result shifts between two runs on comparable material. Next-generation sequencing (NGS) results for off-target editing frequency, vector integration site profiling, and sequence-level identity are only as trustworthy as the software chain that produced them, and that chain changes quietly if nobody controls it. Replace every <<FILL: ...>> placeholder, set your document numbers, and route it through document control. A filled specimen follows. Verify each cited regulation against the current source. This is general guidance to adapt, not legal or regulatory advice.

Document control header

Purpose and scope

This work instruction defines the step-by-step control a bioinformatics analyst applies before a sequencing-based result (variant call, off-target editing frequency, integration site call, sequence identity confirmation) supports a release, comparability, or safety decision. It applies in addition to, not instead of, the general custom software validation procedure governing the pipeline itself.

1. Before generating a GxP result

2. Running and reviewing the analysis

3. When a result differs from a prior run on comparable material

Use this path whenever a sequencing-based result looks different from what a prior run reported for what is meant to be the same or comparable material.

1. Confirm whether the sample or the underlying process genuinely changed (different lot, different edit, different manufacturing step). If yes, treat the difference as a biological or process finding and investigate it on its own merits; stop here.
2. If the sample is comparable, confirm whether the pipeline version, any parameter, or the reference database version changed between the two runs.
3. If yes, re-run the earlier sample’s raw data through the current locked pipeline and reference to confirm whether that reproduces the shift. Document the comparison. Route the pipeline or reference change through change control, with an impact assessment covering every previously reported result that used the prior version, before the new version supports another GxP result.
4. If the pipeline, parameters, and reference are confirmed unchanged and the sample is confirmed unchanged, but the result still differs, treat this as a reproducibility failure. Stop using the pipeline for GxP results and escalate to the pipeline owner and Quality Assurance the same working day.

4. Reference database updates

1. Treat every reference database update (a new genome build, a refreshed annotation set, an updated off-target prediction list) as a controlled change, evaluated through <<FILL: SOP-ID for change control>>, not applied automatically or silently.
2. Before adopting an updated reference for GxP use, re-run a defined set of previously reported, representative samples through the new reference and document whether and how results shift.
3. Record which reference version was in effect for every previously reported result, so a later question about a specific result can be answered without ambiguity.

Records generated

References

21 CFR 211.194 (laboratory records); 21 CFR 211.192 (investigation of discrepancies). 21 CFR Part 11 (audit trail, electronic records) as applied to computerized analysis systems. GAMP 5 category 5 thinking for custom/configured software, applied to a bioinformatics pipeline (reference the current GAMP guide by number and edition; do not reproduce its text). FDA draft guidance, Leveraging Prior Knowledge in the Development of Human Gene Therapy Products Incorporating Genome Editing (draft, 2 Jun 2026), for the traceability expectation on data supporting a genome-editing program.

Confirm each reference against the current source before issue.

Filled specimen

The following shows the record completed for an example off-target editing frequency analysis, including a triggered result-shift investigation. Values are illustrative; replace them with your own.

In this example the pipeline did exactly what it is supposed to do when a result shifts: it forced the question “sample or software” to be asked and answered with data, rather than left as an unresolved discrepancy between two reports.

Common inspection findings this work instruction prevents

• A sequencing-based result reported with no record of which pipeline version or reference database produced it.
• A reference database update applied with no change record, discovered only when a result unexpectedly shifts.
• A result re-run with different parameters until it “looked right,” with no audit trail of the earlier attempts.
• No second-person review of a bioinformatics result before it supports a release or safety decision.
• An inability to state, for a specific previously reported result, which software and reference version were in effect at the time.

How to adapt this work instruction

1. Point the parent SOP reference to your actual custom software validation and result invalidation procedures.
2. List your specific pipelines and analysis types in the header scope line.
3. Set your own QC thresholds (coverage, mapping quality) from your method’s validated performance.
4. Define your own change control trigger for a reference database update, including how many representative samples get re-run before adoption.
5. Confirm every regulation and guidance reference against the current published version before issue.