A Framework For Diagnosing Clinical Research Technology Maturity

By John Oncea, Chief Editor, Clinical Tech Leader

Yolanda Davis has spent nearly 30 years moving through almost every seat in clinical research operations: clinical research associate, monitor, data manager, project manager, informatics, and compliance and quality assurance, across pharma, CRO, and academic medical center settings. She calls herself a “unicorn” in the industry, and it’s hard to argue otherwise. It also happens that she’s spent the last 13 years building research infrastructure at the University of Miami, despite being a Florida State University graduate, a rivalry she jokes about but that has clearly not slowed her down.

Her view, distilled from that cross-functional vantage point, is straightforward: most organizations don’t fail at technology because they picked the wrong system. They fail because they misunderstood their own readiness. Rather than a checklist of software to buy, Davis describes a four-stage progression that most organizations move through unevenly, and often without realizing which stage they’re actually in.

The Four Stages Most Organizations Never Name

Davis breaks technology maturity into four stages: concept, process and workflow development, implementation, and continuous refinement without altering the core. The distinction matters because organizations frequently attempt to jump straight from concept to implementation, skipping the workflow development stage where the actual operational rules get worked out. When that happens, the technology gets blamed for problems that are really process gaps.

Concept: At this stage, an organization has identified a need but hasn’t yet translated it into operational requirements. It has a problem statement, not a workflow. The risk, Davis says, is assuming that naming the problem means the organization is ready to solve it. It isn’t.

Process and Workflow Development: This is the stage Davis believes organizations rush past most often. It’s where teams define who owns each step, what triggers the next action, what must be documented, and what requires escalation. Skip it, and technology implementation becomes guesswork, whether that’s an eConsent platform, a CTMS deployment, or AI-assisted protocol review. Technology can accelerate a process. It can’t compensate for one that was never clearly defined.

Implementation: Implementation is the stage many organizations mistake for maturity. A system gets selected, configured, and rolled out, but deployment alone doesn’t prove readiness; it only proves a system exists. If every department has a slightly different read on the underlying workflow, the technology tends to expose those gaps rather than close them.

Continuous Refinement Without Altering the Core: The final stage isn’t reinvention; it’s disciplined optimization. Organizations here have a stable process and enough visibility to make informed improvements without rebuilding the foundation every time. It’s also where leaders are best positioned to judge whether new technology is actually needed, rather than chasing every new tool that comes along.

Why New And Established Organizations Should Start Differently

Just as important as the stages themselves is the order in which Davis says organizations should tackle them, and her rule isn’t universal. Newer organizations should prioritize people first, then documents and systems since roles and decision pathways are still forming. Established organizations should reverse that order, tackling documented process before people, because the people and their habits are already in place and need a framework to work within, not a blank slate. Get the sequence backward, Davis says, and the risk is the same either way: misalignment between people, process, and technology.

Why Organizations Overestimate Their Own Readiness

Asked how organizations should start assessing their own maturity, Davis points inward before outward: take an honest inventory of internal resources and existing infrastructure before bringing in an outside consultant. A consultant can help, she says, but isn’t required to get started.

The harder problem is that organizations tend to overrate their own readiness. Davis uses a “nose blind” analogy: people who live with a smell every day stop noticing it, and organizations that live inside their own broken processes every day stop seeing them as broken. In her experience assessing organizations, she says roughly one in five, or about 20 percent of the time, she encounters a red flag serious enough to change her initial assessment of where a group actually stands.

A few questions tend to surface that gap quickly:

• Can two people in different departments describe the same workflow the same way?
• Are process owners clearly identified, or is ownership assumed?
• Did workflow mapping happen before or after the technology was selected?
• Are exceptions documented, or handled through informal, tribal knowledge?

If the honest answer to several of those is “no,” Davis’s framework suggests the organization is likely operating at an earlier stage than leadership believes.

When “More” Becomes The Enemy: Scope Creep In Clinical Tech

Davis is direct about a failure mode specific to clinical technology vendors: scope creep. She compares it to Coca-Cola’s attempt to replace its core product with New Coke, or a burger chain deciding to add chicken sandwiches to the menu; the analogy being that expansion away from a core competency, done carelessly, dilutes the thing that made the product trustworthy in the first place.

In clinical research specifically, she points to EDC vendors that started as strong, focused data capture systems and then expanded into CTMS, eConsent, and lab management, often diluting the quality of the original product in the process. She singles out Veeva as a vendor that has managed to expand its footprint without losing the strength of its core offering, an example of scope expansion done well rather than a cautionary tale. The lesson, Davis says, is that expansion should be judged by execution, not ambition.

Where AI Fits, And Where It Doesn’t

On artificial intelligence, Davis doesn’t treat it as a single maturity stage that organizations either have or don’t. She describes it as spread across the entire maturity curve: an organization can use AI at a very basic level or a highly sophisticated one, regardless of how mature its broader operations are. Her characterization of what it’s actually good for is blunt: an “executive assistant on steroids,” useful for drafting, summarizing, and organizing.

Her line on what it shouldn’t be used for is just as blunt: never for decisions, especially anything touching patient safety, patient rights, or risk. And she’s equally clear that AI output is only as good as what goes into it: crap in, crap out, in her words, is as true for AI in clinical research as it is anywhere else. Before trusting an AI-supported workflow, she suggests asking whether the process behind it is actually defined, the data feeding it is reliable, and a human is positioned to catch what the tool gets wrong.

Starting The Assessment

For an organization trying to place itself on this framework, Davis’s advice comes down to two habits: take stock of what you actually have before assuming you need something new, and treat self-assessment with suspicion, because the people closest to a process are the least likely to see its flaws clearly. Getting an honest read on which of the four stages an organization occupies, she suggests, is less about sophistication and more about willingness to look past what’s become invisible through familiarity.