Tutorials May 17, 2026

Why synthetic data matters in public-health bioinformatics

Why public repositories for surveillance workflows should include safe synthetic inputs, expected outputs, and smoke tests when restricted data cannot be shared.

Synthetic data Reproducibility Training

Restricted data should not make methods invisible

Public-health laboratories often work with clinical, environmental, or operational datasets that cannot be shared openly. That restriction is real, but it should not make the workflow unreviewable. Synthetic data gives a repository a public test path without exposing restricted surveillance material.

A good synthetic dataset does not need to recreate every biological detail. It needs to exercise the logic: input naming, configuration, read parsing, mapping or assembly steps, QC summaries, report generation, and expected failure modes.

Synthetic, simulated, and de-identified data are different

A synthetic dataset is generated rather than collected from a person or surveillance site. A simulated dataset usually follows an explicit model, such as reads generated from a known reference with controlled error and coverage. De-identified operational data remain real data and may still carry governance restrictions or re-identification risk.

A repository should name which type it contains, document how it was produced, and avoid presenting synthetic performance as evidence of field or clinical validity. The value of synthetic data is controlled ground truth and safe execution, not automatic biological realism.

What synthetic data should prove

The repository can be cloned and checked without private FASTQ files.
The workflow discovers the intended sample names and input paths.
Helper scripts parse realistic file formats and write expected outputs.
Documentation matches the commands a new user can actually run.
Tests catch broken imports, malformed configs, and missing resources early.

Build a minimum test matrix

One happy-path sample is not enough. I would include a small matrix that tests the normal workflow and the failures most likely to confuse a new analyst. Each case should have a declared expected outcome so that the test checks scientific outputs as well as process completion.

A positive example with known mapping, coverage, and consensus expectations.
A zero-target or negative example that must not produce a confident call.
Low-depth and partial-coverage examples that exercise masking and limited-use reporting.
Malformed sample sheets, duplicate identifiers, or missing FASTQ mates that should fail clearly.
A versioned manifest containing generation parameters, random seed where relevant, and file checksums.

Connect test data to continuous integration

A small dataset becomes much more useful when every code change runs it automatically. The test should confirm that required outputs exist and that key values fall within declared ranges. Checks can include mapped-read counts, breadth at the masking threshold, consensus length, expected ambiguous positions, and report generation.

My Viral Genomics Nextflow Demo follows this pattern with a tiny synthetic FASTQ dataset, modular workflow steps, expected QC and consensus outputs, and a smoke test that runs in continuous integration. This makes the repository executable evidence rather than a collection of untested scripts.

Know what synthetic data cannot prove

Synthetic inputs cannot establish diagnostic sensitivity, robustness to extraction variation, resistance to contamination, or performance across real sample quality. Those questions require characterized reference material, operational specimens, independent replicates, and comparison with accepted methods.

Synthetic data are still valuable for training. A new analyst can learn the expected file structure, run the workflow safely, inspect normal and failed outputs, and understand the reporting logic before receiving access to restricted data.