Takeda Test-Driving Clinical Trial Software Prior To Study Starts
By Deborah Borfitz
February 25, 2022 | Takeda Pharmaceuticals is implementing a “digital visit testing site” for clinical trials, using internal volunteers to test-drive devices in a sandbox environment simulating real-world study conditions prior to their actual deployment. It’s an element of the company’s just-in-time software builds that kick off this month in “proactive preparation for the future,” according to April Downing, Ph.D., director of digital strategy, speaking at the recent Summit for Clinical Ops Executives (SCOPE) in Orlando, Florida.
Downing focused her talk on the first half of the life cycle of digital devices during the study startup phase, which comprises the scoping, solutioning, implementation, and first-patient-in periods. That’s traditionally when software and device demos happen but these tend to be static presentations or, if they are more dynamic, come with preset solutions that aren’t customized to the clinical trial at hand, she says.
Invariably, everything works great, and no bugs or issues come to light, Downing says. There is no opportunity to see how it goes when a study requires unconventional software logic and customized software interfaces or has a nonstandard study visit schedule.
“The study team can’t test-drive the solution to see if works with their patient population... [which is] why problems often appear during implementation,” continues Downing. Their first trial run with new software is during user acceptance testing (UAT) right before it is to be deployed.
The digital visit testing site is an answer to the problem, she says, providing an isolated environment for building and testing software. The sandbox contains communication components and can adjust software as needed to flexibly match study needs.
Among the key components of a successful digital testing site are standardized and customized capabilities, turnaround time of four weeks or less, and the ability for the software to be deployed on a mobile device or via the web, says Downing. The environment should also allow for hands-on testing by the study team, real-time feedback, flexibility in build configuration, and be open to both vendors and sponsor so they can collaborate to build new study instances.
Building a digital testing site begins with a standard visit schedule and modules get added for various study elements—e.g., eConsent, electronic clinical outcomes assessment, electronic patient-reported outcomes (ePRO), telehealth, and devices, including those for monitoring vitals and, especially, smartwatches (“We have lots of requests for this,” Downing says).
During the scoping and solutioning periods of study startup, the digital testing site is used to develop specifications based on input from scientific, operations, and digital team members, she shares. That represents about 80% of what is expected to be in the final build, with custom elements flagged as high priority. Devices get tested by study and UAT teams before being added to the protocol.
Setting Expectations
Benefits of the sandbox environment are many, says Downing, including gaining experience with common and uncommon clinical trial components so specific technologies can be recommended to clinical teams. Expectations of the software platform can also be realistically set, lessening frustrations among clinical and operations team members, and feedback can be given to the platform provider on desired new features and those that aren’t working as intended.
One use case for the digital testing site is the Mayo Clinic symptom severity index for ulcerative colitis, a calculation based on patient-reported stool frequency and rectal bleeding, mucosal appearance on endoscopy, and physician rating of disease activity. This collectively creates one disease severity score, she says, and the sandbox can be used to test out how those multiple modules get integrated to obtain the proper tally.
Integration of this type might be needed for an ambulatory blood pressure monitoring (ABPM) device that has day and night modes and might be used for an in-clinic overnight visit or in the home, says Downing. ABPM is used for safety monitoring after dosing and its key features are real-time but remote monitoring, alerts for abnormal readings, and a dashboard readout for clinical staff.
Backend reporting capabilities are both standard (e.g., medication and ePRO compliance, results) and customized based on unique team needs and unusual time scales, she adds, and the reports can be automatically sent to multiple recipients.
Reducing Burdens
Many potential collaborators are available to help build a digital visit testing site, among them Syneos Health, Medable, Medidata, and IQVIA, Downing says, adding that Takeda worked with a decentralized clinical trial partner as “a standalone project outside of a clinical trial.”
The sandbox environment will be test-driving components for future trials and experimenting with digital devices to hone the experience of internal teams, she says. The plan is to stand up a variety of features over a series of six-month periods.
Feedback from study sites would be welcome, says Downing in response to an attendee’s question. But there may not be any sites ready to go at the scoping and solutioning stages of study startup when the builds will be happening.
The intent of the digital testing site is to help reduce the burden of trial participation, she says. “We realize in study builds we ask too much of patients [e.g., an ePRO survey that 25 minutes to complete] and this disconnect is what we’re trying to solve.”