This article is the third in a series of articles on compliance with the electronic signatures/electronic records rule found in 21CFR11. The previous articles summarized the requirements of Part 11 and specifically looked at the high-level, policy SOPs necessary to satisfy the validation requirement as well as requirements and design documentation.
This article will also focus on the validation requirement of Part 11. Here we will look at the specific elements necessary to meet the validation requirements for each computer system for test documentation.
Test Documentation
Following a System Life Cycle model, test documentation is developed based on the requirements and system functionality as defined in the system requirements documentation. The test documentation is used to verify that each requirement and function defined in the requirements documentation has been implemented in the design of the system.
Test documentation covers both hardware and software. The testing of the system is generally divided into three sections: Installation testing verifies that the physical installation of the system meets the defined requirements; Operations testing verifies that the system performs the defined system functionality; Performance testing verifies that the system will operate at the extreme boundaries of limits of the requirements and functionality, i.e., maximum volume and system stress. Installation testing and some form of operational testing are performed on all systems, while Performance testing is used for scalable systems and custom (categories 4 and 5) systems.
First, we must discuss the guidelines for the development of test documentation, defining how to write test cases and what tests are required for each complexity category model. Then, we will define how to document the execution of the test cases.
The guidelines presented in this section for the development of testing documentation shall follow the complexity model presented in Table 1 (p. 54).
Regardless of the complexity of the system, the following sections are required in any testing document.
Header and Footer: The header and footer should follow the format generally used in company SOP documents. For example, headers usually contain standard elements (company name), document type ("Requirements Document," for example), and title of the document ( "Requirements Documentation for LIMS version 2.5.") The footer usually contains at a minimum the page number ("Page 5 of 35.")
Approvals: All requirements documents shall have an approvals section where responsible persons will sign. I would suggest the following persons: the author of the document, the computer systems validation specialist and a member from IT.
Introduction: The introduction is a brief statement of what the system is, what the system does and where it is to be located.
Ownership: The ownership section is a statement identifying the owner of the system. The statement of ownership is written in a generic sense, identifying the department that owns the system and the department manager as the responsible person.
Overview: The overview is a detailed description of the system, indicating what the system is expected to do and how it fits into the operation of the department. If the system described in the requirements document is a replacement for an existing system, a brief description of the current system should be included. Enough detail should be included in this overview to give the reader an understanding of the system and what it does without going into discrete functions.
General Instructions to Testers
This section defines the procedures and documentation practices to be followed when executing the test cases. A further explanation of these procedures and practices are presented later in this document.
Discrepancy Reports: This section defines the procedures to be followed when the actual results of the test do not match the expected results.
Signature Log: This section is used to identify all personnel participating in the execution of the test cases. The person’s printed name, full signature and initials are recorded at the beginning of the execution of the test cases.
References: This section identifies the appropriate reference documents pertinent to the execution of the test cases. These documents shall include the SOP, the appropriate requirements documentation, and the appropriate design documentation.
Prerequisite Documentation: This section lists the validation documentation such as the requirements documentation and the design documentation that is to be in place before the execution of the test cases. The first test case shall be verification that these prerequisites have been met.
Test Equipment Log: This section is a log in which all calibrated test and measuring equipment used during the execution of the test cases is logged.
Test Cases: This section presents the test cases used to verify that the requirements and functions defined in the requirements documentation have been met. Each test case shall test one requirement or function of the system. In some cases, several closely related requirements or functions might be verified in one test case. Test cases shall be written in a landscape page setup using a table format and include the following elements:
• Objective – This is a brief statement indicating what requirement, function or module of the system the test case is intended to verify.
• System Prerequisite – This section describes any previously inputted data or other system status that must be in place to properly execute the test case. For example, when testing system security, users of various security levels may need to be in the system in order to test security levels at login.
• Input Specifications – This section defines any specific input data required to execute the test other than keystroke entries. This may include instrument test data files, barcode files, etc. A specific data file may be identified or the file identified may be generic.
• Output Specifications – This section defines the expected output of the test case other than output to the monitor. The output may be identified as reports, data files, etc.
• Special Procedural Requirements – This section details any special considerations that may be required to successfully execute the test case.
• Test Procedure – The test procedure is setup in a table format with the following column headings:
Procedural Steps – This is a systematic series of instructions to be followed in the execution of the test. These steps should be sufficiently detailed as to allow the test to be duplicated by any qualified personnel without changing the outcome of the test.
Expected Result – For each procedural step, the expected outcome of that step should be defined. The defined outcome should be detailed enough to allow an unequivocal determination of the pass/fail status of the step.
Actual Result – This column is to be left blank and completed by the person executing the test when the step is executed. The actual result of the step is recorded at the time the test is executed.
Pass/Fail – This column is used to record the Pass/Fail status of the test by comparing the actual result to the expected result.
Tester Initials and Date
• Comments – This section is complete following execution of the test case and is used to record any discrepancies or details not captured elsewhere in the test script.
• Test Conclusion – This is an indication of the Pass/Fail status of the test case.
• Tester’s Signature – This section records the signature of the person executing the test case and date.
• Verification Signature – This section re-cords the signature of the person verify ing the test results and date.
Requirements Traceability
Each requirement and function defined or described in the requirements documentation shall be reflected by one or more test cases. Following completion of the test documentation, the requirements documentation shall be reviewed to ensure that each requirement is reflected in the test documentation. The section number of the test case that fulfils the requirement shall be recorded in the second cell of the table in the right margin of the page. This provides a cross-reference between the requirement and the test case and ensures that the requirements are being completely verified.
As requirements of the system change, test cases that no longer have an active requirement shall be voided, not deleted. To void a test case, delete the test but not the section number, then enter "VOID" in place of the text. This prevents sections from being renumbered after a deletion and invalidating the references in the requirements document. This also eliminates the potential for confusion caused by re-assigning a section number previously used for an unrelated design element.
Considerations for Developing Test Cases
Installation Testing
Hardware Installation Testing – Hardware installation test documentation provides a high degree of assurance that the hardware has been installed according to the vendor’s specifications and configured in accordance with the requirements and design documentation for the system. This may include access space, power supply/UPS, network communications, interconnecting wiring/ cabling, ambient temperature, ambient relative humidity and peripheral systems connections.
Software Installation Testing – Software installation test documentation also provides a high degree of assurance that the software has been installed according to the vendor’s specifications and configured in accordance with the requirements and design documentation for the system. Hardware installation testing must be performed before installation and testing software. Software installation testing applies to all software components that are a part of the system including operating system software, network and communications software, OEM software and custom software. It should also include virus checking, verification of required drive space, RAM space and drive configuration, software version numbers, security access for installation and operation, directory configuration, path modifications and any system parameter configuration.
Operational Testing
Operational test documentation provides documented evidence that the system fulfils the requirements and functions as defined on the requirements documentation. Each function described in the requirements documentation shall be tested independently.
When a function is defined with a specified range of inputs or range for a data field, that function shall be tested at each end of the range. For example, if the range of acceptable inputs is 1 to 5, the test case shall challenge the functions using inputs of 0, 1, 5 and 6, with 0 and 6 expected to fail.
Test cases shall also test to verify that illogical inputs are not accepted. For example, test cases shall challenge a date function with non-date inputs, or a numeric field with non-numeric characters.
For COTS applications, many times the vendor will supply the test cases. These may be used in lieu of test cases developed in-house. There shall be a documented review of the test cases provided by the vendor relative to the functional documentation to ensure that the vendor test cases are sufficient. For applications where vendor-supplied test cases are used, requirements for the various functions of the application shall not be required, provided there is documented evidence that the vendor has followed a validation methodology.
Performance Testing
Performance testing ensures that the system shall stand up to daily use. Test cases during performance testing shall verify that the system can function properly during times of high user input and high data throughput.
Performance testing is not always applicable. For systems with only a single user, stress on the system is inherently limited. Performance testing is usually executed on complex systems with multiple inputs and outputs as well as network-based systems.
Test Execution
Before the start of testing, all personnel participating in the execution shall enter their names, signatures and initials in the signature log of the test documentation.
Once execution of a test case is started, that test case must be completed before moving to the next test case. An exception to this would be if the test case fails, the failure is noted and the next test case is started. Execution of the entire set of test cases does not have to be completed in one sitting, though once testing begins, the systems may not be altered. Any failed tests shall be recorded and testing shall continue unless the failure prevents continuation. If testing must be discontinued in order to correct any issues in the system, then all tests must be re-executed.
As test cases are executed, information shall be recorded neatly and legibly in black ink. Sign-off and dating of the test case shall occur on the day that the test case was executed. Mistakes made during execution of the test cases shall be corrected using a single strikethrough, so as not to obscure the original data. Any corrections made in this manner shall be initialed and dated by the person making the correction.
Errors in the test script shall be corrected using a single strikethrough so as not to obscure the original data. Any corrections made in this manner shall be initialed and dated by the person making the correction. Any corrections made to the test case during execution shall be justified in the comments section of the test case.
Completed test forms shall not contain any blank spots where information might be entered. If an item does not apply to the current test, the tester should fill in a ‘N/A’ followed by an initial and date. Completed tests are reviewed and approved by the Computer Systems Validation Specialist, or designee, who signs and dates the bottom of each approved test page.
Test Failures and Discrepancy Reports
Results of tests that do not match the expected results shall be considered failures. The failure of a single step of the test case shall force the failure of the test case. However, if a step in the test case fails, execution of the test case shall continue unless the failure prevents completion of the test case.
Errors in the test case that would result in test case failure if left alone may be corrected as noted above. This correction must be justified in the comments section of the test case. Steps in the test case where the expected result is in error shall not be considered test failures if corrected. Test failures shall be noted in the test case and documented on a test discrepancy form. The form is then logged to facilitate tracking of errors during system testing.
Upon resolution of the failure, the cause of the failure is examined with respect to the failed test case and any similar test cases. All test cases associated with, or similar to, the resolved failed test case shall be reviewed to determine the extent of re-testing required. This re-testing, commonly referred to as regression testing, shall verify that the resolution of the failed test has not created adverse effects on areas of the system already tested. The analysis of the testing shall be documented to justify the extent of the regression testing.
Regression testing shall be executed using new copies of the original test script to ensure that the requirement of the system is still being met. In some instances, resolution of the failed test requires extensive redevelopment of the system. In these cases, a new test case must be developed. In either case, the failed test shall be annotated to indicate the tests executed to demonstrate resolution. The additional tests shall be attached to the discrepancy report. This provides a paper trail from the failed test case, to the discrepancy report and finally to the repeated test cases.
Test Documentation by Complexity Model
Test documentation varies with complexity category. Com-plexity categories are defined in Table 1 above.
Category 1 – Operating Systems: Category 1 systems are local operating systems and network systems. These systems provide the backbone needed by all other systems to operate. Due to widespread use of these applications, they do not need to be tested directly. As these systems are the base of other applications, they are indirectly tested during the testing of other applications.
Category 2 – Smart Instruments: Category 2 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 2 systems. Installation and Operational Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system. Performance Testing is not required.
Category 3 – COTS Applications: All functions and operations embedded by the manufacturer of the COTS do not need to be tested. Only those functions and operations used by the applications developed in-house require testing.
Category 3 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 3 systems. Installation and Operational Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system. Performance Testing is not required.
Category 4 – Configurable Software Systems: Category 4 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 2 systems. Installation and Operational Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system. Performance Testing should be considered if the system shares data on a network.
Category 5 – Fully Custom Systems: Category 5 systems shall be tested following the requirements and functions listed in the requirements documentation. All sections of the testing document as defined in the section "General Consideration for Developing Test Cases" listed above shall be included in the test document for Category 5 systems. Installation, Opera-tional Testing and Performance Testing shall be executed. The complexity of the test cases should be commensurate with the complexity of the system.
Following a System Life Cycle model, test documentation verifies that all requirements have been properly met in the design phase of software development. Future articles will follow the SLC model into the next phase of software validation: change control.
Friday, June 19, 2009
Validation Requirements
Electronic Records & Electronic Signatures
When 21 CFR Part 11 was released on March 20, 1997, it was given an effective date of August 20, 1997. By any measure, Part 11 was a surprise to the healthcare manufacturing industry. Many of us had waited for the Agency's approval to use electronic signatures, and the concerns of industry proponents about electronic signatures centered on the belief that the Agency would allow for their use only after the incorporation of various complicated security biometrics. We expected that the provisions for electronic signatures would potentially include requirements for retinal scans, thumb prints, voice identification, etc.
When Part 11 was released, the security control requirements for electronic signatures were fairly straightforward and benign. The requirements for electronic signature manifestations and the use of a dual user's identification and password were very clear and reasonable. But the section of Part 11 that dealt with electronic records was anything but benign. That section required predicate rule-mandated records created and maintained electronically, to comply with the Part 11 requirements, i.e., audit trail, system security, system self-check, etc. There was no provision for grandfathering legacy systems into compliance with Part 11. This is a big deal, impacting literally thousands of legacy systems in the regulated industry. Furthermore there was no provision for a grace period.
Part 11 was not widely reviewed or discussed prior to its effective date, and many quality and regulatory professionals stumbled into the legacy system impact of Part 11 only after they began to read and study the rule in anticipation of pursuing the application of electronic signatures. In the last two years, the industry has begun to understand more fully the implications and impact of the final rule on its computerized systems. The rule does not create any new record or signature requirements. The use of electronic records as well as their submission to FDA is voluntary. The agency can use regulatory discretion and compliance expectations may be realized gradually.
The realities of Part 11 include the following facts: We are now more than four-and-a-half years past the effective date and Part 11 is not going to go away. Our booming e-commerce industry will only strengthen the need for controls of electronic records and signatures. The FDA provided for only a five-month implementation period so, as a result, the industry has been trying to work out of a state of noncompliance. We should be past grousing and complaining about Part 11 and well into trying to understand it and implementing remediation plans.
Definition and Field
An electronic record is defined as any combination of text, graphics, data, audio, pictorial or other information representation in digital form that is created, modified, maintained, archived, retrieved or distributed by a computer system, and is applicable to records required by any other FDA regulation and applicable to records submitted to FDA under the Food, Drug &Cosmetic Act or the Public Health Service Act, even if not required by FDA. The goal of the regulation is to provide a framework and set of rules for developing sound business practices to ensure the trustworthiness and reliability of electronic data, documents and signatures that are transmitted to FDA. It requires that industry demonstrate its ability to develop and maintain reliable and secure computer systems and sound business processes around these systems. Specifically, the rule applies to data captured in a computer system (electronic records) and signatures or authorizations generated by a computer (electronic signatures) as well as the security controls and business processes associated with them.
Electronic Records Provisions
Closed Systems: A closed system is defined as an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system. Controls for closed systems:
Open Systems: An open system is defined as an environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system. Controls for open systems:
Hybrid System: A hybrid system is defined as a system for which handwritten signatures executed on paper and paper-based records (if applicable) are maintained in addition to electronic records. The controls for hybrid systems are a combination of the above two systems.
Signature/record linking:
Signature Manifestations:
Electronic Signatures Provisions
Part 11 defines specific requirements for the design, use and implementation of computer systems that create, modify, maintain, archive and retrieve electronic records with or without electronic signatures. These requirements can be achieved either by technical or procedural implementation. Some requirements may include both a technical solution in the design of the system and a procedural process. Procedural processes may be used also as interim solutions while technical solutions are being developed and implemented. The electronic signature must be unique to an individual and not reassigned, and the identity of the individual must be verified by organization. It must be certified. The FDA example is given below:
"This is to certify that {Company X} intends that all electronic signatures executed by our employees, agents or representatives, located anywhere in the world, are the legally binding equivalent of traditional handwritten signatures."
Electronic signature components and controls:
Controls for identification codes/passwords:
Audit Trail
One of the biggest concerns regarding Part 11 compliance is defining when the audit trail begins. Take a pragmatic approach, proceduralize it, adhere to it and be prepared to defend it. Audit trail initiation requirements for data should be different from audit trail initiation requirements for textual materials, such as operating procedures, reports or guidelines. If you are generating, retaining, importing or exporting any electronic data, the audit trail begins from the instant the data hits durable media. This should be recognized as an operational and regulatory imperative. It needs to be absolutely and demonstrably inviolate in this regard. But if the electronic record is textual and subject to review and approval, the audit trail begins upon the approval of the document.
Retaining the pre-approval iterations in the audit trail is not value added. If an operating procedure, for example, is typed into a word processor (stored to durable media or not) and subsequently routed either in hard copy or electronically for review and approval, it is not versioned until it is approved by all required approvers. The following procedures are imperative:
With these procedural controls in place, the textual document is not complete and usable until it has been formally approved and released. At this point, the 21 CFR Part 11 required audit trail is applicable. Obviously, the predicate rule drives the need for a document and subsequently the document's approval, versioning and retention requirements. If the predicate rule does not require the retention of the document's draft versions, Part 11 does not apply to draft versions. However, as I write that, I believe that, during the document's iterative draft stages, it is necessary to fully control the draft versions until the document has been approved for use. Upon approving and version controlling the final version, all electronic draft versions of the document can be deleted. An example of this is as follows:
The draft version document described in Step 3 is controlled and saved only until the final version, described in step 4, is approved and version controlled. After the approval of the final document, any versions or copies of the draft document can be deleted.
Agency representatives have differed on the point at which the Part 11 audit trail becomes applicable. The perspectives within the agency have ranged from a very conservative umbrella statement of, "whenever anything is stored to durable media," to the more pragmatic approach previously described for audit trailing textual documents that are not available for use until approved, released, version controlled and retained per predicate rule requirements. With 21 CFR Part 11 requiring an audit trail for human-entered transactions, as opposed to those initiated by machine or computer, and not describing exactly when the audit trail begins, the industry and the FDA must develop a consistent and reasonable approach to resolving this issue.
Compliance Strategy
FDA References
Systems Covered
Plan
SOPs
Policies
Compliance Mission
Many companies have adopted the following Part 11 compliance approach, keeping in mind the following mission statement:
"To develop an action plan for addressing Part 11 requirements in existing systems and to support the preparation and training of business processes and procedures to assure the development, implementation and use of compliant systems in accordance with the FDA regulations."
Compliance Plan
In order to determine a remediation path, it is necessary to project accurately the remediation cost of each system. This will include determining whether the most effective course of action is to upgrade the existing system, buy a new system that can be brought into compliance, buy a system that is scheduled to be in compliance, or buy a system that is already in compliance with Part 11.
Interdisciplinary Remediation Planning
When Part 11 remediation plans are being developed, it is essential that Quality Assurance, Regulatory Affairs/Compliance, Operations, and Information Systems personnel are all jointly involved in the planning. The software, equipment and intended use have to be considered at the very outset of planning. Is the record required by a predicate rule? What is the actual application and use of the equipment/ software? What is the criticality of the system? What is the extent of the noncompliance? Can the program be brought into compliance? Is a compliant new system available? These questions are best answered from a multidisciplinary perspective.
Legacy Systems
Part 11 remediation is especially frustrating for older systems that have been validated to other standards and have been operating in an otherwise nonproblematic state. Legacy system remediation presents a unique dilemma because spending a significant amount of time and money to update an older system could appear to be of limited value. However, remaining in noncompliance while new and compliant systems are sought is fraud with regulatory peril and can't be taken lightly. It may be very costly to remediate these systems, but the fact remains that Part 11 does not provide for grandfathering legacy systems, and it does allow the industry to use electronic signatures.
Software and System Suppliers
Software and equipment suppliers have begun to understand that Part 11 represents a new set of expectations for their products, and many are trying to respond, but most are not there yet. It has become apparent that "buyer beware" is a term or concept that is very applicable to Part 11 compliance efforts. In a recent review of several well-known systems/ software packages that were advertised as "Part 11 compliant," it was evident that some aspects of Part 11 were addressed, but others were not. It is imperative that manufacturers understand the requirements of the final rule and are in a position to ask the right questions of their suppliers.
Laboratory Equipment
The remediation approach of replace or upgrade will need to be looked at on a system-by-system basis or at least a system-type basis. Laboratory equipment will need to be assessed after a gap analysis has determined the level of noncompliance. If an analyzer is not designed to store data to durable media, and it holds the analysis in RAM, prints out the analysis results, and subsequently deletes the results from RAM to make way for the next analysis, it is generally interpreted that Part 11 does not apply. The electronic typewriter concept pertains, with the paper copy becoming your raw data, subject to appropriate predicate rule retention requirements.
If an analyzer stores analysis data to durable media, Part 11 applies. The raw data in this case is the electronic data, and any subsequent hard-copy printout of the data is ancillary. The printout must be, as part of the systems validation, demonstrated to be the same as electronic raw data. But the presence of paper copy does not remove the Part 11 requirements that probably represent the easiest and most direct compliance approach. If the analyzer can't be readily upgraded, the new purchase option exists, but the vast majority of new analyzers themselves are noncompliant.
FDA-regulated industry is just one player in the overall laboratory analyzer market, and demands from the industry to make new analyzers Part 11 compliant can be much like the tail trying to wag the dog. The industry believes that, while this can eventually meet with positive results, it is more likely to be met with frustration in the short run.
Discuss your options and be creative and innovative in your remediation approach. If your analyzers can't be made Part 11 compliant, get a laboratory information management system (LIMS) or an external data control system that can. Treat your analyzers as second generation for your LIMS, and assure that your LIMS software is Part 11 compliant. The FDA is not prescriptive relative to where the data is retained, which file or database. You are required to validate your system and to be able to demonstrate that your system and its data acquisition, retention and Part 11 controls are solid and repeatable.
Solutions
Information systems professionals, when introduced to Part 11 requirements, have come up with innovative solutions to the remediation quandary. With Part 11 providing the capacity for audit trailing to be accomplished via the use of ancillary equipment or different databases, the industry has the opportunity to view entire interrelated and interconnected systems looking for the most opportune mechanism to fulfill the various Part 11 requirements. Examples of this are the use of Documentum's underlying Oracle database to record time/date transactions or the use of an NT server's security function to provide the required level of systems security for an application accessed on line utilizing the server.
Many commercially available software programs already have systems self-checks and alert database administrators to prevent entry attempts. Instead of being dismayed by the complexity and all-encompassing nature of 21 CFR Part 11, we need to accept the likelihood that we will probably not find an answer that does it all for every system. We must begin to look opportunistically at the systems, equipment and processes that we already have in place for resolution.
The pharmaceutical industry is actively working to develop plans to address full compliance with Part 11. It has already taken several steps toward adherence to the rule in preparing standards for the development, validation and use of computer systems. The industry has begun to oversee the remediation of business systems, business processes and the development of new business systems used to generate, store and authorize information delivered to the FDA. It will also be used to drive and support the use of good business practices around the development and use of computerized systems. Part 11 will remain with us, and organizations that have delayed remediation are falling further behind the compliance power curve. Investigators are trained on Part 11, FDA 483 citations are being issued, and Part 11 violations are being noted in warning letters. Part 11, whether you like it or not, whether you feel it's needed or not, is a released Final Rule in the Code of Federal Regulations governing our industry and must be adhered to.
It is "foolish" to try to wait it out. You will fall further behind your peers and your competition, and you will put your organization at risk. The industry, working with the FDA, must develop a consistent and reasonable approach to resolving the Part 11 issue. Understand the rule, understand your requirements, and by all means understand your opportunities. Keep track of your plan, your actions and accomplishments, your innovations and solutions, and your remediation expenses.
When Part 11 was released, the security control requirements for electronic signatures were fairly straightforward and benign. The requirements for electronic signature manifestations and the use of a dual user's identification and password were very clear and reasonable. But the section of Part 11 that dealt with electronic records was anything but benign. That section required predicate rule-mandated records created and maintained electronically, to comply with the Part 11 requirements, i.e., audit trail, system security, system self-check, etc. There was no provision for grandfathering legacy systems into compliance with Part 11. This is a big deal, impacting literally thousands of legacy systems in the regulated industry. Furthermore there was no provision for a grace period.
Part 11 was not widely reviewed or discussed prior to its effective date, and many quality and regulatory professionals stumbled into the legacy system impact of Part 11 only after they began to read and study the rule in anticipation of pursuing the application of electronic signatures. In the last two years, the industry has begun to understand more fully the implications and impact of the final rule on its computerized systems. The rule does not create any new record or signature requirements. The use of electronic records as well as their submission to FDA is voluntary. The agency can use regulatory discretion and compliance expectations may be realized gradually.
The realities of Part 11 include the following facts: We are now more than four-and-a-half years past the effective date and Part 11 is not going to go away. Our booming e-commerce industry will only strengthen the need for controls of electronic records and signatures. The FDA provided for only a five-month implementation period so, as a result, the industry has been trying to work out of a state of noncompliance. We should be past grousing and complaining about Part 11 and well into trying to understand it and implementing remediation plans.
Definition and Field
An electronic record is defined as any combination of text, graphics, data, audio, pictorial or other information representation in digital form that is created, modified, maintained, archived, retrieved or distributed by a computer system, and is applicable to records required by any other FDA regulation and applicable to records submitted to FDA under the Food, Drug &Cosmetic Act or the Public Health Service Act, even if not required by FDA. The goal of the regulation is to provide a framework and set of rules for developing sound business practices to ensure the trustworthiness and reliability of electronic data, documents and signatures that are transmitted to FDA. It requires that industry demonstrate its ability to develop and maintain reliable and secure computer systems and sound business processes around these systems. Specifically, the rule applies to data captured in a computer system (electronic records) and signatures or authorizations generated by a computer (electronic signatures) as well as the security controls and business processes associated with them.
Electronic Records Provisions
Closed Systems: A closed system is defined as an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system. Controls for closed systems:
| • | Establish minimum controls for all systems; |
| • | Are designed to assure authenticity, integrity and confidentiality (as appropriate); |
| • | Are designed to ensure that the signer cannot readily repudiate the signature as genuine; |
| • | Validate the systems to ensure accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records; |
| • | Maintain the ability to generate accurate and complete records in human readable and electronic form so that FDA may inspect, review and copy the records; |
| • | Protect records so that they are readily retrievable throughout the retention period; |
| • | Limit system access to authorized individuals; |
| • | Use secure, computer-generated, time-stamped audit trails for operator entries and actions; |
| • | Do not obscure previous entries; |
| • | Use operational system checks to enforce sequencing steps; |
| • | Use authority checks to ensure that only authorized individuals can access and use the system; |
| • | Use device checks to determine the validity of data input or operational instructions; |
| • | Ensure appropriate training of users, developers and maintenance staff; |
| • | Establish and follow written policies that deter falsification of records and signatures; |
| • | Establish adequate controls over the distribution of, access to, and use of system documentation; |
| • | Establish adequate controls over revisions and changes and maintain audit trails of modifications to system documents. |
Open Systems: An open system is defined as an environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system. Controls for open systems:
| • | Ensure authenticity, integrity and confidentiality (as appropriate) of records from point of creation to point of receipt |
| • | Employ all of the controls required for closed systems |
| • | Implement document encryption. |
| • | Implement digital signatures. |
Hybrid System: A hybrid system is defined as a system for which handwritten signatures executed on paper and paper-based records (if applicable) are maintained in addition to electronic records. The controls for hybrid systems are a combination of the above two systems.
Signature/record linking:
| • | Applies to electronic and handwritten signatures. |
| • | Must ensure that the signatures cannot be excised, copied or otherwise transferred to falsify an electronic record. |
Signature Manifestations:
| • | Signed electronic records must include: |
| - Printed name of the signer | |
| - The date and time of the signature | |
| - The meaning of the signature (e.g., review, approval, authorship) | |
| • | Electronic signatures are subject to same controls as electronic records. |
| • | The information required must be included in any human-readable copy of the record. |
Electronic Signatures Provisions
Part 11 defines specific requirements for the design, use and implementation of computer systems that create, modify, maintain, archive and retrieve electronic records with or without electronic signatures. These requirements can be achieved either by technical or procedural implementation. Some requirements may include both a technical solution in the design of the system and a procedural process. Procedural processes may be used also as interim solutions while technical solutions are being developed and implemented. The electronic signature must be unique to an individual and not reassigned, and the identity of the individual must be verified by organization. It must be certified. The FDA example is given below:
"This is to certify that {Company X} intends that all electronic signatures executed by our employees, agents or representatives, located anywhere in the world, are the legally binding equivalent of traditional handwritten signatures."
Electronic signature components and controls:
| • | Non-biometric signatures must consist of two distinct components (e.g., an identification code and a password). |
| • | In one continuous session, the first signing must use all components; subsequent signings may use just one component. |
| • | Non-continuous session: use all components of the electronic signature. |
| • | Must be used only by their genuine owner. |
| • | Administered and executed to ensure that use by others is precluded and that any attempted use would require collaboration by two or more individuals. |
| • | Biometric signatures are a method of verifying identity based on measurement of an individual's physical feature(s) or repeatable action(s) where the features and/or actions are both unique to that individual and measurable. |
| • | Voice Prints, handprints, retinal scans |
Controls for identification codes/passwords:
| • | Ensure no two individuals have the same combination. |
| • | Ensure that identification codes and passwords are periodically checked, recalled or revised. |
| • | Electronically deauthorize lost, stolen, missing, or compromised tokens, cards and devices. |
| • | Subject replacements to rigorous controls. |
| • | Conduct initial and periodic tests of tokens and cards for function. |
| • | Use transaction safeguards to: |
| - Prevent unauthorized use of passwords and identification codes. | |
| - Detect and report (in an immediate and urgent manner) attempts at unauthorized use. |
Audit Trail
One of the biggest concerns regarding Part 11 compliance is defining when the audit trail begins. Take a pragmatic approach, proceduralize it, adhere to it and be prepared to defend it. Audit trail initiation requirements for data should be different from audit trail initiation requirements for textual materials, such as operating procedures, reports or guidelines. If you are generating, retaining, importing or exporting any electronic data, the audit trail begins from the instant the data hits durable media. This should be recognized as an operational and regulatory imperative. It needs to be absolutely and demonstrably inviolate in this regard. But if the electronic record is textual and subject to review and approval, the audit trail begins upon the approval of the document.
Retaining the pre-approval iterations in the audit trail is not value added. If an operating procedure, for example, is typed into a word processor (stored to durable media or not) and subsequently routed either in hard copy or electronically for review and approval, it is not versioned until it is approved by all required approvers. The following procedures are imperative:
| • | The document is not used until it has been fully approved and released into the appropriate documentation system. |
| • | The document is not released for use until it has, in a post-altered or amended state, all of the required approvals. |
| • | The document is maintained via appropriate version control and retention requirements. |
With these procedural controls in place, the textual document is not complete and usable until it has been formally approved and released. At this point, the 21 CFR Part 11 required audit trail is applicable. Obviously, the predicate rule drives the need for a document and subsequently the document's approval, versioning and retention requirements. If the predicate rule does not require the retention of the document's draft versions, Part 11 does not apply to draft versions. However, as I write that, I believe that, during the document's iterative draft stages, it is necessary to fully control the draft versions until the document has been approved for use. Upon approving and version controlling the final version, all electronic draft versions of the document can be deleted. An example of this is as follows:
| 1. | An author writes a procedure/report/guideline/etc., and sends a draft copy to five different reviewers/ approvers. |
| 2. | Each reviewer/approver makes a change to the draft copy and sends his/her copy comments back to the original author for incorporation into a new draft version of the document. |
| 3. | The author then consolidates the comments and sends the document back to the reviewers/approvers as a new and controlled draft version. |
| 4. | The new and controlled draft version is approved by the reviewers/approvers, and the document is released as a controlled final version. |
| 5. | After the document has been released as a controlled final version, all draft versions can be deleted. |
| 6. | If the released document is subsequently revised, the above process is repeated and only the various final approved and released versions are retained. The current approved version is retained in an active status, and previous approved versions are retained in an archival status. |
The draft version document described in Step 3 is controlled and saved only until the final version, described in step 4, is approved and version controlled. After the approval of the final document, any versions or copies of the draft document can be deleted.
Agency representatives have differed on the point at which the Part 11 audit trail becomes applicable. The perspectives within the agency have ranged from a very conservative umbrella statement of, "whenever anything is stored to durable media," to the more pragmatic approach previously described for audit trailing textual documents that are not available for use until approved, released, version controlled and retained per predicate rule requirements. With 21 CFR Part 11 requiring an audit trail for human-entered transactions, as opposed to those initiated by machine or computer, and not describing exactly when the audit trail begins, the industry and the FDA must develop a consistent and reasonable approach to resolving this issue.
Compliance Strategy
FDA References
| • | Compliance Policy Guide 7153.7 May 1999 |
| - Nature and extent of deviations | |
| - Effect on product quality and data integrity | |
| - Adequacy and timeliness of corrective actions | |
| - Compliance history (especially data integrity) | |
| • | Guidance - Computerized Systems in Clinical Trials - 1999 |
Systems Covered
| • | Inventory all systems |
| - Proposed | |
| - Current | |
| • | All proposed systems should comply with Part 11 |
| • | Determine threshold of risk the company is willing to accept |
Plan
| • | Develop plan for compliance of high risk systems with time frames |
| • | Demonstrate progress in implementing timetable |
| • | Determine what will be done with other systems—support or validate transcription |
| • | Document process |
SOPs
| • | System setup/installation |
| • | Data collection and handling |
| • | System maintenance |
| • | Data backup, recovery and contingency plans |
| • | Security |
| • | Change Control |
Policies
| • | Systems should clearly identify the electronic version of records as confidential |
| • | Any printout of records should be automatically marked as confidential |
| • | Establish e-mail and voice mail policies |
| • | Inform employees about the legal consequences of certification |
Compliance Mission
Many companies have adopted the following Part 11 compliance approach, keeping in mind the following mission statement:
"To develop an action plan for addressing Part 11 requirements in existing systems and to support the preparation and training of business processes and procedures to assure the development, implementation and use of compliant systems in accordance with the FDA regulations."
Compliance Plan
| • | Study and fully understand Part 11. Applies to electronic and handwritten signatures |
| • | Ensure that signatures cannot be excised, copied or otherwise transferred to falsify an electronic record |
| • | Identify and inventory all of the Part 11-applicable electronic systems |
| • | Develop and apply a Part 11 compliance checklist in order to create a Part 11 compliance gap analysis for systems |
| • | Develop and apply a systems criticality matrix that can be used to prioritize systems for Part 11 remediation |
| • | Develop and execute against a comprehensive Part 11 remediation schedule |
In order to determine a remediation path, it is necessary to project accurately the remediation cost of each system. This will include determining whether the most effective course of action is to upgrade the existing system, buy a new system that can be brought into compliance, buy a system that is scheduled to be in compliance, or buy a system that is already in compliance with Part 11.
Interdisciplinary Remediation Planning
When Part 11 remediation plans are being developed, it is essential that Quality Assurance, Regulatory Affairs/Compliance, Operations, and Information Systems personnel are all jointly involved in the planning. The software, equipment and intended use have to be considered at the very outset of planning. Is the record required by a predicate rule? What is the actual application and use of the equipment/ software? What is the criticality of the system? What is the extent of the noncompliance? Can the program be brought into compliance? Is a compliant new system available? These questions are best answered from a multidisciplinary perspective.
Legacy Systems
Part 11 remediation is especially frustrating for older systems that have been validated to other standards and have been operating in an otherwise nonproblematic state. Legacy system remediation presents a unique dilemma because spending a significant amount of time and money to update an older system could appear to be of limited value. However, remaining in noncompliance while new and compliant systems are sought is fraud with regulatory peril and can't be taken lightly. It may be very costly to remediate these systems, but the fact remains that Part 11 does not provide for grandfathering legacy systems, and it does allow the industry to use electronic signatures.
Software and System Suppliers
Software and equipment suppliers have begun to understand that Part 11 represents a new set of expectations for their products, and many are trying to respond, but most are not there yet. It has become apparent that "buyer beware" is a term or concept that is very applicable to Part 11 compliance efforts. In a recent review of several well-known systems/ software packages that were advertised as "Part 11 compliant," it was evident that some aspects of Part 11 were addressed, but others were not. It is imperative that manufacturers understand the requirements of the final rule and are in a position to ask the right questions of their suppliers.
Laboratory Equipment
The remediation approach of replace or upgrade will need to be looked at on a system-by-system basis or at least a system-type basis. Laboratory equipment will need to be assessed after a gap analysis has determined the level of noncompliance. If an analyzer is not designed to store data to durable media, and it holds the analysis in RAM, prints out the analysis results, and subsequently deletes the results from RAM to make way for the next analysis, it is generally interpreted that Part 11 does not apply. The electronic typewriter concept pertains, with the paper copy becoming your raw data, subject to appropriate predicate rule retention requirements.
If an analyzer stores analysis data to durable media, Part 11 applies. The raw data in this case is the electronic data, and any subsequent hard-copy printout of the data is ancillary. The printout must be, as part of the systems validation, demonstrated to be the same as electronic raw data. But the presence of paper copy does not remove the Part 11 requirements that probably represent the easiest and most direct compliance approach. If the analyzer can't be readily upgraded, the new purchase option exists, but the vast majority of new analyzers themselves are noncompliant.
FDA-regulated industry is just one player in the overall laboratory analyzer market, and demands from the industry to make new analyzers Part 11 compliant can be much like the tail trying to wag the dog. The industry believes that, while this can eventually meet with positive results, it is more likely to be met with frustration in the short run.
Discuss your options and be creative and innovative in your remediation approach. If your analyzers can't be made Part 11 compliant, get a laboratory information management system (LIMS) or an external data control system that can. Treat your analyzers as second generation for your LIMS, and assure that your LIMS software is Part 11 compliant. The FDA is not prescriptive relative to where the data is retained, which file or database. You are required to validate your system and to be able to demonstrate that your system and its data acquisition, retention and Part 11 controls are solid and repeatable.
Solutions
Information systems professionals, when introduced to Part 11 requirements, have come up with innovative solutions to the remediation quandary. With Part 11 providing the capacity for audit trailing to be accomplished via the use of ancillary equipment or different databases, the industry has the opportunity to view entire interrelated and interconnected systems looking for the most opportune mechanism to fulfill the various Part 11 requirements. Examples of this are the use of Documentum's underlying Oracle database to record time/date transactions or the use of an NT server's security function to provide the required level of systems security for an application accessed on line utilizing the server.
Many commercially available software programs already have systems self-checks and alert database administrators to prevent entry attempts. Instead of being dismayed by the complexity and all-encompassing nature of 21 CFR Part 11, we need to accept the likelihood that we will probably not find an answer that does it all for every system. We must begin to look opportunistically at the systems, equipment and processes that we already have in place for resolution.
The pharmaceutical industry is actively working to develop plans to address full compliance with Part 11. It has already taken several steps toward adherence to the rule in preparing standards for the development, validation and use of computer systems. The industry has begun to oversee the remediation of business systems, business processes and the development of new business systems used to generate, store and authorize information delivered to the FDA. It will also be used to drive and support the use of good business practices around the development and use of computerized systems. Part 11 will remain with us, and organizations that have delayed remediation are falling further behind the compliance power curve. Investigators are trained on Part 11, FDA 483 citations are being issued, and Part 11 violations are being noted in warning letters. Part 11, whether you like it or not, whether you feel it's needed or not, is a released Final Rule in the Code of Federal Regulations governing our industry and must be adhered to.
It is "foolish" to try to wait it out. You will fall further behind your peers and your competition, and you will put your organization at risk. The industry, working with the FDA, must develop a consistent and reasonable approach to resolving the Part 11 issue. Understand the rule, understand your requirements, and by all means understand your opportunities. Keep track of your plan, your actions and accomplishments, your innovations and solutions, and your remediation expenses.
Packaging Process Validation
Packaging process validation is often supplemented by 100% inspection online. Many firms take the approach that a 100% online inspection is the way to go. Even today, many companies have inspectors set up offline to sort out or rework unacceptably packaged product. Often, process variables are not adequately studied or the process is not observed to “nail it” through process validation. The following approach used by a large pharmaceutical company to validate the blister packaging process may shed some insights on how Design of Experiments (DOE)—prior to packaging validation—can help.
This case study is about an OTC product. The product launch date was set in stone; the marketing managers were even talking about pre-launching the product to select large-scale retailers. The operations team was under tremendous pressure to finish the process validation and pre-launch activities of this OTC product. The product was a coated tablets, the packaging put-up was a carton with three blister cards, each card with eight tablets per card, making it a pack of 24 tablets.
The team consisted of a Packaging Engineer, an Operations Engineer, a Production Manager, a Quality Engineer and a Project Manager. Traditionally, the company validated the packaging process by optimizing the packaging process variables and making three runs. A statistically valid sampling plan would be implemented and sample packages would be tested per the finished product specifications. In most cases, this approach worked. But this was not one of those usual projects.
Let us look into the specifics. The package design required the patient to peel the foil by holding on to a center tab. See Figure 1, which shows an example of the four-way notch at the center tab. Since the product was geared towards the elderly, the package design presented some unique challenges. A trial run was performed and some samples were shown to marketing. While the overall package quality in terms of appearance and integrity was fine, Marketing thought that the package was simply too hard to open.
The team decided to establish optimum packaging process parameters using Design of Experiments (DOE), prior to conducting packaging process validation. In “old school” scientific experimentation, people are used to conducting an OFAT experiment. What that means is that the process is studied by simply by changing One Factor At a Time (OFAT). This method, while successful in some cases, is almost always time consuming, costly, and does not guarantee that all the parameters have been optimized.
The team decided to do the more methodical DOE ap-proach, where one changes multiple parameters at a time to understand the process output.
There are many schools of thoughts and styles for conducting such sophisticated DOE trials. One way is to conduct a “Full Factorial” experiment. That is, the process is run for many trials at all the possible extremes of each variable. Such experiments are essentially an OFAT multiplied many times over. One can collect a large amount of information about the process, but the quality of the information depends on the number of trials one runs at each set-up parameter. Although it may seem counterintuitive, one can design a set of trials that is not a full factorial experiment, and still collect adequate information. The obvious justification for this is resource savings. Here’s a simplified example:
Let's say there are two variables (A & B) that impact product quality. And let’s say that the two extremes of each parameter are defined as + and – signs. This means the process can be run in four possible combinations as follows:
| A+ B+ |
| A+ B- |
| A- B+ |
| A- B- |
One can then run the process at each of these settings and collect results. None of these may be optimal, but one can get some information about how the process behaves at these extremes. (The purpose of this article is not to provide an extensive treatment of statistical analysis, but to give a flavor of how experimental trials can be constructed.)
In the present case, before these trials were designed, the team brainstormed on different variables and decided to list all the significant ones. Here is a simplified list of all the potential parameters that would affect the package quality:
 |
| Materials: | |
| Process Variables: | |
| Determines the dwell time of the blister card on the sealing plate. | |
| This is measured as the force with which the blister card is formed by combining the PVC with the foil-backing. The force is applied by a plate by a rotating cylinder. | |
| Temperature of the knurling plate — a critical parameter for the overall process can be raised or lowered, but once reached, it remains constant. To get to a different temperature, the line needs to be stopped until the temperature is reached to the new requirement. | |
One of the significant questions was: What is the one thing that the team is trying to solve? Marketing only gave one clue, that the package should just be easy to open. That is a very broad statement. How can one determine what is easy to open? What may be easy for one person may be difficult for another. There is also the question about technique, of how each person holds the blister card before opening and how one peels the backing. So the team decided to establish a scale of difficulty-to-open. The scale was established as 1 being too difficult, 5 being the best possible, easiest to open without impacting product seal integrity, but even this scale would differ among different people. Finally, the team took some of the samples of the trial runs and had a random group of in-house consumers decide on the technique (per the instruction on the blister card). Once the technique was finalized, about 10 people were asked to peel blister cards and define the difficulty scale. The results were averaged and, with some statistical and some empirical observations, a set of ‘standards’ was created for each notch in the scale (1-5). These ‘standards’ were set aside to be used for comparing the process outputs from each experimental trial.
In technical terms, the process output or the quality para-meter that is checked after running an experimental trial is called a response. When results of each trial are graphed statistically, one gets a ‘response curve,’ which is a sort of continuum that shows the impact of various parameter levels on the response. Within statistical bounds, one can extrapolate or predict the response of a combination of process parameters simply by looking at the graph.
Based on the parameter list, the team decided to set combination of the trials. All the possible combinations are as follows:
|
As you can see there are six possible combinations:
|
Essentially it is a 3! (Factorial) experiment i.e. 3 x 2 x 1 possible combinations. But is running this one set of trials enough? A statistician will tell you no. One can get some information by running these six trials, but one cannot have a high level of statistical confidence in the results. The team decided to run all six of these trials in a random order. Each set of trials was run three times, for a total of 18 trials. The number of trials was decided after a statistical review and a formal cost-benefit analysis performed by the operations team and the Quality Engineer. From each trial, a set of about 100 blister cards were sampled. About five people ‘opened’ these 100 samples from each trial and rated the difficulty to open on a scale of 1-5. These results were statistically processed to calculate their averages and variance. The results were tabulated and statistically graphed.
These three variables, we note, are continuous, by which we mean that one can run the process having the variable at any point within the extremes. There are also categorical variables, which can only be run at a set level. For the purpose of the experiment, the process was run at only high and low levels, but the response curve can show with graphical detail how the process will behave at intermediate points.
This approach—conducting a DOE prior to committing to a full-scale packaging process validation—can save a lot of problems down the road and also improve process understanding.
Some readers may think that this is way too much of a hassle to go through before process validation activities, and one might even argue that this process should have been optimized much earlier. Management is always driving to reduce costs and restrict resources. All the line time, material and support personnel costs add up to a hefty bill. How can one convince management that this is a worthy project? The short answer is that everyone must be engaged. In terms of the overall project, it is truly the Project Manager’s role to challenge the team about minimizing costs and assuring success. This team had a competent Project Manager who did not baby-sit the project but held regular formal and informal meetings on an individual and team basis. He would visit the production line at odd hours to see how he could smooth out any administrative or resource issues. Additionally, this project was chartered formally with all the checks and balances. The costs of doing the project were clearly offset by the costs of not doing the project. Marketing made the case of cost of product complaints, loss of revenue, and competitor’s advantages. When the numbers were charted and compared, Senior Management did not hesitate and gave a go-ahead. Contingencies about launch delays were also planned, to the dismay of Marketing. The team members managed expectations quite well. Every department head was fully engaged. The project manager updated the progress on bulletin boards.
But still the question remains, why did it come down to the eleventh hour to start this project? The problem was that, when the product was originally designed, no one took into account the impact of various process variables on the ‘ease of use’ aspect. This customer requirement figured in late in the game, when marketing actually tried to open the package. One of the major lessons learned was to have all customer requirements figured out. In this case, the dimensional and other quality aspects of the blister card — such as appearance and seal integrity, were established, but the ergonomic issue was not captured.
Conducting DOE is not an easy thing. Running the trials and tabulating the results may actually be quite fun, but before one goes about conducting these experiments, a lot needs to be thought out. Thinking this through requires a lot of technical/process expertise and statistical knowledge. A DOE project will require the experimenter to make a set of assumptions. Failure to make the right assumptions can potentially fail the experiments. For example, if an important variable is ignored and not included in the trials, the results may show a set of optimal parameters that won’t work in real life. One can also be blinded by making strictly intuitive ssumptions; the whole idea of experimentation is to provide a laboratory setting. To that end, a good Quality Engineer with a solid statistical understanding can help set the right course.
The reader must be wondering by now about the results of the trials that we conducted. Well, the results showed with graphical clarity and with a high level of statistical confidence that temperature was not a huge factor, but line speed and the seal strength had significant impact on ‘ease-of-use’ response. Additional confirmation trials were run to prove that the optimized setting do in fact produce predictably good product. After that, packaging validation was a cinch. The team was applauded for its hard work and the product launched on time.
We have simplified a lot of information to make this article free from statistical jargon, as it was far beyond its scope. But the lessons of this story are worth noting:
| • | Packaging process validation is not just a regulatory compliance exercise; rather, it is a customer-centric activity. |
| • | Data-based decision making saves time and improves the chances of a successful validation. |
| • | Design of Experiments can be a very powerful tool to understand your process and to predict effect of various variables on the process outputs. |
| • | Projects must be chartered formally to assure success. Team members must be selected carefully and the Project Manager must keep the project moving. |
| • | Senior Management must fully trust the team and provide the agreed upon resources. |
| • | Contingencies for failure must be planned and what-if scenarios must be fully understood. |
It can be said that a competent, motivated team, a worthy project, and sound management can solve any packaging validation problem. END
:
While a full factorial experiment was conducted in this case study, there are many statistically sound ways of conducting experiments. For example, there are many ways to conduct partial factorial experiments. One can also study the impact of several parameters by conducting screening experiments. The reader is encouraged to study the subject. One recommended book to get a feel for the subject is The Experimenter’s Companion by Richard B. Clements – ASQ Press
Aseptic Process Validation
by Tom Spurgeon
What are the regulatory pressures facing aseptic process validation today and what will they be like over the next few years? An inquiry into existing literature and with current industry personnel reveals a corner of the pharmaceuticals industry driven by a lattice of suggested improvements, a constant hum of activity and improvements that fight to keep pace with general industry trends and emerging technology. Those working in aseptic processing validation must consistently look five years ahead and five years behind, at rules and informative processes and market realities, all of which play off one another like so many strings on a musical instrument. With an important FDA guidance revision just now beginning its long fade into routine and a brand new one described as imminent, aseptic processing and its regulatory outlook is at the forefront of pharma and biopharma business plans.
 |
It's worth noting that the core guidance revisions for aseptic processing validation are still new. "The reason it's a hot area is that we had the aseptic processing guidance that was revised in 2004," said Hal Baseman, chief operating officer and a principal partner at Valsource.
Maurice Phelan, director of Pharmaceutical Technology, BioProcess Division at Millipore Corp., noted that newer statements are driving much of the attention: "The one thing that's gotten everybody interested, and sort of sparked a lot of interest in this subject over the last say year and a half, is the major statements by particularly the FDA about the need to change the way we manufacture sterile products."
Mr. Baseman added, "In September of 2004, there was a revision of the aseptic processing guidance. That resulted in a lot of discussion around validation of aseptic processing and things like that. It's always been a hot issue, an important issue, if you look at it from a risk management perspective. It's certainly a process that gathers a lot of attention."
Mr. Phelan sees the 2004 guidance as even more important in context. "I think it's the 2004 guidance, which was long awaited, but is also the strategic plan that the FDA has laid out, all of the concepts that are embodied in their GMPs for the 21st century initiative. All of the high-level sorts of concepts and aspirations that they have that are laid out in things like the Critical Path Initiative. And then there's the 2004 aseptic process guidance, when it's considered in the context of quality by design, design space concepts, all of the buzz in the industry around efficiency and manufacture, things like process analytical technologies -- when you consider all of those as contributors, then I think the buzz that's around aseptic processing and next generation manufacturing is a result of all of those together, and the context they have for whatever kind of manufacturing you do, whether it's biotech, or classical pharma-type manufacturing. It all depends on your interpretation on what it means to you."
The 2004 revision was the first major one since 1987, and therefore drew attention not just for the new standards it suggested, but for how the revision reflected modern industry practices. The result was a wave of attention to such issues that continues unabated. There are at least two major conferences this autumn that promise discussion of the subject, and specific classes on techniques involving aseptic processing and its validation that are filled weeks in advance. Mr. Phelan noted that there is genuine change reflected in the approach to process validation, within the hierarchy of validation.
He said, "Historically much of the body of work that would be called process validation wouldn't necessarily differentiate between that which was super-critical and that which was a required component but had variability that the process could tolerate. Intuitively the FDA is saying it's not just practical. Intuitively, if you've thought through a rationale that allows you to rank the criticality of unit operations in your process, then there should be a corresponding validation in your unit operations that's increasing in focus and scientific content as you go up the criticality scale. "I've heard an FDA inspector say, ‘Say what you're going to do. Prove that you can do it. And then when you get into manufacturing, do what you say you do.' That's a fairly straightforward statement for these guys to make."
In making its guidance revisions, the FDA gathers information from industry sources and then, once compiled, releases it back, causing a re-affirmation of the industry's best practices distinct, in its way, from standards the FDA might apply to drive companies into certain practices. At one meeting in 2002, the FDA's Advisory Committee For Pharmaceutical Science heard from several industry leaders and its own speakers on a variety of subjects related to aseptic process validation, including container-closure and sterile isolators. As Mr. Baseman put it, "Because we had an opportunity to comment extensively as the FDA allowed us to do [for the 2004 guidance], it became a reflection of what the industry was doing."
That give-and-take continues into the field. Said Mr. Phelan, "I heard this from the FDA as recently as last week: If you want to interact with them, and you're prepared to think about applying some of these next generation concepts, than they want to engage you." This is a change from times past, he noted. "Historically the FDA would have said, ‘Our door is open, and nobody's coming to talk to us. It's a one-way affair for us, and we have no option but assume a worst-case scenario. The only opportunity we have to share information is in the limited capacity of inspections or audits or reviews.' Now they're saying, ‘We have to change the way we do business. It's our view that you, the manufacturing community, need to look at how you manufacture and look at these types of areas.' Quality by design is the classic example of what they'd like to see.
"They've put programs into place," he added. "They have a pilot program that's gone on for the last 12 months for the review of new drug applications, where they've invited people to participate in basically a risk-based construct for the CMC sections in their new drug application."
The Guidance revision not only provides a platform for understanding the FDA's expectation and current industry practices, it also serves as a spur to science by offering up its own set of ways to approach certain problems while fostering from related organizations more up-to-the-minute, specific technical solutions.
With the FDA's more general efforts starting in 2001 to implement GMPs "for the 21st Century" -- itself two decades since the last similar effort -- came an emphasis on risk analysis. Risk analysis became the tool through which managers began to approach the validation of their aseptic processing techniques.
Mr. Baseman explained the general process as it has an impact on a facility's approach to their processing procedures: "Most biological contamination comes from people. So anything involving human intervention is going to be a riskier step. If we're doing an aseptic process test, let's say there's a step in there where somebody has to add a component manually, like a stopper. That becomes a riskier step. If we can eliminate that step by having some automated system to do that, then we eliminated and improve the process. That pushes us towards using isolators rather than conventional filling lines." The prioritization that comes with risk-management engenders a step-by-step vetting of the process validation. It puts emphasis on key points such as filtration, and then works its way backward to elements with less of a risk. As risk-management works its way to and then through those industry agents that have yet to fully embrace that approach, their use should become more and more routine.
This is just the way the FDA wants it, said Mr. Phelan. "Classically, validation exercises have been very, very document-heavy exercises. The FDA are now saying that we think there's a very practical approach to be taken in addressing all of the validation that needs to be done in a manufacturing process, assessing what the risks and/or overarching benefits are to putting so much effort into that enormous body of work, and then maybe thinking about a different way of justifying the amount of focus you put on in respect to validation, exercises based on their risk to your program."
Despite the fact that ideal sterilization technique is terminal, or heat-based, the market should drive more and more companies into aseptic processing. As most are quick to point out, terminal sterilization is a poor technique to apply to unstable products such as those represented by protein-based drugs. Aseptic processing places a specific emphasis on filtration as the last process performed to destroy organisms or contamination within a product. "Filtration would be where you would take the product, put it through a .2 micron filter and then fill it under very controlled conditions, in a clean room, perhaps in an isolator or perhaps in a conventional clean room but one with a lot of controls to keep the contamination out of the product," said Mr. Baseman. "Because there will be no subsequent step to destroy those organisms. That's why filtration is of interest related to aseptic processing."
With technology, market concerns and the introduction of new techniques and practices all driving interest in aseptic processing and its validation, one might think of the regulatory backbone as one of pressure and punishment. Actually, the opposite seems closer to the truth. Mr. Baseman praised the FDA for its ability to solicit commentary when preparing its guidances, both from individual players and major industry organizations like the Parenteral Drug Association (PDA). Not only does this give them a wider array of knowledge to use, the process settles industry players for whatever changes are to come. "I believe it's rare for the FDA to come out with something that's a big surprise," said Mr. Baseman. "For the most part what happens is that guidance gets issued that reflects what the FDA has been talking about and what the industry has been doing.
"I think there's an anticipation, but I don't think people are sitting there saying, ‘Maybe we shouldn't do any process validation this year because everything is going to change.' I don't think that's the case. The FDA has done a good job indicating where it's heading with this. They certainly put out some pretty good information in their initiative documents. There was a CPG that came out I think last year, but that CPG -- and that's their internal guidance document -- talked about what the agency would internally be looking for when it reviewed submissions. So if you read that, you kind of understood what the Agency is looking to do."
Groups like the PDA provide further support by issuing technical reports following guidances and standards, reports that provide a very specific way of meeting required standards, to be accepted, used or even refused, and make more clear the science of what's being done, away from purely regulatory motivations. For instance, PDA Technical Report #42 deals specifically and in what is described as a "practical" fashion with Process Validation in terms of protein manufacturing.
This system of multiple supports and reinforcements sets the stage for a revised guidance from the FDA for processing validation. Mr. Phelan characterized such revisions as "imminent." As to what that revision will entail, Mr. Baseman opined, "I think it may have something to do with new techniques. There's so much new technology that's coming out now, and I think it's important that the PDA weigh in on new technology, things down the road: new technologies for monitoring and so forth."
Mr. Phelan thinks the emphasis will be on the principles driving multiple solutions. "What I would expect is that it will contain all the intellectual components that one would classically associate with process validation and then it will have loaded on top of those good validation practices the concepts of design space, critical process parameters, risk-based decision-making and then practical validation approaches -- a rationale that says I understand what drives my process and I understand the critical parameters I need you to control and I need to validate.'"
As more companies are driven to work with drug forms that resist terminal sterilization, those that embrace GMPs and a risk-based outlook should find strong support in terms of aseptic process validation techniques, applied to steps ranging from filtration to use of isolators to air flow, that match the criticality of each phase to their overall function. Look for future guidance and technical papers to build on rather than replace the general outlook, at least until it becomes routine, as all former hot topics must sooner or later.
Subscribe to:
Posts (Atom)