No Connectivity, No Purchase Checklist
Use this for every institutional device that does meaningful repeated work, before it reaches a shortlist. It tests the presumption that such a device comes with a machine-readable interface, a lifecycle-management strategy, and evidence export, unless a documented exception says why not. Procurement sends it to the vendor, and HTM, information technology (IT), security, and the clinical or process owner review the answers; “Hospitals Should Make Connectivity the Default for Institutional Device Purchases” works it on the automated probe reprocessor. Send the same questions for a CT scanner, a hematology analyzer, an electrosurgical unit, or a smart bed.
Send the seventeen questions to the vendor in writing. Require a written answer to each question. Accept “not applicable” only with a reason. Score each answer in the last column as acceptable, not acceptable, or not applicable with a reason.
The No Connectivity, No Purchase Checklist: seventeen questions the vendor answers in writing before the device reaches a shortlist.
| # | The vendor must explain | Vendor’s written answer | Acceptable? |
|---|---|---|---|
1 |
What machine-readable data does the device emit? |
||
2 |
What machine-readable commands does it accept, if any? |
||
3 |
What device state can the institution observe? |
||
4 |
How does the device identify itself? |
||
5 |
How does the device handle patient or specimen context, where relevant? |
||
6 |
How does the device represent the provenance of each event? |
||
7 |
Which standards or application programming interfaces (APIs) does the device support? |
||
8 |
How does offline operation work? |
||
9 |
How does synchronization work after reconnection? |
||
10 |
How are updates delivered? |
||
11 |
How are vulnerabilities managed? |
||
12 |
How are logs exported? |
||
13 |
How is fleet inventory maintained? |
||
14 |
How is end of life handled? |
||
15 |
What data can the manufacturer access? |
||
16 |
What data can the institution export? |
||
17 |
What happens if the vendor’s cloud service disappears? |
A vendor can answer “none” to a capability question and still pass, as long as the answer explains why the work doesn’t need it. When the institution decides to buy a device that doesn’t meet the presumption, the team completes the exception record before the purchase order goes out.
The exception record: completed and signed before the institution buys a device that doesn’t meet the presumption.
| Field | Entry |
|---|---|
Device class, and the device (type, model, software version, number of units) |
|
Checklist items not met (by number) |
|
Reason for the exception: connectivity isn’t required (the work the device does, and why the institution doesn’t need machine-readable evidence of it); clinical performance outweighs the connectivity gap; or no bidder meets the class minimum |
|
Roadmap commitment, where one applies (the capability, the delivery date, and the remedy if the date slips) |
|
What the institution will rely on instead (paper log, printout, manual entry) and who keeps it |
|
Who approved (name, role, date) |
|
Review date |
A blank answer, or one that points to a sales conversation instead of a document, fails its item. Don’t buy a device with failed items and no signed exception record. With a signed exception record, the institution buys the device with its gaps written down, and the review date brings the question back before the next purchase.