On a recent Diligent Pharma Webinar, Joseph Kim, Chief Strategy 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 that sites can execute, 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 clinical research and working with service providers will only serve to increase the risk of operational failure. Furthermore, designing research studies 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 trial 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 clinical 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 clinical 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 (e.g. native apps) 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 research 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 I wonder how many others got this wrong too.
Figure 2: A few days before a #FAIL
Seems hopeless, but it’s not. 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 Digital Automation.