Systems Validation for 21CFR Part 11 Compliance

21CFR part 11 requires that all systems that govern any cGXP process - including Good Manufacturing Practices (GMPs), Good Laboratory Practices (GLPs), and Good Clinical Practices (GCPs), should be validated. FDA issued a very comprehensive guidance on systems validation in a document released in January 2002. This white paper uses that FDA guidance as an input to define an “easy-to-implement” framework for systems validation. Finally the paper identifies a best practice which calls for IT organizations and software vendors to proactively audit their software development and implementation processes on an ongoing basis to identify and correct any systemic issues to lower the cost of compliance.

Why System Validation?
Current Good Manufacturing Practices (cGMP) are mandated by the FDA to ensure that the products manufactured by the industries such as pharmaceutical, biotech and medical devices, meet specific requirements for identity, strength, quality, and purity. In order to comply with cGMP, companies are required to record, track, manage, store and easily access various production documents and their detailed change history including Standard Operating Procedures (SOPs), Master Production Batch Record (MPBR), Production Batch Record (PBR), Equipment log books etc. Historically, all such documents have been maintained on paper by companies in order to comply with FDA's cGMP. Even as companies automated their production and quality processes, they were still being forced to maintain and track paper records for FDA acceptance. The code of Federal Regulations (CFR) Part 11 was implemented in 1997 to let the FDA accept electronic records and signatures in place of paper records and handwritten signatures for compliance. The regulation outlines controls for ensuring that electronic records and signatures are trustworthy, reliable, and compatible with FDA procedures and as verifiable and traceable as their paper counterparts.

Hence 21 CFR Part 11 also specifies a number of requirements for software systems to enable trustworthy and reliable electronic records and signatures - see Figure 1. These software requirements must be met for the resulting electronic records to comply with FDA's cGMP. If an organization does employ electronic records and signatures, but fails to comply with these system requirements, the FDA will cite the firm for violating the underlying regulation. For example, if a drug company maintains its written complaint records, required by 21 CFR 211.198(b), in electronic form, but the agency finds that these records are unacceptable substitutes for paper records, the FDA would charge the firm with violating 211.198(b). The potential impact might include FDA requested recall, FDA mandated recall, Warning Letter, seizure, injunction, prosecution, civil penalties, and detention

Figure 1: Scope of 21CFR Part 11 Requirements Source: CGE&Y
(Please click on image for enhanced version)

System Validation is a key 21CFR Part 11 requirement - its primary benefit is to assure quality and performance of the systems deployed to manage any cGxP process. It is the establishment of documented evidence that provides a high degree of assurance that a specific process, managed by the system, will consistently yield a product meeting its predetermined specifications and quality attributes. The ultimate goal of any system validation project is to realize and sustain compliance, while ensuring the peak performance and functionality of those systems.

What is System Validation?
Validation is the process of compiling written verification of all system functions and the performance of those functions to system specifications, as well as data integrity and system maintenance. That written documentation must be in alignment with the industry standards and regulatory laws that guide the FDA in their evaluation and enforcement of regulatory compliance. To successfully manage compliance, each regulated system must be proven to operate in accordance with its intended use and design, and all documentation supporting that evidence must culminate in FDA-acceptable documentation.

The FDA’s General Principles of Software Validation – “Final Guidance for Industry and FDA Staff”, published jointly by CDRH and CBER was originally written with the medical device industry as its intended audience. (See www.fda.gov/cdrh/comp/guidance/938.html). This guidance describes how certain provisions of the medical device Quality System regulation apply to software and FDA’s current approach to evaluating a software validation system. Any software used to automate any part of the device production process or any part of the quality system must be validated for its intended use, as required by 21 CFR 820.70(i). Hence, this requirement applies to any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system. In addition, computer systems used to create, modify, and maintain electronic records and to manage electronic signatures are also subject to the validation requirements. Systems that maintain certain employee training records may even be subject to validation. Such computer systems must be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.

This guidance is now being held up to the rest of the FDA-regulated world as an example of best practices in computer system validation. This guidance is now used to validate systems that are governed by any of the GxP regulations, including Good Manufacturing Practices (GMPs), Good Laboratory Practices (GLPs), and Good Clinical Practices (GCPs.)

Framework for System Validation
While various consulting companies have created their own methodologies for systems validation, our experience shows the following framework to be the comprehensive and applies to both -off-the-shelf software or home grown. This framework ensures that the software being deployed is most likely to be compliant with FDA requirements and will continue to sustain the compliance over time. Key elements of that framework include:

• Compliance with core 21CFR Part 11 requirements: This element ensures that the software is compliant with key requirements of the regulation including
• Any change to any record is captured in the audit trail and these entries are time stamped with additional information including operator name and why the record was changed.
• System provides adequate security to prevent unauthorized modification by ensuring role-based access and preventing users from directly updating the database.
• Software employs electronic signatures for any transaction into the system


• Software Development Lifecycle: This element ensures that the software vendor (or an IT organization that develops its own software) follows a clearly defined and documented software development lifecycle to ensure quality and prevent software defects. The components of the lifecycle include:
• All system Requirements must be clearly defined and approved before any design or coding effort starts. All system functions must be identified at this stage.
• System design specification must be clearly documented and design reviews must be done to evaluate the capability of the design to meet system requirements and to identify any problems.
• Test plans, test procedures and test cases should be developed as early in the development lifecycle as possible.
• Coding Standards should be well documented and code reviews must be done to ensure that these standards are followed.
• Multi-level testing methodology including unit test, functional test, integration test and system test must be followed. In addition stress Testing and disaster recovery testing must be performed to ensure that system performance requirements are met.
• Closed-loop change control: This element ensures that proper change control documentation, approval and testing procedures are followed for any changes including, correcting software defects or adding new capabilities for a new version of the software or making changes to software configuration. Change control procedures must be written and well understood through training, to ensure compliance. Unauthorized changes to a validated system, even during the implementation process, can have a detrimental affect on the system integrity.
  
  


Figure 2: Change Control Process
(Please click on image for enhanced version)

• Facility: This element ensures that the vendor facilities (or an IT organization software development lab) employ adequate security controls to prevent unauthorized access to software, computer rooms and backup media storage rooms.
• Organization: This element ensures that the software developers, designers, QA engineers are project managers are trained to perform the technical aspects of their jobs and the company has training policies to ensure they continue to have the right skills on an ongoing basis to do their job.
• Validation for intended use: This element ensures that the requirement specifications are developed for the intended use of the system. The system documentation is compared to the intended use specification to identify any gaps. Then the system is tested against the intended use specification to identify any additional gaps. Any major gaps are fixed using the closed-loop change control method described above and retested before the system is validated as ready for intended use.

Organizations that implement this framework find it easier to keep their system FDA validated on an ongoing basis.

Using a QMS system for Proactive System Validation
In a world where technology and business practices are dynamic rather than static, reactive compliance audit methodologies provide questionable value. Best practices call for IT organizations and software vendors to use the above framework to proactively audit their software development and implementation processes on an ongoing basis to identify and correct any systemic issues. Industry leaders are deploying Quality Management Systems (QMS) within their IT/development organizations to streamline and automate the entire internal audit and corrective action process.

The QMS system serves as a system-of-record for the systems validation project. All documents including SOPs, specifications and test plans are stored in its repository. The QMS audit capabilities are used to create and track an audit checklist and its results. Once issues have been identified through the internal audit process, the first step is to initiate an investigation and to properly identify the root cause of the problem. After the root cause has been identified, Corrective Action (CAPA) items are created. When corrective actions are approved, appropriate changes are implemented in the environment through a change-control process and then the CAPA is closed out. These changes may include amendments to a documented procedure/SOP or creating a new documented procedure/SOP when one is lacking, or placing controls to ensure that the documented process is followed, or upgrading the skill set of an employee through a training and certification process. Its dashboard provides IT and regulatory management ongoing view into the process metrics. By using a QMS, companies ensure that the ongoing and proactive audit and corrective action process is systematized and provides the basis for lowering the cost of compliance.

In summary, system validation is not a onetime project – it is an ongoing process. Through a combination of a good implementation of system development lifecycle and proactive internal auditing of the software development and implementation process, companies can easily comply with the system validation requirements of 21CFR part 11 at a lower cost of compliance.

About MetricStream
MetricStream is a market leader in Enterprise-wide Compliance and Quality Management software for global corporations. Leading companies in the Pharmaceutical industry are using MetricStream’s products to comply with 21CFR Part 11 and cGMP regulations. MetricStream is headquartered in Redwood Shores, California and can be reached at www.metricstream.com.

Please send feedback on this paper or ideas for additional research topics to the author at agupta@metricstream.com