“An investment in knowledge pays the best interest.” –Benjamin Franklin
Introduction
Computerized system validation is a process and shall be followed the entire system life cycle. The validation of a computerized system starts often with a project and ends with its retirement.
When validating a GxP-classified computerized system four typical mistakes shall be avoid which cause unnecessary cost.
1) Defining scope and starting validation strategy and planning at the very end
The most important is to know what business wants and therefore what the scope is as all validation efforts will be related to the business process and data scope.
To start the development of a computerized system without knowing the process scope and its data might lead to retro-prospective validation effort.
The obvious solution would be to start scoping and defining the validation strategy and planning at the beginning of the project. All validation activities will have value in the project itself when integrating it with documenting the business process and requirements as well as the system design, development, building and testing.
Having a scope and strategy as well as a clear change management process in place are key aspects of validation process.
2) No matter what – rules are rules and rules are not negotiable
Patient safety, data integrity and product quality are not negotiable, likewise mandatory regulation, for example FDA 21 CFR part 11 and Annex 11 established by the EMA.
The regulatory requirements of a business process shall not be underestimated when defining user requirements. Identifying regulatory requirements in a very early phase of the project and keeping them up-to-date along the system life cycle will ensure compliance with current GxP regulation.
In general validation strategy and planning is authorized on projects for systems to be developed or configured and tested. This causes repetition of certain project deliverables and activities which require a lot of project time and resources such as writing of project and life cycle documents.
Establishing a lean governance structure, standard operating procedures, and interpreting regulation on the organizational level will help your project team to follow the right regulation within the project and during operations. Industry best practice can help to make the right decision when establishing a computerized system validation framework.
3) Ignoring where requirements are derived from, how they are satisfied and how they are tested
Not linking business processes, requirements and testing can lead to a major problem for the end users of a computerized system. Without traceability there is no evidence that the intended system purpose have been met. Computerized system might be incomplete and inconsistent as well as gaps may creep when going live. There is no guaranty that a correct system has been built and tested. Indeed, there is a great chance that the wrong product is built and in use. This can not only lead to compliance issues but also to higher additional costs in operations.
Creating and maintaining a traceability matrix for your computerized systems can relieve this challenge and provide an effective and efficient solution to describe and trace the life of requirements, in both a forward and backward direction. A Traceability Matrix is the heart of a computerized system and therefore one of the most imported documents which should be created within a project and maintained in operations during the life cycle of a system.
4) Focusing validation efforts on the less important requirements and over validating others
Identifying risks and conducting risk assessment throughout the project and system life cycle from beginning to end helps to concentrate on the most critical requirements and potential high risks to patient safety, data integrity and product quality.
Knowing the business process scope, a detailed business process risk assessment should be completed first.
An initial overall risk assessment of the computerized system should be performed at the start of the project with focus on business processes and its regulatory requirements as well as the IT solutions and its vendors.
A Function Risk Assessment may be performed once the Functional Specification is completed to identify the systems functional risks.
All risk assessment should be performed by cross-functional teams with capabilities including but not limiting of the implemented technology, business area, as well as in quality and compliance.
Not performing risk assessments at all might lead to increased risk of not concentring your validation effort to the most critical requirements and risks and overseeing issues which could have been avoided in the first place. This again can not only lead to compliance issues but also to inefficient budget spent.
Conclusion
Overall avoiding the top four mistakes above will lead to a more efficient and effective quality, time and resource management.
KVALITO Consulting Group is dedicated to help our life science clients to master its validation and qualification efforts in a compliant as well as a more efficient and effective way. Our computerized system validation services include inter alia:
- Mock-up audit
- Vendor audit and assessment
- Governance, risk and compliance assessment and matrix
- Quality risk assessments
- Audit readiness package
- Validation planning and strategy
- Test planning and strategy
- Regulatory requirements engineering
- Traceability matrix
- Training concept
- GAMP5 alignment
- SOP writing
Authors: Daniel Attard and Magdalena Kurpierz
