Maintenance
Preventive Maintenance for Lab Equipment: An Audit-Ready Program
Calibration gets the attention. It has certificates, traceability chains, and a whole vocabulary of its own. Preventive maintenance — the unglamorous work of cleaning probes, replacing tubing, checking seals, and verifying temperatures — gets a paper log taped to the side of the instrument.
Then the inspection happens, and the auditor doesn’t start with calibration. They pick an analyser, ask for its maintenance plan, and start pulling threads: Who decided this gets monthly maintenance? Where’s the record for March? This entry says a part was replaced — which part, and where did it come from? This one says “issue noted” — what happened next?
If your answers live in a binder, on three different paper forms, and in one technologist’s memory, you already know how that conversation goes. This post is about building a preventive maintenance program where every one of those threads, when pulled, leads to a record.
What a complete PM program actually contains
Strip away the tooling and a defensible preventive maintenance program is five things:
- A defined task list per instrument — not “perform maintenance” but the specific items: what gets checked, what gets measured, what gets replaced.
- A schedule with a rationale — how often each task list runs, and why that frequency.
- Execution records — who did it, when, what they found, with the result of each item.
- Evidence — photos, printouts, or readings that prove the work happened as described.
- A follow-up loop — when maintenance finds a problem, a tracked path from “issue noted” to “issue resolved”.
Most labs have fragments of all five. The audit findings come from the joints between them — the issue that was noted but never closed, the schedule nobody can justify, the record that says “done” with nothing behind it.
Checklists, not checkbox theatre
A maintenance log that says “Monthly PM performed — ✓” is close to worthless as evidence. It proves someone signed a form. It doesn’t prove the waste line was actually inspected or that the incubator actually held 37 °C.
The fix is to make the checklist itself the record, with item types that match the work:
| Item type | Example | What gets recorded |
|---|---|---|
| Check | ”Inspect sample probe for clots/damage” | Done / not done, with notes |
| Measurement | ”Record incubator temperature” | The actual value, against an expected range |
| Text response | ”Describe condition of pump tubing” | Free-text observation |
| Action item | ”Replace ISE membrane if >30 days old” | Action taken yes/no, with details |
Measurements are the items auditors love, because they’re falsifiable. “Temperature checked ✓” tells an inspector nothing. “36.8 °C, acceptable range 36.5–37.5” tells them the check happened and the instrument passed. When a measurement lands outside its range, the record should show that too — flagged, not buried.
Scheduling: time-based, usage-based, and the 80% rule
Most PM tasks run on calendar intervals — daily, weekly, monthly, quarterly. That’s fine for tasks driven by time: seals dry out, dust accumulates, filters clog at roughly constant rates.
But some maintenance is driven by workload, not time. A centrifuge that runs 40 cycles a day and one that runs 4 do not deserve the same rotor inspection interval. For these, usage-based scheduling — maintenance due every N operating hours or N cycles — matches the maintenance burden to the actual wear.
A practical detail that matters more than it looks: don’t let usage-based tasks go from “fine” to “overdue” overnight. A sensible system flags the task as due soon at 80% of the threshold, giving the team a window to schedule the work instead of discovering it the morning it tips over.
Two more scheduling rules that keep a program honest:
- A failed PM does not advance the schedule. If the monthly maintenance found a problem and the result was a fail, the task is still due. Marking it complete because “we attempted it” is how broken instruments quietly stay in service.
- “Pass with issues” is a legitimate result. Maintenance often succeeds while surfacing something that needs attention — a part nearing end of life, a reading drifting toward its limit. The schedule advances, but the issue enters the follow-up loop instead of evaporating into a comment field.
Evidence: the difference between a claim and a record
When maintenance involves anything visual — tubing condition, rotor wear, a printout from the instrument’s own diagnostics — attach the evidence to the record. A phone photo of the replaced part next to its packaging takes ten seconds and ends an entire category of audit questions.
For evidence to survive scrutiny, it needs integrity: the file attached to the March record must demonstrably be the file that was uploaded in March. Checksums (SHA-256 fingerprints computed at upload) make tampering detectable, which is precisely the property an auditor cares about when the record is two years old.
The follow-up loop is where programs die
Here’s the most common maintenance finding in real inspections, and it’s not a missing log. It’s this sequence:
- Technologist performs PM, notes “slight leak at valve 3, monitor”.
- Nothing else, ever.
The work was done. The observation was even recorded. But there’s no evidence anyone acted on it, and six months later the same valve appears in a service engineer’s repair report. The lab now looks like it knew about a problem and sat on it — which is worse than not knowing.
Every issue raised by maintenance needs three things: an owner, a due date, and a resolution record. Open follow-ups should be visible on a dashboard, not filed inside individual maintenance logs where they’re invisible until someone goes looking. The loop closes when someone with authority marks it resolved and says what was done.
Parts and consumables: the quiet audit trail
If maintenance replaces things — tubing, membranes, filters, lamps — track them. A simple parts register (part number, supplier, unit cost) plus a per-maintenance record of what was consumed gives you three things labs rarely have:
- Proof that the replacement actually happened, with the specific part identified
- A cost picture per instrument, which is how you justify replacing the analyser that eats consumables
- Early warning when consumption rates change — a pump that suddenly needs tubing twice as often is telling you something
Measuring the program: one number
“Is our maintenance under control?” should not require opening a binder. The honest metric is simple: of all equipment with maintenance plans, what percentage has every plan current? Not “mostly current”, not “the important ones” — every active plan on the instrument within its due window.
That number, recalculated continuously, does two jobs. Day to day, it tells the lab manager where this week’s attention goes. At inspection, it’s the answer to the auditor’s opening question — and a lab that can answer it instantly, with the overdue list one click away, has set the tone for the entire visit.
The reminder problem, again
We’ve written before about why spreadsheets fail lab compliance, and maintenance is the worst case of the pattern: dozens of small recurring tasks across many instruments, each individually forgettable. A paper schedule or spreadsheet doesn’t notice when Tuesday’s weekly PM doesn’t happen. By the time anyone notices, it’s a gap in the record that no amount of diligence can backfill.
Active reminders — sent before the due date, and repeating when something goes overdue — turn maintenance from a memory problem into a queue. The technologist starts the day with a list, not a guess.
Where to start
If you’re building or rebuilding a PM program, the order that works:
- Inventory first. Every instrument, in one register, with its operational status. You can’t schedule maintenance for equipment you haven’t listed.
- Checklists for the top five instruments. Start with the analysers that would hurt most if they failed. Real item types, real measurement ranges.
- Schedules with rationale. Manufacturer recommendation is the defensible default; adjust with documented reasoning where your usage justifies it.
- The follow-up loop before anything else fancy. A program that surfaces issues and tracks them to resolution is worth more than one with beautiful checklists and a black hole behind them.
- Then scale. Add the remaining instruments, parts tracking, and usage-based schedules once the core loop is running.
The goal isn’t a perfect program on day one. It’s a program where every thread an auditor pulls leads somewhere — a record, an owner, a resolution. That property, more than any individual feature, is what survives an audit.
Related reading:
