Successful Computer Validation - A Monthly Blog by Dr. Teri Stokes

Computer Validation from the Regulatory Perspective

2012-01-03T10:08:00.000-05:00

Today computers are everywhere in our lives and we are well aware that mistakes and disruptions do occur with computer systems and their databases. (2) … All computer system regulations and guidance have four themes in common. These four themes form the essential components of computer validation policy and practices for any regulated environment. (12)

People complain about regulations and inspections by authorities, but there is a sad history (1937 Elixir Sulfanilamide incident, 1962 Thalidomide effects) behind the need for regulatory controls in the pharmaceutical industry. The 1983 publication of the FDA’s “Blue Book” guidance to inspections of GMP systems introduced authority control specifically to computerized systems in the manufacture of pharmaceutical products. Today the initial blind trust in a computer printout has been replaced with decades of personal and corporate experience and the reality that computers are not infallible. The 25+ years following the “Blue Book” have produced a plethora of legislation and guidance from authorities around the world and can seem overwhelming to system owners trying to be compliant.

It is important to remember that computers do not “know” in which GXP environment they are being used. There are, however, some standard principles for quality assurance of computer systems that work across all GXP environments and uses of the technology. One of these is assuring proper human interaction with the computer by having standard operating procedures (SOPs) and work instructions specific to the user’s work process, and training records for workers who are system users. Another is having a solid User Requirements Specification (URS) that clearly maps the work process and its interactions with the computer technology. It is important to document the work process flow, the data or control flow, and the system/user activity flow.

In fact the basic inspection questions suggested by the “Blue Book” in 1983 are still relevant today despite the increase in system complexity. They are also adaptable across all the “X” variations. Chapter 1 in my book discusses the “Blue Book” in relevant detail and also has an appendix that gives a table showing the changes and retained elements in the EU GMP Guide Annex 11: Computerized Systems from 1992 to 2011. None of this compliance guidance or GXP regulations discusses technology details. They are all readable by managers and end users. Newcomers to computer validation should be encouraged by this and find the short 25 page chapter a quick course in the essentials of the regulatory and compliance perspective. Any confusion about terms can be addressed by the seven-page Glossary of Terms and Definitions at the front of the book.

Next Month: User Team’s Role in Computer Validation

Sometimes users describe a “requirement” but can’t figure out how to “test” for that requirement. In this case they have described a “wish” and must rethink their description until they can figure out how to test for what they are asking. There must be no “wishes” in a URS. …Developing a well-considered URS is the first step in the successful purchase of a new GXP system. (40)

Computer Validation from the Business Management Perspective

2011-12-01T16:53:00.000-05:00

Proposals that include new automation or substantial computerized applications in GXP areas without including a specific schedule, cost, and personnel estimate for validation should not be approved until those factors are added for consideration. If the figure for validation is less than 40-50% of the purchase price of the computer hardware and software, it should be questioned closely. (34)

One of my pet peeves is computer validation getting a bad rap for delayed implementations and budget overruns when it is usually the last item considered, seldom budgeted with appropriate people and time resources, and often not invoked until the last few weeks of the system project. As Go-Live approaches, suddenly someone remembers, “oh yeah this system needs to be validated” and decides to call in QA and QC. This is the usual recipe for validation disasters.

Validation for a GXP computer system should begin on “Day Zero”, the day that management decides to have such a system. For GXP systems computer validation is a non-negotiable business requirement. The manager who “owns” the regulated business process using the GXP system will be held responsible by authorities for its reliable performance in regulated tasks and for the integrity of its processing of regulated data from those work tasks. All data submitted to or inspected by authorities to prove the safety, efficacy, and other quality attributes of regulated product for market approval or production purposes must be handled by validated systems when in electronic form.

The process manager is responsible for having the GXP status of the proposed system identified so that relevant laws and guidance can be considered in the User Requirements Specification (URS). No one knows the work process better than the end users, and it is the process manager’s role to identify a User Team to examine the work tasks and identify where, when, and how the system will be used to control the regulated process and/or handle data from the process. Writing the URS is NOT an IT role and it should not have an IT technology focus. The focus for the URS is a close view of work process needs for automated control and electronic data handling.

In parallel with developing the user requirements, the process owner should sponsor the writing of a Validation Plan (VP) to identify the tasks, timeline, and resources needed for computer validation. Since every item in the URS must be documented and tested during validation, it takes both a URS and a Validation Plan to properly scope, budget, and project manage the implementation of a GXP system. There have been some sad examples in industry where elaborate computerized facilities have been constructed and then were unable to be used due to the lack of adequate planning for computer validation and consequent failure of inspection by authorities. Don’t let this happen to you.

Next Month: Computer Validation from the Regulatory Perspective

Today computers are everywhere in our lives and we are well aware that mistakes and disruptions do occur with computer systems and their databases. (2)… All computer system regulations and guidance have four themes in common. These four themes form the essential components of computer validation policy and practices for any regulated environment. (12)

Introduction: Successful Computer Validation

2011-11-02T08:02:00.000-04:00

Many people consider computer validation to be a “necessary evil” and not a “rewarding adventure,” but my experience over the past 20 years has disproved this dire view. It has shown that a common sense approach to the discipline of computer validation for regulated systems can give many significant rewards in data credibility for authorities, reliable system performance for end users, and pride in system quality with uneventful inspections and audits for validation teams, QA/QC, and management.

Computer validation is not a casual experience. It is a formal practice designed to provide system owners with documented evidence that their system reliably performs as expected and is in compliance with all relevant regulations, laws and authority guidance. For the pharmaceutical, biotech, and medical device industries, the major areas for such regulations and guidance are Good Clinical Practice (GCP), Good Laboratory Practice (GLP), Good Manufacturing Practice (GMP) and other electronic record keeping and submission practices (Part 11, etc.). “GXP” is the term I use for convenience to refer to any and all the relevant regulations for computer systems.

In writing my new book, Computer Validation: A Common Sense Guide, I decided to look at the discipline of computer validation from the perspective of the people who have to participate and actually do the work in a computer validation project. This starts with the end user manager responsible for the regulated work process who decides that a system is needed and funds the requisition, purchase, validation, deployment, and ongoing operation of the system. The laws that this manager must comply with as well as the organization’s corporate infrastructure provided to perform computer validation in an auditable and cost-effective fashion are also important parts of this book.

It is the broader context of corporate governance and non-IT people required for a successful validation project that separates this book from its other brethren in the industry. The ten chapters speak clearly and directly to the roles and responsibilities for all concerned from management, user team, and IT infrastructure role, to the roles for system supplier, QA/QC, and electronic archivist. Chapters also describe the content of an inspect-able validation package and formal testing practices. Each chapter has one or many appendices giving examples of real project documentation that illustrate the concepts discussed.

Consistent, documented training is always an issue for validation teams. This book is also available in electronic chapter units suitable for focused team training locally and at a distance. Each month on this blog I will highlight concepts from this book, sharing insight and excerpts from my book and experience from my global consulting practice to support your success in validating computer systems.

Next Month: Computer Validation from the Business Management Perspective