Reducing Risk in Decentralized Trials

On a recent Diligent Pharma Webinar , Joseph Kim , Chief Marketing Officer of ProofPilot , covered 7 key issues that Sponsors must consider to manage risk in designing and deploying Decentralized Clinical Trials (DCT). 

First and foremost, acceptance of the truth that a schedule of events (or other manually represented protocol concept) is not a study design, will set you free. 

Figure 1. Not a study Design

This representation does nothing to help anyone understand key differences that define what makes a DCT, a DCT.  For example, this chart does not plan for location, mode of data collection, or timing and interdependencies between and amongst the procedures or study tasks - unless of course you refer to the 30 footnotes below a typical table like this to account for the wherefore's and howto's. So why then do we use this (and powerpoint and excel spreadsheets) to inform service providers as to how to build a user interface/experience (UI/UX) for a DCT?

When designing a DCT, there are critically important and complicated key differences from a brick and mortar trial that must be designed very thoughtfully before you deploy.  Traditional ways of designing and working with service providers will only serve to increase the risk of operational failure. Furthermore, designing in a waterfall method will needlessly extend timelines and increase cost, putting even more pressure on the enrollment savings required to justify the increased complexity and cost:

• Coordination of supplies - since all study supplies will not be sitting at the site, where then will these things be inventoried, how/when will they be deployed, who will ship and receive?  
• Coordination of 3rd parties - who is doing what, when? Am I going to see a remote nurse only at home? What about my place of work? Will scheduled tasks at a retail health location have me in their books?
• Unlocking study tasks - because the site isn’t exclusively managing the flow of activities at the clinic, how then will study tasks be triggered for participants and 3rd parties?  You certainly don’t want people doing things out of order or too early if it breaks the science.
• Locking study tasks - likewise, how do you avoid having people do study tasks too late?  In a brick and mortar study, this is well controlled because once a participant leaves the clinic, study tasks don’t happen anymore. In a DCT, participants aren't always in a controlled environment.
• Access/familiarity with tech, wifi, etc - It’s true that many folks don’t have home broadband. It’s true that not everyone has access to the latest mobile device. It’s true that native apps need to keep up with the latest mobile OS or risk being not supported. It’s true that maintaining two different types of native apps creates costs. It’s true that most people use a mobile device as their only access to the internet. It’s true that some people like using laptops if they have them.  It’s true that I don’t have the perfect answer to this, but certainly designing a DCT build on platforms that exclude populations isn’t going to be good.
• Help desk - since there is more tech and more responsibility placed on the participant and other 3rd parties, which questions will get answered by whom? Clinic staff are not going to want to answer username and password questions or questions about shipping or stipends, particularly if they were not involved.
• User instructions - how best do you train participants to do their part, or better yet, design the UX in a way to eliminate user error?  In my recent experience as a DCT participant, I ended up submitting a saliva sample in the wrong tube because the activities were designed in a way that allowed for user error - who knows if this mistake can be unwound, and wonder how many others got this wrong too.

Figure 2: A few days before a #FAIL

Tune in to our next post to learn more about what you can do to help reduce the risk of your DCT going south through the power of self-serve Digital Design.