Risk Assessment for Computer System Validation in Blood Establishments
via MS Clipart
Overview
Having previously performed numerous Risk Assessments on Computer Systems for many Blood Centers, I wish to share the importance of performing a proper Risk Assessment. Now that I am an independent consultant and no longer limited by prior employer policies and politics, often driven from a cost (not quality perspective), I can freely state the correct methodology for Risk Assessments. The main focus for a Risk Assessment should be to define the level of testing required for system validation based upon the risks to patient and quality of product. It is imperative to perform Risk Assessments early in the process to help define the validation activity before the validation plan or test cases are developed. Risk Assessments should be utilized throughout the process and post implementation (separate or integrated within Change Control). My recommendation is to utilize a worksheet to capture this process and thus established a specific timeframe. Further information on this topic can be attained from http://www.fda.gov/cber/gdlns/becsvalid.htm (FDA/CBER guidance doc) and http://www.ispe.org/cs/gamp_publications_section/gamp_publications_overview (GAMP5 publication). This post will be relevant for companies within the blood industry (and most other regulated industries) for compliance with computer system validation.
Define Critical Quality Attributes
Critical Quality Attributes (CQA) are central to developing a proper Risk Assessment. CQA are best defined as those attributes that have the greatest impact upon patient safety and product quality. Once these are defined, specific system standards and requirements can be developed which further define testing methods and risk focus. This is the basis for making science and risk based decisions that will ensure that the system is designed or configured and meets its intended use. Make sure that as part of this CQA definition, your regulatory requirements are indicated.
Risk Assessment
I cannot stress enough how important a Risk Assessment is for proper system validation. Once the basic system requirements of the system have been identified, this Risk Assessment is done to help define the validation plan and what validation test will be required for the system. Without doing a proper Risk Assessment, key CQA areas might be omitted or unnecessary testing may be done. One important thing to keep in mind is that the total elimination of all risk is not the focus; it is justification of residual levels of risk. Risk may simply not be able to be eliminated or the cost associated with total elimination may not be justified by the business. Risks identified may change over the course of the system validation. It is possible to perform ongoing Risk Assessments during the course of validation as additional items are identified. I have found that the best method for capturing this information is to utilize a Risk Assessment based worksheet. This worksheet should capture the following information:
- Initial Risk Level Classification
- Identified Issue (what is causing the risk)
- Identified Risk Component(s) (specific risk or risks from the Identified Issue)
- Likelihood of Detection
- Likelihood of Occurrence
- Severity of Impact
- Mitigation Strategy
- Corrective Actions
- Final Risk Level
- Justification of Final Risk Level
In circumstances where the Severity of Impact is high, assume that the Likelihood of Occurrence is high if there is no way to determine this outcome. This should be noted in the Final Validation Report and increased auditing of the system should occur until a level of confidence is established.
Frequency of Risk Assessments
To keep things simple, this is the basic guidelines for when to perform a Risk Assessment:
- Prior to the start of validation but after the System Requirements have been defined
- During the course of validation, especially when changes to the process occur or when additional issues are discovered that would warrant a Risk Assessment
- Prior to implementation of the system when all testing has been completed
- Periodically during system audits
- During every change to the system via Change Control or as a separate Risk Assessment
- Prior to decommissioning of the system
I welcome any and all feedback on my posts.
If you are interested in how my expertise can contribute to your validation project or company, please contact me at greggsalomon @ yahoo dot com.
Quality meets Validation 