As a parent, I want my daughter’s physicians to be the most qualified experts in their field. Do I care if they know the mechanics of how an X-ray works or how the latest MRI technology functions right down to the technical specifications? Not at all. Do I care if they understand the latest treatments available and offer the highest standard of care possible? Absolutely. And that is where they should be spending their time, not trying to ensure that the technical specs of the MRI machine will translate into the image they need to provide the best treatment.
So why do we ask our clinical study teams, who should be spending their time operationalizing a clinical trial, to be responsible for sifting through hundreds of pages of complex technical requirements to build a clinical system?
The result of this outdated process is that systems are built by professionals that don’t necessarily understand what they are approving, nor should they! Or, worse, they don’t participate in the IRT specifications process. I have heard clinical supply professionals say they didn’t read a clinical system specification, they ‘just signed it’.
These systems have critical functions, like dispensing drugs and randomizing patients, with direct patient impact. This is unacceptable to me both as a parent and a clinical systems professional in the bio/pharma industry. This is why the process of building clinical systems needs to change. The question is, how? The systems themselves have been evolving, but unfortunately, the process for defining requirements for them has not. As I take a deeper look at the process, here are a few questions that arise:
How should this process be governed? If clinical teams shouldn’t be responsible for translating technical requirements into the operational needs of their study, who should? IT professionals may be more familiar with the technical specifications but they don’t understand the operational needs of a study like their clinical operational counterparts. Should every company seek to hire a hybrid position that understands both clinical systems (from an IT perspective) and clinical operations? Isn’t there a better way? Can we solve the problem by disrupting the process rather than adding additional resources?
I think it is possible.
Clinical systems should be a minimal time and resource investment for clinical teams when starting up and operating a study. I’m not saying that because I don’t love clinical systems (I do!) or because I don’t think they are absolutely crucial for a study (they are!). I’m saying this because if they work as they should, you should not have to focus your time there once they are set up properly to meet the needs of the study.
Unfortunately, systems often only get attention when they aren’t working. So clinical software folks; let’s disrupt the specification process so we can ensure they are designed correctly and get the clinical teams back to study operations. The solution requires a change in people, processes, and technology. It challenges us as an industry to look at our SOPs, our governance structure, and our choices of technology.
What if we could build systems at the same time as the study team gets to review the system?
Traditional RTSM systems can take 6-8 weeks to build, from spec development to system release. User-acceptance testing is done right before system release so there is a risk of delaying the trial if issues arise.
Prancer RTSM uses cutting edge-technology (natural language processing) to build the system within moments and since study teams see the system before signing off on the specs, it removes the burden on them to sift through massive technical documents allowing them to actually see what they are asking for.
Not only does this get the study teams back to the study – but it improves the quality of this critical system and decreases study start-up by 4 weeks.
Wouldn’t you want your study teams to focus on the study and not the technology? I’d love to show you how.