Drug Library Update, Wi-Fi Architecture, and a Three-Week Deadline

Reject the flat shared-PSK SSID. A shared secret is not a device identity: it cannot be rotated per device, every holder of the key can reach every pump, and a single compromised laptop is a path to the whole fleet. On a device that delivers vasoactive drugs, the credible worst case is unauthorized or corrupted library content, or a denial-of-service during a shift. The worm incident last year is exactly what segmentation is supposed to contain.

Recommended target state:

• A dedicated medical-device VLAN and SSID, with ACLs that permit only the update server, the pump management server, and required management traffic. No internet egress, no guest route, no lateral path to clinical workstations.
• 802.1X with per-device certificates (EAP-TLS) on the generation that supports it, and NAC profiling on the generation that does not.
• Wireless IDS monitoring and disabled unused switch ports in pump storage and biomedical areas.

If the older generation truly cannot authenticate, do not fall back to a shared key across the fleet. Use MAC-based admission on an isolated VLAN with NAC profiling and explicit, documented, time-limited risk acceptance by the CISO and the medical director, with a compensating control such as scheduled key rotation and monitoring of the pump server logs. Put a fleet-replacement date in the capital plan.

On schedule: the three-week deadline is real because the library change addresses a patient-safety near-miss, but it does not justify a weaker architecture. Sequence the work so pharmacy can go live on the corrected library using a properly segmented pilot path, and treat full-fleet connectivity as a separate deliverable.

The update changes hard and soft dosing limits, so it is a clinical change, not an IT patch.

Before deployment

• A change request with a risk assessment covering wrong-library, partial-update, and loss-of-connectivity scenarios.
• Pharmacy double-checks the library content against the order sets and signs off on the concentration and the pediatric limits; the checksum or signature of the file is verified.
• Test on at least two pumps per model with representative drugs: confirm hard limits cannot be overridden, confirm soft-limit behavior, confirm the version string on the device, and confirm that a pump dropped mid-update fails safe rather than partially loading.

Deployment

• Pilot in one unit (about 10 pumps), monitor for one week, then 50%, then the remainder.
• Stage by unit so out-of-service time is predictable; schedule around peak medication times; keep manual programming as the documented fallback.
• Confirm in the configuration management database which serial numbers carry which version - a mixed fleet is acceptable only if the version is known per pump.

Rollback

• Keep the prior library on the server and the ability to reinstall it remotely; define who can authorize rollback and the clinical criteria for doing so (for example, a wrong-limit report from a unit).

After

• Re-measure the programming discrepancy rate the pharmacy quoted (2.1%) to see whether the update changed it, and feed the result into the auto-programming decision.

Auto-programming trades a manual transcription error for an interface and patient-identification error. It is worth doing - it attacks the 2.1% discrepancy rate - but only when the failure modes are controlled.

Prerequisites:

• Positive patient identification that links the order to the pump at the bedside, not to a room or a bed number.
• A validated mapping table from orderable to library entry, tested with dummy patients and deliberately mismatched orders, so the system fails to manual programming rather than to a wrong infusion.
• A visible confirmation at the pump that the nurse must acknowledge; alerting that is specific enough not to be dismissed reflexively.
• Interface-engine monitoring with alerting on message failures, and a downtime procedure that all bedside staff can execute.
• The cybersecurity review that this project needs anyway - auto-programming adds an integration engine and another path into the pump, which raises the consequence of the shared-key problem described above.

Sequencing: do not enable auto-programming until the library update has been stable on the full fleet for a defined period and the version is known per pump. An interface that maps orders into a library that is still being corrected multiplies the error surface.

Finally, keep independent double-checks for high-alert drugs. Automation reduces transcription errors; it does not replace the check that catches a wrong-but-valid order.