Test a Vendor’s AI-Ready Claim Against Twelve Capabilities
AI-Readiness Procurement Checklist
Companion to Medical Device Connectivity · Updated 2026-09-29
Use this when a vendor calls a device AI-ready, or when you plan to let an AI system observe or assist with a device’s work. Buyers ask the questions, and builders can use them as a design target; “An AI-Ready Device Is Mostly a Well-Engineered, Interoperable Device” works it on the automated probe reprocessor. Ask the same questions of an AI-enabled imaging system, a fetal monitoring system, or a laboratory analyzer.
An AI-ready institutional device is one that can do the twelve things below, within appropriate governance. Having an interface, uploading to the cloud, supporting HL7 FHIR, or shipping an AI feature doesn’t count by itself. Ask each question. Accept only evidence the team can see. Record the evidence. Mark each capability shown, partly shown, or not shown.
The AI-Readiness Procurement Checklist: twelve capabilities, each phrased as a question the vendor answers with evidence.
| # | Capability | Question the vendor answers with evidence | Evidence seen | Finding |
|---|---|---|---|---|
| 1 | Identify itself | Does the device present a unique, persistent identity on every interface and in every record? | ||
| 2 | Describe its relevant capabilities | Can a system ask the device what it measures, what it does, which interfaces it supports, and which software version it runs? | ||
| 3 | Expose current state | Can an authorized system read the device’s current operating state (running, idle, alarming, faulted, in maintenance) without a person reading the screen? | ||
| 4 | Expose meaningful events | Does the device emit events as they happen (cycle started, completed, or failed; setting changed; alarm raised; override used) through a documented interface? | ||
| 5 | Preserve provenance | Does each record carry its source device, time, units, quality, device state, calibration, configuration, transformation history, and whether it was measured, entered, inferred, or derived? | ||
| 6 | Identify relevant context | Does each record carry the patient, specimen, or workflow association that gives it meaning, and show when that association is missing? | ||
| 7 | Expose data quality and assurance information | Can a consumer see signal quality, calibration status, self-test results, software version, and the age of each value alongside the data? | ||
| 8 | Operate safely when AI services are unavailable | When every AI service is unreachable, does the device keep its essential function, and does the workflow have a defined path? Show us. | ||
| 9 | Permit authorized machine-to-machine access | Can an authorized system authenticate and read data without a person signing in, and can the institution grant and revoke that access? | ||
| 10 | Log consequential automated actions | Does the device record every action taken on an automated recommendation or command, with its source, its time, and the person who approved it where approval applies? | ||
| 11 | Support lifecycle management | Can the institution inventory, configure, update, and retire the device through a documented interface? | ||
| 12 | Support after-the-fact reconstruction | Using exported records alone, can an investigator reconstruct what the device did, in order, with its state and context at each step? |
Most of these questions are ordinary systems engineering and interoperability questions. A failure on items 1 to 7 means an AI system working with the device’s data has to guess. A failure on items 8 to 12 means AI assistance around the device can’t be governed, so keep AI at observation until the vendor closes the gap. Put each gap into the contract as a dated roadmap commitment with a remedy, or record an exception under the No Connectivity, No Purchase Checklist. No answer on this checklist justifies moving AI toward autonomous control of a safety-critical function.