You know how you implemented that regulated IT system a few years ago, and it was all shiny and new, and then it went through a bunch of change controls and the validation documentation got kind of unwieldy, and now you’re kinda wishing you could start over with a clean slate, but without losing the functionality you’ve come to depend on?
One of our clients was recently in that boat with their Oracle Siebel Clinical system. Back in 2013, they implemented Oracle Siebel 8.1.1.4. At that time, they assessed the clinical trial management system (CTMS) as non-GxP, so the initial implementation followed a non-GxP process, as did the subsequent change controls.
But, in 2015, they decided to integrate their CTMS with a GxP system. The nature of the integration changed the intended use of their CTMS, so they converted it to a GxP system and got all of their documentation up to snuff. Then, the subsequent change controls followed a GxP process.
Earlier this year, they realized that Siebel 8.1.1.4 had become quite outdated and they wanted to upgrade to IP2017 to gain all of the new features and benefits it provides. They also wanted to move the system to a more secure IT network container on brand new, powerful, sparkly servers. But, what they didn’t want was to bring along all of the old baggage (i.e., messy, complex testing and validation documentation).
So, we helped them design a compliant approach to a fresh start.
Essentially, they are going to treat the implementation as a new system, since the hardware is new and the installation of Siebel IP2017 will be from scratch. Once the base system is installed in the new development environment, they will bring the old configuration over to the new system using the incremental repository merge (IRM) process that comes out of the box with Siebel these days. Any configuration conflicts identified by the IRM process will be thoughtfully resolved and tested by a developer.
In terms of validation documents, they will leverage some of the existing documents, but drop those extra few pounds. The old requirements specification will be converted to a new one, removing all of the revision history and starting with version 1.0, as will the old traceability matrix. And the old test scripts from the myriad prior change controls will be combined into a new, comprehensive test suite.
With that, the validation process itself will be like any other new IT system implementation: a validation plan, qualification protocols, installation logs, test execution records, summary reports, etc. At the end, the old system will be taken offline and the new system will be open for business. All of their requirements will still be met, but they will be free from their documentation baggage (i.e., it will be archived and retrievable, per the regulations).
