Greg Ventura’s Post

View profile for Greg Ventura, graphic

Computer System Validation Manager | Quality & Compliance Manager

Traceability: Part 3-Vendor Systems or Tools Now if the application is something that you have purchased and are not the creator of, then you will not have all of the documents described in previous posts at your disposal.  You may not have access to their requirements or the design specifications.  If you don't, then at a minimum you will need to create your own requirements document.  The benefit of doing this is that your list of requirements will only be what is important to you.  If the system has a module that you do not use, then it does not need to be included in your requirements.  You obviously will not have a design specification and do not need to create one.  If you have been able to audit the vendor and their validation documentation and are satisfied, then the amount of testing you will need to do is reduced.  You should always do your own testing, what I will call user acceptance testing (UAT) and that should be traceable to your requirements. You should be able to show through your trace ability matrix how you have done due diligence.  For example, in your review of the vendor's testing you find that some particular feature is only tested superficially.  You decide to write your own user acceptance testing that goes into more detail on that particular feature.  These test plans will also be listed in your traceability matrix. With a good traceability matrix, you should be able to defend the validation of your system through any audit. #traceabiity #vendor #tools #matrix

Fatma Elfaghi, CQA

VP Quality and Compliance at Castor

3mo

Risk-based validation for “intended use” is certainly the most pragmatic approach for GXP Supplier Qualifications

To view or add a comment, sign in

Explore topics