Before the Record Exists

Summary

In clinical laboratory testing, the pre-analytical phase — collection, identification, transport, receipt, labelling, handling — accounts for roughly 62 to 68 per cent of all errors.¹ The instruments and the analysis, which is where most software investment and nearly all validation attention has gone, account for a minority. This is not a new finding and it is not disputed. What is odd is how little follows from it. Systems of record model the sample from the point it becomes a row in a database; the physical journey that precedes that moment is covered by paperwork, email, spreadsheets, and the judgement of whoever is on the receiving bench. The explanation is not negligence. It is that an audit trail cannot record the history of something that has no record, and the pre-analytical window is precisely the interval between a sample existing physically and existing digitally. Systems designed around the record are structurally blind to it. Closing that gap means the record has to start earlier — at notification rather than at accession — and the system has to hold a sample's identity through a period when the information about it is incomplete, contested, and arriving from parties outside the organisation. That is a different design problem from the one most laboratory software solves, which is why buying more of the same software has not fixed it.

1. The distribution of errors is not where the investment is

Sort laboratory errors by where they occur and the shape is consistent across decades of literature: the majority arise before analysis begins.¹ Collection. Identification. Transport. Receipt. Labelling. Handling.

Now sort software investment and validation effort by the same phases. It concentrates on the analytical: instrument integration, result capture, calculation, review, release. That is where the regulated artefact lives, so that is where the assurance went.

Both distributions make sense on their own. Together they describe a mismatch: the phase with most of the errors has least of the software.

It is worth being careful about what this does and does not prove. Error counts are not severity-weighted, and an analytical error may carry consequences a mislabelled tube does not. Detection differs too — a pre-analytical failure that surfaces at reception is caught cheaply, while an analytical one may propagate. The distribution is a statement about frequency, not about harm.

But frequency is what determines operational load. The people on the receiving bench are absorbing the majority of the failures, and they are doing it with the least support.

2. Why the software stops where it does

The usual explanation is that pre-analytical work is physical, and software is bad at physical. That is true and it is not sufficient — plenty of software handles physical logistics well.

The structural reason is narrower and more interesting.

A system of record begins when the record begins. For a laboratory system, that is accession: the moment a sample is entered, given an identifier, and becomes a row. Everything the system knows, audits, and can attest to starts there.

The pre-analytical phase is, definitionally, the interval before that moment. A sample collected at a clinical site on Monday, shipped Tuesday, and accessioned Thursday spent three days existing physically and not existing digitally. During those three days it was labelled, packed, handed to a courier, held at some temperature, and possibly separated from its documentation. Every one of those steps could go wrong, and none of them is inside the system's jurisdiction, because there is no record for the audit trail to attach to.

This is why audit trails do not help here. An audit trail is excellent at telling you who changed a record and when. It has nothing to say about the period before the record existed. A system can be perfectly compliant, fully validated, and completely blind to the phase generating most of the errors.

The consequence is that the gap gets filled by people rather than systems. Manifests arrive by email. Discrepancies are worked out by phone. Corrections are tracked on a spreadsheet. The receiving bench becomes the integration layer between the outside world and the validated system — performing, by hand, the reconciliation that nothing was designed to do.

This is an argument from mechanism rather than from measured evidence. The error distribution in §1 is documented; this explanation for it is reasoning, and a reader should treat it as a hypothesis about cause rather than an established one.

3. What is actually hard about this ground

Four properties make the pre-analytical phase genuinely difficult to model, and they are worth naming because they explain why extending an existing system into this space usually fails.

Identity is provisional. In the analytical phase, a sample has one identifier and it is authoritative. Before accession it may have several — a collection-site label, a barcode applied at packing, a number in a manifest, a courier tracking reference — and they may disagree. A system that assumes a single authoritative identifier cannot represent the period in which identity is still being resolved.

Information arrives before the object, or after it, and rarely together. A manifest may arrive days before the shipment or turn up after the boxes are already on the bench. The system has to hold a sample that is described but not present, and a sample that is present but not described, and reconcile them when both exist. Data models built around a record that is created once, complete, cannot express either state.

The parties are outside the organisation. Collection sites, couriers, central labs, and vendors are the ones generating most of the information, and they are not users of the system. They send spreadsheets in inconsistent formats, on their own schedules, with their own conventions. Any design that assumes the data arrives through a controlled interface has assumed away the problem.

The record must tolerate being wrong. A sample can be received, entered, and later found to be something else. The pre-analytical record needs to support correction as a normal event rather than an exception — which sits awkwardly with regulated systems designed to make records immutable.

Each of these is a data-modelling problem before it is a workflow problem. That ordering matters: a system that has not solved them cannot be configured into solving them, which is why the spreadsheet keeps reappearing no matter how much configuration is available.

4. What covering it would require

Five design properties follow from §3. Each is testable, which is the only reason to list them.

The record starts at notification, not at accession. The moment a shipment is announced — by email, by a vendor feed, by any means — a record exists and begins accumulating history. The sample is then expected, which is a real state with real consequences: it can be late, it can be partially received, it can never arrive. None of those are expressible if the record begins on arrival.

Ask to see: a sample that has been announced but not received, and what the system knows about it.

Identity is a set, not a field. The system holds every identifier a sample has carried, records which system asserted which, and can express disagreement between them without discarding either. Resolution is an event with a timestamp and an author, not a silent overwrite.

Ask to see: a sample whose manifest identifier and physical label disagreed, and how that was resolved.

Reconciliation is a first-class operation, not a report. Comparing what was expected against what arrived, producing a discrepancy list, and driving it to closure is a workflow the system runs — not a spreadsheet somebody maintains alongside it.

Ask to see: the discrepancy list for a real shipment, and the audit trail of how each line was closed.

Inbound data is assumed to be malformed. Format variation from external parties is the normal case. A system that treats a non-conforming manifest as an error to be rejected has pushed the work back to a human; one that treats it as input to be parsed, mapped, and — where it fails — remediated through a governed loop has absorbed it.

Ask to see: what happens when a manifest arrives in an unexpected format.

Correction is a designed path. Amending a pre-analytical record is expected, governed, and leaves the prior state intact and readable. This is ordinary data-integrity practice; the point is that it must apply to the messy early record, not only to the clean analytical one.

Ask to see: a corrected receipt, with the original still legible.

5. Why this matters more than it used to

Three shifts, none of them about software.

Sample volumes are growing faster than the people handling them. Where a laboratory's inbound volume grows materially year over year, the receiving bench does not scale by the same factor, and the manual reconciliation layer is the first thing to fail. This is a throughput constraint before it is a quality one, and it is usually noticed as the latter.

Regulatory attention has moved toward how work is actually done. Inspectors comparing the written procedure to the observed practice will find the spreadsheet. A gap covered by informal tooling is a finding waiting to be made, regardless of how well the validated system performs.

The material is increasingly irreplaceable. A sample from a closed study, a consented donor, or a finite collection cannot be recollected. The cost of a pre-analytical failure is no longer a repeat draw; in some cases it is the permanent loss of the only material that will ever exist.

6. Scope of the claim

Where the claim applies, and what it costs.

"No software covers this" overstates it. Established systems do have receiving functions, and some are reasonable. The claim is about where the design centre of gravity sits — the record beginning at accession — rather than about a total absence of features.

Designing for the messy record has costs. A system that models provisional identity, tolerates incomplete information, and treats correction as routine is more complex than one that does not, and complexity has its own failure modes. The claim is that the complexity is already present in the operation and is currently being carried by people; moving it into the software is a transfer, not an elimination.

7. The question worth asking

Not "does your system handle sample receipt." Everything does, in some sense.

Better: where does our record of a sample begin, and how much of its life happened before that point?

The answer is measurable. Take a batch of recently accessioned samples and reconstruct their history from collection. Count the events, decisions, and handoffs that occurred before the system had anything to say about them. Then look at where the problems came from.

Organisations that run this exercise generally find the same thing the literature already told them. The value is not the finding. It is that the finding is now about their own operation, in their own numbers, which is what makes it actionable.

Appendix — Locating the gap in your own operation

Sections 2, 3, and 4 argue from mechanism rather than from measurement, and are marked where they do. Where an assertion is checkable inside a reader's own operation, the check is given rather than asserted. No claim is made here about any specific vendor's coverage of the pre-analytical phase, including our own.