If you've worked in clinical data management, you already know the number: 12 to 16 weeks. That's the typical time it takes from a finalised protocol document to a live, data-entry-ready EDC. For a Phase II or Phase III trial, this isn't a minor inconvenience — it's a multi-month delay at the very start of a study that may run for two to five years.

The question nobody asks often enough is: where does that time actually go?

The anatomy of a 16-week EDC build

The process, as it exists today in most CROs and sponsor organisations, involves roughly five sequential stages — each of which is almost entirely manual:

• Protocol review and interpretation (2–3 weeks): A CDM team reads the protocol, extracts visit schedules, identifies assessments, and maps them to CDISC CDASH domains. This is skilled, time-consuming work — and it's done differently by every team.
• EDC design and build (4–6 weeks): A specialist team configures the CRF library, visit matrix, branching logic, and edit checks in the EDC platform of choice — typically Medidata Rave, Oracle Inform, or similar.
• UAT (User Acceptance Testing) (2–4 weeks): The configured system is tested against the protocol. Discrepancies are found, fixes are made, more testing follows.
• Regulatory and sponsor sign-off (2–3 weeks): Documentation is prepared, Part 11 validation evidence is compiled, and formal approval is obtained.
• Training and site go-live preparation (1–2 weeks): Site coordinators are trained, help materials are distributed, and the study opens for enrolment.

Add these up optimistically and you get 11 weeks. In practice, each stage runs long, reviews bounce back, and coordination across time zones adds friction at every handoff. The result is a 16-week average that everyone treats as a given.

What automation changes — and what it doesn't

The first two stages — protocol interpretation and EDC design — are where the time sinks. They're also where automation has the most leverage.

A modern AI pipeline, trained on clinical protocol documents and CDISC domain structures, can extract the visit schedule, assessments, SDTM domain mappings, and CRF field definitions from a protocol PDF in minutes rather than weeks. This isn't a speculative capability — Clinly's parser does this today on real protocols, achieving an 87.8% first-pass accuracy rate on field extraction, benchmarked against untuned LLMs.

What automation doesn't replace is the CDM's judgement on the ambiguous 12.2%. Protocol documents are written by clinicians, not data architects. They contain ambiguities, shorthand, and implicit decisions that require human expertise to resolve correctly. A responsible automation platform flags these for review — it doesn't silently fill them in.

"The goal isn't zero humans. The goal is humans doing the work only humans should do — and AI handling everything else."

What the math looks like in practice

If AI handles the extraction work that currently takes 6–9 weeks of CDM time, and a human CDM reviews and resolves flagged items in a structured HITL workflow, a realistic target timeline looks like this:

• Protocol parsing + HITL review: 3–5 days
• UAT (reduced scope since build is auto-generated): 1–2 weeks
• Regulatory sign-off: 1–2 weeks
• Site go-live prep: 1 week

Total: 4–6 weeks instead of 12–16. That's not a marginal improvement — it's a structural shift in how trials can be run.

The bottleneck in drug development isn't the science. Often, it's the paperwork infrastructure that surrounds it. Automation doesn't solve every problem in clinical trials — but removing a 16-week tax from every new study is a meaningful place to start.

There's a version of the "AI in clinical trials" conversation that goes like this: AI reads the protocol, AI builds the EDC, AI monitors the data, AI submits to the FDA. Everything is automated, nothing is touched by human hands.

This version is wrong — not just technically, but philosophically. And building a clinical data platform without understanding why is how you end up with a system that passes a demo but fails a real audit.

Why fully automated clinical data management isn't safe

Clinical trial data underpins regulatory submissions. The decisions made from that data — whether a drug is safe, whether it works, whether it should reach patients — have life-or-death consequences. The regulatory frameworks that govern this data (FDA 21 CFR Part 11, ICH E6 GCP, EMA Annex 11) exist precisely because of this stakes profile.

These frameworks share a core principle: every change to clinical data must be traceable to an accountable human being. Not a system, not an algorithm — a person with a name, a role, and a signature. When something goes wrong in a trial (and things always go wrong eventually), the question regulators ask is: "Who made this decision, when, and why?"

An AI model cannot answer that question. An AI model can make a decision, but it cannot be held accountable for it. This is the fundamental reason why full automation — at the point where data interpretation and judgement are required — isn't a viable path in regulated clinical research.

What AI is genuinely good at in this context

This doesn't mean AI has no role. It means the role has to be correctly scoped. AI is excellent at:

• Extraction at scale: Reading a 200-page protocol document and pulling out visit schedules, assessments, and field definitions faster and more consistently than a human reading the same document for the third time at 4pm.
• Pattern matching: Recognising that "blood pressure measured at rest" maps to the VS CDISC domain, that "concomitant medications" maps to CM, that "adverse events" maps to AE — reliably, across thousands of fields.
• Flagging ambiguity: Identifying where the protocol text is unclear, contradictory, or incomplete — and surfacing those items for human review rather than silently guessing.
• Consistency enforcement: Applying the same logic to every field, every visit, every form — without the variability that comes from different humans interpreting the same document differently.

What the HITL gate actually looks like

In Clinly's workflow, the HITL gate is a structured review step that sits between AI extraction and any production-ready output. Every item the AI has flagged as uncertain appears in a review queue, with the AI's best interpretation shown alongside the source text from the protocol and the reason for the flag.

The CDM doesn't re-do the AI's work. They adjudicate it. They review the interpretation, confirm or correct it, and sign off. The decision is logged in the audit trail with their identity, timestamp, and the action taken.

This means the final output is not "AI-generated." It's "CDM-reviewed and approved, with AI assistance." That's a distinction that matters enormously in a regulated environment — and it's the distinction that makes automation safe rather than reckless.

"Human-in-the-loop isn't a limitation on automation. It's what makes automation trustworthy in a context where trust is non-negotiable."

The 87.8% question

Clinly's AI achieves 87.8% accuracy on first-pass field extraction. Some people hear that number and think: 87.8% isn't good enough for clinical data. They're right — if the 87.8% is the end of the pipeline. It isn't. The 12.2% that requires human review is exactly the point. The HITL gate exists because we know the AI isn't perfect. The audit trail documents every human correction. The final output is 100% human-reviewed — just not 100% human-generated.

Compare this to the alternative: manual EDC build by specialist CDM teams, which Tufts CSDD estimates has a 15–25% rework rate due to interpretation errors on first pass. The AI pipeline plus HITL review outperforms fully manual processes — while being faster and cheaper. That's the actual comparison that matters.

When people worry about automating clinical data management, they usually worry about compliance. "What happens to the audit trail?" "Does AI-generated content satisfy Part 11?" "Can we submit a study built with an AI tool to the FDA?"

These are serious questions and they deserve serious answers — not hand-waving reassurances about how "it's all compliant, trust us."

What 21 CFR Part 11 actually requires

21 CFR Part 11 governs electronic records and electronic signatures in FDA-regulated industries. Its core requirements are straightforward, even if the implementation details are not:

• Electronic records must be attributable to the individual who created or modified them.
• All changes to records must be logged in an audit trail that captures what changed, who changed it, and when.
• The audit trail must be computer-generated, not user-modifiable, and retained for the required period.
• Electronic signatures must be linked to their records and cannot be transferred to another record.
• Systems must include access controls that prevent unauthorised modifications.

Notice what Part 11 does not say: it does not say that records must be created manually. It does not say that automation is prohibited. It says that records must be attributable, traceable, and protected from unauthorised modification. Whether those records were created manually or with AI assistance is largely irrelevant — what matters is the integrity and traceability of the final record.

Where automation introduces risk — and how to mitigate it

Automation introduces Part 11 risk in two specific places:

• Attribution: If an AI generates a record and no human reviews it, the record is attributed to a system rather than a person. This breaks the attributability requirement.
• Audit trail integrity: If the audit trail is application-level (stored in tables the application can modify) rather than database-level (enforced by triggers the application cannot override), it can be tampered with.

Both risks have mitigations. Attribution risk is resolved by the HITL review gate — every AI-generated item that enters the production system has been reviewed and confirmed by a named human, and that review is the attributed action in the audit trail. The AI's extraction is an internal computation, not a regulated record.

Audit trail integrity is resolved by implementing the audit trail at the database trigger level rather than the application level. In Clinly's architecture, audit log entries are written by PostgreSQL triggers that fire on INSERT, UPDATE, and DELETE operations. The application layer cannot suppress or modify these entries — they're enforced below the application's visibility.

Moving fast without cutting corners

The compliance concern with automation often conflates "fast" with "sloppy." They're not the same thing. A well-designed automated system can actually be more compliant than a manual one — because it's consistent, documented, and enforced by code rather than by individual habits.

Manual EDC build means different CDMs make different interpretation choices, apply different naming conventions, and document their work with different levels of rigour. Automated extraction means the same logic is applied to every field, every time, with every decision logged.

"Automation doesn't undermine compliance. Badly designed automation does. The difference is in the architecture."

The goal of a compliant automated EDC platform is not to remove regulatory scrutiny. It's to make regulatory scrutiny easier — by producing records that are cleaner, more consistent, and more traceable than what came before. That's a goal worth building toward.