We’ve done it so many times, we don’t even have to think about it anymore. We’ve got our Siebel CTMS implementation process down pat and it’s marvelously efficient. How do we do it?
It starts with our pre-configured version of Oracle’s Siebel Clinical, something we call ASCEND. Combine ASCEND with our hosting services, and you shave weeks (maybe even months!) off the process of acquiring and configuring the hardware. Plus, we’re experts in the hardware requirements and installation process for Siebel CTMS – no learning curve.
Next up, we have our fully validated ASCEND master template instance that we clone to create client environments. The cloning process alone is 80% faster than installing from scratch, but the real value comes from the “fully validated” part. Because we’ve already executed our comprehensive operational qualification test suite (OQTS) on our master template, we’re able to leverage all of that documentation for clients, rather than needing to re-executing it. That’s a HUGE savings right there – no need to perform the OQ phase of validation.
So, ultimately, for the implementation of a client’s production environment of base ASCEND, we just need a validation plan, an installation qualification (IQ) phase, and a validation summary report. And those documents are a snap to author, thanks to our extensive library of Word document templates. So, as long as the client is quick with their reviews and approvals of validation docs, voila! Siebel CTMS goes live in just a few weeks.
But, what if you want some customizations? Or an integration? Or an add-on module? Fear not! That might just be the best part of the whole thing. We actually still follow the process above for their production environment, BUT, in parallel, we install a development environment and begin working on client-specific changes there.
It works out beautifully because the base ASCEND implementation requires minimal participation from the client and from Perficient’s clinical operations practice, leaving them free to begin working on the impending change control. And, because the change control work is taking place in the development environment, there’s no risk to the validated state of their production environment.
As soon the base ASCEND system goes live, we officially open the change control, and we often have the bulk of the documents lined up for approval by that time: change plan/protocol, user requirements specification, design specification(s), etc. As soon as those are approved, development begins, and then we follow a standard performance qualification (PQ) phase and close it out with a change summary report.
By completing the requirements and design phases of the change control in parallel with the implementation of the production environment, we shave several weeks off of the overall project without violating any validation principles or introducing any risk.
And that, my friends, is how we do it.
Want to learn more? Download this Quick Guide (with a long title!) written by the director of our clinical trial management solutions group, Param Singh.
