The Vendor Questions Most Clinical Tech Buyers Forget To Ask

By John Oncea, Chief Editor, Clinical Tech Leader

Most vendor evaluations for remote monitoring and decentralized trial technology start with the same question: what AI does this platform use? After spending time with Yasir Shafiullah, a Ph.D. researcher in RF and analog IC design at the University of Oulu’s CWC-RF department, with 11 years of experience designing the sensors and wireless hardware underneath consumer and industrial devices, I’ve come to think that’s close to the least useful question a sponsor or CRO can ask first.

The reason is straightforward once you’ve walked through the technology stack the way Shafiullah described it across our conversation. By the time AI ever touches a dataset, a physical sensor has already measured a physiological signal, an analog front end has already converted it, a wireless protocol has already transmitted it, and a network has already delivered, or failed to fully deliver, the result. Every one of those steps can introduce error that no algorithm downstream can detect or correct. If a vendor conversation skips straight to analytics, it skips the layers where trustworthy data is actually won or lost.

This checklist pulls together the practical questions that conversation surfaced, organized by where in the stack they apply. It’s meant to sit alongside the deeper engineering discussion in the four companion articles in this series, as something you can bring directly into a vendor call.

Sensor And Hardware Questions

Start with how the device was validated, not what it claims to measure. Ask what temperature and environmental range the sensor’s analog front end has actually been tested across. Shafiullah was direct that hardware validated in a lab at room temperature doesn’t tell you whether it performs reliably in a decentralized unit exposed to real seasonal extremes. “Bad design is bad design, and we cannot fully compensate for it later,” he said, which makes this a pre-deployment question rather than something to troubleshoot after the fact.

Ask, too, how the sensor samples data before transmission, whether it sends raw single-point readings or averages over an interval, which Shafiullah described as generally more dependable, and what repeatability testing has been done. His practical definition of a trustworthy sensor wasn’t about brand reputation; it was whether the same measurement, taken under the same conditions, produces the same result. If a vendor can’t answer that directly, it’s worth treating as a gap rather than a formality.

Synchronization Questions

This is the layer Shafiullah suggested gets the least attention industry-wide, and it only matters more as protocols add sensor types. If your trial is collecting ECG, movement, glucose, or other multi-modal data from a single patient, ask how the vendor maintains timestamp accuracy across devices, especially if those devices come from different manufacturers. Ask what the acceptable drift tolerance is for your protocol’s specific endpoints, and how transmission acknowledgments are logged. A dataset can look complete and still have signals that don’t actually correspond to the same moment in time.

Connectivity Questions

Move past “is there a connection” and ask about packet loss thresholds, the point at which a signal, even if technically received, becomes too degraded to decode reliably. Ask how the system handles multipath interference in built-up or reflective environments, and what happens operationally when a Bluetooth-connected wearable drifts out of range of its receiver, which Shafiullah noted is an expected limitation rather than a malfunction. For genuinely remote or rural trial sites, ask directly what backup connectivity options exist, satellite services among them, for locations where standard Wi-Fi or cellular coverage can’t be counted on.

Battery And Power Questions

Every battery-life decision is also a data-quality decision, even when it isn’t marketed that way. Ask what tradeoffs were made to extend battery life, reduced sampling frequency, lower transmission power, less on-device processing, and how those tradeoffs affect the completeness or resolution of the data your trial actually needs. A device optimized for a week of battery life on a fitness app may not sample often enough for a clinical endpoint that depends on catching transient events.

Data Integrity And Validation Questions

Separate availability from integrity explicitly in the conversation. Ask how the vendor distinguishes a complete data set from a dependable one, and what feedback loop or validation process catches data that’s technically present but compromised by patient movement, poor skin contact, or a sensor removed and reapplied incorrectly. Shafiullah was candid that this can’t be fully automated away: “We cannot automatically guarantee that the data we receive is valid. Problems can come from the network, the device, or human behavior.” Ask what human review still sits in that loop, and where.

AI Questions, Asked Last, On Purpose

Only after the above is it worth asking about AI. And even then, the more useful question isn’t what the AI does, but for what it’s being asked to compensate. Ask specifically how the platform’s AI or analytics layer handles known sensor errors versus genuine physiological variation and be skeptical of any answer suggesting AI can meaningfully correct for bad hardware or connectivity data after the fact. It can’t. Shafiullah was clear that AI’s real value sits in validation and anomaly detection on top of trustworthy data, not as a substitute for getting the earlier layers right.

Two Non-Technical Questions Worth Keeping

Shafiullah’s own advice to sponsors evaluating a new decentralized unit didn’t stop at hardware. He emphasized confirming realistic connectivity and latency at the actual deployment site, not just theoretical coverage maps, and making sure staff are properly trained on device handling and data transmission before go-live. Both are easy to treat as logistics rather than data-quality issues. In his experience, they’re not separable.

Using This List

None of these questions require a vendor to hand over proprietary engineering specs. They require a vendor to demonstrate they’ve thought about the same stack Shafiullah walked through: sensor, analog front end, synchronization, wireless transmission, power, and only then, analytics. A vendor who can answer confidently at every layer is a different proposition than one who can only speak fluently about their dashboard.

This checklist draws on the deeper technical discussion in the other four articles in this series: Why Trustworthy Clinical Trial Data Starts as Analog, Not Digital, The Synchronization Problem Clinical Research Isn’t Watching, Wireless Connectivity Is a Data Integrity Issue, Not an IT Issue, and What AI Can’t Fix in Decentralized Clinical Trial Data. Read together, they make the case that vendor diligence for decentralized trial technology needs to start earlier in the stack than most current evaluation frameworks do.