The Value of Performing a Good ValidationIn Transfusion Medicine
For Blood & Biologics
The blood establishment bears the responsibility for the regulatory compliance of the automated/computerized systems used. Full validation of the computerized system is required for systems critical to product and quality (information management, storage, tools for operational decision-making, and control). The Quality Risk Management approach to validation advocated by GAMP 5 and ICH Q9, a life cycle approach within the QMS, and the use of risk assessments to define the validation strategy for critical systems is a must before any validation is contemplated. It is important that the approach to validation used by a blood establishment should allow provision for the process to be scalable to the functionality of the system, e.g. the validation of a centrifuge is less complex than that for a home-grown blood management system.
The benefits of validation are as follows:
improve the use of technology
improve the business benefits
improve the relationship between stakeholders (users, suppliers, authorities, etc.)
improve operational efficiency
reduce the risk of failure
improve compliance with regulations
What is Validation?
The objective of validation is to produce documented evidence that provides a high level of assurance that all parts related to the use of an automated system will work correctly and consistently. Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) classify the different validation tasks that have to be performed for ensuring the quality of the use of an automated system.
IQ shows that the system has been installed correctly. Once IQ has commenced, the system and infrastructure should be under formal change control. IQ considerations include:
hardware and software installation
installation conditions (wiring, utilities, UPS, etc.)
interface connections
calibration, preventive maintenance
safety features
supplier documentation, prints, drawings and manuals
software and hardware documentation
spare parts list
software backup
security aspects
environmental conditions (such as temperature, humidity)
OQ challenges the automated system and process operating parameters to ensure that they will result in a product that meets all defined user requirements under all anticipated conditions of manufacturing, including worst case testing. The User Requirements must have already been defined in order to perform OQ validation. These are usually built upon the regulatory agencies' regulations and standards for blood banking and the corporation's own business rules. Therefore this type of validation proves that the facility can do business and comply with the rules (regulations) for which the Transfusion Service is responsible and mandated to follow. OQ considerations include:
functionality of the automated system
alarms and limits
configuration
process control limits monitored by the automated system
software operational parameters (ideally linked to the functional and design specifications as provided by supplier)
automated system operational specifications
process operating procedures
process change control
training
preventive maintenance and calibration and monitoring
data to prove stability and capability of the process where the automated system is used
evaluations for potential failure modes and worst-case conditions (risk analysis and critical control points, failure mode and effect analysis, fault tree analysis)
backup and recovery
system access and security
PQ demonstrates that the computerized process will consistently produce acceptable product/output under normal operating conditions. For practical reasons, part of the limiting and boundary conditions testing is often performed at this stage. The demonstration is achieved by using the appropriate methods and tools for process validation. PQ considerations are:
use of actual computerized parameters and procedures established in OQ and used during the operation
reconfirm acceptability of the computerized processes as established in OQ
reconfirm process repeatability and assure process stability when used in the field with trained operators
Challenges to the process should simulate conditions that will be encountered during the operation. Challenges should include the ranges of conditions covered by the standard operating procedures and should be repeated often enough to assure that the results are meaningful and consistent.
Data Migration is the process of transferring existing data, either manually or electronically, from a source system to a target system (usually from an old system to a new system). The data migration process should be managed according to a specific plan and requirements set in a Data Migration Plan. The content of the Data Migration Plan may vary depending on the complexity of the data migration processes. It must set forward sufficient elements to guide the data conversion team to a successful data migration. The plan should cover but not be limited to:
migration scope
roles and responsibilities
requirements and deliverables
risk analysis; configuration management strategy
software tools and strategies for ensuring compliance and fitness for intended use
data quality assessment; data mapping; data transformation rules
migration steps
data verification strategy and acceptance criteria
system transition plan
rollback strategy
Why is Testing NOT Validation?
Testing of software is not in itself "validation"; it is a verification activity. It should not be divorced from the overall validation of a process/system; however, it cannot take the place of a formal validation activity. Testing can use significant levels of human and financial resources. The biggest difference between testing and validation is the time in the project they are performed and the state of the frozen system at the time. The illustration below shows that testing is performed before the system is frozen. The tester runs testing scenarios, finds issues, fixes issues and re-tests.
1
Figure 1:
In validation, the system is frozen and when issues are found they must be documented until the validation has been completed. Then, using Change Control and documenting every change, changes can be made to the validated system. Those changes must be evaluated by a team of experts to determine the impact on the system and then the cycle begins once again.
What's the Solution to Tedious and Time-Consuming Testing and Validation?
My company typically relies on clients to test their systems before the Nozick OQ Validation begins. Some sites have spent hundreds of hours testing their blood bank modules and still we find database errors when the validation is completed. This forces clients to fix the database and revalidate virtually right away. If they had tested more thoroughly, they would have found the database mistakes before my company's validation. Plus, when we manually implement the customized scripts to perform the OQ validation, the average time to implement scripts over all the major blood bank systems is between 100 to 200 hours. Again, this is a time-consuming, labor-intensive and expensive process.
To solve these problems, my company has affiliated with an industry-renowned automated solution for laboratory testing and validation that enables 100% testing of core processes of laboratory applications and generates the comprehensive documentation the client needs to demonstrate that their system was accurately and completely tested. The solution operates like an actual user on their system: entering data, checking on orders, running reports. The end user controls the application functions invoked to conduct realistic and repeatable tests, quickly and straightforwardly. We expect this method of testing and validation to become the industry standard very soon.
How Much is Enough?
A question often posed by blood establishments is, "How much validation do we need to perform?"Validation is essentially a component of the organisation's quality management system, so this question could be rephrased as, "How much quality do we need?" The product quality and cost benefits to be achieved by an organization through adopting the Total Quality Management (TQM) principles of customer satisfaction, employee involvement and continuous improvement are well established and are equally applicable to validation. The objective of validation is to produce documented evidence that provides a high level of assurance that all parts related to the use of an automated system will work correctly and consistently.
The answer to the question, therefore, is that the blood establishment needs to ensure that enough of the right work is done by the right people to achieve system acceptance in a way that satisfies the quality system.
With this in mind, it is worth considering what makes validation projects successful:
senior management commitment
tight project management
sufficient resources
competent project management
collaborative team approach, i.e. users/technical reps/validation/QA/IT professionals
risk assessment
cost efficiency
Validation is a complex process. The skill sets and experience of the team are very important in ascertaining the scope of work to be carried out and that not too much, or unnecessary, work is performed. There may be a temptation to 'mix and match' elements to reduce workload. This approach is not recommended and should be avoided.
1Sampson, J., Nozick, RF. et al, ISBT-Guidelines for Validation of Automated Systems in Blood Establishments, March 2009
FDA Link
Guidance for Industry: Blood Establishment Computer System Validation in the User's Facility (http://www.fda.gov/cber/gdlns/becsvalid.htm)Additional Articles
Nozick, RF, "CIO Perspective, Risk Assessment", AABB News, July/August 2002.Nozick, RF, "Book Review: Information Technology in Transfusion Medicine", AABB News, September/October 2003, pg 42Nozick, RF "Lessons Learned: Software Vendors' Different Approaches to User Validation", Citings Information Exchange, October 1, 2003, Volume XIII, no. 4,Nozick, RF, "ISBT Guidelines for Validation and Maintaining the Validation State of Automated Systems in Blood Banking", AABB News, January/February 2004.