The V Word
Validation – this word has been making many in pharma industry shudder at the thought for almost 15 years. In 1997, the FDA released 21 CFR part 11 – new regulatory code aimed at establishing the rules and expectations for using computer systems (specifically electronic records and electronic signatures) in place of physical records for regulated activities. In this context the regulations are the GxP “predicate rules” such as GLP, GCP, and GMP. Such computer systems had not been specifically permitted before this time. While the allowance of new technology was a relief, the interpretation of the rules threw many for a loop.
The FDA released guidance documentation in 2003, which helped clarify scope and application of the rules. Over the past 15 years, the industry has integrated the regulations into their IT operations, sometimes at great cost, but the goal always being to ensure quality product. One common example of the type of computer system that is regulated and required to be validated is the manufacturing batch record. Validating such a system should demonstrate convincingly that the measurements coming off the production line are accurately stored and are able to be accurately retrieved at any point in the lifetime of that data.
So what goes into validation that makes it painful? First, there is the concept of qualification. This typically refers to hardware and infrastructure, and is a set of steps and records that are kept to ensure that a system is specified in minute detail and that it is not tampered with or changed in an uncontrolled manner. Even normal system maintenance, such as operating system patch updates, must be explicitly approved, documented and tested in a qualified environment.
There is also the concept of the audit trail. This generally refers to data or meta-data kept to show a re-traceable record of all changes and deletions to regulated data. That means for every row in a database that gets updated, there must be some data that shows which system operator made the change and that a time and date stamp is recorded. The entire history of a data record must be available for review and audit. Audit trails aren’t a standard feature in all database platforms, so this can lead to the likely possibility of extra coding, selection of a more expensive DBMS, and significant increase in testing effort.
Another concept of computer systems validation is traceability. Traceability starts with specific, testable requirements, which all design, code, and testing elements can be linked back to. The theory is that this has value in both directions. Unauthorized code can’t be added to a system if there is not a requirement for it. Conversely, for each requirement, tracing to the linked design elements and code blocks allows thorough testing of all areas of the system that are related to that requirement. Effective traceability requires extensive and thorough documentation, and quite often complex Quality Management Systems to support this.
There are other elements of validation as well, but with these three main pillars, there are some elements of software and systems development and quality assurance you may not expect or plan for (especially if you’re a web-based startup). Other industries have similar, and even more rigorous, guidelines and standards. See MISRA C++ coding standards for automotive for example.
ISPE is one pharma industry organization who as been the forefront of establishing best practices for Computer Systems Validation. Their GAMP 5 guidance document provides a pragmatic and specific interpretation and steps for implementing, maintaining, and retiring validated systems. This group has been influential enough to where the new EU Annex 11 regulation (Europe’s counterpart to 21 CFR Part 11) mirrors the GAMP 5 protocol which was released a few years earlier.
Operating in IT in the pharma industry requires experience, patience, and a commitment to quality. Ultimately, the manufacturer of product is responsible for the quality of their product, and it’s their responsibility to ensure that their internal IT staffs and IT vendors are conforming to regulations.
Author
