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.
Assumption — timing rule: The 30-second wash window is a design assumption. The actual protocol may specify a different duration, or may require a minimum wash duration (e.g., 20 seconds of hand-rubbing) rather than just a soap dispenser activation. This should be confirmed with the lab's protocol documentation before implementation.
Assumption — alert channel: Supervisor notification via a phone app is assumed. The actual escalation path (SMS, dedicated monitoring screen, integration with an existing incident system) should be confirmed.