Category Archives: Specifications

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)