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.

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

¹Sampson, J., Nozick, RF. et al, ISBT-Guidelines for Validation of Automated Systems in Blood Establishments, March 2009

Robin Nozick is the founder and Chief Technical Officer of R.F. Nozick and Associates, the Leader in Blood Bank Solutions and I.S. Compliance. Robin spent the last 25 years serving the Clinical Laboratory and especially the Transfusion Services department, teaching and implementing, building, validating and testing, and training end users on all of the Customizable Blood Bank Systems available today. Robin sat on the AABB Information Systems Committee for six years, during which time she spoke about validation, the ISBT Validation Guidelines, and risk management" on several occasions. In 2000, Robin joined the International Society for Blood Transfusion Working Party on Information Technology's Validation Task Force and helped write the first version of the "ISBT Guidelines for Validation and Maintaining the Validation State of Automated Systems in Blood Banking." She is presently the co-chair of the Validation Task Force, who has recently approved for publication V2 of the guidelines, and is responsible for an education project that will be creating an e-learning tool to train Transfusion Service personnel charged with the validation of their system to perform a quality validation. This work is geared towards less-developed countries that have few resources for information technology. Robin is currently working with the Tanzanian National Blood Transfusion Service, helping in the selection of a sophisticated Donor System. The education project is ongoing and anyone interested in working with the Task Force may contact Robin at rnozick@rfnozick.com. Nozick would be happy to answer any questions about validation, QMS, Testing etc. For details, please email djohnson@rfnozick.com or call 480-346-7011 or visit www.rfnozick.com.

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.