Valley Community Health: Cold-Chain Monitoring Design Review
Valley Community Health is designing temperature monitoring for 34 rural clinics, each holding 12 vaccine lines in 400-litre refrigerators plus one walk-in cold room. The proposed design uses BLE loggers reporting every 5 minutes to a clinic gateway, then cellular to a cloud dashboard with SMS escalation to on-call nurses. Requirements are: excursion alert within 10 minutes, three-year audit retention, 8-hour ride-through of mains outages, no on-site IT staff, and remote firmware update. Six clinics have their cold room in a basement with no cellular signal; two of those lose mains power three to four times a month. The draft uses one shared gateway password across all sites, loggers with a 10-minute advertising interval, and a cloud-only rules engine. The programme manager wants a design review before the 200-unit purchase order is placed.
1. The draft design cannot meet the 10-minute alert requirement during a WAN or mains outage. Redesign the edge and backhaul layers to close that gap, and justify each change.
Read the worked answer
The alert path currently has three single points of failure: the radio link to the cloud, power, and the cloud rule engine itself. Each must be removed.
1. Move the rule engine to the edge. The gateway must hold the temperature thresholds for its own fridges and raise an excursion locally. With a cloud-only engine, every WAN outage is a silent blind spot of unbounded duration.
2. Give the gateway two independent alert paths. The primary is cellular data to the cloud. The secondary should be an SMS sent directly by the gateway's own modem, not routed through the cloud. Independently powered, independently addressed, and it works when the cloud or the WAN does not.
3. Power. An 8-hour requirement with outages of three to four per month means a UPS sized on measured load, not nameplate: 8 hours of gateway plus modem at, say, 6 W consumed is roughly 48 Wh, so specify 100 Wh of usable capacity for margin and battery ageing. Loggers must also ride through; they should keep sampling and buffer, then backfill on recovery.
4. Basements. BLE through two concrete slabs will not reliably reach a ground-floor gateway. Either site the gateway in the basement with a cellular antenna run to the surface, or use a lower-frequency link (sub-GHz) for those six sites. The antenna run is usually cheaper and easier to maintain.
Finally, correct the 10-minute advertising interval - it is slower than the 5-minute sample rate and alone breaks the 10-minute requirement.
2. Evaluate the logging interval, buffering and alert escalation choices. What would you specify instead, and what trade-off are you accepting?
Read the worked answer
Interval. A 10-minute advertising interval against a 5-minute sample rate means the newest value can be 10 minutes old before it is even transmitted, and the 10-minute alert budget is already spent before any network delay. Specify an advertising interval of 30-60 seconds so several advertisement events occur per sample; the gateway filters duplicates. The trade-off is radio duty cycle and therefore logger battery, which is why the loggers should use connectionless advertising rather than maintaining a connection.
Buffering. Loggers must store at least 72 hours at the sample rate, with timestamps, and backfill on reconnect. Without this, a WAN outage produces a gap in the audit record even though nobody was at risk - which is exactly what an inspector will ask about.
Escalation. Acknowledged, tiered escalation: nurse on call at 0 minutes, clinic lead at 15, district pharmacist at 30, with automatic re-escalation if unacknowledged. A single SMS to one phone is not an alerting system; phones are silent, out of coverage, or on leave. Every alert must be logged with delivery, acknowledgement and action, because the three-year retention requirement covers the response, not just the temperature.
Trade-off accepted. Shorter intervals and local buffering cost battery and firmware complexity, and I would accept a two-year logger battery instead of five to get an auditable, sub-10-minute alert path.
3. Identify the security weaknesses in the draft and set out a device-lifecycle security design that works with no on-site IT staff.
Read the worked answer
The shared gateway password is the critical defect. One leaked credential compromises all 34 sites, and it cannot be revoked without a site visit to every clinic. The design also implies remote firmware update with no stated signing or rollback, which is a remote bricking risk.
Device identity. Each logger and gateway gets a unique credential provisioned at manufacture - a per-device key or certificate stored in a secure element, never a printed password. Gateways should authenticate to the cloud with mutual TLS, and loggers to the gateway with per-device keys so a rogue device cannot inject false readings that mask a real excursion.
Firmware. Images signed by the vendor and verified by the device before install; A/B partitions with automatic rollback if the new image fails a health check; staged rollout at 1%, then 10%, then the fleet. With no on-site staff, a bad update is a truck roll multiplied by 34.
Gateway hardening. Disable unused ports and services, no default accounts, management only over the encrypted tunnel, and network segmentation so compromised loggers cannot reach clinic IT systems.
Lifecycle. Inventory every device with model, firmware and credential; rotate credentials on a schedule with overlapping validity so nothing drops offline; revoke on decommission; retain security and alert logs for the three-year audit window. Plan for the day the vendor stops issuing firmware - require a support commitment and escrow terms in the contract.