c and q lifecycle pharmaceutical industry no deviation

Defining Requirements in the C&Q Lifecycle

The ISPE Baseline Guide Volume 5: Commissioning and Qualification Second Edition proposes an integrated C&Q approach that aims to make the C&Q process compliant, efficient, and cost-effective. The key facets of this approach are as follows:

  1. Using a System Risk Assessment (SRA) to identify Critical Design Elements (CDEs) that need to be qualified
  2. Using properly performed and documented tests to qualify the system
    Science and Risk-based C&Q Process Map obtained from the ISPE Baseline Guide Volume 5: Commissioning & Qualification (2nd Edition)In this article, we will be discussing the Define Requirements stage of the C&Q process, specifically the following activities:

    1. User Requirements and Specifications (URS)
    2. System Impact Assessment (SIA)
    3. System Risk Assessment (SRA)


    User Requirements and Specifications (URS)

    The URS is a list of requirements that need to be met in order for the system to carry out its intended purpose. An example of requirements from an URS for an autoclave may be as follows:

    |S/N Description Classification
    1 The autoclave chamber shall have minimum dimensions of L1.3 m x W1.3 m x H1.5 m. Business
    2 The autoclave chamber leakage rate shall not exceed 1.3 mbar/min (EN285). Quality
    3 The autoclave shall be able to maintain a uniform temperature of 121oC for at least 15 min during the dwell period (EMA Guideline on the sterilisation of the medicinal product, active substance, excipient and primary container) Quality
    4 The autoclave doors must be locked closed when the chamber temperature exceeds 45oC (company safety standard CSS101). EHS

    From the example, we note the following:

    1. Requirements may be classified into one or more categories (Quality, Business, EHS). The requirements may arise due to:
      1. Product and process knowledge (during development)
      2. Regulatory requirements
      3. Organisational requirements
      4. Engineering standards and specifications
      5. Project requirements/project charter

    Understanding the rationale of the requirements and their categorisation will help with developing commissioning and qualification testing that is fit-for-purpose.

    1. In general, requirements do not state how they are to be met. Having these defined early may overly restrict the design in subsequent phases of the project. On the other hand, generic statements such as ‘System must comply with all regulatory requirements.’ would not help the team in defining the requirements either.
    2. Requirement should be testable. This means that requirements should be SMART (Specific, Measurable, Achievable, Relevant, Traceable). Some examples of requirements for an autoclave for porous loads that do not meet the criteria are as follows:
      Attribute Bad Example
      Specific The autoclave should be 1.3 m x 1.3 m x 1.5 m.


      Which part of the autoclave is this referring to – outer or chamber dimensions? Are any of the dimensions fixed as height, or are the dimensions interchangeable?

      Measurable The autoclave chamber shall not leak significantly.


      The criterion of “significantly” is unclear.

      Achievable The autoclave chamber leakage rate shall not exceed 0.000003 mbar/s.


      It is very unlikely for an autoclave to be manufactured that meets this requirement. It is also unlikely for a pressure transmitter capable of measuring to such a precision to be found.

      Relevant The autoclave shall be able to maintain a uniform temperature of 121oC for at least 15 min during the dwell period when loaded with liquid loads.


      The requirement is not relevant to the product being manufactured in the process. An autoclave for porous loads would not have requirements for liquid loads cycle.

      Traceable The autoclave doors must be locked closed when the chamber temperature exceeds 45oC.


      Without any knowledge of organisation-specific standards, we are unable to tell where this value of 45oC comes from. We have seen two methods of providing such clarity: 1) Referencing the standards from which this requirement is obtained; 2) Providing a Classification column in the URS template. Another possible method can be to provide the rationale for changes leading to the current requirement under the Revision History.

      Depending on the complexity of the project, multiple URS’s might be involved. The division of URS’s between different equipment and systems may differ depending on system boundary, purpose, potential vendor involvement, complexity, chronology etc. Some cases to consider:

      • Equipment shared between different processes may have 1 URS encompassing all processes, or one per process for simplicity.
      • A complicated system (e.g. “superskid”) can be split into different sections, with each section having 1 URS.
      • Consider if there are opportunities for grouping systems with similar/identical URS for potentially more efficient qualification down the line.


      System Impact Assessment (SIA)

      The URS gives the project team an idea of the Critical Aspects (CAs) required of the system. A SIA determines if the system has direct quality impact and therefore requires qualification activities. Most common SIA formats follow some form of the 8 guiding questions from the ISPE Baseline Guide for C&Q (see below), with additional classifications that can be done per organisational requirements (e.g. GAMP5 classification).

      1. Does the system contain CAs/CDEs or perform functions that serve to meet one or more process requirements (CQAs) including CPPs?
      2. Does the system have direct contact with the product or process stream and does such contact have the potential to impact the final product quality or pose a risk to the patient?
      3. Does the system provide an excipient or produce an ingredient or solvent (e.g. WFI) and could the quality (and compliance with the required specifications thereof) of this substance impact the final product quality or pose a risk to the patient?
      4. Is the system used in cleaning, sanitizing, or sterilizing, and could malfunction of the system result in failure to adequately clean, sanitize, or sterilize such that a risk to the patient would result?
      5. Does the system establish a proper environment (e.g., nitrogen blanket, closed process, exposed filling zone air quality, maintenance of temperature, humidity when such parameter is part of the product CPPs) for the process and could failure of the system to function properly pose a risk to the patient?
      6. Does the system use, produce, process, or store data used to accept or reject product, CPPs, or electronic records subject to 21 CFR Part 11 and EU GMP Vol. 4, Annex 11 or the local equivalent?
      7. Does the system provide container closure or product protection, the failure of which would pose a risk to the patient or degradation of product quality?
      8. Does the system provide product identification information (e.g., lot number, expiration date, counterfeit prevention features) without independent verification or is the system used to verify this information?


      The most important input document needed to generate the SIA, besides the URS, is the P&ID with clearly defined system boundaries. The inclusion of elements into the system’s boundary has the potential to change the response to some of the questions listed above and therefore impact the system’s classification.

      System Risk Assessment (SRA)

      Per the ICHQ9 framework, the objective of the SRA is to identify hazards to product quality, assess the risk they pose and provide sufficient control measures to mitigate the risk throughout the product lifecycle. As described in the introduction of this article, the SRA identifies the CDEs (or the control measures per the ICHQ9 framework) that will need to be qualified; additionally, it also provides some basis for the rigour of qualification required. Subsequent documents such as the Requirements Traceability Matrix (RTM) will track where the CDEs identified are qualified – the project team should take note of tests that can take a long time to complete. In projects with tight schedules, SRA also helps the project team prioritise testing that mitigates the largest risks.

      There are many excellent guides to the various commonly used risk assessment tools and how a risk assessment should be conducted. The number of choices available may, however, pose a problem when a project team needs to select one such tool to use. The recent revision R1 of ICHQ9 recommends project teams to take note that the formality of SRAs should be commensurate to the level of risk posed by the system. The level of risk is typically inherent to the system and the process(es) involved, but other factors, such as experiences with similar equipment, or experiences with the equipment vendors, may be considered as well. For example, a standard off-the-shelf system such as a Shaker may not even require an SRA to be conducted – a standard test protocol can be used since the risks the system brings to most processes are relatively universal and well-understood. For systems that are less clear-cut, risk-screening can be done using a simple tool such as a questionnaire or decision tree to determine the formality relatively easily.

      A complete SIA is a pre-requisite for the SRA, which in turn necessitates that the URS and P&IDs with clear system boundaries should be available as well. The two other important types of input documents are a list of process CQAs and CPPs, which help determine the CAs and CDEs required for the system, and Design specification documents, which list the various functions and design elements built into the system.


      What’s next?

      The beauty of the risk-based C&Q integrated approach lies in the fact that documents written earlier in the process will end up as important inputs for subsequent documents. Here we highlight two examples:

      After the system requirements have been defined, the C&Q Engineers will begin writing the C&Q Plan, which detail the C&Q activities for individual systems in the entire project. From the US FDA Guidance for Industry – Process Validation: General Principles and Practices: “Qualification of utilities and equipment can be covered under individual plans or as part of an overall project plan. The plan should consider the requirements of use and can incorporate risk management to prioritize certain activities and to identify a level of effort in both the performance and documentation of qualification activities.”

      Prior to the construction and assembly of the system, a Design Review (DR) or Design Qualification (DQ) is typically performed to assess whether all the requirements listed in the URS are met, and whether all the CDEs identified in the SRA have been included in the final design. For more information on the DR and DQ, please refer to Joon’s excellent article on the topic.

      At No deviation, we partner with you to help you with executing your CQV process, troubleshooting or your CAPA, or implementing new digital solutions. Reach out to us for a full risk-based paperless validation with integrated commissioning and test plan or to bring efficiency to your existing paper-based IQ, OQ execution.

      You can also visit our website for more information on our services.

      We want to thank Dong Heng  for his contribution & his expert insights in this blog post. 

      With 4 years in the pharmaceutical and Oil and Gas industries, Dong Heng has been a valuable member of the No deviation team. In this role, he has successfully contributed to Design and CQV projects with numerous clients. Dong Heng holds a Master’s Degree in Chemical Engineering from the University of Cambridge.

Leave a Comment

Your email address will not be published. Required fields are marked *