FDA Warning Letter - Change Control

Date: 25 Aug 11
Link: FDA Warning Letter (New Window)

Observation

This observation relates to the revalidation following changes of a Cutting and Packing Machine, however it could be applied to any computerised system. 2. Your firm failed to ensure that the automatic, mechanical, or electronic equipment, or other types of equipment including computers or related systems, will perform a function satisfactorily [21 C.F.R. § 211.68(a)]. For example:

a. The initial qualification for the (b)(4) Cutting and Packing Machine, Model (b)(4) was completed on June 7, 2007. Approximately 25 major and minor changes were implemented between June 14, 2007, and July 15, 2010, before your approval of the re-qualification report for equipment (b)(4).

In your response, your firm states that (b)(4) Cutting and Packing Machine is a custom-made unit. The unit consists of subunits that perform functions independently of one another and that modification to one subunit does not necessarily adversely impact other subunits or the equipment as a whole. You added that the requalification requirement was documented in each approved Change Control. Your response, however, is inadequate because you have neither provided documentation to demonstrate your claims of independently functioning subunits, nor have you provided your rationale why each equipment change did not necessitate a re-qualification and/or a re-validation of the (b)(4) Cutting and Packing machine.

In addition, your firm states that further system enhancement will be made to validation procedures. However, it is not clear as to your estimated completion date because the content of your proposal entitled, “(b)(4),” is so broad. Furthermore, we are not able to evaluate the adequacy of your corrective actions without sufficient details of your proposed enhancement.

Comment

Although this change may relate to mechanical and / or software changes the FDA regulatory requirement could apply to any Computerised System (automation, laboratory or IT system).

It is rarely practical or possible to perform a full revalidation following a change, particularly for large automation systems. However each change should be Risk Assessed to determine the potential impact on the overall system. For software systems the modularity of the software can be used to support mitigation, but a sound rationale must be provided to determine that the correct level of verification has been performed for each change and that the impact to patient safety, product quality and data integrity have been maintained.

Following a Risk Based approach to the validation and control of the system the risk assessments performed during the design phases should have identified the Quality Critical Attributes. This also should be used to support the approach to the verification following a change. Should a change be performed that has the potential to impact a Quality Critical Attribute of the system then the risk assessment for the change should identify consider the potential impact. Following the commissioning of the change (to demonstrate that the change functions as required) then re-verification of the critical attribute should be tested; this may be as simple as running the initial test script.

Managing risk and formally documenting the risk assessment process will provide sufficient detail to demonstrate that the change to a computerised system has been implemented and the risk to quality controlled and minimised.

A formal periodic review process should also consider the cumulative impact of change, along with quality events (incidents / deviations) to determine whether further controls or verification are required to maintain the computerised system within a qualified state.

Comments are always welcome.

Related Posts
Computer System Periodic Review
FDA Warning Letter - Computer System Periodic Review

Risk Management – A Continuous Process

Introduction

As discussed in previous posts the regulatory expectation is that risk management will be applied to all lifecycle phases of a computerised system. The recent issue of EU Annex 11 includes risk management at all stages of the computer system lifecycle.

GAMP 4 first introduced the concept of risk management and risk assessments and following the issue of the ASTM E52500 Specification and Verification and ICH Q9 Quality Risk Management the ISPE Good Automation Manufacturing Guide (GAMP) was updated. GAMP5 has risk management throughout the lifecycle of the computerised system.

The article Computer System Quality Risk Management provides an introduction to the computer system quality risk management lifecycle and the available risk analysis tools.

This post introduces the concept of the risk review throughout the lifecycle and the importance of maintaining the initial risk assessments generated through the project lifecycle.

FDA Warning Letters - Risk Assessments

Introduction

Although to date I have not found any references within the FDA warning letters directly relating to computerised systems and risk assessments within the pharmaceutical / biotechnology industry it is interesting to review inspection findings where risk assessments have been detailed.

In this post there is a review of two FDA warning letters which reference the use of documented risk assessments.

EU Annex 11 – Risk Management

As stated in the earlier post EU Annex 11 has been updated and becomes effective on the 30 June 2011. This is part of a series of reviews detailing what has changed and the impact on Computer Systems Validation.

Risk Management now underpins the whole process of Computer Systems Validation. This has been a driving force since the introduction of GAMP4 and even more so through GAMP5.
In the revised EU Annex 11 risk management is placed at the heart of the lifecycle of computerised systems

1. Risk Management

Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.

This aligns with Annex 15 Qualification and Validation which states

A risk assessment approach should be used to determine the scope and extent of validation.

The ISPE GAMP5 was issued in 2008 and providing a process incorporating a risk based approach. However it is still taking companies time to integrate a risk based approach in to their process. Although a risk based approach based on process understanding can save a lot of work in the implementation and operation of computerised systems it is a major change the current process.
The steps to incorporating a science and risk based approach to computer systems validation is to determine and document in validation procedures the points where risk assessments will be performed and which tools are the most appropriate.

Although risk management should be a continuous process the key stages in a project where risk assessments should be performed and the suggested risk tools.

• Identification of User Requirements - Preliminary Hazard Analysis
• Design Review (Functional Design Specification) – Failure Mode Effects Analysis (FMEA)
• System Handover – Update of FMEA
• Incident Management – Fault Tree Analysis / Fishbone (Ishikawa) Diagrams / Statistical Tools
• Change Control - Update of FMEA

The FMEA should be the underpinning quality risk management tool for computerised systems and this should be updated regularly based on process data (incidents, changes, etc) to ensure that the risks that were initially identified during the project phase and the perceived risk scores are supported by operating data and the controls that have been put in place to reduce risk are affective. As a minimum the FMEA should be checked and updated during the periodic review of the computerised system.

See Article Quality Risk Management for more information.
Your comments on implementing a Quality Risk Management approach within computerised systems validation and also Annex 11 are welcome.

FMEA for Computer Systems

I have published an article on the Computer Systems Validation web site (www.csv-qa.com) for performing Failure Mode Effect Analysis (FMEA) for automation and process control equipment.

This article provides an introduction to performing a FMEA risk assessment for computer system validation as part of a quality risk management process.

The process details application of the approach included in GAMP 5 for performing a risk assessment along with some techniques to ensire that all the hazards are identified.
I hope that you find the article of interest, comments and suggestions relating the FMEA for Computer Systems article are welcome; please publish them on this blog.

What is a risk based approach?

As discussed in a previous article (Changes in Validation) a risk based approach to computer systems validation has change the way validation is performed.

Spend Less

Many in the pharmaceutical and biotech industries miss understood the message of a Risk Based Approach as an opportunity to take quality risk and spend less on the introduction of new equipment; that is to take a risk.

However this is not the purpose of a Science and Risk Based approach to qualification. While it provides an opportunity to reduce validate computer systems more efficiently (and therefore more cost effectively) the primary purpose is to concentrate validation effort on ensuring Patient Safety, Product Quality and Data Integrity.

A Science and Risk Based approach provides opportunities for a more efficient testing process, separating the quality aspects from the Good Engineering Practice (GEP).

Good Engineering Practice (GEP)

This separation of the quality and GEP verification (testing) offers new challenges for the pharmaceutical industry. Over the last 15 to 20 years the testing process has fallen under the “Validation” banner. At many companies the Validation Protocols would include tests for both quality and business (including safety) functions. This added additional burden to the testing, and the considerable overhead of the quality system on to areas of GEP.

The challenge to driving efficiency savings in to the validation of software / computerised systems is to develop processes (Good Engineering Practice) with the requirements for formal qualification / verification of quality attributes (Product Quality, Patient Safety and Data Integrity).

Development of these processes provide the greatest opportunity for driving efficiency and cost savings, removing the Quality Unit and the burden of the quality system from areas that do not impact GMP (while of course maintaining control).

Summary

A Science and Risk Based approach does not offer a method for cutting corners and doing less to ensure compliace with GMP.  However it does allow for the development of processes and reduced controls over areas that do not impact GMP compliance to become more efficient and cost effective.

Related
Article - Quality Risk Management Overview for Computer Systems

Computer System Impact / Risk Assessment

Purpose of Risk Assessment

The purpose of the risk assessment process is to ensure that the validation (quality) effort is directed at the systems that have the potential to impact product quality, efficacy and data integrity (throughout this article referred to as Product Quality).

Initial Risk Assessments

In the ISPE Commissioning and Qualification Guide the approach to an initial impact assessment was first introduced. This was designed to ensure that only systems that have the potential to impact product quality require formal validation.

The impact assessment process had selections.

• Direct Impact - A system that is expected to have a direct impact on product
  quality.
• Indirect Impact - A system that does not have a direct impact on product quality
  but is linked to / supports a direct impact system.
• No Impact – A system that does not have the potential to have an impact on
  Product Quality and is not linked to or support a direct impact system.

Only systems that have a Direct Impact on Product Quality require full formal validation. Where systems are identified as Indirect Impact then the interfaces to the Direct Impact System should be considered. No Impact systems do not require formal verification and should be installed following Good Engineering Practices (GEP).
While this impact Assessment provides guidance as to what systems require validation it does not support the level of validation required. At the early stage of the process a Risk Assessment can support the approach and level of software validation required.

Computer System Risk Assessment

GAMP 5 supports the approach of performing an initial risk assessment to determine:

• What are the risks to the business
• System GxP Determination
• What is the overall impact of the system
• Determine if more risk assessment are required

This provides the impact assessment and some planning. However even at the early stage of the project a simple risk assessment can provide guidance to the Computer Systems Validation requirements, based on

• Product Quality / GMP Impact
• Complexity of the Process
• Stability of the Software (GAMP Category)

From the combination of these items a number of recommendations can be made. This includes

• Supplier Audit requirements
• Software development controls (e.g. Source Code Review)
• Design Documents (Functional Design Specification, User Manuals, etc)
• Further risk assessment (Component Assessments, FMEA, etc)
• Test Documentation
These recommendations as to the validation requirements can be automated in a spreadsheet, based of a combination of the Impact, Complexity and GAMP category.

In future posts I will provide examples of this Impact / Risk Assessment process for computerised systems. If there are any specific examples that you would find useful then please post them within the comments.