10 April 2014 by Richard Dirkson, Senior Validation Services Consultant, MasterControl Inc.
More and more regulated companies are using electronic quality management systems, but the concept of software validation remains a mystery to many engineers and quality professionals. In this article, I will try to shed light on the underlying goal of software validation within the context of FDA guidelines and offer a practical strategy.
The FDA defines software validation as the "confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled." (1)
This means your validation project should include documentation that your system meets its usage requirements and quality attributes. To meet this requirement, you must perform the following “3Q” tests and provide documented evidence of the testing:
- Installation Qualification (IQ),
- Operational Qualification (OQ), and
- Performance Qualification (PQ)
The FDA recommends a risk-based assessment of your electronic QMS. In particular, 21 CFR Part 11 provides that validation of any computerized systems should take into account the impact of those systems on the accuracy, reliability, integrity, availability, and authenticity of required records and signatures. The agency recommends that you base your validation approach on “a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety, and record integrity.” (2)
In other words, the level of your system validation should be commensurate to the level of risks posed. Risk assessment and management should be an integral part of your validation project.
From what I’ve seen as a validation consultant, most companies face their biggest challenge after the validation strategy and systems are defined. The resources and time required to identify, create, and execute the 3Qs can be the most problematic and time-consuming aspect of validation. It is the biggest reason why many companies resist switching to an electronic system or upgrade to the latest software version or add new functionalities.
For companies looking to implement risk-based software validation in a timely, efficient, and cost-effective manner, I recommend focusing on OQ. It could be the key to a practical strategy that will help you simplify software validation and still ensure regulatory compliance.
At MasterControl Inc., we follow the Good Automated Manufacturing Practice (GAMP) (3) guidelines, which define OQ as documented verification that a system operates according to written and pre-approved specifications throughout all specified operating ranges.
GAMP goes on to state that much of the evidence required for OQ may be based on testing that a supplier has already performed and could be leveraged and would not need to be repeated.
Based on this GAMP principle, we have provided many of our customers TOQ (Transfer Operational Qualification) test data, which allow them to leverage MasterControl’s validation test data as part of their validation documentation, avoiding unnecessary duplication of validation activities. By using TOQ, our customers have significantly reduced the time, cost, and effort involved in validating their electronic quality systems.
For MasterControl customers that are considering system upgrades, we provide a risk-based approach focusing on the areas of review, impact of change, and testing. Our customers have significantly shortened the validation lifecycle with the help of the following services: planning and validation strategy, risk assessment, tailored protocols, and summary reports.
Companies that use TOQ are able to concentrate more on PQ testing, instead of IQ and OQ. This leads to a faster, more efficient, and more cost-effective software validation.
If you’re thinking of using a software provider’s validation documentation, I would recommend that you audit the vendor’s validation test records. Get a thorough understanding of the vendor’s methodology and test records. So, when it’s time for inspection, you will be able to defend your software provider’s validation data. I can’t emphasize this enough—use only audited documentation from a software provider with a track record of successful validation.
Note: The views expressed in this article are those of the author and do not necessarily represent those of his employer, GxP Lifeline, its editor or MasterControl Inc.
Richard Dirkson is a senior validation services consultant at MasterControl Inc. He has over 25 years of quality and compliance experience in the life science and aerospace industries. His expertise includes QS9000, ISO 9000, ISO 13485, GAMP, cGMP, QSR, 21 CFR Part 820, and 21 CFR Part 11.
- This definition is from the “General Principles of Software Validation; Final Guidance for Industry and FDA Staff,” viewed on March 26,2014 at: http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm
- From 21 CFR Part 11, “Electronic Records, Electronic Signatures—Scope and Application, viewed on March 26, 2014 at: http://www.fda.gov/regulatoryinformation/guidances/ucm125067.htm
- ISPE (International Society for Pharmaceutical Engineering) is instrumental in developing GAMP principles. It offers information about GAMP on its web site: http://www.ispe.org/guidance-documents