AI Clinical Protocol Data Extraction for Research Organizations

At a glance

Why did clinical trial setup stay manual?

Study setup at a US clinical research organization stayed manual because clinical protocol data extraction had never reached its workflow.

The client runs trials across several studies at once. Each study needs an eCRF, the electronic case report form listing every field that study collects.

Staff filled those templates by hand, with no intelligent document processing anywhere in the process.

Where the manual process broke

• New studies began with a full read of the protocol, & setup waited on that read.
• Extraction ran through a subject matter expert, so one calendar set the pace for study readiness.
• Parameters moved from page to cell by retyping, so values went missing or landed inconsistently.
• Reviewers wrote the same clinical term a little differently, which broke comparisons across studies.
• Requirements spread across several documents per study, so no single read covered everything.

None of these pressures is easing on its own. A Tufts Center analysis of 9,737 protocols found complexity measures rising across phase I to III trials ^[1].

What do teams try before AI extraction?

Teams usually reach for one of three familiar tools before they try AI extraction.

A 2026 study in the Journal of Biomedical Informatics measured this gap directly. A retrieval pipeline built for clinical trials extracted protocol details at 89 percent accuracy, against 63 percent for standalone models ^[2].

How we built clinical protocol data extraction

Brainy Neurals built the extraction pipeline around one structured core. A parser reads each protocol, & language models pull out the defined parameters. A terminology layer standardizes every term, & a graph database stores how those terms relate.

From that core, one path fills the client’s eCRF Excel templates. The other feeds a retrieval augmented generation chatbot, which answers from passages it looks up, so files & answers share one source.

The first decision was what an extraction may be. We ruled out free-form summaries in the first week. A summary cannot fill a template, so every extraction targets a named field.

A summary cannot fill a template, so every extraction targets a named field.

The second decision was where the models run. The pipeline works with hosted language models or with locally hosted ones. A study whose documents cannot leave the network still gets the same output.

The models turned out to be the least interesting part of this build. What did the work was the schema & the term map built around them.

Ronak Patel & Rushabh Sha built the pipeline for this engagement & reviewed every generated field against the protocol wording.

The technology stack we used

Each layer of the stack had to answer one question, which is whether a reviewer can trust its output. The same layers appear in our LLM development work, with different documents underneath.

Documents & structure

Models & knowledge

Application & delivery

How is one clinical protocol processed?

One clinical protocol moves through six stages, in the order the pipeline reads it.

1. Each protocol arrives as a PDF or Word file, & the parser splits it into structured sections.
2. Language models read each section & extract the defined parameters, from age limits to eligibility criteria.
3. A terminology layer maps every extracted term to its standard form, so one measurement carries one name.
4. The relationship mapper links each parameter to its study & to the passage it came from.
5. Next, the generator fills the client’s own eCRF Excel template from those fields, ready for review.
6. That same structured data feeds the chatbot’s index, so anyone can ask what a protocol requires.

Because the file & the chatbot come from one extraction, the two can never disagree.

The problems that nearly stopped the build

Three problems nearly stopped the build, & they arrived in this order.

First, the early protocols scrambled their own tables. Plain-text parsing flattened the schedule & criteria tables, so extractions quietly pulled values from the wrong rows.

Next, terminology drifted from section to section. One vital sign arrived under several names, & the template mapping broke each time it did.

Last, the models overreached on fields the protocol never specified. When asked anyway, they sometimes produced a plausible value, which is worse than producing nothing.

That last failure is documented well beyond this build. A PLOS Digital Health evaluation of two leading models found hallucinated & wrong values in clinical extraction ^[3].

Weeks like these are when clients bring in specialist engineers instead of learning it the slow way.

How we fixed each problem

Each fix looks simple now, though finding it was the slow part of the build.

The case report form predates computers by decades, & paper versions are still legal in most trials.

That discovery work is what an AI proof of concept is for, surfacing problems before anything is promised.

What changed once it went live?

Once the pipeline went live, study setup at the client changed from the first page onward.

We haven’t published a turnaround or error figure, though the client reports faster setup & more consistent extractions. A number we have not measured is a number we will not print.

Day to day, a data manager now opens a drafted eCRF with every field traceable, instead of a blank one. Expert hours moved from retyping to reviewing, which is the work those hours were hired for.

What runs in production today

The extraction pipeline runs in production across the client’s active studies. Each new protocol follows the same path of parsing, extraction, standardization & generation.

Generated eCRF Excel files land in the client’s own templates, while the chatbot answers study questions with the source passage attached.

Since handover, the client has pointed the same pipeline at new studies across its life sciences work. Adding a study takes a template mapping instead of a rebuild, & that rule still holds.

What we would change next time

Four lessons from this build would change how we start the next one.

A field with no source passage is a guess, & reviewers treat it as one.

Where else does this pattern fit?

AI document data extraction fits wherever a team still retypes dense regulated documents into a system of record. The pattern reads each document & writes its defined parameters into structured templates.

Porting the pattern takes a new template mapping plus a term map built for that domain’s own vocabulary.

Services behind this case study

Brainy Neurals drew on six of its services for this build, each linked below.

An AI proof of concept is the fastest way to test this on your own documents. Our AI consulting team helps you choose the deployment path before anything gets built. An AI readiness assessment shows whether your templates are ready, & the industries hub shows where this pattern already runs.

Similar case studies

Brainy Neurals shipped three more builds like this one into regulated or review-heavy settings.