Our previous blog posts talked about the skills needed to be a C&Q engineer and the 7 guides you should read.
This blog talk about the deliverables expected from a C&Q engineer. And we will try to list them down in a project chronological sequence.
- System List
The first thing you will need on a project is a system list.
The system list will come in an excel sheet, but ideally, a database. The database could either be Access or Airtable, anything where you can create relationships between other project databases. The engineering company will list systems they will design, procure, and install on the project. It can also include existing systems that will be modified, removed, or relocated. The document will evolve and should be maintained during the project life cycle as change will happen, such as adding or removing a new system from the project scope.
The list will be the basis of the resources needed for the project, the contractor’s scope, the GMP impact assessment (generally attached to the validation master plan), the establishment of a construction and start-up sequence and the level 2 schedule. Therefore, you must control its version and have precise system identification.
- VMP or pVMP
The project Validation Master Plan (pVMP) is a document that describes the project activities having a GMP impact or, if you prefer, activities that could impact the quality of the product. In addition, it outlines the qualification and validation requirements applicable to the facility, utilities, equipment, and processes. The pVMP is the GMP plan of record for a project.
- Project Plans
The project team will generate many plans as part of the project delivery – Project Execution Plan, Construction Plan, Commissioning and Qualification Plan, Safety Plan. Depending on the size and strategy, those plans could be a single page document or a dozen pages. Likewise, they could be project-specific or global guidances. CQ contributes to those plans, some in their entirety, some as a section or a reviewer. Either way, you need to be aware of them as they govern the project definition and implementation strategy.
- System Classification, also often called SIA
The system classification will be your first triage exercise to focus the effort on the quality impact system. To assess if a system has a direct impact or no direct impact on quality, you will need to use a set of criteria. Once you have classified your system, you will be able to define the type and level of testing you need to do. The system classification is almost always done using the system list we mentioned above and attached to the VMP.
- URS
All systems you buy, install, or test will need to have some type of User Requirement Specification from a good engineering standpoint. Using your system classification, you can easily focus on writing URS for systems with direct quality impact. We generally refer to another name for a non-direct impact system (i.e., Material Requisition, System Specification, etc.). But for a quality direct impact system, EudraLex Annex 15 defined the expectation for URS. The URS is the basis of your design and testing requirements and should define the intended use of the system without necessarily dictating the engineering solution. In addition, the description should be specific enough to allow the definition of test acceptance criteria.
- System Risk Assessment
I can’t put it any better than the ISPE definition:
“The System Risk Assessment is the application of QRM to examine the product quality risk controls for direct impact systems. This assessment identifies the critical design controls (CAs/CDEs) and procedural controls that are required to mitigate system risks to an acceptable level. It is important for the project team performing the System Risk Assessment to include technical SMEs that understand the science behind the process and the risks associated with the CQAs”
(ISPE Baseline® Guide: Commissioning and Qualification – Page 27)
What does it mean?
This step will assess your system’s design elements and identify those that help build the quality in your product attribute by controlling a series of critical parameters within a pre-defined range. Those Critical Desing Elements will be the target of your qualification test protocols.
- Design Review and Design Qualification
Through the different phases of the design, which are Concept Design (CD), Basis of Design (BOD), and Detail Design (DD), the design of the different systems (facilities, equipment, utilities) will evolve. However, the Design Review will ensure that the system is still aligned with the process needs. The DQ, also defined in Annex 15 will record that the system’s design is fit for its intended use, meaning that all your user’s process requirements have been considered in the design of the equipment. Find out more about DR DQ on our blog.
- Test Protocols
Protocols provide documented evidence that the system was installed and operating according to its specification. Commissioning and qualification test protocols have a lot of names.
Here are a few:
FAT – Factory Acceptance Test
SAT – Site Acceptance Test
IQ – Installation Qualification
OQ – Operational Qualification
CCL – Commissioning Checklist
ICL – Installation Checklist
NCTP – Non-Critical Test Protocol/Plan
CTP – Commissioning Test Protocol or Critical Test Protocol/Plan
CQTP – Commissioning and Qualification Test Protocol/Plan
IV – Installation Verification
OV – Operational Verification
PQ – Performance Qualification
PPQ – Process Performance Qualification
etc.
How you name things does not impact the quality of the equipment or the process and, therefore, shouldn’t matter as long as you are consistent and Your CQV team has a good understanding of the expectation. Most important is that those protocols follow a plan allowing you to gain assurance that the equipment is designed and operated as per its intended use (the URS) and that it serves to build quality into the product.
- Traceability Matrix
Traceability Matrices, also called Requirements Traceability Matrix (RTMs), are used to trace each requirement to the design specifications (URS). In the matrix, you will match the requirement with the test that demonstrates that this requirement is met by referencing the documented and approved testing location (e.g., IQ, OQ). The best practice is to create the matrix early in the project. Therefore, the Traceability Matrix can be used throughout the project as an engineering tool to manage DR, testing activities, results, and documentation that ensures all CDEs have been met. In addition, it provides traceability for each URS requirement by design and thorough testing.
- Acceptance and Release Completion
Acceptance and Release is a pretty big decision. From this step onward, your system/process is deemed fit for the intended use and in a state of control. This means the product that would be manufactured is fit for human use.
Quality Unit acceptance and release represents the initiation of the “qualified state” and the beginning of QA-managed Quality Change Control, continuous performance monitoring, and periodic review.
Both EMA and FMA make it clear that a formal approval is needed:
- EudraLex Annex 15
A formal release for the next stage in the qualification and validation process should be authorised by the relevant responsible personnel either as part of the validation report approval or as a separate summary document.
- FDA Guidance for Industry Process Validation: General Principles and Practices
This states a clear conclusion as to whether the data indicates the process met the conditions established in the protocol and whether the process is considered to be in a state of control.
On top of those documents, you will need to have a robust change management system to cover Project change, Engineering change, and Quality change. Change management would be the topic of our futures blogs.
This is just an outline of the main document you will encounter in a CQV project.
Reach out to us if you are interested in knowing more about risk-based CQV. You can also visit our website for more information about No deviation and its services.
Pierre is a Chemical Engineer and the CEO of No deviation. He likes to develop a team vision for quality accountability and innovation. He is hugely optimistic and sees the opportunity in every task he undertakes.
