Dear Blog Reader,

In 2011 I published a new book to celebrate the 15th anniversary of establishing my global computer validation consultancy GXP International. The book is titled Computer Validation: A Common Sense Guide and it is available in both hard copy and electronic form at www.BioPharm-Guides.com. The book’s 10 chapters describe computer validation practices that field experience has shown to be practical to execute and that produce results which have passed audits and inspections. The 29 chapter appendices provide full scale examples of validation document sets, policies, and SOPs from real projects to illustrate the concepts discussed.

This blog takes quotes from the book and expands on the ideas presented. In addition, a 2012 Webinar Series is available for training purposes using Chapter Briefing Units from the book. Training is in association with the International Pharmaceutical Academy of Canada (IPA). For course information go to http://ipacanada.com/w_scv0112.php. Your comments and concerns about validation topics can be sent to me at my email: GXPINTL@RCN.COM. I look forward to a healthy exchange of ideas and wish you every success with your own computer validation projects.

Teri Stokes, Ph.D., Director, GXP International


Tuesday, January 3, 2012

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)
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)