<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en_GB"><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://babasaraki.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://babasaraki.github.io/" rel="alternate" type="text/html" hreflang="en_GB" /><updated>2026-10-25T17:05:25+01:00</updated><id>https://babasaraki.github.io/feed.xml</id><title type="html">Umar Ahmad</title><subtitle>Umar Ahmad, PhD — genomic scientist working on cancer genomics, pathogen genomic surveillance and bioinformatics capacity building across West Africa.</subtitle><entry><title type="html">Cost per reportable genome</title><link href="https://babasaraki.github.io/blog/2026/10/cost-per-reportable-genome/" rel="alternate" type="text/html" title="Cost per reportable genome" /><published>2026-10-25T00:00:00+01:00</published><updated>2026-10-25T00:00:00+01:00</updated><id>https://babasaraki.github.io/blog/2026/10/cost-per-reportable-genome</id><content type="html" xml:base="https://babasaraki.github.io/blog/2026/10/cost-per-reportable-genome/"><![CDATA[<p>The question I am asked most often by laboratories planning to start sequencing
is which instrument they should buy. It is the wrong question, and answering it
directly does people a disservice.</p>

<p>I spent some time this year preparing a technical briefing for the Pathogen
Genomics Initiative team, built around the 2025 edition of the Front Line
Genomics <em>Sequencing Buyer’s Guide</em> — a market snapshot covering extraction,
library preparation, short- and long-read platforms, and outsourcing. It is a
useful catalogue. It is also, as its own foreword states, sponsored by two
companies that sell into the market it surveys. That is not a reason to discard
it, but it is a reason to treat its comparison tables as a starting inventory
rather than as an evaluation.</p>

<p>Working through roughly forty platforms, the thing that struck me is how little
of the purchasing decision the specifications actually determine.</p>

<h2 id="the-number-that-matters-is-downstream-of-the-instrument">The number that matters is downstream of the instrument</h2>

<p>Vendors compete on output per run, read length and quality score. Q30 means an
estimated one error per thousand bases; Q40, one per ten thousand. These are
estimated per-base error probabilities. They are not the accuracy of a finished
genome, and they are certainly not the reliability of a public health
interpretation. Coverage depth cannot recover a region the assay never
amplified, and it does not correct a systematic error.</p>

<p>What a surveillance programme actually consumes is <strong>reportable genomes</strong> —
samples that pass the complete workflow and produce something a public health
decision can rest on. So the procurement metric I proposed to the team was cost
per reportable genome: total attributable workflow cost divided by the number
of samples meeting reporting criteria. It is a harder number to obtain than a
price per gigabase, because no vendor publishes it. That is rather the point.</p>

<h2 id="where-throughput-goes">Where throughput goes</h2>

<p>A worked example, with illustrative figures rather than a recommended
threshold. Take a bacterial genome of 5 Mb at 50× depth: 250 Mb of target bases
per sample. Take a run producing 15 Gb, of which perhaps 70% survives filtering
and is on-target: 10.5 Gb of effective output. That divides into about 42
samples. Ask for 100× instead and it halves to 21.</p>

<p>Then subtract your controls. Then account for uneven pooling, and for the
libraries that underperform. The headline capacity on a datasheet and the number
of genomes you report at the end of the month are different quantities, and the
gap between them is where budgets are lost.</p>

<h2 id="utilisation-and-the-trap-inside-it">Utilisation, and the trap inside it</h2>

<p>Fixed run costs reward filling the flow cell. A hypothetical run costing
US$1,200 works out at US$50 per sample across 24 samples, US$25 across 48, and
US$12.50 across 96. The arithmetic is seductive, and it quietly argues for
waiting until you have a full batch.</p>

<p>During an outbreak that argument is wrong. Waiting to fill a run converts money
saved into days lost, and days are the currency of outbreak response. Any
honest operating plan has to model both: a routine mode optimised for cost per
result, and a surge mode that accepts a half-empty flow cell.</p>

<p>The same realism applies to turnaround. Instrument run time is one segment of
the interval between specimen receipt and an approved report. Transport,
extraction, library preparation, queueing, transfer, analysis, QC review and
release make up the rest. A fast instrument in a slow system produces slow
reports.</p>

<h2 id="what-the-datasheet-never-covers">What the datasheet never covers</h2>

<p>Site readiness decides more installations than chemistry does: power stability
and backup, environmental conditions, reagent shipping and shelf life, minimum
order quantities, replenishment lead times, trained operators, and — the one
most often discovered too late — whether the manufacturer or distributor
actually provides engineering support in the country of installation, as
distinct from the region.</p>

<p>Then there is the data. Versioned analysis pipelines, compute sufficient for
timely basecalling and demultiplexing, documented export of reads and metadata,
retention and access governance, and interoperability with the repositories a
programme is obliged to submit to. Deciding this after the instrument arrives is
expensive.</p>

<h2 id="scoring-and-the-limits-of-scoring">Scoring, and the limits of scoring</h2>

<p>I proposed a weighted scorecard to structure the comparison: assay fit and
demonstrated quality 30%, total cost of ownership 25%, supply and service 20%,
reporting speed and capacity 15%, data and workforce fit 10%.</p>

<p>The weights matter less than one rule that sits above them. Mandatory
requirements are applied <em>before</em> weighted scoring. A vendor that fails a
must-have does not get rescued by a low price or a strong total — otherwise the
scorecard becomes a mechanism for talking yourself into a bad purchase.</p>

<p>And the scorecard does not end the process. Acceptance criteria should be agreed
before delivery, and the pilot should run representative specimens — routine and
difficult — with proper controls, measuring QC success, reporting time,
concordance and repeat rate on complete reports rather than on vendor run
metrics.</p>

<h2 id="not-everyone-needs-an-instrument">Not everyone needs an instrument</h2>

<p>The last point is the one most resisted. Sequencing capacity is a network
property, not a per-laboratory badge. Predictable recurring workload justifies
in-house capacity. Low, intermittent or specialist demand often does not, and a
referral or contracted arrangement with clear terms on quality, logistics, data
return and raw-data access will serve the public health objective better than an
underused instrument with an unfunded service contract.</p>

<p>An instrument that sits idle is not capacity. It is a depreciating asset with a
cold chain attached.</p>

<hr />

<p><em>The briefing itself was prepared for
internal discussion; platform details derive from the Front Line Genomics
guide and require configuration-specific confirmation with vendors before any
procurement.</em></p>]]></content><author><name></name></author><category term="pathogen genomics" /><category term="procurement" /><category term="sequencing" /><summary type="html"><![CDATA[Notes from a technical briefing I gave the Pathogen Genomics Initiative team and the AU Member States on choosing sequencing platforms. The instrument specification is the least useful number in the decision.]]></summary></entry><entry><title type="html">A rebuilt site, and why the publication list is now generated</title><link href="https://babasaraki.github.io/blog/2026/10/a-rebuilt-site/" rel="alternate" type="text/html" title="A rebuilt site, and why the publication list is now generated" /><published>2026-10-24T00:00:00+01:00</published><updated>2026-10-24T00:00:00+01:00</updated><id>https://babasaraki.github.io/blog/2026/10/a-rebuilt-site</id><content type="html" xml:base="https://babasaraki.github.io/blog/2026/10/a-rebuilt-site/"><![CDATA[<p>The old version of this site kept every publication, course and award inside
the HTML of seven separate pages. That has two failure modes, and both of them
had already happened: entries drift out of date because updating them means
editing markup, and content from the template a site was forked from can sit
there unnoticed for years.</p>

<p>Everything is now held in <code class="language-plaintext highlighter-rouge">_data/*.yml</code>. A course is a two-line YAML entry. An
award is three. The publication list is not written by hand at all — it is
generated from my <a href="https://openalex.org">OpenAlex</a> record by a script in the
repository, so adding a paper means running one command.</p>

<p>Two deliberate constraints:</p>

<ol>
  <li><strong>Corrections are separate from generated data.</strong> OpenAlex attributes a
handful of materials-science papers to me through a name collision. Those
DOIs are listed in <code class="language-plaintext highlighter-rouge">_data/pub_overrides.yml</code>, which the generator reads and
never rewrites, so the correction survives every refresh.</li>
  <li><strong>Quartile labels come from a source, not an estimate.</strong> Journal quartiles
live in their own file with the ranking edition they were taken from. There
is no automatic inference, because a plausible-looking guess on a CV is
worse than no label at all.</li>
</ol>

<p>The source is on <a href="https://github.com/babasaraki/babasaraki.github.io">GitHub</a>
if any of it is useful to you.</p>]]></content><author><name></name></author><category term="open science" /><category term="meta" /><summary type="html"><![CDATA[The site is now built from structured data rather than hand-edited HTML, and the publication list is regenerated from OpenAlex instead of maintained by hand.]]></summary></entry></feed>