Data integrity is one of those phrases that sounds like paperwork until an auditor asks you to prove that the volume on a report is the volume the instrument actually delivered, on that day, with that method. In a regulated lab the answer cannot be a shrug or a spreadsheet someone edited last week. It has to be a record you can trace back to a specific run, a specific instrument, and a specific set of parameters, with nothing in between that a person could have quietly changed. That chain is what data integrity means in practice, and pipetting sits right in the middle of it.
This is a guide to the ideas behind 21 CFR Part 11 and the wider GxP expectations, aimed at the people who run liquid handlers rather than at the quality department. You do not need to memorize the regulation to work in its spirit. You need to understand what a good record looks like and where your liquid handling method fits into it.
ALCOA: the shape of a trustworthy record
Regulators describe a sound record with the acronym ALCOA, later extended to ALCOA+. It is a useful checklist even outside a regulated setting, because it names the ways a record quietly goes wrong.
- Attributable: you can tell who or what produced the data and when. A dispensed volume tied to an operator, an instrument, and a timestamp is attributable; a number typed into a shared file is not.
- Legible: the record can be read and understood, now and years from now, without insider knowledge of an abbreviation someone invented.
- Contemporaneous: the record is made at the time the work happens, not reconstructed from memory the next morning.
- Original: the first capture of the data, or a verified true copy of it, is preserved rather than replaced by a transcription.
- Accurate: the record reflects what actually happened, with errors corrected in a visible, explained way rather than overwritten.
The plus adds complete, consistent, enduring, and available: nothing dropped, nothing contradictory, nothing that decays or disappears when you need it. Read that list back and notice how much of it is about the history of a value, not the value itself. A number is only as trustworthy as the story of how it came to be.
The two ideas that trip people up: audit trails and electronic signatures
Part 11 is a rule about electronic records and electronic signatures, and two of its requirements do most of the work. The first is the audit trail: an automatic, secure, time-stamped log of who did what to a record, including changes and deletions, that cannot itself be edited. The point is not to prevent change but to make change visible. A parameter that was adjusted should show the old value, the new value, who changed it, when, and ideally why.
The second is the electronic signature: a signing act bound so tightly to a record that it cannot be copied onto another record or repudiated later. In a lab this is what turns approved into a fact rather than an assertion. Between them, the two requirements answer the auditor's real question, which is never simply what the value is but whether anyone could have changed it without leaving a mark.
Where liquid handling enters the audit trail
It is tempting to treat data integrity as something that starts at the analytical instrument, after the sample is prepared. But the pipetting step decides the composition of every sample the analyzer later measures. If a dilution was built with the wrong dispense parameters, the cleanest chromatogram in the world is a precise measurement of the wrong thing. So the pipetting method is part of the record, and it needs the same attributability as the result.
In concrete terms, a defensible run lets you reconstruct three things after the fact. What was the method: the volumes, the sequence, the labware. What were the pipetting parameters: the flow rates, air gaps, and corrections that governed how liquid actually moved. And what was the context: which instrument, which tips, which operator, at what time. Miss any one of those and you have a result you cannot fully explain, which in a regulated setting is close to having no result at all.
Practical habits that keep you audit-ready
- Version your methods and your pipetting parameters, so a report can name the exact version that produced it rather than a method that has since been edited.
- Never overwrite a parameter set in place once it has produced reported data; create a new version and keep the old one, so the audit trail stays intact.
- Record the instrument, tips, and operator alongside the run, not in a separate notebook that can drift out of sync.
- Correct errors by addition, with an explanation, rather than by deletion, so the original and the correction both survive.
- Restrict who can approve a method version, and capture that approval as a signature bound to the version.
An auditor rarely doubts your number. They doubt whether anyone could have changed it without leaving a trace. Data integrity is the discipline of making that impossible, and it starts at the pipette, not the analyzer.