What a continuous temperature monitoring system must do

WHO Technical Supplement 16 describes the design and qualification of monitoring systems for fixed storage areas. The functional requirements are simple to state: measure the right thing, in the right place, often enough; tell someone when it goes wrong; keep the record.

Requirement checklist

• Calibrated sensors with documented uncertainty and calibration interval.
• Sampling interval justified against product limits and expected excursion dynamics.
• Local buffering so data survive network outages; battery backup for power loss.
• Alarms with escalation, acknowledgement and record of response.
• Access control, audit trail, time synchronisation.
• Reports for periodic review and for excursions.
• Validated software with change control.

Qualification of the system follows IQ/OQ/PQ: installation checks, alarm and failure-mode tests, then performance under routine use.

Choosing the sampling interval

The interval is a risk decision, and WHO Technical Supplement 16 asks for it to be justified rather than defaulted. The test is simple: could an excursion that matters to the product start and finish between two readings? A cold room that takes two hours to drift out of range is safe at 15-minute logging. A shipper box that can cross 8 °C in eleven minutes is not, and a 30-minute interval there does not blur the excursion, it deletes it.

A workable rule is to log at least four or five times within the shortest excursion you need to detect, then confirm it against a real trace rather than a rule of thumb. Faster logging costs storage and nothing else; missing the event costs the batch.

Alarms that actually reach someone

Most monitoring failures found at inspection are not sensor failures. They are alarms that fired at 02:00 into an unmonitored inbox, or an alarm delay set so long that the notification arrived after the product was already lost. Three settings decide whether an alarm is useful:

What Annex 11 adds once the system is computerised

A monitoring system is a computerised system, so Annex 11 applies on top of the functional requirements. In practice that means user accounts that identify individuals rather than a shared login, an audit trail that cannot be switched off, time synchronisation to a single source so that a sensor record and an alarm record can be placed in the same order, backups that have been restored at least once to prove they work, and a supplier assessment on file for the software.

Two of those are the common findings. Shared logins make an audit trail worthless, because every entry names the same account. And an untested backup is an assumption, not a control.

Surviving failure

• Local buffering: the sensor or gateway keeps recording when the network drops, and backfills when it returns. Without it, a network outage becomes a hole in the record that has to be explained.
• Battery backup sized to the realistic outage, with the battery state itself monitored — a dead backup battery is invisible until the day it is needed.
• A heartbeat or watchdog, so that silence from a sensor raises an alarm. A failed sensor that simply stops reporting looks identical to a room that never left range.
• Documented behaviour on restart: does the system resume logging automatically, and does it reissue alarms that were active when it went down?

Qualification follows IQ/OQ/PQ: installation checks, then alarm and failure-mode tests against every requirement above, then a period of routine use reviewed for gaps, nuisance alarms and unacknowledged events.