Decentralized clinical trials: managing data integrity risks

When a Phase III oncology protocol sends its endpoints home — straight to a patient’s living room, a kitchen table, or a tablet propped against a pillow — something quietly changes about what sponsors owe regulators, monitors, and the people who volunteered for the trial. The geography of a study has moved. The obligations have not.

Across the industry, decentralized clinical trials (DCTs) are changing who collects data, when it is collected, and where the underlying observation takes place. Regulators have responded with a consistent message: decentralization is a model of execution, not a renegotiation of accountability.

That message matters because the volume and ambition of decentralized elements have grown faster than the operating discipline around them. The U.S. Food and Drug Administration’s final guidance, Conducting Clinical Trials With Decentralized Elements, finalized in September 2024, and the European Medicines Agency’s Guideline on computerised systems and electronic data in clinical trials from March 2023 approach the issue from different directions but arrive at the same destination. Data captured in a participant’s home — through eDiaries, wearables, telehealth visits, or mobile nursing — must satisfy the same integrity standards as data captured at an investigator site.

The principle sounds administrative until we remember what is actually at stake: a patient who consented to participate must be protected by data they — and we — can rely on.

The Regulatory Reality: Sponsor Accountability in Decentralized Models

It is tempting to read the rise of decentralized models as a relaxation of oversight. In practice, the opposite is true. The FDA’s 2024 guidance makes clear that decentralized trial elements do not lessen sponsor responsibilities for participant safety, trial integrity, data quality, or regulatory compliance under 21 CFR Part 312 for drug trials or Part 812 for device trials. The EMA’s computerized systems guideline places the same expectation within the broader framework of ICH E6(R3) Good Clinical Practice.

What changes is the surface area of the sponsor’s responsibility.

When an endpoint moves from a clinic’s calibrated sphygmomanometer to a participant’s own blood pressure cuff, the sponsor inherits everything that comes with that device: its accuracy, its calibration history, its firmware version, its cybersecurity posture, the contract with its manufacturer, and the audit trail that proves how the measurement was produced and handled. Decentralization does not distribute accountability across the vendor stack. It multiplies the number of places where accountability must be demonstrated.

Decentralization changes how we reach patients, but it does not change what we owe them: data they can trust and oversight we can defend.

We have seen sponsors approach this as a procurement question rather than a clinical one: who supplies the platform, who prices the wearables, who manages the home-health network. That framing misses the point. Every one of those vendors is a node in the sponsor’s own quality system, and every one of them may become relevant during an inspection.

The ACT EU recommendation paper from December 2022 makes this practical implication explicit in the European context by highlighting the need for contingency planning around critical-to-quality decentralized elements. Regulators are not asking sponsors to abandon flexibility. They are asking sponsors to be deliberate about how that flexibility is controlled.

A DCT therefore needs a clear chain of responsibility before the first participant is enrolled. The sponsor should be able to explain:

• which party owns each data-generating activity;
• who is responsible for training participants and field personnel;
• how device suitability and calibration are established;
• how deviations, missing data, and technical failures are recorded;
• which system is the source for each critical data element;
• how the sponsor will access records if a vendor changes, fails, or exits the study;
• and how safety signals move from a remote interaction into the sponsor’s medical review process.

The answer cannot simply be that a contract research organization or technology vendor manages the activity. Outsourcing a task does not outsource the sponsor’s responsibility for understanding whether the task is being performed in a way that preserves participant protection and data reliability.

Navigating ALCOA++ Principles in Remote Data Collection

If sponsor accountability is the legal frame, ALCOA++ is the operational one. The standard — Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available — predates decentralized trials by years. The EMA guideline on computerized systems and electronic data brings these principles directly into the remote-data conversation, while the FDA’s decentralized guidance connects them with expectations under 21 CFR Part 11 and ICH E6(R3).

Translated for a working sponsor team, ALCOA++ asks several practical questions about every data point that leaves a clinic:

• Attributable: can the measurement be traced unambiguously to the participant, the person performing the activity, and the device or system that recorded it?
• Legible: can the record be read and interpreted throughout its retention period, including after data migration or system changes?
• Contemporaneous: was the information captured when the observation occurred, or could it have been entered later from memory?
• Original: is the source data preserved, or is the sponsor seeing only a derived summary?
• Accurate: are the device, method, units, and transcription processes suitable for the intended endpoint?
• Complete and consistent: are required fields, corrections, missing observations, and related metadata handled coherently?
• Enduring and available: will the record remain intact, recoverable, and accessible after vendor transitions, platform updates, or decommissioning?

In a fully paper-based environment, these questions appeared to have a straightforward answer: a nurse wrote an observation in a binder, dated it, and signed it. That model had its own weaknesses, but the evidence trail was visible in one place. In a decentralized model, the answer is only as strong as the combined audit trail across the software, device, service provider, and study team.

That is why moving from paper clinical outcome assessments to validated electronic clinical outcome assessments (eCOA) is not merely a technology upgrade. It can be an important operational expression of ALCOA++ in a distributed environment. Properly validated eCOA platforms can mitigate classic paper-related risks such as illegible handwriting, incomplete contemporaneous recording, and limited visibility into when an entry was made. They may also support more consistent prompts, controlled workflows, and traceable corrections.

But validation does not, by itself, prevent retrospective entries or guarantee that every timestamp reflects the moment an underlying experience occurred. A participant may complete an assessment late, use a device incorrectly, share access credentials, or encounter a synchronization problem. A system may record the time of entry without proving the time of the clinical event being reported. Additional controls remain necessary: clear protocol instructions, participant training, role-based access, audit-trail review, exception handling, device controls, and predefined approaches to late or missing assessments.

The platform provides the substrate. The study team still has to design the protocol on top of it.

That distinction is important when sponsors evaluate vendor validation packages. A system can be technically validated for its intended functions and still be poorly suited to a particular endpoint or participant population. The relevant question is not only whether the software works as designed. It is whether the design, configuration, user behavior, and study procedures together produce data that are fit for the protocol’s purpose.

Mitigating Variability in eCOA and Participant-Reported Outcomes

Here is where the warmth of the model meets the friction of the data.

A participant who completes a patient-reported outcome on their own phone, in their own home, at 11 p.m. after a difficult day, produces a different kind of evidence from one who completes it in front of a research coordinator in a quiet clinic room. Both may be valid in context. Neither is automatically more reliable than the other. But they are not interchangeable without considering the conditions under which the assessments were produced.

This is the variability problem that repeatedly appears in DCT operations. Remote participant-completed assessments may be affected by device type, connectivity, timing, fatigue, accessibility settings, household interruptions, and the participant’s understanding of the instructions. Third-party mobile health providers may add another layer of variability when they have limited experience with clinical research procedures.

Where the meaningful endpoint depends on the patient’s lived experience, the protocol’s tolerance for that variability is, in some sense, the protocol’s tolerance for the disease itself. The objective is not to remove every trace of real-world variation. It is to distinguish clinically meaningful variation from variation introduced by an uncontrolled process.

Several controls are particularly useful.

• Device control. Bring-your-own-device (BYOD) approaches expand reach but introduce heterogeneity in screen size, operating system, accessibility settings, battery life, and user behavior. Provisioned medical-grade sensors reduce some of that heterogeneity but create an additional logistics and support layer. Neither approach is universally correct. The protocol should make the choice deliberately and document its implications in the data management plan.
• Training and prompts, not just instruction. Participants who understand why a daily eDiary entry matters — and how it connects to the endpoint — are better positioned to complete it consistently. Training should cover the assessment itself, the relevant time window, what to do when a response is missed, how to report technical problems, and when a symptom requires immediate contact with the study team. A short, human-voiced tutorial is often more usable than a lengthy reference document, but it should not replace protocol-specific documentation.
• Limits on free text, structure where appropriate. Open-ended fields invite variability in interpretation and coding. Where the protocol can use a validated numeric rating or structured response, it usually should. Where the patient’s narrative is itself clinically important, structured choices should be paired with clear instructions about the reporting period and the meaning of terms such as “today,” “since the last entry,” or “usual symptoms.”
• Language and accessibility controls. Translated instruments, screen-reader compatibility, font size, contrast, and input methods can affect whether a participant can complete an assessment as intended. These are not cosmetic details when the resulting data contribute to a primary or important secondary endpoint.
• Monitoring variability as an ongoing signal. Completion time, missingness patterns, repeated technical exceptions, and within-participant variance can reveal that a site, participant group, device type, or delivery channel is drifting. Statistical Process Control (SPC) methods may help identify emerging patterns, but the response should be clinically and operationally informed rather than driven by a threshold alone.
• A defined path for late entries and corrections. The data management plan should explain how late assessments, duplicate submissions, corrections, and unsynchronized records will be handled. A technically available timestamp is not a substitute for a documented interpretation of what the timestamp means.

Remote monitoring also needs to distinguish between noncompliance and friction. A participant who misses an eCOA because of repeated connectivity failures is not presenting the same problem as a participant who simply chooses not to complete it. Both may produce missing data, but the remediation, participant support, and impact assessment should be different.

The strongest remote-data strategies are therefore not built around the assumption that technology will make behavior predictable. They are built around making deviations visible early enough to support the participant and protect the analysis.

Vendor Oversight and Cybersecurity in Distributed Trial Environments

Every decentralized trial is, by construction, a multi-vendor study. Home-health nursing agencies, eCOA platform providers, central laboratories with mobile phlebotomy services, courier networks for investigational product delivery, telehealth vendors, and wearable manufacturers may each hold a piece of the evidence chain.

The regulator’s question is the same one a sponsor’s quality team should ask at every kickoff meeting: who, today, is responsible for confirming that this vendor’s contribution to the dataset is intact?

Vendor oversight in DCTs is not a paperwork exercise. It is a clinical exercise, because vendor failure appears in the dataset and can affect participant safety. A firmware update that changes a wearable’s sampling rate is a clinical and data-quality event. A telehealth platform that logs a video visit but does not preserve a reliable timestamp is an audit-trail issue. A courier failure involving temperature-sensitive investigational product can become a product-quality and treatment-continuity issue.

The service-level agreement has to anticipate these situations, and the sponsor’s monitoring plan has to verify that the agreed controls are working in practice.

A useful oversight model maps the vendor’s service to the critical data and decisions it supports:

Cybersecurity sits inside this conversation, not next to it. Continuous data transmission — the heart of a remote-monitoring model — is also a continuous threat surface. A device that has not been patched, a cloud endpoint that has not been appropriately segmented, or an account that remains active after a coordinator leaves are not merely IT hygiene issues. They can affect whether the data reported is the data collected and whether confidential participant information remains protected.

The practical implication is that vendor governance must move upstream of study start. Due diligence on data flows, validation evidence, security controls, incident history, business continuity, subcontracting, and decommissioning plans should be completed before the first participant is consented, not after the first inspection finding.

Quality agreements must be specific enough to identify which party owns which part of ALCOA++ for which data element. The vague promise that a vendor handles the platform is not an answer that survives a monitoring visit. Nor is a dashboard that shows data arriving without revealing how the data were generated, transformed, corrected, or excluded.

ALCOA++ in a decentralized trial is not a compliance checklist. It is the patient promise, written in operational language.

Oversight should also continue after go-live. A vendor can pass qualification and still introduce risk later through a software release, a subcontractor change, a staffing transition, or a new device model. Change control therefore needs to be connected to the clinical and data-management teams, not confined to a technical help desk.

Contingency Planning for Digital Infrastructure and Remote Visit Disruptions

The most under-discussed file in a DCT’s Trial Master File is often the contingency plan, and that is precisely why regulators keep asking for it. The ACT EU recommendation paper, drawing on the same general principle as the FDA’s decentralized guidance, highlights the need for contingency planning around critical-to-quality decentralized elements: digital tool malfunctions, disrupted remote visits, courier delays involving investigational product, and outages affecting home connectivity.

These are not abstract scenarios. They are the lived experience of the field: a participant whose wearable fails during a primary endpoint window, a telehealth platform that is unavailable when an unscheduled safety visit is needed, or an investigational product shipment that is delayed because the receiving patient’s local courier route is suspended.

Each scenario needs a defined fallback. Depending on the protocol, that may involve a paper backup diary, a phone-based assessment, a replacement device, a second telehealth channel, a documented route to in-clinic evaluation, or a medical review of whether the missed activity can be repeated at all. The fallback must protect the participant without creating a second, uncontrolled method of collecting an endpoint.

A useful approach is a tiered contingency architecture rather than a flat list of generic actions. The tiers are not a substitute for protocol-specific planning. They are a starting point whose contents must be tuned to the study’s critical-to-quality factors.

The plan should identify decision owners, escalation routes, documentation requirements, and the point at which a technical problem becomes a clinical or regulatory issue. It should also be tested. A contingency plan that exists only in the Trial Master File but has never been exercised may fail when the team is under pressure.

What does not vary is the principle: a contingency plan written after the disruption is a CAPA, not a plan.

Sponsors who treat planning as a once-a-year document exercise, rather than as a living operational tool, are the ones whose data-integrity narrative falls apart the first time a participant’s broadband provider has an outage. More importantly, those are the moments when participants feel the burden directly. They may have arranged work, childcare, travel, or medication schedules around a study activity. A weak fallback turns a technical failure into an avoidable human cost.

What This Looks Like at the Bedside

We often speak about data integrity in the language of regulators and audit trails, which is appropriate but incomplete. The patient at the center of a decentralized trial does not experience ALCOA++; they experience continuity.

They experience a daily eDiary that loads quickly and saves reliably. They experience a home nurse who arrives on time, with the right kit, and who knows the purpose of the visit. They experience a coordinator who calls when the device fails, with a real plan rather than a script. They experience the difference between a remote trial that has been designed around their circumstances and one that has simply moved site procedures onto a screen.

That is the bedside reality the data-integrity conversation is ultimately about.

The statistics on DCT participation that surface in cross-sectional literature — including a natural language processing analysis of 4,874 DCT cases drawn from ClinicalTrials.gov, in which drugs were involved in only about 1.8% of the trials studied and most of those involved previously approved oral formulations — can make decentralized trials sound like a small corner of the development landscape. Those numbers understate what is happening in the protocols being designed and amended now.

Decentralized elements are quietly becoming a default expectation in studies that were once entirely site-based, particularly in chronic conditions and rare diseases where the participant’s geography is part of the reason a conventional model may fail. Remote patient monitoring, home nursing, telehealth, eCOA, and direct-to-patient logistics can all reduce unnecessary travel. None of them removes the need to understand how the resulting data were generated.

Convenience is not the endpoint. A participant may find a remote visit easier, but the sponsor still has to demonstrate that the measurement was appropriate, the timing was meaningful, the device was controlled, the system was secure, and the record remains interpretable. The operational benefit and the evidentiary burden arrive together.

We owe participants a system that protects both their safety and the meaning of their data. The regulatory framework is already in place: the FDA’s 2024 guidance, the EMA’s guideline on computerized systems and electronic data, the ACT EU recommendations, ALCOA++ as the operational backbone, and ICH E6(R3) as the procedural scaffold. None of this is new in concept. What is new is the discipline required to apply it consistently when data are no longer gathered under the sponsor’s or investigator’s roof.

The sponsors and clinical teams that lead this work will treat decentralization as a clinical methodology — not a logistical convenience, not a marketing line, and not simply a way to reduce monitor visits in a budget cycle. They will write protocols with the patient’s home as a first-class setting. They will qualify vendors with the same seriousness applied to investigator sites. They will connect cybersecurity, data management, medical oversight, and quality management instead of treating them as separate workstreams. They will keep contingency plans close to the operational documents people actually use, rather than allowing them to become static files that no one can find during an outage.

And they will remember, every time they review an audit trail or a missingness report, that behind every data point is a person who trusted the study team to get this right.

That is the work. It is unglamorous, often invisible, and entirely what the era of decentralized clinical research is asking of us.