EXECUTIVE INTERVIEW - From Data Collection to Data Provenance: Building More Traceable Infrastructure for Decentralized Trials


Key Points

  • Sponsors must be able to trace every data point from the raw signal to the study database, including each transformation along the way.
  • Vendor oversight is built before the trial starts, with audit rights, raw-data access, and update notifications written into the contract.
  • Reusable connected devices carry a service history of firmware, calibration, and maintenance that makes wearable data defensible in an inspection.

Cecilia Xi, VP of Clinical and Scientific Affairs at VivalinkAs decentralized and hybrid clinical trials generate increasingly large volumes of data from wearables, remote sensors, and other digital health technologies, sponsors are facing a more fundamental challenge than simply collecting the data. They must be able to demonstrate where each data point came from, how it was transformed, and whether the underlying record can be reproduced and defended years after a study ends. That places greater emphasis on data provenance, auditability, vendor oversight, and long-term data governance as sponsors build digital infrastructure for clinical research. Reusable connected devices are also adding a new layer of traceability, requiring sponsors to account for device history, firmware changes, maintenance, calibration, and subject assignments over time. Drug Development & Delivery recently interviewed Cecilia Xi, VP of Clinical and Scientific Affairs at Vivalink, on the growing importance of data provenance, traceability, and long-term data governance in decentralized clinical trials.

Let’s start broad: why is data provenance becoming a bigger conversation in decentralized trials than data collection itself?

Sponsors have largely solved collection, which is only one part of data provenance. The data lifecycle is much more complicated with digital health technologies, since the data is flowing from many different sources. The inputs, their various sources, the data pipeline infrastructure, and the final destination of that data are all pieces of the collection puzzle. This complexity of collection requires very clear and detailed records of the data pipeline and the data life cycle for adequate data provenance. Regulators and third-party auditors don’t take a dataset at face value. They expect it to be independently verifiable, requiring the sponsor to show where each value originated, what was done to it, and why anything is missing or imputed. A sponsor that can’t answer those questions has a data integrity problem no matter how well the data was captured, and that puts the endpoint at risk. That risk has grown as wearables and connected sensors moved into decentralized and hybrid trials. Now the number of sources has multiplied and data stopped arriving as a handful of readings taken at a site on a scheduled visit. Due to this complexity, if the data provenance is not well established and validated, you get mismatched or missing data that cannot be readily traced through the chain of custody.

Walk us through what actually happens to patient data between the moment it’s captured on a wearable or remote sensor and the moment it lands in the study database. Where are the points where sponsors typically lose visibility?

The data is captured on the device, transmitted over a connectivity layer, and transformed several times before it reaches the database. A raw signal is converted into a reported measurement, timestamped, reformatted for the receiving system, and often filtered or averaged by an algorithm along the way. Each of those conversions is a point where the sponsor can lose sight of the data, because the record of what the system did to it usually sits with the vendor. Most sponsors can describe the beginning and the end of that path but not the middle, and often no single vendor in the chain has the whole picture either, because each one typically supplies a subset of the data. Continuous data makes that harder. A connected device can produce thousands to millions of data points a day, which rules out checking a sample by hand and forces the auditing to be automated. And because the patient is living a normal life rather than sitting still for a clinician, the stream carries real-world noise (like motion disruption, poor skin contact, periods when the device was taken off, and connectivity drops that surface later as missing values the sponsor still has to account for).

Many sponsors rely on vendor-managed platforms for device data processing and analysis. What does “vendor oversight” actually look like in practice when the sponsor doesn’t control the infrastructure the data moves through?

Regardless of who manages the platform, the sponsor carries full responsibility for data integrity, so most of the oversight has to be built before the trial starts. That means vendor qualification audits and a contract that spells out audit rights, data ownership, sponsor access to raw data, and notification obligations for algorithm updates, firmware pushes, server migrations, and data breaches. It also means scrutinizing the vendor itself, including financial stability, a documented track record with studies of similar scale, encryption in transit and at rest, and standard nonproprietary data formats with API access so the sponsor isn’t locked in. Once the trial is running, oversight becomes a monitoring function, mainly for data quality. As values stream in from a wearable, whether that’s heart rate, activity counts, sleep staging, or ECG traces, they should hit a set of rules before anyone looks at them. Is the value physiologically plausible? Is the timestamp in the expected window? Is the device ID valid and assigned to the right patient? Did the expected volume of data arrive that day, or is there a gap? Periodic checks must confirm what comes out of the pipeline matches what went in, belonging in the same routine. Those checks, and the record of what they catch, are what oversight consists of when the sponsor doesn’t own the infrastructure.

You’ve spoken about the industry shift toward reusable, connected devices as part of a more transparent data infrastructure strategy. How does the reusability of connected devices—generating a continuous usage and maintenance history—factor into traceability and auditability?

Reusable devices generate more history to track, and that history is what makes the data defensible. A disposable worn for seven days never faces a firmware upgrade or a recalibration. A reusable device over the course of, say, 12 months, goes through both, plus repairs, and may be assigned to several subjects in the same trial. That means the record has to carry the device UDI, firmware and software version, calibration status, and maintenance history with timestamps, linked to subject ID, plus a documented reset between subjects so one participant’s data cannot contaminate the next. All of this adds complexity to the traceability, but these factors are also very critical for auditability. That record allows a sponsor the ability to prove the device was working as intended on the day a given measurement was taken, which is the first question an auditor asks about a value that looks wrong. Before choosing, sponsors should weigh whether the device’s service life covers the length of the study. They should also be realistic about training because the history only holds up if sites and patients follow the instructions for use on cleaning, disinfection, and recalibration. An incomplete service history undermines the data it’s supposed to support.

Let’s talk about endpoint validation. When a digital endpoint is derived from raw sensor data through a vendor’s proprietary algorithm, how should sponsors validate and document that transformation so it holds up years later?

Start with version control. The algorithm version, the firmware version, and the parameter configuration behind each transformation should be documented and frozen so the analysis dataset can prove which transformation produced which value. A proprietary algorithm is the harder case, because sponsors cannot get the source code. What they need is a description specific enough to explain the result years later: which raw inputs the algorithm takes, what methodology or model it applies, at what parameter configuration, and what metrics come out the other side. Ideally the sponsor also holds a frozen, read-only version of the algorithm as it ran, so the transformation can be reproduced rather than just described. Validating that transformation is a separate job, and the V3 framework gives sponsors the structure to work through, covering verification that the raw measurement is accurate, analytical validation that the processed output is accurate, and clinical validation that the derived metric is meaningful for the intended population and use condition. That third step is where sponsors most often fall short, and it’s the one that determines whether an endpoint is fit for the purpose of the study. An algorithm validated against a normal adult heart rate of 60 to 100 beats per minute doesn’t carry over to pediatrics, where normal is typically above 100, so the same output has to be validated again in the population being studied.

Inspection readiness is a recurring theme in the pitch. What does an inspection-ready decentralized trial data infrastructure actually look like, in concrete terms?

The test is whether an inspector can take a single value in the final dataset and walk it back to the raw signal it came from, in one sitting, without anyone from the original study team explaining it. Meeting that test takes audit trails that cover data attributes and not just the values themselves, logs of every creation, access, modification, and deletion, and automated reporting that flags missing data or periods when a device was not worn or not connected. It also takes data encrypted in transit and at rest, authentication that meets standard requirements, and documented system validation showing the software works as intended. And the access has to be ready, meaning verified read-only access an auditor can use the day they arrive, rather than assembled once they ask for it.

Zooming out — this data may need to be traced or reproduced not just by regulators, but by future partners or acquirers. How should sponsors be thinking about long-term data governance as a strategic asset, not just a compliance requirement?

It’s a mindset shift from reactive to proactive. A reactive sponsor works the compliance checklist to avoid penalties and clear the regulatory bar. A proactive sponsor treats the trial data as a scientific asset for its therapeutic area, which changes decisions all the way back at study design, well before anyone is screening vendors against a finished protocol. In practice, that means standardized, nonproprietary data formats so results can be reanalyzed and used across trials, a centralized repository such as a cloud-based data lake, and a complete copy of the full dataset pulled down as soon as the study closes. That last piece is what protects a sponsor in front of partners and acquirers. If a vendor goes out of business or discontinues the product, a sponsor without ownership can lose access to its own historical evidence. Datasets get bought and sold, and one with gaps in its traceability loses value quickly once someone runs diligence on it. This is what we build for at Vivalink, since a sponsor shouldn’t need its vendor still around to read its own data.

Vivalink logo

Cecilia Xi is VP of Clinical and Scientific Affairs at Vivalink.