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
- List every function that depends on the vendor’s cloud service. Mark each one as clinical, operational, or reporting.
- Confirm that the device’s essential function continues with the cloud service unreachable. Ask the vendor to demonstrate it.
- Confirm which records the device journals locally while the service is unreachable, and for how long.
- Confirm that device identity, certificates, and user sign-in keep working without the vendor’s cloud.
- Confirm that no license check disables the device or a clinical function when the service can’t be reached.
- 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
- Confirm that the export the Device Data Rights Checklist requires includes history, audit logs, configuration, and derived results, not just the current view.
- Run a test export before go-live, and load it into another system. Repeat the test once a year.
If the service ends
- Record the contractual notice period before the vendor retires the service or the product line.
- Record the transition assistance the vendor owes, and how the institution runs the functions it needs locally or on another platform.
- 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.
