FDA Warning Letter - Automated System Validation

Date: 03 February 2012
Link FDA 483 (New Window)

Observation

Although this observation does not directly relate to 21CFR211.68 for computerised systems it still has an impact on the validation requirements of an automated system within a tablet manufacturing and packing line.

4. Equipment used in the manufacture, processing, packing or holding of drug products is not of appropriate design to facilitate operations for its intended use. [21 C.F.R. § 211.63) For example,

a. Our review of the equipment qualifications for multiple automated Tablet Testing System (TTS) machines, used to conduct in-process tablet testing (weight, hardness and thickness) revealed that performance qualification was not conducted to ensure the accuracy of the machine at the various available speed settings. A February 2010 investigation of OOS tablet weights for Digoxin tablets revealed that the TTSs were giving incorrect tablet weights for lighter weight ( < 200 mg) tablets when run at the default speed of (b)(4) and concluded it would give accurate results only when run at a speed of (b)(4) However, your firm failed to make a further assessment of the overall reliability of the TTS machines, including evaluating their accuracy with other products and other tablet weights at other speeds.

b. Your firm has not adequately qualified the in-line Pressure Control Device (PCD)-2 Automatic Tablet Weight Control System on the (b)(4) and (b)(4) tablet press machines. Your firm did not Qualifications (PQ) that are representative of all of the products run on the tablet presses to assure proper functioning, including evaluating the reject station timing in relation to tablet press rpm. There is no assurance that the PCD-2 system is accurately rejecting the "marked" OOS tablets throughout the compression run.

Definition of Raw Data

Within EU Chapter 4 – Documentation there is a clear definition of Raw Data and the requirements to retain the raw data.

Records: Provide evidence of various actions taken to demonstrate compliance with instructions, e.g. activities, events, investigations, and in the case of manufactured batches a history of each batch of product, including its distribution. Records include the raw data which is used to generate other records. For electronic records regulated users should define which data are to be used as raw data. At least, all data on which quality decisions are based should be defined as raw data

Electronic Raw Data

This provides clear definition of raw data and the regulatory requirements.

Where paper based records are maintained the regulated company should determine whether all the raw data is presented within the paper record or whether the record is a summary of the data. If it is a summary of the decision (for example within Laboratory Analytical test systems where the samples are taken, interpreted and a final result included) then the electronic raw data must be maintained to assure the integrity. Where the paper record is the complete record then the electronic data may be removed (see Deleting Electronic Data).

Raw Data will exist in many computerised systems and should be identified during the initial impact or validation determination statement. Examples of raw data maintained by computerised systems include

• Quality critical process data from instruments stored within data historian
• Alarm logs from automation systems
• Event logs and audit trails
• Laboratory instrument data
• Environmental monitoring data

Following from the final guidance from the FDA for 21 CFR Part 11, Electronic Records Electronic Signatures the regulated company must identify all raw data associated with making GMP decisions and determine what format (paper / electronic) that the data will be maintained. If the raw data is to be maintained in electronic format then the integrity of the record must be assured.

FDA Warning Letter - Alarm Management

Date: 25 May 11
Link FDA 483 (PDF - New Window)

Observation

b. During routine operations, if there is an alarm event (e.g., time out, high and low temperature for washing and siliconizing, instrument line failure, jacket gauge failure and steam header failure) during the wash and depyrogenation process, the [redacted] Stopper Washer captures the alarm condition via a print out and the data is retained with the / manufacturing batch record. The Quality Compliance Manager confirmed that the alarmed events are not periodically reviewed or trended to assure that the [redacted] stopper washer and/or wash and depyrogenation process is not drifting from the validated state of control;

Comment

This is an interesting observation relating to the management of alarms and the use of periodic review and / or trending to demonstrate that the system is not drifting from the validated state. This can relate to almost any automated or monitoring computerised system.
When specifying and designing an automated control or monitoring system careful consideration should be given to the alarms generated by the system. A process for identifying and prioritising alarms is critical to the success.
In very general terms those alarms that have quality impact will be set to operate at the point of Out-of-Specification which should result in a quality related deviation. Normally when there are Quality Critical Alarms then then there will be associated warnings, with a setpoint at a level appropriate to take action, before the Quality Critical Alarm is tripped.
The trip points are alarm setpoints should be clearly rationalised and approved by the Quality Unit.
Periodic Review / Trending
To demonstrate the process is operating within the specified range a review of the alarms generated during the process should be reviewed routinely. This should initially be performed during the initial performance monitoring (performance qualification) of the system. This should ascertain that the warning levels are appropriate (provides operators with sufficient opportunity to rectify the problem before a breach in quality limits) and if the process is controlling within the quality critical limits.
Following the PQ, all breaches in specification must be reported through the batch record / deviation system. This should provide a trend of the critical alarms.
For the warnings a periodic review should be performed, which may use statistical analysis based on an acceptable number of alarms (process capability) to ensure that the system is continuing to operate in control and without degradation of performance.
The frequency of review and the depth of the review should be based on the impact of the computerised system and the operating history.
As stated at the start of the comment by building the alarm management in to the requirements and design of the system, the statistical analysis can be performed by the control system or the alarms stored within a database to ensure that they can be access for trending and review purposes.

Useful information

ANSI/ISA–18.2–2009 - Management of Alarm Systems for the Process Industries
EEMUA 191 - Alarm Systems- A Guide to Design, Management and Procurement

EU Annex 11 - Computer System Inventory

EudraLex - Volume 4 Good manufacturing practice (GMP) Guidelines Annex 11 for computerised systems includes the requirement for the regulated company to maintain an up to date listing of relevant systems (GMP Computerised Systems) and their GMP functionality (inventory).

This is also a Japanese regulatory requirement and also an expectation of the FDA although not included within the regulations (21 CFR 211) it is often requested prior or during an inspection.

This post looks at the methods for developing the inventory for computerised systems to meet the requirements of EU Annex 11.

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