Category Archives: Specifications

ISPE’s Commissioning and Qualification Guide Second Edition

Hello good people of the world! Today’s post covers ISPE’s release of the second edition of their commissioning and qualification guide. This is volume 5 of the baseline guides. The first edition was first released way back in March 2001, so we should expect this to be a significant revision. Please note this guide is not available for free.

One very nice thing about this second edition is that it not only updates the first edition of the volume 5 guide, but incorporates scope from two other now-outdated guides as well: “Science and Risk-Based Approach for the Delivery of Facilities, Systems, and Equipment” and “Applied Risk Management for Commissioning and Qualification.” So if you have these in your library, you can safely archive them.

It’s always important to note that industry guides such as this one do not constitute regulations and are not required to be followed. It is often the case however that best practices documented in guides become industry standard, and then set expectations for regulators. Per the guide, it is intended to comply with EU GMP Annex 15FDA Guidance on Process Validation, and ICH Q9.

The table of contents shows the following sections:

  1. Introduction
  2. User Requirements Specification
  3. System Classification
  4. System Risk Assessment
  5. Design Review and Design Qualification
  6. C&Q Planning
  7. C&Q Testing and Documentation
  8. Acceptance and Release
  9. Periodic Review
  10. Vendor Assessment for C&Q Documentation Purposes
  11. Engineering Quality Process
  12. Change Management
  13. Good Documentation Practice for C&Q
  14. Strategies for Implementation of Science and Risk-Based C&Q Process

And the following appendices:

  1. Regulatory Basis
  2. User Requirements Specification Example
  3. System Classification Form Example
  4. Direct Impact System Examples
  5. System Risk Assessment Example
  6. Design Review/Design Qualification Examples
  7. Supporting Plans
  8. System Start-Up Examples
  9. Discrepancy Form Example
  10. Qualification Summary Report Examples
  11. Periodic Review Example
  12. Periodic Review for Controlled Temperature Chambers
  13. Vendor Assessment Tool Example
  14. Organizational Maturity Assessment Example
  15. Approach to Qualifying Legacy Systems or Systems with Inadequate Qualification
  16. References
  17. Glossary

You’ll have to purchase the guide to get all the details, but below are some highlights that stuck out to me:

  • This second edition introduces the term Critical Design Elements (CDEs). CDEs are defined as “design functions or features of an engineered system that are necessary to consistently manufacture products with the desired quality attributes.”
  • Concepts that were removed from this edition of the guide include Component Criticality Assessment, Enhanced Commissioning, Enhanced Design Review, Enhanced Document, Indirect Impact (systems are either direct impact or not direct impact now), and the V-Model.
  • A Direct Impact system is defined as a system that directly impacts product CQAs, or directly impacts the quality of the product delivered by a critical utility system. All other systems are considered to be not direct impact. An example included in section 3 demonstrates the previously categorized “indirect impact” systems would become not direct impact systems and would be commissioned only, although the commissioning for these system may be more robust than a purely “no impact” system. The guide provides an eight (8) question process for determining if a system is direct impact.
  • System boundaries should be marked on design drawings.
  • Inputs to the URS should include: CQAs, CPPs, regulatory, organization quality, business, data integrity and storage, alarm, automation, and health, safety, and environmental requirements, and engineering specifications and industry standards. The example URS template does include a classification of each requirement (e.g. business, safety, quality).
  • A system risk assessment is performed to identify CDEs and controls required to mitigate risks. Standard off-the-shelf systems typically do not require a risk assessment. Risk levels are defined as low, medium, and high and the risk assessment approach is not a typical FMECA process. Instead each CQA at each step gets one entry on how the CQA can be impacted, what are the design controls around that CQA and any alarm or procedural controls to mitigate risk. The residual risk post-controls is includes as low, medium, or high.
  • Design Qualification looks somewhat informal 0=- no DQ protocol, but a DQ report that summarizes other documents (URS, SIA) and design review meetings.
  • A C&Q plan should include clear scope, the execution strategy, documentation expected for each system (URS, FAT, SAT, IOQ, SOPs, etc.), and roles and responsibilities (e.g. approval matrix).
  • The discrepancy form has closure signatures only (no pre-implementation signatures)
  • For legacy systems without adequate C&Q documentation, focus should be on identifying product and process user requirements including Critical Quality Attributes (CQAs) and Critical Process Parameters (CPPs), and then the Critical Design Elements (CDEs) that affect them. It is necessary to confirm that accurate drawings exist, that maintenance files are up-to-date, and there is test evidence to support changes since commissioning. A risk-based approach can be used to qualify the system in the absence of typical C&Q documentation.

Do you use the ISPE guides for your C&Q approach? Comment below.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

 

Advertisement

Specifications: How to Write Them

GAMP V Model

Hello good people of the world! Today’s post is about the left side of GAMP’s V-model: specifications. Specifically, their purpose and how to write them.

Of course there are many variations of the V-model, and it is best to find what suits your organization and processes. For the purposes of this discussion, I’ll refer to the basic GAMP V-model, pictured above.

The specifications are: User Requirements Specification, Functional Specification, and Design Specification. In general each feeds in to the next. Also, Installation Qualification may test the details of the Design Specification, Operational Qualification may test the functional descriptions in the Functional Specification, and Performance Qualification may test the high-level requirement’s of the User Requirements Specification, although these boundaries are often blurred in practice.

Any new project should start with a User Requirements Specification which clearly defines the testable user requirements. It is important that requirements are testable, and often a SMART approach is applied: each user requirements should be Specific, Measurable, Achievable, Relevant, and Time-bound. It is also helpful to categorize user requirements upfront, since not all will be quality-related. This makes it easier to rationalize the requirements that are explicitly tested in qualification protocols versus commissioning or not at all. Typical categories include: business, safety, maintenance, and quality.

The Functional Specification is then a response to the User Requirements Specification, typically provided by the vendor, explaining in detail how automated components will function to fulfill the user requirements. Functional Specifications are often confused with Functional Requirements or Functional Requirements Specification, which may be another document defined by a process. GAMP’s V-model does not intend the Functional Specification to document new or further detail requirements, but to define the functionality employed to meet the requirements defined in the User Requirements Specification. The Functional Specification can describe sequence of operations, interlocks, alarms, etc.

The Design Specification should provide sufficient detail that an engineer could recreate the control system from scratch if need-be, to recreate the functionality described in the Functional Specification to meet the user requirements. The Design Specification is typically provided by the vendor and should contain such details as I/O list, alarm list, HMI security levels, sequence of operations details including device positions at each step and transition conditions. This should be a very detailed document, and if you’re working with 10-20 pages it is too light.

Documentation can be expensive and is maybe not fun to generate and review, but is critical to a highly effective validation program.

What do you like to see in specifications?

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

 

WHO’s Draft Guidelines on Validation May 2016

Hello good people of the world! On May 15, 2016, the World Health Organization released its draft Guidelines on Validation. It is available on the WHO website for download here.

This post covers my review of the guidance. Continue reading WHO’s Draft Guidelines on Validation May 2016

Staying in Control: Alerts and Alarms

alarm

Hello good people of the world! If you work with a mix of process equipment and supervisory control or monitoring systems, you know the importance of alerts and alarms, but most companies do not take the necessary steps to ensure their alerts and alarms are well configured and meaningful. One of the enemies is so-called “nuisance-alarms,” but just as important is knowing that you have enough alerting/alarming so that critical events are not missed and appropriate actions are taken before harm is done.

And by the  way, alerts and alarms are something the FDA has historically shown to care about (e.g.  FDA had observation at Teva Irvine for lack of validation on alerts and alarms). So what considerations are at play?

What should alert/alarm? If you’ve clearly defined your Critical Process Parameters (CPPs) and know what your Critical Quality Attributes (CQAs) are, you know already what needs alerts/alarms: all CPPs.

What should the alert/alarm limits be? This part is tricky: you need limits that provide operators with sufficient information without becoming a nuisance. All too often I see the situation where alarm banners are flashing but no one is paying attention because “there’s always alarms” or whatever.

What action should occur based on alert/alarm conditions? This is another place I often see improvements needed: every alert and alarm should have a documented action associated with it, typically in the SOP, that operators are trained on. If there is no documented action required for an alert/alarm, why do you have it?

What do you find critical in configuring alerts/alarms and introducing them into a manufacturing process?

Like this MWV (Mike Williamson Validation) post? Be sure to like, share, and subscribe! 

URS for Purified Water Systems

WFI Still
WFI Still

Hello good people of the world! Today’s post deals with the User Requirements Specification (URS) for a Purified Water System. It may be RO/DI, Purified Water, or WFI, but it should probably have a URS. As with any URS, make sure requirements are specific, measurable, accurate, repeatable, and testable. Considerations specific to purified water systems include: Continue reading URS for Purified Water Systems

Creating a User Requirements Specification (URS)

URS
Life without a good URS

Purpose of a URS:

  • Specify guiding regulations and industry and site standards the system must meet
  • Specify deliverables

Tips:

  1. Ensure each requirement has a unique number. This is for ease of traceability and referencing in other documents
  2. Evaluate the impact to quality in the URS itself. This will allow agreement up front for what requirements will need to be tested as part of qualification/validation, and which can be safety ignored.
  3. Each requirement should be specific and measureable so that it can be easily tested. While it’s tempting to include statements like “The XYZ system shall comply with applicable regulations” this statement really becomes meaningless because it is not specific enough, and is not testable. Continue reading Creating a User Requirements Specification (URS)