Computer System Validation (CSV) is the validation process used in regulated industries throughout the world to verify that a computerized system performs as it is designed to and that it maintains the integrity of its data to ensure the safety and effectiveness of the product. In the United States, the Food and Drug Administration requires regulated companies to perform validation of computerized systems that operate or support the production of the regulated products, including Pharmaceuticals, Biologicals, Medical Devices, Infant Formulas, Blood and Blood Components, Human cell and tissue products, etc.
Perform CSV when implementing a new computerized system or when you make a change to a validated computerized system. CSV processes are validation processes, based on applicable regulations and guidance documents, industry best practices, and the intended use of the computerized system being validated. In this post we are going to discuss a few best practice recommendations for effective, risk-based CSV.
Computer System Validation 101
FDA defines software validation as “Confirmation by examination and provision of impartial evidence that software specifications follow user needs as well as proposed uses, and that the precise requirements implemented through software can be consistently achieved.” In the FDA regulated world, a “computer system” is not just the computer hardware and software, but the entire system, including any equipment or instruments connected to the system, as well as the actions of the users that operate the system, and the Standard Operating Procedures, manuals, and documentation.
CSV ensures that both new and existing computer systems are suitable for their intended use(s), produce correct and trustworthy results that enable regulatory compliance, meet the User Requirements Specifications, maintain required audit trails, and provide the ability to detect invalid or altered records.
The CSV process uses a variety of static and dynamic testing activities that you should conduct throughout your entire software development lifecycle, from system conception to retirement. You should plan to validate that your system will work in all the situations that you want the system to work in. Write a CSV Master Plan. Document your CSV processes. If you didn’t document your CSV, your CSV didn’t happen.
Plan your CSV activities using some or all of these elements based on your particular computerized system and its intended use(s).
System inventory and assessments determine which systems need to be validated.
System boundary documents determine where your computerized system starts and ends.
Validation plans define the purpose, scope, and plan for the validation study.
User requirement specifications explain what the system should do. For example, “I want to drive 6 people from Reno to Las Vegas (438 miles) in not more than 7 hours”.
Functional need specifications explain how the system will look and function for the user to be able to achieve the user requirements. For example, “The vehicle speed has to be at least 80 miles per hour.”
Validation Risk assessments analyze the failure scenarios in order to determine the scope of validation efforts. For example, “Speeding ticket, flat tire, etc.”
Validation Traceability Matrix references each specification to one or more specific validation tests in the Installation, Operational, and Performance Qualifications.
Network and Infrastructure qualification verifies that the infrastructure, hardware, and software supporting the application system being validated have been installed properly and are working correctly.
Installation Qualification Protocols, Test Scripts, and Final Reports demonstrate that the system has been installed correctly in the user environment. For example, “What kind of car did I buy?”
Operational Qualification Protocols, Tests Scripts, and Final Reports demonstrate that the various functions of the system do what they are intended to do in the user environment. For example, “Do the tail lights work? Do the brakes work?, Can I do at least 80 miles per hour?, etc.”
Performance Qualification Protocols, Test Scripts, and Final Reports determine that system does what it is intended to do along with qualified people following SOPs in the production environment even under the worst case. For example, “I drive me and 5 ‘people’ from Reno to Las Vegas. Did I make the trip in less than 7 hours?”
Validation Reports include reported results, deviation resolutions, and conclusions of all activities in the validation study.
System Release Documentation documents that validation activities are completed, that the system was released by the authorized quality function, and the system is available to use.
