Aligning SDLC and Validation Documents
Raise your hand if you have used classical waterfall validation and documentation for system that is developed/configured with iterative/prototyping/agile approach. I am guessing most of us have done this at one point or another.
When GAMP5 was published 10 years ago (yeah, how time flies), waterfall SDLC was still in use and other SDLCs had not yet come of age. So, it made sense to have a waterfall STLC/Validation cycle which was well aligned with the SDLC. However, in the past 10 years SDLC has gone through a dramatic change. We also have more than one environment (dev/sandbox/val/prod) and try out various scenarios with end users before going to production. Today’s SDLC is iterative, allows for changes, prototypes etc.
To accommodate this ‘discrepancy’, we have been trying to retro-fit validation documentation onto a waterfall. Some of us keep our specification documentation open and only approve it once the system has gone through a few iterations in the development/demo environment and is 'final'.
SDLC & Risk Mitigation
Coding/Configuration – In today’s SDLC – coding/configuration does not happen after URS/FRS/SDS are reviewed/approved. In quite a few cases, they are done upfront on sandbox/development environment. Once users are satisfied, then ‘deployment’ on production environment takes place.
In my opinion, the flexibility of demo-ing the system to the users and incorporating their feedback early on actually mitigates lot of risk. So, one can argue that evaluation of risk and subsequent mitigation is actually in-built in this iterative/demo/prototype approach.
Do we need FRS and SDS documents in this approach? If so, what would one verify these documents against? Once again, today’s world of software development involves close cooperation between users, developers and testers/validation team members. I have seen project teams where all three of them work out of the same war-room. Moving these documents out of validation documentation (V) model into project outcome or maintenance related documents makes more sense (think FDD or SDD). Today’s systems are also capable of auto-generating system design documents and such documents/diagrams can be put in as part of project documents if at all.
FDA seems to be shocked at amount of CSV documentation. Please take a look at the following link:
https://youtu.be/Z4BLB3yZuGw?t=48m10s
It focuses on FDA’s interaction with CSV in medical devices, however same is applicable to pharma as well.
Aligning SDLC and Validation
Below is proposal for an alternative validation model for configured/developed systems; especially where close collaboration exists between users and developers (in-house development).
- Users come up with an initial URS. Based on discussions, developers configure/develop the system with periodic feedback from the users. Once users are okay with the application, a final URS is prepared to capture the refined requirements.
- A UA certificate from users certifies the system by the users.
- The system is then deployed from development/demo environment to production environment.
- Qualification of the system is then done on production environment with an IQ and OQ/PQ/OPQ which basically confirms that the system is working as per finalized requirements in production environment.
- As part of system maintenance documents, one could maintain a system design document.
This concept will deliver best results of computerized syatem .
The "V" model is just not limited to the team; but extends to Finance and Sales division in many cases. The sales will verify and validate whether a bucket of capabilities are rolled out so that they can start making sales pitch to the client. The Finance will ask around whether another bucket of capabilities are fully live, given that the bucket of money is spent. They wont like to talk about small incremental features; rather when a marketable product capability is out there generating revenue. Internally the technology group can maintain such small "V models"; but the big "V model" is still relevant out there.
Very relevant article. Agile methodology and DevOps do call for a change in approach in terms of how we approachCSV. I feel the V model is still relevant, just that it gets divided into smaller cycles. Also instead of a formal URS, now these become user stories and use cases. As long as we can formally establish that all such user stories, especially the ones that impact product quality, patient safety and data integrity are developed and tested (RTM), we should be compliant.
Very good article sir..
Very Good Article