The Synchronization Problem Clinical Research Isn't Watching
By John Oncea, Chief Editor, Clinical Tech Leader
Ask most clinical technology teams what could go wrong with a multi-sensor remote monitoring setup, and you’ll hear about connectivity, battery life, and sensor accuracy. Almost no one brings up timestamps. That’s a blind spot, according to Yasir Shafiullah, a Ph.D. researcher in wireless systems at the University of Oulu’s CWC-RF department, whose analog and RF design background gives him a different lens on decentralized trial data than most clinical operations professionals bring to the conversation.
“Synchronization matters when multiple sensors are collecting data, such as ECG, SPO2, movement, glucose, or temperature sensors, and those sensors are not transmitting at the same time,” Shafiullah said. Individually, each sensor might be functioning perfectly. The problem shows up in the relationships between them.
Why Timing Is A Hidden Layer Of Every Measurement
Every sensor transmission, Shafiullah explained, is anchored to a clock or timestamp, and involves communication most people never see: a sensor sends data, and the receiving system sends an acknowledgment back based on timing. He compared it to the everyday experience of connecting a phone to a Bluetooth speaker; the “connected” confirmation is itself a timing handshake, just one we never think about. Multiply that across four or five sensors on one patient, each with its own transmission schedule, and small delays start to accumulate.
Those delays matter because clinical interpretation often depends on correlating signals, not just collecting them. If an ECG reading and an oxygen saturation reading are meant to reflect the same moment in a patient’s physiology but are actually offset by seconds due to transmission delay, the relationship between those two data points, the thing a researcher or an AI model is actually trying to learn from, becomes unreliable, even though each reading might be technically accurate.
Where The Drift Comes From
Shafiullah pointed to a few concrete sources: sensors that don’t transmit on identical schedules, delays in uploading, and, in a genuinely decentralized, multi-site trial, time zone differences between locations, like a unit operating in Alaska versus one in Texas. None of these are exotic engineering failures. They’re the ordinary behavior of distributed hardware operating independently, which is exactly what a decentralized trial architecture requires.
Asked how common synchronization problems actually are, Shafiullah was candid that this isn’t an area with extensive published data yet: “I do not think it is usually that common... I have not looked deeply into synchronization issues.” That’s more useful than a confident answer either way; it points to a gap in the industry’s own diligence rather than a settled risk. Nobody is watching this closely enough to know how common it actually is.
Why This Compounds With Scale
The synchronization question gets more urgent, not less, as trials add more sensor modalities. A single-sensor trial has nothing to synchronize against. A trial layering ECG, movement, glucose, and temperature data from multiple device manufacturers, increasingly the norm in digital-endpoint-heavy protocols, is asking several independently engineered systems, each with its own transmission logic, to agree on a shared timeline. That agreement isn’t automatic. It has to be designed for.
Practical Questions This Raises For Sponsors And CROs
This is a case where the right diligence question doesn’t currently have an obvious home in most vendor evaluation checklists. It’s worth asking wearable and monitoring vendors directly: how is timestamp accuracy maintained across devices from different manufacturers, what’s the acceptable drift tolerance for a given protocol’s endpoints, and how are transmission acknowledgments logged and audited? For any trial correlating multiple physiological signals, which describes most multi-sensor decentralized protocols, the answer to those questions may matter as much as the accuracy of any individual sensor.
This connects directly to the analog and sensor-quality issues covered in “Why Trustworthy Clinical Trial Data Starts as Analog, Not Digital”: a perfectly synchronized signal from a poorly designed sensor is still bad data, and a perfectly accurate sensor with drifting timestamps is still an unreliable dataset. Both layers have to hold. The next layer, getting that synchronized, accurate signal off the device and across a network reliably, is its own engineering challenge, covered in Wireless Connectivity Is a Data Integrity Issue, Not an IT Issue, coming August 10.