Write Fleet Capability Into the Product Requirements

Fleet Management Requirements Checklist

Use this when writing product requirements, so fleet capability ships with the device. Product managers and systems engineers own it, with field service; “Manufacturers Should Build Devices to Be Managed as a Fleet” works it on the smart infusion pump fleet.

The Fleet Management Requirements Checklist: what the product must do so an institution can run all its units as one fleet.

Requirement	Pass when	Status
Discovery	The institution can find every unit on its network, including units in storage or out for repair, and match it to an inventory record.
Inventory	Each unit reports its identity, model, hardware revision, installed software and configuration versions (not just the versions it was sent), location, and last check-in time in a form the computerized maintenance management system (CMMS) can take in.
Provisioning	A new unit joins the fleet with its identity, certificates, and configuration without hand entry at the device.
Configuration	The institution can set, compare, and restore configuration across units, and the device records every change.
Policy	The institution can apply a policy (drug library, alarm limits, imaging protocols, security settings) to a group of units at once.
Certificate rotation	Certificates renew before they expire, without taking units out of service.
Updates	The institution can see which units need which update and schedule each installation.
Staged rollout	An update can go to a named subset first, with a hold point before the rest of the fleet.
Rollback	Any unit can return to a previous signed, authorized release, and the fleet view shows that it did.
Maintenance	Maintenance status and service history are readable per unit and can feed the CMMS.
Vulnerability response	The institution can list every unit affected by a vulnerability within the fleet view.
Retirement	A unit leaves the fleet with its data retrieved, its data removed, and its certificates revoked.

Requirement

Pass when

Status

Discovery

The institution can find every unit on its network, including units in storage or out for repair, and match it to an inventory record.

Inventory

Each unit reports its identity, model, hardware revision, installed software and configuration versions (not just the versions it was sent), location, and last check-in time in a form the computerized maintenance management system (CMMS) can take in.

Provisioning

A new unit joins the fleet with its identity, certificates, and configuration without hand entry at the device.

Configuration

The institution can set, compare, and restore configuration across units, and the device records every change.

Policy

The institution can apply a policy (drug library, alarm limits, imaging protocols, security settings) to a group of units at once.

Certificate rotation

Certificates renew before they expire, without taking units out of service.

Updates

The institution can see which units need which update and schedule each installation.

Staged rollout

An update can go to a named subset first, with a hold point before the rest of the fleet.

Rollback

Any unit can return to a previous signed, authorized release, and the fleet view shows that it did.

Maintenance

Maintenance status and service history are readable per unit and can feed the CMMS.

Vulnerability response

The institution can list every unit affected by a vulnerability within the fleet view.

Retirement

A unit leaves the fleet with its data retrieved, its data removed, and its certificates revoked.

Each unit must also expose these through a documented interface, so healthcare technology management and field service can support it without walking to it:

Health and performance
Logs
Configuration and software version
Connectivity state and synchronization state
Self-test results
Storage condition
Security events

When the product doesn’t meet a requirement, staff at every customer site do that work by hand, often in a spreadsheet; “Devices That Can’t Report Cost Hospitals Staff Time That Budgets Miss” describes that work. Every unchecked item goes on the roadmap with a date, or into the documentation as a known gap.