qPCR result → bedside antibiotic: the seven hand-offs nobody draws

When non-clinical people picture an AMR (antimicrobial-resistance) AI, they picture this:

[qPCR result] ──► [model] ──► [antibiotic]

When I picture an AMR system in production, I picture this:

[wet lab] ──► [analyzer] ──► [LIS] ──► [mapping layer]
   ──► [interpretation engine] ──► [ordering surface]
   ──► [prescriber] ──► [pharmacy] ──► [patient]

Same outcome. Different number of failure points.

I want to walk through those seven hand-offs in plain language, because the gap between them is where most AMR decision-support products quietly stop working — usually somewhere between weeks four and twelve after go-live.

1. Wet lab → analyzer

The sample’s identity is established here, and it’s the most under-respected step in the entire pipeline. The whole downstream system inherits whatever the wet-lab tech wrote on the tube at 6:40 in the morning. If the patient barcode is wrong by one digit, none of your beautiful AI is going to catch it. Most LIS-side validation is a soft check, not a hard one.

The thing nobody draws: approximately 1–3% of samples in a busy lab have a sample-identity issue serious enough to invalidate the result, and your AI cannot detect any of them.

2. Analyzer → LIS

The analyzer emits a structured result. The LIS receives it. In theory this is a solved problem. In practice every analyzer has its own quirks (cycle-threshold reporting, internal-control flagging, multiplex de-duplication), and every LIS has its own interpretation of those quirks. Two analyzers reporting the same pathogen-resistance result can produce two different LIS records.

The thing nobody draws: your AI has to know which analyzer produced the result before it can interpret the result. Most don’t.

3. LIS → mapping layer

The LIS speaks in lab codes. The clinical decision support speaks in concepts. The bridge between them — the local mapping from ECOLI_ESBL_POS to “Extended-Spectrum Beta-Lactamase producing E. coli” to the right LOINC code to the right ICD-10 family to the right antibiotic-susceptibility schema — is the most fragile and least appreciated piece of software in the entire stack.

It is usually maintained by one person. That person usually has another full-time job.

The thing nobody draws: the mapping layer is where AMR decision support actually lives or dies. The model on top of it gets the glory.

4. Mapping → interpretation

Now you have a clean, normalized result. Time for the AI, right?

Not quite. First you need the context the AI needs to interpret responsibly. That includes:

• The patient’s allergy list (and how recent it is — drug allergies older than 5 years should be re-confirmed; almost no system does this)
• The patient’s renal function (because most antibiotic dose adjustments are renal)
• The patient’s current medications (drug-drug interactions and especially QT-prolongation stacks)
• The local antibiogram (resistance patterns in this hospital, in this unit, in the last 90 days — globally optimal recommendations can be locally wrong)
• Whether the patient is pregnant
• Whether the patient is currently on the antibiotic the model is about to recommend

Every one of these is a separate data fetch, from a separate system, with its own staleness and its own permission model. The “model” in AMR decision support is doing 5% of the work. Fetching and reconciling its inputs is doing the other 95%.

The thing nobody draws: there is no “the model” in clinical decision support. There is a model, surrounded by a small army of fetchers, normalizers, and timestamp-watchers.

5. Interpretation → ordering surface

The recommendation now has to land somewhere a clinician will actually see it. That surface is almost always inside the existing electronic ordering system — not in your AI’s beautiful React app. Which means your AI has to either:

• Push into the order set (requires write integration, often via HL7 v2 ORM messages, often through a middleware layer the hospital paid $400K for in 2017)
• Or present as a side panel inside the EHR (requires SMART-on-FHIR or a vendor-specific embedding API, both of which take 6–9 months to certify)

Or, if neither of those is achievable, the AI gets demoted to “a separate screen the prescriber is supposed to also check.” Anything that lives on a separate screen does not exist in clinical practice.

The thing nobody draws: if the recommendation is not in the order set, it does not affect prescribing. Full stop.

6. Prescriber → pharmacy

A doctor accepts the AI’s recommendation. The pharmacy sees the order. Now an entire second system of checks kicks in — pharmacy verification, formulary substitution, IV-vs-PO routing, dose rounding, brand-vs-generic. Any of these can change the drug, the dose, the route, or all three.

If your AI’s “accuracy” metric is measured at the prescriber’s click and not at the dose-administered event, you are measuring the wrong thing.

The thing nobody draws: the prescription a patient actually receives is not the prescription a doctor wrote. Your audit trail needs to follow the drug, not the click.

7. Pharmacy → patient

The drug is dispensed. The patient takes it (or doesn’t). Sometime later, a culture grows. A new resistance pattern. A new qPCR. Loop closes.

If your system doesn’t capture that loop — if the patient outcome doesn’t flow back into the model’s view of the world — then your AMR system is permanently learning from a frozen snapshot of resistance patterns. Real AMR is a moving target. Your model needs to move with it.

The thing nobody draws: AMR decision support without an outcome-feedback loop is a recommendation engine, not a clinical tool. It will drift, and the drift will be invisible.

So why bother?

Because each of those seven hand-offs is also a leverage point. The teams who build genuinely useful AMR decision support are the ones who respect the hand-offs — who treat the wet-lab tech, the LIS admin, the pharmacy lead, and the prescribing doctor as first-class users of the system. The model is a small part of that respect; the rest of it is engineering, and patience, and a willingness to spend three months on a mapping layer that nobody will ever applaud.

If your AMR project is six weeks in and you’ve spent more time on the model than on the mapping layer — you’ve built the wrong thing.

— C.