The world is now convinced that a risk-based approach is the way to go. We understand why regulators want us to use risk to focus our efforts and we understand how well applied risk management will lead to safer, more effective products, and ultimately to happier regulators. If you are not among the convinced, go back and read all of my previous posts.
Now comes the hard part. How do we apply these principles to Computer System Validation (CSV)? We can pick up a few clues from ICH Q9 Annex II. Some of these examples are crystal clear while some will take a little interpretation or extrapolation. Start each of these examples with "We could use Quality Risk Management to..."
...design a quality product and its manufacturing process to consistently deliver the intended performance of the product
Focus your CSV efforts on the parts of the computer system that directly impact the intended performance of the product.
...determine appropriate preventive maintenance for associated equipment (e.g., inventory of necessary spare parts)
Should you have redundancy? Should you have an automatic fail over strategy? How much testing should you do for your backup and recovery system? It all depends on the risk level of your system and of each feature.
...determine the scope and extent of qualification of facilities, buildings, and production equipment and/or laboratory instruments (including proper calibration methods)
This one is quite direct and the most likely reason you have read this far. The scope and extent implies that we apply more resources to validating some computer systems than to others. This is risk-based computer system validation in its truest sense.
...select the design of computer hardware and software (e.g., modular, structured, fault tolerance)
Design and validation go hand-in-hand. The fault tolerance decisions you make during design will directly affect your validation efforts.
...determine the extent of validation, e.g., identification of critical performance parameters, selection of the requirements and design, code review, the extent of testing and test methods, reliability of electronic records and signatures
This is as direct as it gets. Someone used Quality Risk Management to determine the critical quality attributes of your product or process. It is probably the business people, the clinicians, the R&D scientists, or the process engineers. Go talk to them. Learn from them what is important about the product or process. Now figure out how your computer system impacts those attributes. How do you measure how well your computer system executes those features that impact the critical quality attributes? These are your critical performance parameters. Analyzing (severity and likelihood) bad things that could happen that would keep your system from meeting these performance parameters results in you understanding the risk level of your system and of each feature. Armed with this information, you will be able to adjust all aspects of your System Develop Lifecycle to be more thorough or less intense, depending on the risk.
How exactly do you measure the risk level of a system and each of its features? I will tell you all about it next week. In the mean time, consider attending one of my upcoming webinars.