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