Tag Archives: Qualification

Validation Project Plans

develop-project-plan-1200x480

Hello good people of the world! Today’s post is about Validation Project Plans, which is a specific type of project plan for projects in the pharmaceutical, biotechnology, and medical device regulated industries. This post covers Validation Project Plans for pharmaceutical/biotechnology industries in particular.

Often I’ve see Validation Project Plans contain a lot of fluff but little meat, making them of less value to the project team. A good project plan clearly documents the following, at a minimum:

  1. What facilities, systems, and equipment are in scope of the plan
  2. What are the expected activities and deliverables
  3. Who is responsible for what
  4. What is the validation approach and rationale for that approach
  5. What happens after the validation scope covered in the plan is completed (i.e. ongoing requirements)

Note I do not include project cost or schedule in a project plan, because these are often changing rapidly and should be maintained in a less controlled, more flexible manner, e.g. with scheduling software for a schedule.

The plan itself should be controlled (i.e. approved and revision controlled) as soon as possible in the project but early enough so that scope will not change (too much).

Additional things to think about when drafting your plan:

  1.  Commissioning versus Qualification versus Validation. If your project has multiple phases (and any decent-sized project should), be sure to clearly state responsibilities and deliverables at each stage.
  2. Include references to regulations, industry guidance, and site procedures that govern your plan. Make it clear to everyone who reads the plan what framework you are working inside.
  3. The purpose and scope of the document should be clear and up front.
  4. Get buy-in from all functional groups by having them approve the document.
  5. Like all controlled documents, the plan should have version/revision history.
  6. Use tables to clearly present information.

I put together a quick template here:

Validation Project Plan Template MWV

What do you feel is necessary in a Validation Project Plan? Comment below.

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

 

 

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!

 

Basic Components of a Test Form

Hello good people of the world! Today’s post is a short one on what are the basic components of a test form. In Validation, you’re going to record a lot of data, and you want this data to be well organized and easily understood. Here are the basic components I think every test form should have:

  1. Numbering! Each step should have a unique number so that it is easily identifiable and easy to reference elsewhere.
  2. A Title! What is this test all about? A short description should be provide.
  3. Purpose! What is the purpose of the test? Make it clear.
  4. Verification Steps! Clearly define what steps need to be performed.
  5. Expected Results! Clearly define what the expected results are. Does every step need an expected result? Every step can have one, so include it.
  6. Actual Results! This is where the actual data is collected. The actual results can be recorded exactly as the expected results are stated to avoid any confusion.
  7. Pass/Fail! Did the step pass or fail? This will quickly tell you. Also a good place to reference any comments.
  8. Initials/Date! In order for the data to be attributable, initial/date uniquely identifying the test executer must be included for each step.

What basic components do you include on your test forms? Comment below.

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

Considerations in SaaS Validation

SaaS Qualification

Hello good people of the world! Today’s post is about qualifying Software as a Service (SaaS), also known as “cloud-based” or “hosted” software. Simply, SaaS is any computer system in which any server is not hosted by the system owner. Here are some key considerations in qualifying SaaS computer systems:

Continue reading Considerations in SaaS Validation

Container Closure Integrity Testing

Hello good people of the world! The present post concerns itself with Container Closure Integrity (CCI) testing. CCI testing is an integral part of packaging validation, involving primary packaging such as ampoules, blisters, bottles, vials, syringes, tubes, etc. Biopharmaceuticals are typically packaged in hermetically-sealed containers to prevent the ingress of any liquid or gas that could be reactive or carry microorganisms. Packaging may also by light-resistant, if light could affect the properties of the product.

There are three regulatory/industry guidelines typically cited in the U.S. regarding CCI testing:

  1. FDA Guidance for Industry (2008), Container and Closure System Integrity Testing in Lieu of Sterility Testing as a Component of the Stability Protocol for Sterile Products
  2. PDA Technical Report No. 27 (1998), Pharmaceutical Package Integrity (not available for free)
  3. USP <1207>, Sterile Product Packaging – Integrity Evaluation

CCI testing is either physical (bubble, liquid tracer, vacuum/pressure decay, dye ingress, etc.) or microbial (microbial ingress).

Each has it’s advantages and disadvantages, as shown in the below from American Pharmaceutical Review:

When should these tests be performed? CCI testing is applicable to new container closure systems and can be performed on newly sealed containers to validate sealing performance, and then annually and at the expiration date to validate stability.

What are your preferred methods of Container Closure Integrity Testing?

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

Cleanroom Isolators

RABS

Hello good people of the world! Today’s post is about cleanroom isolator technology, specifically Restricted Access Barrier Systems (RABS). RABS are typically employed at the high-risk manufacturing step of fill/finish, were finished product may be exposed to the surrounding environment (i.e. the process is “open”). In the case of parenteral (injectable) pharmaceuticals or biologics, where post-fill sterilization is not possible, environmental control at the fill step is of paramount criticality.

Heating, Ventilation, and Air Conditioning (HVAC) general concepts: HVAC is an important system in maintaining cleanroom cleanliness, but is typically categorized as an “indirect-impact” “commission-only” system, separated from the cleanroom itself via High Efficiency Air Particulate (HEPA) filters and controlled via feedback from local cleanroom differential pressure (DP), temperature, and, if required, humidity sensors.  The main components of the HVAC system include the Air Handling Unit, which may be comprised of a mixing chamber (for return and outside air), filters, heaters, coolers, and humidifiers.

Cleanroom general concepts: the cleanroom is typically classified according to ISO 14644-1, GMP EU grades, and/or US Federal Standard 209E classes, among others. A good summary is here. These classifications define the allowable number of total airborne particles and viable airborne particles. Total and viable particulates can be reduced by increasing the air exchange rate, which is the number of times (typically per hour) that the total room air volume moves through the AHU. For class B (ISO 7 in operation), 30-60 air changes are used. For class C (ISO 8 in operation), 20 air changes may be used.  Class A space (ISO 5) could require Unidirectional Air Flow (UDAF), which should be differentiated from Laminar Flow (LF), with an air velocity of 0.45 m/s ± 20%.

In cleanrooms, by far the grossest contributor to airborne particulate counts are the operators. Moving even slightly, an operator might produce more than 2.5 million particles of size 0.3 μm or greater per minute! (source). For this reason alone, barrier technology is critical in Class A cleanroom space. This is typically achieved via an active or passive Restricted Access Barrier System (RABS) or via an Isolator.

A RABS is an area that has a rigid enclosure with safety-interlocked doors, and glove ports for manual interventions. Passive RABS has no aeration equipment. Active RABS has it’s own aeration and filtration equipment.

Isolators are similar to RABS, except that they are hermetically (airtight) sealed to completely separate operators from the process area.

Both the RABS and Isolator create an UDAF over the Class A space.

Which do you use? Which do you prefer? What application would required an Isolator over a RABS?

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