How A Duke Coordinator Turned An EHR Tool Into A Feasibility Engine
By John Oncea, Chief Editor, Clinical Tech Leader
For years, one of the most time-consuming steps in opening a new clinical trial at Duke University had nothing to do with the study itself. It was the site qualification form, the document sponsors use to confirm a prospective site actually has the patients, providers, and product familiarity a protocol requires. Completing it meant combing through operative notes, cross-checking implant and device usage, and estimating how many eligible patients a given investigator actually saw.
“It would just take a couple of weeks to try and fill out and understand what products were being used,” says Anna Thirakul, MS, CCRP, research program leader in the spine division at Duke University. “Combing through operation notes, that took some time.”
Thirakul, who has spent nearly nine years at Duke moving from research technician to overseeing a full portfolio of Phase I–IV spine studies, found a faster way: not by asking IT for a new system, but by putting an existing one to a new use.
Repurposing A Tool Built For Clinicians
Duke’s EHR, Epic, includes a self-service analytics feature called Slicer Dicer, designed to let clinicians query patient populations directly from the EHR. Thirakul began using it during study startup to answer a narrower, more specific question than most clinicians ask: does Duke actually have the patients and the product familiarity a given protocol requires?
“I use this technology to go back in the EHR to help me fill out a site qualification visit,” she says. “It can slice and basically filter on a provider. Do you have the patient population, and are you using the products specified by the sponsor? Is there true compatibility?”
The output isn’t just a yes-or-no. Slicer Dicer lets her filter and export a defensible summary showing whether a specific investigator’s caseload lines up with the products and patient population a study needs, a distinction that matters more than it might sound. Catching a mismatch during startup is a very different outcome than discovering it mid-enrollment.
“I’d rather figure out early on using technology that can help measure and accurately depict what’s already established here at Duke, rather than be in the midst of a study that’s open to enrollment and then struggling to enroll because we didn’t take the time to figure it out in the beginning,” Thirakul says.
Proving The Case, One Dashboard At A Time
Thirakul didn’t roll this out through a formal IT proposal. She built it, used it, and took the results to her supervisor.
“She’s a wonderful supervisor, very supportive,” Thirakul says. “She’s like, ‘If you can demonstrate that it’s improving your process.’” That’s precisely what happened: turnaround on site feasibility forms measurably improved, and what started as one coordinator’s workaround became a standard part of how her division evaluates new studies before committing to them.
Her advice to others sitting on a similar idea is to start narrow. “If you have a vision of, ‘I’d like to focus on reducing the number of times it takes me to fill out this form,’ drill down on that and then just keep using it,” she says. “I learned a lot of things just through exposure – okay, this actually works better when filtering out … use this data model and then keep building your Slicer Dicer session.”
From Workaround To Teaching Tool
The story didn’t stop at adoption. Thirakul has since spent time teaching colleagues across her division how to build their own Slicer Dicer queries for their studies, becoming an informal subject-matter expert for a tool that was never marketed to clinical research coordinators in the first place.
That pattern – a frontline staff member finding an underused capability in an existing system, proving its value to a supervisor, and teaching it forward – is arguably more replicable than any specific feature of Slicer Dicer itself. It didn’t require a procurement cycle, a vendor contract, or a pilot committee. It required permission to experiment, and a manager willing to evaluate the result on its merits.
The Broader Lesson For Site Technology Strategy
Thirakul’s feasibility workflow is a useful reminder for sponsors and site leadership alike: some of the most effective clinical trial technology isn’t purpose-built. It’s a general-purpose tool, already licensed and already running, put to a specific operational use by someone close enough to the problem to see the opportunity.
It also illustrates something sponsors don’t always account for in feasibility surveys: sites that can answer compatibility and enrollment questions quickly, using their own internal data, are in a stronger position to say yes to the right studies – and no to the wrong ones – before enrollment ever opens.
It’s also a reminder of where the responsibility for feasibility tooling actually sits. Duke didn’t buy a feasibility product; a coordinator found one already embedded in the EHR platform most academic medical centers already run. For sponsors, that suggests the more valuable investment may not be another standalone feasibility survey tool, but encouragement and, where possible, technical support for sites to build this kind of query inside systems they already have access to.
Slicer Dicer is just one line item in a technology footprint Thirakul estimates at roughly ten systems on a given day, a mix of legacy platforms and newer rollouts she and her colleagues are still learning to integrate. That broader picture, and what it says about burden versus redistribution, is worth its own look, which will be coming on November 9.