ISPE GAMP® 5 and Critical Thinking

21 CFR Part 11 is a regulation that establishes the criteria for electronic records and electronic signatures used in GxP environments. Compliance with this regulation is essential for companies operating in the Life Science industry. However, despite the importance of compliance, many projects fail to meet the regulatory requirements of 21 CFR Part 11. One of the biggest risks to these projects is the validation stakeholders themselves.

Validation stakeholders are responsible for ensuring that systems and processes are compliant with regulatory requirements. However, if they fail to apply the Critical Thinking appendix of GAMP 5 second edition, they can become a significant risk to the success of 21 CFR Part 11 projects.

The Critical Thinking appendix of GAMP 5 second edition is designed to provide guidance on how to approach validation activities in a structured and systematic way. It outlines the importance of using critical thinking to identify potential risks and to develop strategies for mitigating those risks.

Unfortunately, many validation stakeholders fail to apply the principles of the Critical Thinking appendix, either due to lack of knowledge or due to a lack of willingness to change their approach. This can lead to a range of issues, including inadequate risk assessments, incomplete testing, and ultimately, failed projects.

One of the biggest risks associated with validation stakeholders who fail to apply the Critical Thinking appendix is inadequate risk assessments. Without a thorough understanding of the risks associated with a system or process, it is impossible to develop effective strategies for mitigating those risks. This can lead to inadequate testing and validation, which can ultimately result in non-compliance with 21 CFR Part 11.

GAMP 5 second edition was written primarily as a response to updated guidance and thinking from the regulators themselves, indeed the US FDA’s case for quality it's largely driven by an encouragement to follow critical thinking in the course of one's application of compliance activities in support of regulated products. In order to successfully apply critical thinking in the context of a computerized system validation, it is critical to define ones intended use and to adequately assess that intended use through the prism over regulatory requirements. There are five general themes that are useful to consider when applying criticality to one's intended use and requirements specifications, they are; electronic signatures, audit trails, security, data integrity, and integrations.

In addition to core functional requirements each of these five areas should be considered to ensure that one's intended did use is filled with regulatory expectations.

Another risk associated with validation stakeholders who fail to apply the Critical Thinking appendix is incomplete testing. Without a structured and systematic approach to testing, it is easy to miss critical issues that could impact compliance with 21 CFR Part 11. This can result in failed projects and costly delays.

The desire to meet the expectations of the global regulatory bodies has driven a great deal of overburdensome and unnecessary documentation that sometimes becomes the focal point of a computerized system validation often pushing testing or rather the focus on testing into the background. It is both the desire of the US FDA and the intention of GAMP 5 second edition to provide at the industry with an overarching common theme that thing being test more document less. Ultimately the safety purity identity performance and quality of our drug products is more likely to be insured with robust software assurance activities than robust documentation.

While the concepts of computer software assurance may seem new they are really an extension of the FDA's least burdensome approach, and are a far better measure of the health of one's quality system and an isolated computer system validation activity. Indeed by engaging suppliers more robustly we can find products that are better suited to our regulatory uses earlier and our validation process, and conversely avoid potential pitfalls with suppliers and applications that are not well suited to use in regulated environments.

Also, consider that many suppliers of mainstream life science applications supply some level of validation package. One should evaluate these validation packages in order to assess their applicability to your business process and their appropriateness for acceptance into your quality system. It is largely redundant and unnecessary to commit time and resource to retesting aspects of an application that have already been tested, this is a misconception of the purpose of validation, the intention is not to ensure that any particular piece of software has been tested. For this is the job of the software supplier, the intention is to prove that your configuration has been tested and more broadly is sufficient for task relative to the regulated activity that you intend to deploy the software application into.

A great deal of time and effort has historically been spent on questioning the neatness of people's handwriting, the formatting of documents, and an overemphasis on screen captures and other evidentiary requirements. While we want our documents and our validation deliverables to be well ordered and neatly conducted, there is a reality that when the human element is involved people make mistakes, a good documentation practice error should be considered in the context of the wider software testing effort, does someone's poor handwriting really impact a conclusion as to the effectiveness of a software function? If not we have to consider the value of such reviews unless a notation materially changes the implied outcome of a test step where does the value lie? Indeed even a cursory review of 21 CFR Part 210 or Part 211 does not yield a single mention of good documentation practices, and while a batch record must be presented with absolute certainty, does an erstwhile line or a smudged initial hidden within a wayward step of a validation protocol truly necessitate a deviation or other action by QA?

Indeed validation records are not explicitly listed as predicate records under subpart J of 21 CFR Part 211, and while they are most certainly a supportive activity of good GXP practice we must question while they are so often treated as works of deep import requiring the most delicate spelling and grammatical precision.

Overall, the biggest risk to your 21 CFR Part 11 projects might be the validation stakeholders themselves. If they fail to apply the Critical Thinking appendix of GAMP 5 second edition, they can become a significant risk to the success of your projects. To mitigate this risk, it is essential to ensure that your validation stakeholders have the knowledge and skills necessary to apply critical thinking principles to their work. This can help to ensure that your projects are compliant with regulatory requirements and that you avoid costly delays and failures.

Written by

Stephen Robert Ferrell   AUSTAR Consultant