For nearly six decades, the way data moves through a clinical trial has barely changed. A site collects it, a sponsor analyzes it, and the FDA eventually receives it, months or years after the fact. That lag has delayed regulatory decisions, slowed drug development timelines, and in some cases, kept promising therapies from reaching patients who needed them sooner.
Thankfully, that is starting to change. In late April 2026, the FDA announced something that has been talked about for years but rarely demonstrated, real-time clinical trials.
The agency unveiled two proof-of-concept studies already underway, one with AstraZeneca and one with Amgen, where safety signals and endpoint data are being shared with the FDA as the trial progresses, not months or years later. Additionally, a broader pilot program is set to launch this summer.
This is a fundamental rethinking of how clinical evidence gets generated and reviewed, with implications for how quickly the industry can move from trial initiation to regulatory decision. The old model was sequential in how it collected data, packaged it, and delivered the data at the end. The new model treats it as something that flows continuously, in real time, to the people who need to act on it.
However, real-time data sharing only works if the data being shared is coherent in the first place.
The structural problem underneath the timeline problem
A clinical trial is, at its core, an operationalization of the protocol. Every system that gets built, every document that gets written, every workflow that gets configured exists to execute what the protocol specified. The visit schedule comes from the protocol. The CRF fields come from the protocol. The eligibility criteria, the endpoint definitions, the risk thresholds, the monitoring frequency: all of it traces back to that one source document. In theory, the protocol is the single blueprint from which an entire trial is constructed.
Today, a protocol is authored once and then manually reinterpreted by every team that touches it. For instance:
- A study design reads it to build visit schedules,
- data managers read it to build case report forms (CRFs)
- clinical operations reads it to configure monitoring and CTMS,
- statistics reads it to define endpoints and SAPs, and
- Regulatory teams read it to prepare submission artifacts.
Each team recreates the same information in parallel, in isolation, with no structured connection between them. As a result, endpoint definitions and trial processes can often drift from team to team.
Adding to this is that when an amendment hits, documents and systems must be re-checked to ensure the change was appropriately made. That process could take days depending on the trial, but it routinely takes weeks. Additionally, with an average of 1.5 protocol amendments per clinical trial in the US according to Tufts CSDD research, these delays compound across a trial's lifecycle, driving significant cumulative cost and time inefficiencies.
The inefficiencies here are twofold. First, there's the sheer execution complexity of the re-check itself: coordinating across documents, systems, and teams every time an amendment lands. Second, and more insidious, is what happens to data quality underneath that process. If the endpoint definition in your EDC does not precisely match the one in your SAP, which does not precisely match what your monitoring logic is tracking, you get specification drift (small, unreconciled gaps between systems that compound over time). The result is that the signals you're sending to the FDA in real time are not as good as they should be, and not actually a coherent picture of your trial.
What digital data flow (DDF) does about it
The CDISC Digital Data Flow initiative, and Medable's implementation of it, tackles this at the source. Rather than treating the protocol as a document that teams read and re-interpret, DDF transforms it into a structured USDM 4.0 study asset.
We’re all familiar with web pages, and you’ve probably heard of HTML. HTML is what tells a browser how to display a web page. JSON serves a similar purpose for data. Instead of describing how something should look, it describes what the information is in a structured way that software and AI can understand.
The DDF Agent ingests the protocol through a phased, deterministic workflow, extracts and structures it against CDISC-defined schema and controlled terminology, validates every output, and commits it to a single source of truth.
From that one source, study plans are generated rather than drafted, EDC configurations are auto-populated rather than hand-translated, CTMS milestones and KPIs are derived from the actual visit schedule, and monitoring logic is built from the same endpoint and risk domain definitions that appear everywhere else.
Critically, the same protocol version produces the same structured output every time. That is not a small thing. It means there is no interpretive variance between teams, no drift across documents, and no ambiguity about what the trial is actually measuring.
Why this matters for real-time trials specifically
The FDA's real-time trial framework requires sponsors to establish criteria for reporting signals in real time and then transmit them to the agency through a validated technical pipeline. The AstraZeneca TRAVERSE trial has already demonstrated this is technically feasible, with signals validated through Paradigm Health. But, technical feasibility of the transmission layer is only half the equation. The other half is whether the data being transmitted is trustworthy, consistent, and traceable, and whether that trustworthiness can be operationalized at scale, across hundreds of sites and thousands of patients, not just in a pilot or a single well-controlled study.
A digitized protocol that drives all downstream systems from one structured source is what makes that possible. When endpoints, eligibility criteria, visit schedules, and risk domains are defined once and propagated uniformly, the signals coming out of EDC, eCOA, and monitoring systems are genuinely comparable to each other and to the protocol. When an amendment changes something, delta detection identifies exactly which downstream elements are affected, flags only those for review, and maintains a full audit trail automatically rather than triggering a full re-authoring cycle across four teams.
That kind of traceability and consistency is not just good practice. It is what the FDA would need to trust a real-time data stream enough to make regulatory decisions from it.
The connection
The FDA's announcement is about the receiving end of the pipeline. DDF is about the sending end. Both are necessary. A real-time trial that transmits data fast but inconsistently is not an improvement over the current system as it only surfaces the fragmentation sooner.
Getting from where the industry is today to genuine continuous trials requires treating the protocol not as a document teams read from, but as a structured asset the trial operates from. That shift in how study information is created, stored, and propagated is the foundational work that makes everything the FDA is building toward actually achievable.
To see Medable’s DDF in action, click here.
