A biochemistry analyzer completes a calibration. Hardware normal. Sensors normal. Self-test passed. The system logs a successful run.
Two days later, a support call: “The machine is giving wrong results.”
A field engineer is dispatched. After two hours of diagnostics, the instrument checks out fine. Everything is within specification.
The real cause? The operator skipped the reagent verification step before calibrating. This is a workflow deviation — and the machine had no way to detect it.
Workflow deviation : the gap nobody monitors
Modern lab instruments are sophisticated. They track temperature, pressure, reagent levels, optical performance, error codes. They know their own health in remarkable detail.
But they have a blind spot.
They cannot tell you whether the operator followed the correct procedure.
A calibration can complete successfully — from the machine’s perspective — while two critical validation steps were never performed. The instrument sees a completed sequence. It does not see a compromised workflow.
This is the gap between **machine state** and **workflow state**.
Machine state is what the instrument knows about itself.
Workflow state is how the operator actually executed the procedure.
Almost every lab instrument monitors the first. Almost none monitor the second.
What this looks like in practice
These are not hypothetical scenarios. Anyone who has spent time in a clinical chemistry lab has seen variations of all of them.
**The skipped check.**
An operator starts a calibration without verifying reagent levels. The reagents are at 12% — below the recommended minimum. The calibration runs, produces values that look acceptable, and gets approved. Over the next 48 hours, results drift. Patient samples are affected. By the time QC catches it, dozens of results need re-verification.
The instrument never flagged anything. From its perspective, the calibration was successful.
**The rushed approval.**
Calibration completes. The results screen appears. The operator clicks “Approve” in less than one second. No channel-by-channel review. No comparison against previous calibration values. An out-of-tolerance result on one analyte passes unnoticed.
The instrument recorded a successful calibration with operator approval. It has no concept of whether the approval was informed or reflexive.
**The retry loop.**
A calibration fails. The operator retries immediately. Fails again. Retries again. Four attempts in twenty minutes, each producing the same error. The root cause — an expired reagent lot — is never investigated because the operator assumes the machine is malfunctioning.
Support gets a call about a “broken instrument.” The field engineer finds nothing wrong with the hardware. Two hours of diagnostic time, wasted. The fix was a reagent replacement that the operator could have identified in the first place.
**The procedural drift.**
None of these workflow deviations start as deliberate shortcuts. They begin as occasional time-saving habits. Skip the reagent check when you’re running late. Approve without reviewing when the last ten calibrations were fine. Retry instead of investigate because the error will probably clear itself.
Over weeks, the skip rate climbs. 2% becomes 7% becomes 18%. No single incident triggers an alarm. The drift is gradual, invisible, and cumulative — until something downstream breaks badly enough to be noticed.
Why existing systems don’t catch this
**LIMS** tracks what was ordered, what was tested, and what was reported. It does not track how the operator navigated the instrument software between those events.
**QC systems** catch result-level anomalies after the fact. They cannot distinguish between a legitimate analytical failure and a procedural shortcut that corrupted the run before it started.
**Audit trails** record what happened in the system. They do not evaluate whether what happened matches what should have happened. A complete audit trail can document a perfectly executed bad workflow.
**Training programs** teach correct procedures. They have no visibility into whether those procedures are actually followed on Tuesday morning when the lab is understaffed and the queue is long.
The instrument itself is the closest observer — it sees every operator interaction in real time. But it is designed to monitor its own systems, not the human workflow around it.
The cost is real but hidden
These failures rarely present as “operator error.” They present as:
– **Support tickets**: “The machine is inaccurate” or “The machine is frozen”
– **Reagent waste**: Failed runs consume expensive calibrators and controls
– **Re-runs**: Compromised batches require repeat testing, delaying results
– **Compliance findings**: Auditors see the gap between documented SOPs and actual practice
– **Customer dissatisfaction**: Labs blame the instrument vendor, not the workflow
For equipment manufacturers, this is particularly painful. The support burden from procedural deviation is real, recurring, and difficult to prove. The manufacturer knows the machine is working correctly. The customer insists something is wrong. Neither side has visibility into the workflow layer where the actual problem lives.
What would change if workflow state were visible
Imagine the instrument software knew — in real time — that a validation step was skipped. Not because it forced the operator to comply, but because it observed the workflow and recognized the deviation.
The calibration still completes. The operator is not blocked. But the system flags:
– Which step was missed
– How long the approval took
– Whether this pattern has occurred before
– What the downstream risk is
The lab manager sees a workflow integrity trend: “Reagent verification skip rate on Analyzer-02 has increased from 2% to 18% over the past 30 days.”
The service director sees a pattern: repeated support calls cluster around procedural deviations rather than hardware faults.
The quality officer sees something new: compliance evidence based on what operators actually did, not what they reported doing.
None of this requires changing the instrument. It requires observing the workflow.
The distinction matters
This is not about surveillance. It is not about monitoring operators. It is not about performance tracking.
It is about understanding whether the procedure was followed — at the workflow level, in real time, with enough context to act before the consequences accumulate.
Technical software already knows machine state.
The missing layer is workflow state.
That gap is where the most expensive, most invisible, and most preventable failures hide.
*Cristian Valcea has spent 20+ years developing firmware and operator software for biochemistry analyzers. He is currently exploring workflow-state intelligence through