Get Every Cloud Exit Protection Into the Contract

Vendor Cloud Exit Checklist

Companion to Medical Device Connectivity · Updated 2026-09-29

Use this whenever any function of a device, or any of its data, lives in a service the vendor hosts, such as remote monitoring, an image archive or viewer, a drug-library server, fleet analytics, or remote service. Use it before signing, and again at every renewal. IT, HTM, and the clinical owner complete it together; “Hospitals Should Make Connectivity the Default for Institutional Device Purchases” works it on the bedside monitor’s vendor-hosted surveillance service.

Don’t assume any law gives you these protections. Get each one in the contract. Before go-live, test each one that can be tested.

While the service runs

  1. List every function that depends on the vendor’s cloud service. Mark each one as clinical, operational, or reporting.
  2. Confirm that the device’s essential function continues with the cloud service unreachable. Ask the vendor to demonstrate it.
  3. Confirm which records the device journals locally while the service is unreachable, and for how long.
  4. Confirm that device identity, certificates, and user sign-in keep working without the vendor’s cloud.
  5. Confirm that no license check disables the device or a clinical function when the service can’t be reached.
  6. Confirm which workflow takes over from any cloud-hosted alarm, notification, or surveillance function during an outage, and who staffs it. Confirm how the receiving side detects that a device’s feed has stopped and whom it alerts.

Getting the data out

  1. Confirm that the export the Device Data Rights Checklist requires includes history, audit logs, configuration, and derived results, not just the current view.
  2. Run a test export before go-live, and load it into another system. Repeat the test once a year.

If the service ends

  1. Record the contractual notice period before the vendor retires the service or the product line.
  2. Record the transition assistance the vendor owes, and how the institution runs the functions it needs locally or on another platform.
  3. Record what happens to the service and the data if the vendor is acquired or exits the market.

A function that fails an item in the first group stops working when the vendor’s service is unreachable. Before go-live, either the vendor removes that dependency, or the institution designs and staffs the downtime workflow for it.