IVD Technology
Magazine
IVDT Article Index
Originally Published IVD Technology June 2005
Regulations & Standards
Regulations for software validation of automated processes
Dennis L. Rubenacker
 |
| Dennis L. Rubenacker is cofounder and senior partner at Noblitt & Rueland (Irvine, CA). He can be reached at dlr@noblitt-rueland.com. |
FDA regulation of software validation of automated processes that are used as part of production or quality systems by IVD manufacturers has been evolving during the past several decades. Although required since 1978 by the original good manufacturing practices regulations, FDA scrutiny of software validation of automated processes has increased significantly since 1996, when the agency promulgated the quality system regulation, 21 CFR 820. FDA also began to enforce section 820.70(i), as evidenced by the increasing number of observations and warning letters from the agency, which cited the industry’s lack of compliance with software validation requirements.
Examples of potential automated processes that require software validation include systems with software related to the following functions: corrective and preventive action (CAPA), production and process control, design control, management control, and other areas of the quality system such as device tracking, clinical trials monitoring, document control processes, and electronic recordkeeping systems. Many automated processes may also include electronic records and signatures. Although these processes would fall under 21 CFR 11, the latest Part 11 scope and application guidance defers FDA enforcement of its software validation requirements for systems to the predicate regulation, 21 CFR 820.70(i).
Identifying the automated processes that require software validation and the level of effort to implement validation activities and documentation for the identified systems are key concerns that can overwhelm IVD manufacturers. To address FDA compliance expectations, a manufacturer needs to develop a master validation plan for software in automated processes. The plan should include a prioritized scheme based on safety and regulatory risks for validating manufacturing and quality system software.
Once such a master plan is established, an IVD manufacturer should develop a practical approach to address software validation for the prioritized systems to attain the appropriate level of validation within reasonable cost and time-frame constraints. The main focus areas in such an approach to software validation should include documentation coverage that is identified as part of project planning related to those key areas in the quality system inspection technique (QSIT) guide for FDA investigators. This guide to inspections of quality systems instructs investigators to look for a software validation plan, software requirements documents, software validation protocols, software validation results, and software change controls to confirm that the software will meet user needs and its intended use, along with any applicable vendor purchasing data for off-the-shelf (OTS) software.
FDA Regulations and Guidance
21 CFR Part 820: Quality System Regulation. FDA software validation requirements for automated processes are stated in 21 CFR 820.70(i). This paragraph in the quality system regulation, which is in reality a collection of software usage requirements, indicates that validation should focus on the software’s intended use in the automated system. An established (i.e., defined, documented, implemented) protocol should include a collection of verification or test procedures for confirming that the identified software usage requirements for the software’s intended use in the automated system are implemented. Change controls should address the identification of software versions so that changes can be tracked and revalidated as appropriate.
General Principles of Software Validation. FDA guidance in the general principles of software validation emphasizes the need to assess the risks related to validating automated process equipment and quality system software. The level of effort for validation activities should be commensurate with risk. The guidance provides examples of levels of validation effort such as the following:
• Low level of validation effort for automated milling machines in which output is fully verified against specification prior to release.
• High level of validation effort for test equipment used for inspecting and accepting circuit boards in life-sustaining devices.
The guidance indicates that IVD manufacturers are required to validate only those software functions used in automated systems as related to the implementation of the quality system regulation. Manufacturers should also reconfirm validation of changes to those used functions.
In addition, the guidance states that defining usage requirements is the key to software validation and can include the following information:
• Intended use of software or automated equipment.
• Extent to which IVD manufacturers depend on software or equipment for production and quality.
• Expected operating environment for hardware and software.
• Performance (e.g., error handling, start-up, shutdown, security).
• Safety (e.g., sensors, alarms, interlocks, command sequences).
Other validation documentation that is traceable to the usage requirements should include:
• Predetermined expected results.
• Validation protocol.
• Acceptance criteria for critical
parameters.
• Test cases and actual results.
• Validation summary report indicating that the software version is validated to its use.
For validating OTS software used in automated processes, the guidance recommends that a beginning point might be an assessment of the vendor’s development and validation information where available, and an audit of the vendor where appropriate, especially for high-risk software. For OTS tools (e.g., compilers, linkers, editors, operating systems, databases), the guidance states that exhaustive black-box testing may be impractical. Proper operation or validation of the tools may be inferred or covered through validating the overall application usage requirements that are traceable and indirectly implemented by the OTS tool functions.
 |
| Figure 1. Sample Part 820 automated system identification checklist (click to enlarge). |
Guide to Inspections of Quality Systems (QSIT Guide). The QSIT guide is a training handbook for FDA investigators for conducting inspections of IVD manufacturers. Consistent with the requirements in the quality system regulation and the guidance in the general principles of software validation, the guide instructs FDA investigators to review the software validation documentation during a QSIT inspection.
21 CFR Part 11: Scope and Application Guidance. The Part 11 guidance (“Electronic Records; Electronic Signatures: Scope and Application”) indicates that FDA “intends to use enforcement discretion regarding specific Part 11 requirements for validation of computerized systems (section 11.10(a) and corresponding requirements in section 11.30). Although persons must still comply with all applicable predicate rule requirements for validation (e.g., 21 CFR 820.70(i)), this guidance should not be read to impose any additional requirements.”
Accordingly, IVD manufacturers should comply with the predicate rule requirements in section 820.70(i) for those systems containing electronic records and signatures since FDA does not intend to add additional validation requirements. The Part 11 scope and application guidance also provides specific advice for validating word processor software tools: “For instance, validation would not be important for a word processor used only to generate standard operating procedures.”
However, IVD manufacturers should be aware that the other remaining part 11 requirements could also be considered as part of the software usage requirements (e.g., security checks, operational system checks, device checks, password aging). In fact, validating these additional Part 11 software-related requirements may be mandatory.
Identifying Potential Automated Processes for Software Validation
Based on the above discussion of FDA regulations and guidance, IVD manufacturers should assess their implementation of software in automated processes that are used in production and the quality systems. One identification method is to inventory all software used in a facility, whether it is stand-alone (e.g., on a workstation or server) or for automating a manufacturing process. After all software is identified, an IVD manufacturer can assess whether the software is used in production or the quality systems.
Another identification method that may be more efficient is to assess the implementation of the quality system requirements and identify the automated systems that implement those specific requirements. Such an assessment can be conducted using a checklist (see Figure 1). Based on 21 CFR 820, the checklist has columns for the applicable part 820 section, potential software implementation or record-related requirements, identification of applicable software and systems, software validation responsibility, system risk, and priority. With such a checklist, each automated system related to the implementation of quality system requirements can be recorded, identified, and managed.
Creating and Implementing
a Master Software
Validation Plan
Assessing Identified Automated Processes. After identifying the automated systems that require software validation, IVD manufacturers should assess each system to determine if it has been validated based on FDA regulatory requirements and internal company validation procedures, if available. Per the identification checklist, the assessment should include the capability to retrieve the following types of implemented documentation for the identified automated systems:
• Software validation plan.
• Software usage requirements specifications.
• Software validation protocol.
• Software validation results.
• Evidence of software version and change control.
• Evidence of vendor qualifications, as appropriate.
IVD manufacturers can then create a master validation plan by listing those automated systems that do not have adequate software validation documentation. The list can be prioritized to schedule activities for responsible personnel based on a risk/prioritization scheme (see Figure 2). Manufacturers should identify and schedule those automated systems with the highest safety and business risk priority at the top of the list in the master software validation plan. Systems with the lowest safety or business risk priority could be scheduled toward the bottom of the list for software validation.
For all automated systems, IVD manufacturers should follow internal software validation procedures that are consistent with FDA expectations for such validation. The level of effort and detail for software validation (e.g., testing and documentation) should be commensurate with safety risk. The possibility also exists that some identified systems may not require software validation since the outcome of the automated process is 100% verified, reviewed, or checked. Manufacturers should document their justification for those automated processes that do not require software validation.
Implementing a Software Validation Procedure. IVD manufacturers should establish adequate procedures for assessing automated systems and implementing software validation activities. The procedures should address automated system software validation planning for consistent implementation of validation projects by a manufacturer.
For each project, IVD manufacturers should create a software validation plan that includes such validation activities as the following:
• Establish a software validation file as a retrievable repository for validation-related documentation.
• Include or reference a project schedule and responsibilities.
• Address qualification of OTS or other purchased custom software, as applicable.
• Address any specific personnel training requirements.
• Identify software validation documentation deliverables required for the project such as:
• Software usage requirements specifications.
• Safety risk analysis to determine safety risk for assessment and level of effort in validation activities and documentation.
• Software validation protocol and test procedures.
• Software validation summary report, including trace matrix that demonstrates testing activities and completion for each software requirement.
 |
| Figure 2. Sample identification checklist, risk/priority legend (click to enlarge). |
Once an IVD manufacturer establishes its software validation procedure
for automated systems, it should be included as part of the quality system and then monitored for proper implementation through an internal auditing program.
Ensuring Configuration Management and Change Controls for Automated System Software. IVD manufacturers should implement configuration management for automated system software and documentation, including version identification and change controls. Manufacturers apply change controls to address any modifications to the system and software, including appropriate change approvals and notifications with subsequent updating of configuration or version number of the system and software.
If an IVD manufacturer implements changes to the automated system software, the software validation file should be reopened. The extent of any revalidation and documentation activities is applied after a regression analysis of the changes, as related to other software usage requirements or validation documentation. If a change is assessed such that no software user requirements are affected (e.g., minor operating system or server patch) and no revalidation is required for the revised software configuration, the manufacturer should document the rationale for the decision in the validation file, as appropriate.
A key focus should be placed on ensuring that the current live system configuration and software version match the configuration and version that are validated in the software validation file.
One practical method to ensure that the current configuration and version of the automated system software remain validated is to conduct configuration audits of the validation file by an independent internal organization such as quality assurance. The audit would attempt to demonstrate that the content of the specific project validation file, including the software version, matches the configuration of documentation reported in the respective software validation plan. After a successful audit, the validation file for the live software version is closed.
Conclusion
IVD manufacturers should prepare to understand the FDA quality system regulation and other applicable FDA guidance that are related to software validation of automated systems and processes. In addition, manufacturers should identify and assess those automated systems that are used in production or the quality system as part of a master plan with a prioritization scheme to address the implementation of software validation.
Subsequently, each IVD manufacturer should have in place software validation procedures for not only currently installed and operational systems but also any automated systems installed in the future. Manufacturers should develop such procedures to comply with FDA regulations for software validation in their automated systems.
Copyright ©2005 IVD Technology
