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