Analysis

In a clinical lab, cross-contamination risk is invisible until it isn't — and by then, the chain of custody that would explain it is gone. This document assesses the feasibility of an automated system that enforces hand-washing protocol between instrument pickups: detecting when a technician handles instrument A, starting a time window, and flagging a violation if instrument B is picked up without a wash event in between. The assessment covers sensor architecture, the specific hard problems in multi-technician environments, regulatory context, and a concrete build sequence. By the end, a reader will know whether this system is buildable, what the genuine risks are, and what to resolve before breaking ground.

What the System Must Do¶

A lab technician walks to a bench and picks up a pipette. At that moment, the system registers an instrument pickup event — sourced from the RFID tag on the pipette, confirmed by a camera trained on the bench. The technician uses the instrument, sets it down, and the system starts a 30-second countdown. If the technician moves to the wash station and activates the soap dispenser within that window, the system resets cleanly. If the technician instead reaches for a second instrument — a centrifuge tube, a specimen jar — before the window closes, the system classifies that as a protocol violation: flags it, triggers an in-lab alarm, sends a push notification to a supervisor's phone, and attaches a video clip of the incident to the violation record.

This cycle repeats for every instrument transition throughout the shift. The system does not manage instrument sterilization state, does not integrate with LIMS or EHR systems, and does not make any determination about whether the technician's work is otherwise correct. Its job is narrow: enforce a single, well-defined protocol rule and produce evidence when it is broken.

Two optional features extend the core: an individual compliance history view, which accumulates per-technician violation and compliance counts over time, and a shift-end compliance report, which summarises the session's protocol adherence across all technicians. Both depend on the core violation log being reliable; they add no new sensors or architectural complexity.

Where Sensor Fusion and CV Add Value¶

This system's detection problem has two distinct sub-problems: knowing that an instrument was picked up, and knowing that a hand-wash event occurred. Neither is trivially solved by a single sensor, and the combination of RFID and computer vision is the architecture's key strength.

Instrument pickup detection is the first sub-problem. A passive UHF RFID tag attached to each instrument is read by an antenna at the bench when the instrument enters the read field — typically when lifted. This gives a reliable, low-latency pickup event. The camera provides a second, independent confirmation: a model trained on the bench view detects a hand grasping the tagged zone. The fusion of both signals eliminates two failure classes that neither sensor handles alone: RFID reads can be triggered by proximity without an actual pickup (false positive); CV alone cannot distinguish which instrument was grasped if two instruments are adjacent. Together, they produce a confident, instrument-specific pickup event.

Hand-wash detection is the second sub-problem. A binary sensor on the soap dispenser (a reed switch or optical break-beam triggered on pump actuation) provides the primary signal — near-100% reliable, zero false negatives on actual washes, no inference required. A camera at the wash station provides secondary confirmation: gesture recognition can verify rubbing motion and estimate wash duration if the protocol requires it. For the base system, the soap sensor alone is sufficient.

Person attribution is what makes the system work in a multi-technician environment. With roughly five technicians working simultaneously (assumption), the system must know which technician triggered which instrument event and which wash event. There are two approaches: wristband or badge RFID (each technician carries a unique tag that is read alongside the instrument tag) or camera-based person tracking (a person detection model identifies and tracks individuals across frames). The RFID approach is more reliable and avoids ML inference in the critical attribution path; the camera approach requires no extra wearable but is harder in crowded or occluded scenes. The recommended starting point is wristband RFID for attribution, with camera tracking as a fallback.

Architecture¶

The system is organized into four layers. The sensor edge layer is the hardware closest to the lab: RFID readers at each bench (instrument detection), RFID wristbands on each technician (person attribution), a soap sensor at each wash station, and cameras covering both bench areas and wash stations. Each sensor emits discrete, timestamped events — not continuous streams — to minimize downstream processing load.

The event broker sits above the edge. It receives events from all sensors, normalises them into a common schema (technician ID, event type, instrument ID, timestamp, camera frame reference), and routes them to the state machine. The broker also maintains the raw video buffer: a short rolling window of footage from each camera, retained long enough to extract a clip around any violation event.

The state machine engine holds the protocol logic. For each technician, it tracks the current state: idle, holding-instrument, or in-wash-window. A pickup event transitions from idle to holding-instrument. A put-down event starts the 30-second countdown and transitions to in-wash-window. A soap sensor event within the window resets to idle. A second pickup event while in-wash-window is the violation trigger. The state machine is a pure deterministic system — no inference, no probabilistic scoring — which means it is testable, auditable, and easy to explain to compliance reviewers.

The violation classifier receives the trigger from the state machine and dispatches two things simultaneously: the alert (in-lab audible alarm + supervisor push notification) and a clip extraction request to the broker's video buffer. The clip is extracted, attached to a structured violation record, and written to persistent storage. The violation record includes technician ID, instruments involved, timestamp, wash window elapsed, and clip reference.

The diagram below shows the component relationships and event flow.

flowchart TD
    subgraph Edge["Sensor Edge"]
        R[RFID Readers<br/>at bench]
        W[Wristband RFID<br/>per technician]
        S[Soap sensor<br/>at wash station]
        C[Cameras<br/>bench + wash]
    end

    subgraph Broker["Event Broker"]
        N[Event normaliser<br/>common schema]
        VB[Video buffer<br/>rolling window]
    end

    subgraph Engine["State Machine Engine"]
        SM[Per-technician<br/>state machine]
    end

    subgraph Dispatch["Violation Dispatcher"]
        AL[In-lab alarm]
        PN[Push notification<br/>supervisor app]
        CE[Clip extractor]
        VR[Violation record<br/>store]
    end

    R --> N
    W --> N
    S --> N
    C --> N
    C --> VB

    N --> SM
    SM -- violation trigger --> CE
    SM -- violation trigger --> AL
    SM -- violation trigger --> PN
    CE --> VB
    CE --> VR
    PN --> VR

What Is Hard¶

Person Attribution in a Multi-Technician Lab¶

This is the system's hardest problem. The state machine requires a technician ID with every instrument pickup event; without it, the system cannot know whose wash window to check. If two technicians are working adjacent benches and one picks up an instrument, the RFID reader at that bench must associate the pickup with a specific person.

Wristband RFID solves this at the bench level: the reader detects both the wristband tag and the instrument tag in the same read cycle, producing a (person, instrument) tuple. The challenge is ensuring read geometry — the wristband must enter the same read field as the instrument. Bench-mounted RFID antennas with well-chosen placement (pointing upward from the bench surface, not sideways) reliably achieve this.

Camera-based person tracking is the fallback. A person detection model (YOLO-class, running on an edge GPU) can assign instrument pickup events to bounding box tracks. This works well in single-occupancy scenes and degrades gracefully in two-person scenes. Beyond two people at a shared bench, occlusion becomes a genuine risk: one technician reaching across another will break the track.

The recommendation is to deploy wristband RFID as the primary attribution mechanism and use the camera track only for validation. A mismatch between the two signals should surface as a data quality alert, not a violation, and be reviewed manually.

On-Metal RFID Reliability Per Instrument Type¶

Standard passive UHF RFID tags lose range and can fail to respond when placed directly on metal surfaces. Clinical lab instruments are frequently metal-bodied — pipettes have metal barrels, centrifuge rotors are aluminium, specimen racks are stainless. On-metal tags address this by including a dielectric spacer, but their performance varies by tag vendor, instrument geometry, and surface curvature.

Before bulk-tagging instruments, a bench test with representative instruments from the actual lab is required. The test should verify read reliability at a range of bench antenna orientations and confirm that the tags survive the cleaning chemicals used in the lab (many labs use bleach or alcohol wipes, which degrade some adhesive-backed tags). If any instrument type proves incompatible with RFID, CV-only detection for that instrument category is the fallback.

CV and RFID Fusion Without Double-Counting¶

When both RFID and CV confirm a pickup event, the state machine should receive one event, not two. Without deduplication, two simultaneous transitions will fire for the same physical action, creating state inconsistencies.

The event broker handles this with a short temporal deduplication window (100–200ms): if a CV pickup event and an RFID pickup event arrive for the same technician and the same instrument within the window, only one is forwarded to the state machine. If only one signal arrives (e.g., RFID read succeeds but CV is occluded), the single event still propagates. The fusion logic is simple and testable; it is listed here because teams that build sensor fusion for the first time frequently overlook it.

30-Second Window Enforcement with Clock Drift¶

The state machine's wash window relies on wall-clock time. Sensor events arrive from multiple edge devices — RFID readers, cameras, soap sensors — each with their own clock. Even a 1–2 second drift between devices can cause the state machine to misclassify a legitimate wash event as a missed window.

The fix is NTP synchronisation on all edge devices to a common lab network time source, plus a short grace margin (2–3 seconds) on the window boundary. The grace margin should be documented in the protocol configuration, not hardcoded, so it can be adjusted as operational data accumulates.

Video Clip Retrieval Latency¶

The supervisor push notification must arrive with the video clip attached, or shortly after. If the clip is not ready when the alert fires, the supervisor receives a notification without evidence — which reduces trust in the system and may cause alerts to be dismissed.

The broker's rolling video buffer must be sized to cover at least the clip window (e.g., 15s pre-violation + 15s post). The clip extraction process must complete within the alert delivery latency budget. For a local-network system with a camera feed stored on-premise, extraction time is typically under 2 seconds. For a cloud-routed setup, this needs explicit measurement.

Clinical Compliance Audit Trail¶

If ISO 15189 or GLP applies, the violation record store must be append-only (no deletions, no edits), with a documented retention period, and access-controlled so that the log cannot be altered by the same personnel who are monitored. These are not complex engineering requirements, but they must be designed in from the start — retrofitting tamper-evidence onto a mutable log is painful. Confirm the regulatory obligation before choosing a storage backend.

Feasibility Verdict¶

The system is buildable. The sensor architecture is sound and the protocol logic is deterministic. The two genuine risks are on-metal RFID reliability (solvable with bench testing before deployment) and the unconfirmed regulatory obligation (solvable with a single confirmation from the lab's quality manager). The longest pole is not engineering — it is the instrument tagging effort: physically attaching on-metal RFID tags to every instrument in the lab, verifying read reliability, and maintaining the tag registry as instruments are added or replaced.

Why These Outputs — Nothing Missing?¶

Build Order¶

The spine for this system is: Sensor Edge → Event Broker → State Machine → Alert Dispatcher.

The sensor edge must come first because every downstream component depends on a stream of real, timestamped events — synthetic events can be used for unit testing but not for verifying sensor placement, RFID read geometry, or fusion deduplication. The event broker must be live before the state machine can be tested against real event sequences, because the broker's deduplication and normalisation logic shapes the event stream the state machine sees. The state machine must be correct before the alert dispatcher is connected — firing false alerts during state machine development erodes trust in the system before it is operational. The alert dispatcher is last because it is the only component with external side effects (alarms, push messages, clip extraction); containing it until the upstream is validated is standard practice.

The CV redundancy layer is a bulge off the sensor edge — it needs a working camera feed and a bench to point it at, but not the state machine or alert dispatcher. It can be built and evaluated in parallel with the event broker. The clip store is a bulge off the event broker — it needs the video buffer to exist, but not the full violation pipeline. The optional compliance history is a bulge off the violation log (itself part of the alert dispatcher); it can be built once the log schema is stable. Shift reports are a bulge off compliance history.

flowchart LR
    SE["Sensor Edge<br/>RFID readers, wristbands,<br/>soap sensor, cameras"]
    EB["Event Broker<br/>normalise, deduplicate,<br/>video buffer"]
    SM["State Machine<br/>per-technician protocol<br/>enforcement"]
    AD["Alert Dispatcher<br/>alarm, push, clip,<br/>violation log"]

    SE --> EB --> SM --> AD

    CV["CV Redundancy<br/>instrument pickup<br/>confirmation model"]
    CS["Clip Store<br/>evidence retrieval<br/>and retention"]
    CH["Compliance History<br/>per-technician<br/>violation trends"]
    SR["Shift Reports<br/>aggregate adherence<br/>summary"]

    SE --> CV
    EB --> CS
    AD --> CH
    CH --> SR

    style SE fill:#E3F2FD,color:#0D47A1
    style EB fill:#E3F2FD,color:#0D47A1
    style SM fill:#E3F2FD,color:#0D47A1
    style AD fill:#E3F2FD,color:#0D47A1
    style CV fill:#E8F5E9,color:#1B5E20
    style CS fill:#E8F5E9,color:#1B5E20
    style CH fill:#E8F5E9,color:#1B5E20
    style SR fill:#E8F5E9,color:#1B5E20

Spine nodes (delay here delays everything): Sensor Edge → Event Broker → State Machine → Alert Dispatcher

Bulge nodes (unblocked when parent spine node completes):

• CV Redundancy — unblocked by Sensor Edge (camera feed live)
• Clip Store — unblocked by Event Broker (video buffer live)
• Compliance History — unblocked by Alert Dispatcher (violation log stable)
• Shift Reports — unblocked by Compliance History

gantt
    title lab-hygiene-sentinel — Spine + Bulge Build Plan
    dateFormat YYYY-MM-DD
    axisFormat W%W

    section Spine
    Sensor Edge (RFID + soap sensor + cameras)     :p1, 2026-04-07, 3w
    Event Broker (normalise + deduplicate + buffer) :p2, after p1, 2w
    State Machine (protocol enforcement)            :p3, after p2, 2w
    Alert Dispatcher (alarm + push + clip + log)    :p4, after p3, 2w

    section Bulge (parallel)
    CV Redundancy Layer                             :b1, after p1, 3w
    Clip Store                                      :b2, after p2, 1w
    Compliance History                              :b3, after p4, 2w
    Shift Reports                                   :b4, after b3, 1w

Parallelism rules:

• CV Redundancy can run in parallel with the Event Broker and State Machine sprints — it only needs the camera feed from the Sensor Edge sprint.
• Clip Store can run in parallel with the State Machine sprint — it only needs the video buffer from the Event Broker.
• Compliance History and Shift Reports cannot start until the violation log schema is stable (end of Alert Dispatcher sprint) — their data model is entirely derived from the log.
• The State Machine sprint cannot be parallelised with the Event Broker sprint — the state machine's correctness depends on the normalised, deduplicated event stream, which the broker produces.

Open Questions¶

1. What is the actual regulatory obligation?
   The system is assumed to operate in a clinical lab context where ISO 15189 or GLP may apply. If either applies, the violation log must be append-only, tamper-evident, and retained for a defined period. Options: (a) confirm no formal standard applies — use any durable storage; (b) confirm ISO 15189 applies — design the log as an immutable audit record from day one. Unblocked by: a single conversation with the lab's quality manager or compliance officer.

2. What is the person attribution mechanism?
   Wristband RFID is the recommended approach but requires technicians to wear a device during shifts. If this is operationally unacceptable, camera-based person tracking is the fallback but degrades under occlusion. Options: (a) wristband RFID — reliable, minor operational overhead; (b) badge RFID at bench entry points — lower reliability for attribution at the instrument level; (c) camera-only person tracking — no wearable, higher CV complexity. Unblocked by: lab operations team confirming willingness to adopt wristbands.

3. Is there existing camera infrastructure in the lab?
   The system assumes cameras will be placed strategically. If IP cameras already exist, their coverage, resolution, and network accessibility need assessment. If none exist, camera procurement and mounting are part of the Sensor Edge sprint. Unblocked by: a site survey.

4. What is the target platform for the supervisor phone app?
   iOS, Android, or both? An existing mobile device management (MDM) profile in the organisation would simplify deployment significantly. If no mobile infrastructure exists, a web-based alert dashboard may be a lower-friction alternative for v1. Unblocked by: IT and operations stakeholder alignment.