Q&A: User Requirements Specifications Related to Commissioning & Qualification

This blog is the first of four posts addressing questions received during the August 2019 webinar summarizing the introduction of 2nd Edition, ISPE Baseline Guide Vol 5: Commissioning and Qualification. The guide provides a well-defined framework for a lifecycle Quality Risk Management (QRM) commissioning and qualification (C&Q) approach to verification and documentation of fitness for use.

Over the coming weeks, each blog post will cover four key focus areas discussed in the guide. The posts will be followed by a live townhall session, scheduled for Tuesday, 7 July 2020. The townhall will be moderated by the panel of authors with each panelist reviewing and answering your questions on these key areas.

The four key focus areas covered in this blog series will be:

• User Requirements Specifications (URS), moderated by Stephanie White, Amgen
• Quality Unit, moderated by Nick Haycocks, Amgen System Risk Assessment, moderated by Steve Wisniewski, CAI
• IT/GAMP® 5, moderated by Steve Wisniewski CAI and Verification (commissioning and qualification execution), moderated by Zachary Luce, Project Farma
• Design Review/Design Qualification, moderated by Nathan Temple, CAI Periodic Review, moderated by Alex Mendoza, Takeda

User Requirements Specifications (URS)

The User Requirements Specification document contains requirements from multidisciplinary sources and supports design, commissioning and qualification activities, operations, and maintenance. Brief highlights of answers to FAQs from prior workshops include:

• Critical Quality Attributes (CQAs) and Critical Process Parameters (CPPs) are key inputs into user requirements specifications which are required to support the Quality Risk Management based Commissioning and Qualification process and are identified prior to User Requirement Specification generation.
• User requirements specifications documents can be written around a platform to address the requirements of a multi-purpose operation.
• User requirements specifications are living documents that are updated as requirements change during any phase of a project or as additional risk controls are identified.
• The user requirements specification document should not contain the content of engineering specifications and standards, the means by which user requirements are met, or contain contractual contract requirements.

What is the alignment between the new Guide and GAMP® 5?

The scope of the BG5 revision is equipment and automated systems. All other computerized systems fall under GAMP®. GAMP® describes a science risk-based approach for hardware and software development. For automation/Process Control Systems attached to systems and equipment the user requirements specifications for each must align when addressing critical process parameter control, alarm management, and data management. These aligned user requirements are verified using an integrated testing strategy.

What is the impact of the Guide on IT and IS systems, (i.e., ERP, SAP, etc.)?

IT and IS are out of the scope of the Guide and fall under GAMP®. GAMP® describes a science and risk based approach, and the GAMP® organization are always looking for ways to optimize the approach.

Can the Guide approach be applied to lab instruments; including any associated automation?

Laboratory instruments are not in the scope of the Guide. Laboratory support equipment, such as controlled temperature storage units, and critical utilities serving laboratories, such as USP/WFI water and gases are covered in Guide Scope.

User Requirements Specifications:

Is it necessary to define Critical Design Elements and critical process parameters during the preparation of user requirement specifications?

Critical quality attributes and critical process parameters are key inputs into user requirements specifications, and the quality risk management commissioning and qualification process, and should be identified prior to user requirements specifications generation. (Ch3)

Critical Design Elements (CDEs) are usually identified based on technical understanding of the products critical quality attributes, process critical process parameters, and equipment/automaton design. Critical aspects (CAs) are identified through system risk assessments. Critical aspects mitigate system risk to an acceptable level and are tested during commissioning and qualification. Critical design elements are identified during design development and implement critical aspects. (Ch3 and Ch4)

Could you please explain more about the difference between critical aspects and critical design elements and provide some examples?

Critical aspects are functions, features, abilities and performance or characteristics necessary for the manufacturing process and systems to ensure consistent product quality and patient safety. Critical Design Elements are design and automation functions or features of an engineered system that are necessary to consistently manufacture products with the desired quality attributes. (Definition in ISPE Baseline Guide Vol 5: Commissioning & Qualification)

Examples of automation design functions include alarms and data management. Examples of engineering design features include components, instruments, and materials of construction.

How can user requirements specifications or critical process parameters be defined for a multi-purpose API plant where the critical process parameters can change based on new product introduction?

The user requirements specifications can be written around a platform (with operating ranges to match the equipment capability). For new product introduction, review product and process requirements against the user requirements specifications. Ideally, as the user requirements specifications is based on very broad requirements, the new product should fit inside these requirements. If it doesn't you will need to make appropriate changes to the equipment and qualify the changes under Quality Change Control or consider new equipment.

Can you explain how this approach works if you don’t know the critical quality attributes and critical process parameters upfront (i.e. they are still being developed)?

Similar to the API question above, the user requirements specifications can be written around the selected equipment/system (with operating ranges to match the equipment capability). For selected product introduction, review product and process requirements against the user requirements specifications Ideally, as the user requirements specifications is based on very broad requirements, the new product should fit inside these requirements. If it doesn't you will need to make appropriate changes to the equipment and qualify the changes under Quality Change Control or consider new equipment.

Are user requirements specifications verified during the design qualification reverified during testing?

The purpose of a design qualification is to ensure that the design intent satisfies the user requirements and is fit for intended use. The design qualifications also verifies incorporation of the risk controls (critical aspects), identified during the System Risk assessment, into the final design so fabrication can begin. The verification that the requirements are being meet (as defined in the user requirements specifications and documented in the design qualifications) are verified through test execution.

Is it appropriate to update the user requirements specifications after FAT, SAT?

The user requirements specifications is living document and changes will be driven by changes in the requirements. FAT and SAT should not drive change, but you may discover a requirement that has been missed that needs to be added to the user requirements specifications through those activities. Any revision changes to the user requirements specifications will be addressed through change management.

Is the user requirements specifications as a total container that is useful for project execution to minimize over-processing?

The user requirements specifications does not include everything, for example, it will not repeat the content of engineering specifications and standards. The user requirements specifications provide a vehicle to inform the responsible designer of specific requirements he/she can use to develop the equipment specifications for the procurement of equipment.

Did you miss the webinar? Members can view Polishing an Old Gem: Commissioning & Qualification Baseline Guide Update webinar. Not a member? Join Today!

Join us next week as we discuss frequently asked questions on the topics of Quality Unit and System Risk Assessments.