AUDIT TRAIL AND ITS IMPORTANCE

What is Audit Trail?

Audit trail means a secure recording of life cycle details such as creation, addition, alteration or deletion of information in record either paper or electronic, without obscuring or overwriting the original record.

An audit trail facilitates the reconstruction of history of such events relating to the record regardless its medium, including who, what, when and why of the action.

The audit trail should include the following parameters:

- Who made the change?- What was changed, incl. old and new values- When the change was made, incl. date and time- Why the change was made (reason)- Name of any person authorizing the change.

For example,

In a paper record, an audit trail of a change would be documented via a single-line cross-out that allows the original entry to remain legible and documents the initials of the person making the change, the date of the change and the reason for the change, as required to substantiate and justify the change.

In electronic records, secure, computer-generated, time stamped audit trails should allow for reconstruction of the course of events relating to the creation, modification and deletion of electronic data. Computer generated audit trails should retain the original entry and document the user identification, the time/date stamp of the action, as well as the reason for the change, as required to substantiate and justify the action.

Computer-generated audit trails may include discrete event logs, history files, database queries or reports or other mechanisms that display events related to the computerized system, specific electronic records or specific data contained within the record.

All processes to be designed so that data required to be created and maintained cannot be modified without a record of the modification. i.e Audit trail.

For example, chromatographic data should be saved to durable media upon completion of each step or injection (e.g., peak integration or processing steps; finished, incomplete, or aborted injections) instead of at the end of an injection set, and changes to the chromatographic data or injection sequence should be documented in an audit trail. Aborted or incomplete injections should be captured in audit trails and should be investigated and justified.

Where Audit trail required?

Audit trail information required throughout the Data life cycle as follows.· Data generation and capture;· Data transmission;· Data processing;· Data review;· Data reporting, including handling of invalid and atypical data;· Data retention and retrieval; back-up & Archival· Data disposal.

Audit trails (identified by risk assessment as required) should be switched on for each electronic system. Users should not be able to amend or switch off the audit trail. Where a system administrator amends, or switches off the audit trail a record of that action should be retained.

Similarly appropriate system should develop for manual systems to track attributable information for each activity.

I.e recording of attributable information in the respective documents/records like who, when, what and why of the activity.

An example of Audit trail environment:

Let’s assume the operator enters the batch number (manually, via keyboard) and confirms his data entry (Button OK). His first entry is now saved as electronic data, comparable when written on paper of the batch production record. It might be that he or his colleague finds out that the wrong number (transposed digits) was entered. The wrong entry can be corrected in real-time directly by the operator on the system (if we want that) by having detailed view on data audit trail as follows.

1. Operator enters batch number into the system
2. Operator presses the OK button or signed electronically with his user name & password – data is saved (version 1)
3. Operator realizes a wrong batch number entry and need to change the initial batch number entry
4. Operator reopens the data object and corrects the batch number
5. Operator presses the OK button or and signed electronically with his user name & password to confirm batch number change – batch number is saved (version 2)
6. Second operator (or shift coordinator or QA) verifies the change of batch number and signed electronically with his user name and password – double signature

How to review in Audit trails?

Routine data review should include a documented audit trail review where this is determined by a risk assessment.

• Determining the risk-based approach to review electronic data and required audit trails based upon process understanding and knowledge of potential impact on products and patients;
• Writing SOPs defining review of original electronic records and including meaningful metadata such as audit trails and review of any associated printouts or PDF records;
• Documenting the system architecture and data flow, including the flow of electronic data and all associated metadata, from the point of creation through archival and retrieval;
• Ensuring that the relationships between data and metadata are maintained intact throughout the data life cycle.

When designing a GXP system for review of audit trails, Audit trails may be reviewed as a list of relevant data, or by an ‘exception reporting' process.

An exception report is a document that states those instances in which actual performance deviated significantly from expectations, usually in a negative direction. The intent of the report is to focus data reviewer attention on just those areas requiring immediate action

For example,

An exception report can be prepared for a chromatographic analysis with following parameters that can reflect all possible abnormalities.

Channel Audit trail summary report:

Which contains Sample set Name, Sample set Id, Instrument method name, sample Name, system name, Channel Id, Run Time (Minutes), Data end time (Minutes), No. of result stored as minimum requirement.

Abnormalities that can be identified but not limited to:

1. Duplicate injections in sample set or sequence
2. Aborted or interrupted injection in the sequence
3. Unprocessed channels
4. Rut time differences in between runs
5. Delays in between injections
6. Instrument method changes in between sequence

Result Audit trail summary report:

Which contains Sample set Name, sample set ID, Instrument method name, Sample Name, system name, Channel ID, Processing method, Faults, Results, No. of result stored, Date Acquired, Acquired By, Date Processed, Processed by, Result Id and Manual as minimum requirement.

Following abnormalities that can be identified:

1. Reprocessed channels
2. Faulty injections
3. Processed with different processing methods
4. Manual integrations
5. Delay in processing

Key personnel, including managers, supervisors and quality unit personnel, should be trained in measures to prevent and detect data issues. This may require specific training in evaluating the configuration settings and reviewing electronic data and metadata, such as audit trails, for individual computerized systems used in the generation, processing and reporting of data.

For example, the quality unit should learn how to evaluate configuration settings that may intentionally or unintentionally allow data to be overwritten or obscured through the use of hidden fields or data annotation tools. Supervisors responsible for reviewing electronic data should learn which audit trails in the system track significant data changes and how these might be most efficiently accessed as part of their review.

Companies should implement procedures that outline their policy and processes for the review of audit trails in accordance with risk management principles. Critical audit trails related to each operation should be independently reviewed with all other records related to the operation and prior to the review of the completion of the operation, e.g. prior to batch release, so as to ensure that critical data and changes to it are acceptable. This review should be performed by the originating department, and where necessary verified by the quality unit, e.g. during self-inspection or investigative activities.

A procedure should describe the actions to be taken if data review identifies an error or omission. This procedure should enable data corrections or clarifications to provide visibility of the original record, and traceability of the correction, using ALCOA principles

What to review in Audit trails?

The relevance of data retained in audit trails should be considered by the organization to permit robust data review/verification. It is not necessary for audit trail review to include every system activity (e.g. user log on/off, keystrokes etc.).

Should not be expect to implement forensic approach during routine checking.

The activities that required audit trail review should be decided based risk assessment and as follows but not limited.

From System audit trail: (but not limited)

a) Unauthorized System policy/Configuration alterations

b) Unauthorized user creation, modification & deletion.

c) Unauthorized user Type/ user level creation, modification & deletion

d) Unauthorized user Group creation, modification & deletion

e) Unauthorized project/ folder creations, modification & deletion

f) Unauthorized data paths

From Data audit trail: (but not limited)

a) Activity/ process breakupsb) Additional data sheet issuancec) Instrument or equipment alarmsd) Critical process parameters deviationse) Process stat and stops against master instructionsf) Unauthorized issuanceg) Unauthorized releaseh) Unauthorized printingsi) Aborted single injection/Sample setj) Unprocessed channelsk) Interrupted injections without proper documentationl) Multiple processing data/ Number of results stored.m) Faulted chromatogramsn) Manually integrated data/ Created manual resultso) Unauthorized method modifications, Method revisions and its changes.

Who should review audit trails?

Audit trail review is similar to assessing cross-outs on paper when reviewing data. Personnel responsible for record review under CGMP should review the audit trails that capture changes to data associated with the record as they review the rest of the record

For example, all production and control records, which includes audit trails, must be reviewed and approved by the quality unit.

The regulations provide flexibility to have some activities reviewed by a person directly supervising or checking information based on criticality of activity.

Reviewers should have sufficient knowledge and system access to review relevant audit trails, raw data and metadata

How often should audit trails be reviewed?

The basic approach for the audit trail review frequency is to review the audit trail after each significant step in manufacture, processing, packing, or holding, and requires data/audit trail review before batch release.

Audit trail review frequency should be based on knowledge of process and risk assessment includes evaluation of data criticality, control mechanism and impact on product quality.

As an industry practice, the audit trail of activities that directly impact the product quality or integrity of analytical results should reviewed on daily basis i.e immediate after completion of action. The audit trails of non-critical activities should be reviewed on predefined (Monthly) frequency. But all decisions should be based on risk assessment only.

DEVIATION MANAGEMENT

As part of quality management system (QMS), Deviation handling plays vital role in assuring quality of products and by contributing to continuous improvement.

Deviation is an undesirable event in the pharmaceutical manufacturing process that can affect product quality or contradict/omit requirements contemplated in the approved procedures.

Deviation categorizations:

1. Incidents
2. Minor Deviations
3. Major Deviations
4. Critical deviations

Incidents:

Incidents are undesirable events that have no effect on product quality and/or do not deviate requirements contemplated in an established standards.

Record the incidents in respective documents like batch records, log books, analytical data sheets as appropriate. It nevertheless need to be documented as separate QMS events.

Possible examples of Incidents as follows:

• Temporary power failure in a warehouse where no temperature sensitive materials are stored, with no temperature excursion from the established range.

• Production process parameters or environmental monitoring data reach alert levels but are still within acceptable range.

Minor Deviations:

Minor deviations are undesirable events that have no effect on product quality but deviated contemplated requirements from established standards.

Minor deviations treated as such by applicable procedure.

Possible examples of minor deviations are given below: -

• Skip of FEFO (first expired-first out) and/ or FIFO (First in First out) principle in raw material handling.
• Balance out of tolerance used to determine gross weight of raw materials upon reception.
• Pressure differential out of established limits in class D washing area.
• Inadequately trained personnel to perform warehouse cleaning activities

Minor deviations requires documented objective evidence written in concise and clear way stating locations, person found the deviation and deviation details.

Minor deviations are normally addressed by Corrections after approval by QA which are taken to correct and contain the problem (including immediate actions), based on sufficient documented evidence.

Minor deviations do not necessarily require an investigation aimed at identifying the root causes of the problem as major and critical deviations do

Major Deviations:

Major deviations are undesirable events that effects product quality and impact to patient is unlikely and deviated contemplated requirements from established standards.

Major deviations requiring immediate action, investigation, and documented as such by the appropriate SOP

Possible examples of major deviations are given below: -

1. Use of unapproved reference standard to test an API or drug product.
2. Inadequately trained personnel to perform sterility tests.
3.  Production started without line clearance.
4. Wrong calculation of assay values during raw material dispensing
5.  Failure to load or withdraw or analyses stability samples with in schedules.
6.  Filter integrity test has been carried out using equipment with no documented installation qualification completed.
7.  Gross misbehavior of staff in a critical aseptic process.
8. Pressure differential out of established limits in aseptic fill areas.
9. Operational parameter out of range for a parameter defined as non-critical.
10. Untrained personnel responsible for segregating the approved and rejected raw material in the warehouse.
11. Failure to calibrate / preventive maintenance of instruments or equipment’s in stipulated schedules

Critical Deviations:

Critical deviations are undesirable events that effects product quality and impact to patient is highly probable including life threatening situations and deviated contemplated requirements from established standards.

Critical deviations requiring immediate action, investigation, and documented as such by the appropriate SOP

Possible examples of major deviations  are given below: -

1. Expired or rejected API component used.
2. Sterilization record of product-contact material used in aseptic filling process not available or unacceptable.
3. Incomplete inactivation stage of fermentation
4. Temperature out of control limit during detoxification stage.
5. Product mix-up
6. Breakdown of equipment during critical operations

Major or critical deviations usually require an enhanced, thorough and objective description which needs to be documented. An adequate description associated to the deviation is essential in order to perform a meaningful investigation.

Major or critical deviations would be typically first addressed by corrections, which would need QA approval as mentioned above. An investigation is then initiated on the root causes of the deviation, followed by the corresponding corrective actions.

If a minor deviation is repeated a significant number of times, it could turn into a major deviation, and must be treated as such. The investigation of the deviation should also determine the reason why the implemented corrective actions were not successful. Based on the same rationale, repetitions of one same incident can turn it into a minor deviation

Note:

The term “planned deviation” is frequently used to describe a decision to carry out a process in a different way from which it is established in a SOP, Method or Manufacturing Batch Record (e.g., a reprocess) due to an unforeseen event. Planned deviations need to be fully documented and justified. Usually, planned deviations associated to onetime events, and change control to permanent changes.

OUT OF SPECIFICATION RESULTS

All test results that fall outside the specifications or acceptance criteria established in drug applications, drug master files (DMFs), official compendia, or by the manufacturer including all in-process laboratory tests that are outside of established specifications.

Regulations require that an investigation to determine the cause of OOS results.

The source of OOS results should be identified either as an aberration of measurement process (Laboratory analysis) or an aberration of manufacturing process.

Obviously investigation starts from laboratory as OOS results generates from laboratory during testing. Investigation contains different phases as detailed below.

Analysts should check the data for compliance with test specifications before discarding test preparations or standard preparations. When unexpected results are obtained and no obvious explanation exists, test preparations should be retained, if stable, and the analyst should inform the supervisor for initiation of OOS investigation

Phase-1a Investigation:

The main purpose of Phase 1a investigation is to verify whether the generated OOS results are accurate, and the testing was performed without any deviation to respective testing procedure and practices.

Focus to be given to ensure no obvious errors occurred during the testing process.

Examples of obvious errors.

1. Incorrect documents
2. Incorrect samples, standard
3. Incorrect or dirty glassware
4. Calculation errors
5. Power outage
6. Equipment failure or Incorrect Instrument Parameters
7. Preparation errors
8. Non-qualified instruments or untrained analysts.
9. Issues with environment temperature & Humidity
10. Incorrect media or reagents, incorrect incubation times

The following steps should be taken as part of the Laboratory assessment:

• Discuss the test method with the analyst; confirm analyst  knowledge of and performance of the correct procedure.
• Examine the raw data obtained in the analysis, including  chromatograms and spectra, and identify anomalous or    suspect information.
• Verify that the calculations used to convert raw data values into a final test result are scientifically sound, appropriate, and correct; also determine if unauthorized or unvalidated changes have been made to automated calculation methods.
• Confirm the performance of the instruments.
• Determine that appropriate reference standards, solvents, reagents, and other solutions were used and that they met quality control specifications.
• Evaluate the performance of the test method to ensure that it is performing according to the standard expected based on method validation data and historical data.
• Fully document and preserve records of this laboratory assessment.
• Review the history and evaluate the previous trends.

A basic hypothesis testing (Investigative analysis) with retained sample preparations can also be considered as part of Phase 1a investigation to identify what might have happened during analysis.

• Same vials can be re-injected, same vial re-injections can provide strong evidence that problem should be attributed instrument performance.
• Same solutions can be re-injected, reinjections of same solutions can provide strong evidence that the problem should be attributed to the instrument or vials, rather than the sample or its preparation.
• Solutions can be re-diluted from stock and re-injected, re-diluted re-injections can provide strong evidence that the problem should be attributed the sample or its preparation.
• Investigation shall be extended to Phase Ib, when the phase Ia investigations did not reveal an assignable laboratory error.

Phase-1b Investigation:

Phase 1b consists of detailed hypothesis testing (or) investigative analysis. i.e testing performed to help confirm or discount a possible root cause i.e what might have happened that can be tested:- Multiple hypothesis can be explored based on the suspection of Phase 1a investigation.

it may include but not limited to

• Testing regarding sample filtration, sonication /extraction to evaluate the impact on sample results and possibility of improper filtration, sonication/extraction
• Testing of spiked samples to confirm or discount the possibility of contamination.
• Examination of the original dosage unit to determine whether it was damaged during laboratory handling in a way that affected its performance for release rate testing of certain specialized dosage form drugs.
• Testing of retention/control samples or additional stability samples.
• Simulations with different preparations, different columns and different conditions based on suspection.

Phase 1b investigations should be driven by written and approved instructions against hypothesis. Description of the testing should be written, and then approved by QA/Contract Giver/QA equivalent prior to initiating investigative testing. 

The requirements of investigative testing listed below:

The description must fully document

• The hypothesis to the test the root cause being investigated.
• What samples will be tested.
• The exact execution of the testing.
• How the data will be evaluated

Investigative testing may not be used to replace an original suspect analytical results. It may only be used to confirm or discount a probable cause.

In summary, when clear evidence of laboratory error exists, laboratory testing results should be invalidated. When evidence of laboratory error remains unclear, investigation should be extended to manufacturing firm to determine what caused the unexpected results. It should not be assumed that OOS test results are attributable to analytical error without performing and documenting an investigation. Both the initial laboratory assessment and the following OOS investigation should be documented fully.

A full-scale investigation should include a review of production and sampling procedures, and will often include additional laboratory testing

Phase IIa Investigation:

Phase IIa investigation consists of manufacturing investigation. Where all cross-functional departments like production, warehouse, vendors etc shall be communicated regarding OOS & laboratory investigation details to initiate investigation at their end as applicable.

Relevant functions shall review the following (but not limited to) to identify the, if any assignable cause

• Manufacturing process sequence and related critical parameters
• Review of executed manufacturing records
• Review of production activity to confirm that operator is properly trained and appropriate standard procedure, batch records are available and followed
• Review of calculations and computer generated data
• Review of performance of machine(s)/personnel(s) associated with the batch.
• Evaluation of storage & transportation of raw materials and samples used in the batch and nature of materials used in the batch.
• Evolution of sampling procedure
• Review of historical trends where applicable
• Impact on earlier supplies
• Vendor investigation report review where necessary

If this part of the OOS investigation confirms the OOS result and is successful in identifying its root cause, the OOS investigation may be terminated and the product shall be rejected.

Phase IIb Investigation:

Additional Laboratory testing involves retesting of the sample.

Retesting can be done from a portion of original sample. The sample used for the retesting should be taken from the same homogeneous material that was originally collected from the lot, tested, and yielded the OOS results. For a liquid, it may be from the original unit liquid product or composite of the liquid product; for a solid, it may be an additional weighing from the same sample composite prepared for the original test.

• If insufficient quantity of the original sample remains to perform all further testing then the procedure for obtaining a re-sample must be discussed and agreed by QA/Contract Giver/QA equivalent. The process of obtaining the re-sample should be recorded within the laboratory investigation.
• The decision to retest should be based on sound scientific judgement. The test plan must be approved before re testing occurs.

If original sample quantity is insufficient or investigation reveals sampling error then re-sampling shall be performed by the same qualified, validated methods that are used for initial sample collection.

The maximum number of retests to be performed on a sample should be specified in advance in a written standard operating procedure (SOP). The number may vary depending upon the variability of the particular test method employed, but should be based on scientifically sound principles.

The number of retests should not be adjusted depending on the results obtained. The firm's predetermined retesting procedures should contain a point at which the additional testing ends and the batch is evaluated. If the results are unsatisfactory at this point, the batch is suspect and must be rejected or held pending further investigation

After retesting,

OOS Confirmed:

If OOS results are confirmed then batch shall be rejected by reporting initial OOS results.

The investigation changes from an OOS investigation into a batch failure investigation, which must be extended to other batches or products that may have been associated with the specific failure as part of Phase III.

OOS Conclusive:

If retesting results found with in specification and assignable cause identified then report the retest results and invalidate the initial OOS results. CAPA shall be proposed accordingly and impact assessment shall be done.

OOS Inconclusive:

If retesting results found with in specification but no assignable cause identified then report all the results and decide on batch disposition.

All test results, both passing and suspect, should be reported (in all QC documents and any Certificates of Analysis) and all data has to be considered in batch release decisions

For inconclusive investigations — in cases where an investigation:-

(1) does not reveal a cause for the OOS test result and

(2) Does not confirm the OOS result

the OOS result should be given full consideration (most probable cause determined) in the batch or lot disposition decision by the certifying QP and the potential for a batch specific variation also needs considering.

Any decision to release a batch, in spite of an initial OOS result that has not been invalidated, should come only after a full investigation has shown that the OOS result does not reflect the quality of the batch. In making such a decision, Quality Assurance/QP should always err on the side of caution.

The QA might still ultimately decide to release the batch. For example, a firm might consider release of the product under the following scenario:

A product has an acceptable composite assay range of 90.0 to 110.0 percent. The initial (OOS) assay result is 89.5 percent. Subsequent sample preparations from the original sample yield the following retest results: 99.0, 98.9, 99.0, 99.1, 98.8, 99.1, and 99.0 percent.

A comprehensive laboratory investigation (Phase 1) fails to reveal any laboratory error. 

Review of events during production of the batch reveals no aberrations or indication of unusual process variation. Review of the manufacturing process and product history demonstrates that the process is robust. 

The passing retest results are all well within the known limits of variability of the method used. Batch results from in-process monitoring, content uniformity, dissolution, and other tests are consistent with the passing retest results. 

After a thorough investigation, a firm’s QA might conclude that the initial OOS result did not reflect the true quality of the batch.

It is noteworthy in this scenario that the original, thorough laboratory investigation failed to find any assignable cause. However, if subsequent investigation nonetheless concludes that the source of the OOS result was a cause unrelated to the manufacturing process, in response to this atypical failure to detect the laboratory deviation, it is essential that the investigation include appropriate follow-up and scrutiny to prevent recurrence of the laboratory error(s) that could have led to the OOS result.

As the above example illustrates, any decision to release a batch, in spite of an initial OOS result that has not been invalidated, should come only after a full investigation has shown that the OOS result does not reflect the quality of the batch.

PRESENTATIONS

1. CORRECTIVE AND PREVENTIVE ACTION - CAPA

2. TEAM WORK - Lessons from Geese

3. QUALITY RISK MANAGEMENT - FMEA

4. CROSS CONTAMINATION & CLEAN ROOM PRACTICES

5. STABILITY

6. CHROMATOGRAPHY - System Suitability

7. CHROMATOGRAPHY - Column Chemistry

8. GOOD DOCUMENTATION PRACTICES

INTERVIEW QUESTIONS

1. HR (HUMAN RESOURCE) INTERVIEW QUESTIONS 

2. QUALITY CONTROL INTERVIEW QUESTIONS ON WET CHEMICAL ANALYSIS

3. QUALITY CONTROL INTERVIEW QUESTIONS ON WET INSTRUMENTAL ANALYSIS

4. QUALITY CONTROL INTERVIEW QUESTIONS ON CHROMATOGRAPHY

5. INTERVIEW QUESTIONS ON SYSTEM SUITABILITY PARAMETERS - HPLC & GC

6. INTERVIEW QUESTIONS ON TROUBLESHOOTING - HPLC & GC

CHANGE MANAGEMENT SYSTEM

In any organization change in the system, process and procedures is natural as part of continuous improvements.

A formal change management (change control) system should be established as an integral part of a Quality Management System (QMS) of the organization to ensure that all the changes are appropriately identified, planned, documented, evaluated, approved & regulated.

There should be written procedures in place for technical & scientific evaluation and potential impact of the proposed changes on the quality of the medicinal products and other possibly affected systems. 

Any proposals for GMP relevant changes should be drafted, reviewed, and approved by the appropriate organizational units, and by the quality unit(s).

Assign personnel responsible for initiation, review and approval of the specific steps of the change. It needs to be noted that a change proposal may be expanded, modified or rejected, based on the evaluation performed during the approval process.

There should be traceable system for change log like identification code or number can be assigned.

Following steps could be considered during the process of change control.

1. Change Proposal / Change Initiation
2. Change review
3. Change classification & Approval
4. Change Implementation plan & Implementation
5. Review the implemented change
6. Effectiveness verification & Closure

1. Change Proposal / Change Initiation:

• The respective personnel from the department initiate the change proposal by detailing proposed procedure/ process/ system against to the current procedure/ process/ system.
• Following should be part of change proposal

¾       Change related to  (documents/ Facility/ process/ equipment/ software/ product…etc)

¾       Current system

¾       Proposed system

¾       Reason for the proposed change

¾       Risk of the proposed change

¾       Impacted documents/ systems/ process...etc

• There should be proper reason or justification with documented evidence for the proposed change
• The risk of the each proposed change to be evaluated in a systematic way. The risk of changes like new facility establishment, new product introduction, process equipment modification/ replacement, change in manufacturing process, change in the API source, lab application software up gradation…etc shall be assessed in a formalized manner by using risk assessment techniques like FMEA.
• Few companies has a practice of change classification (Minor/ Major/ Critical) at this stage by change initiator, but as per me it should be at change approval stage by QA as defined in the respective section.
• Few companies has a practice of providing anticipated date of change implementation at this stage but as per me it should be after change approval as defined in respective section.

2. Change review:

• The proposed change shall be reviewed by all concerned personnel for adequacy.
• Starting from change initiator department head followed by related cross-functional department representatives and finally QA shall review the proposed change as part evaluation.
• QA holds the responsibility to identify the Cross-functional department representatives (i.e functional subject matter experts) that are required to evaluate the proposed change based on the type of proposed change.
• It is better to have provision in your change control SOP that states common proposed changes and required cross-functional departments as part of review process
• Finally QA designee hold specific responsibility to evaluate and assess the proposed change to identify all impacted systems/ processes /procedures w.r.t following but not limited to

¾    SOP’s

¾    Specifications/ STP

¾    MFR (Master formulae record), BMR (Batch manufacturing record), BPR (Batch packing records)

¾    Site master file & Validation master plan

¾    Qualification /Validation

¾    Drawing/ Layouts

¾    Stability studies

¾    Approved vendors/ testing laboratories

¾    Trainings

• As a part of the evaluation process, the need to obtain approval from or to notify the change to authorities and/or customers, must be evaluated.
• The potential for critical changes to affect established retest or expiry dates should be evaluated. If necessary, samples of the medicinal products produced by the modified process can be placed on an accelerated stability program and/or can be added to the stability monitoring program.
• Current dosage form manufacturers should be notified of changes from established production and process control procedures that can impact the quality of the API.

 3. Change classification & Approval

• Finally QA head evaluate change proposal and classify the change and approve the same.
• Changes can be classified (e.g. as minor/ major/ critical) depending on the nature and extent of the changes, and the effects of these changes may impart on the process. A classification procedure may help in determining the extent of document review, testing, validation and documentation needed in line with the proposed change.
• The classification should be based on sound justification based on the risk to product quality.

Minor : Do not have any impact on product quality attributes

Major : Likely to have indirect minor impact on product quality attributes

Critical: Have significant impact on product quality attributes.

4. Change Implementation plan & Implementation

• After the approval of change control by QA Head, the change implementation plan shall be made.
• The change implementation plan should contain following as a minimum criteria.

¾    Number changes to be done

¾    Responsible persons for each change

¾    Anticipated completion date for each change

• As per the change implementation plan, all the proposed changes shall be done with the anticipated dates if not extension to the anticipated dates can be taken with proper justification.
• When implementing approved changes, measures should be taken to ensure that all documents affected by the changes are revised.
• After the change has been implemented, there should be an evaluation of the first batches produced or tested under the change.
• After completion implementation of all changes, the change initiator notifies QA for further verification and closure.

 5. Review of the implemented change

• QA verifies each implementation against proposal.
• If found satisfactory, assess the requirement for effectiveness verification after certain period of time (after one month, two months, three months. Etc).
• If effectiveness verification not required, change control shall be closed.
• If effectiveness verification is required the verification plan shall be made.

  6.   Effectiveness verification & Closure

• As per the effectiveness verification plan, QA designee verifies the effectiveness of implemented changes and if found satisfactory and close the change control.

LEARN ENGLISH

1. CAN WE SPEAK IN ENGLISH?

2. ENGLISH VOCABULARY.

3. USAGE OF 'USED TO'

4. USAGE OF 'GOING TO

MY POETRY

• 
  

1. క్షణ క్షణం 

2. నీవే నీవే ....

3. నీవు...

4.  స్వీట్ హార్ట్

5. ఒక హృదయం 

6. ప్రేమ

7. నీకు ...

8. మొదటసారి

9. నా నేస్తం .... 

10. రాజకీయం?

11. నవ సమాజం ?

12. ప్రజాస్వామ్యం,,,???

8D – PROBLEM SOLVING APPROACH

8D stands for 8 disciplines or 8 critical steps for solving problems.

The Eight Disciplines of Problem Solving (8D) is highly disciplined and effective scientific approach of problem solving typically used by manufacturing industries to find the root cause of a problem that is for resolving chronic and recurring problems.

Ford Motor Company developed this problem solving methodology, then known as Team Oriented Problem Solving (TOPS), in the 1980s. The early usage of 8D proved so effective that it was adopted by Ford as the primary method of documenting problem solving efforts, and the company continues to use 8D today.

The 8D problem solving model establishes a permanent corrective action based on statistical analysis of the problem and focuses on the origin of the problem by determining its root causes. Although it originally comprised eight stages, or disciplines, the eight disciplines system was later augmented by an initial planning stage.



8D is a systematic & scientific approach and it takes several weeks to several months in order to solve a problem and should not be used for following.

Non-recurring problems or problems which can be solved quickly by individual effort.
Problems with known root causes.
Making a decision between different alternatives.
Problems where the simplest and most obvious solution is likely to be the best or adequate solution

D0: Plan

Plan phase is a preparation step before starting the 8D process. Plan for solving problem and determine the prerequisites.

Simply it is an information collection step on symptoms of the problem

A deeper understanding of the problem and its history are necessary to determine if the 8D is the right method to be used for solving the identified problem.

D1: Define Team

Team formation is the first discipline of 8D approach.

Establish a small group of people from cross-functional disciplines with the process and product knowledge and have time to solve problem and implement corrective actions.

There should be at least one member knowing the 8D approach as subject matter expert and to keep a track of the investigation and document the minutes of meeting.

Generally 8D team consists of 4 to 8 people who are closely related to the problem. It usually involves people from different functions/departments in the organization coming together to solve a common problem.

D2: Describe the problem

The success of the root cause analysis depends on the problem description.

A correctly defined problem is 50% solved.

Define and describe the problem in measurable terms, asking questions similar to following will help you to address actual problem and not just symptom.

Key questions:

What is wrong with what?

What is happening?

What are symptoms?

Tools like ‘is’ and ‘is not’ could be used to ask questions and describe the problem

 

The problem statement will

§ Communicate the scope of the problem that the team is working on and get the team focused.

§ Provide information relevant to the problem: data and information on what the problem is and what the problem isn’t.

§ Clarify the role the team should play (determine root causes and implement or recommend a solution), specify the deadline and include monetary limits for the team.

§ Lays down expectations from the team and deliverables that will be measured.

§ Be the output of a process used to amplify the problem statement in terms of Who, What, Why, Where, When, and How Big (how much, how many, how often - level of pain) as stated above.

Gather and Verify Data

When the problem is identified, it is time to begin data collection.

The factual information and data necessary to assure a thorough cause analysis needs to be collected.

Data may have to be collected several times during this process, but the preliminary collection phase occurs now and will guide the analysis process.

Initial data gathering starts at the scene. Data has a shelf life, the longer you wait the more difficult it becomes to obtain good information.

When possible, go to the scene and take note of who was present, what is in place, when the event occurred and where the event happened. If the event is in the form of an audit finding, try to recover as much of the scene as possible.

Types of data to collect:

 Location -the site, building, department, or field location where the event took place

 Names of Personnel -operations personnel, visitors, contractors

 Date and Time

 Specifications -what are the requirements?

 Operational Conditions -start up, shutdown, normal operations

 Environmental Conditions -noise levels, visual distractions, lighting, temperature, etc.

 Communications -verbal or written, what orders were being followed?

 Sequence of Events -in what order did things take place?

 Equipment -what was being operated?

 Physical Evidence -damaged equipment or parts, medical reports

 Recent Changes -in personnel, equipment or procedures

 Training -classroom, on-the-job, none

 Other Events -have there been similar occurrences?

Once gathered, verify the accuracy of the data. Because analysis is performed based on fact. Remember, if you don’t look, you will not find the problem.

Make sure that gathered data is correct and complete. Then go where the data takes you. Do not take the data where you want it to go.

D3: Develop Interim containment action

These are the actions taken immediately after you become aware of the event to stop the event from occurring and preventing or minimizing any impact from the event. Please note that there are no actions here to correct the problem, they are just damage control

Not a problem solving but a means to control the bleeding also referred as corrections.

Define and implement those intermediate actions that will protect from problem until permanent corrective actions are implemented.

Each of these steps should be described in detail. Advise exactly what steps you took to stop the event from occurring, what was the impact and how you determined this.

Describe in detail the steps you took to contain any effects (while we are critically concerned with hardware, effects may go beyond product). If product has, or may have, been shipped to a customer, advise who and how you notified customers.

D4: Determine the Root causes & Corrective actions

Root cause analysis is about finding the true cause(s) of event.

Identify all the potential causes which could explain why the problem occurred.

Investigation process should be structured, but done in so simple manner. It should consists of following steps

· Evaluate all currently available relevant information

· Evaluate any additional information available from horizontal analysis.

· Inspect facilities or environment of the event

· Interview appropriate people

· Communicate with appropriate stake holders

· Clearly define next steps

· Decide a team if needed, Determine team makeup & Leadership

· Do not discount any data or information

During investigation organisation must make all decisions by using a risk based approach. It must determine probability of negative event and its consequences.

There are number investigation tools available but most commonly used are as follows.

1. Genchi & Genbutsu

2. Brain storming

3. WHY-WHY Analysis

4. Fish bone / Ishikawa cause & effect diagram

5. Kepner Tregoe decision making analysis

After identifying the root causes, plan for corrective actions. Corrective action is an action to eliminate the cause of detected non-conformity to eliminate the re-occurrence.

During the implementation of CAPA following shall be ensured.

· The identified CAPA addresses the root cause

· The solution can be implemented

· There is a clear understanding of overall impact of CAPA

D5: Develop the permanent Corrective actions

Plan and implement the corrective actions addressing the root causes.

The permanent corrective action is addresses identified root cause and removes / changes the conditions of the product or process that was responsible for the problem

Often the solution or solutions become obvious once the root causes are known. However, sometimes, a systematic approach is needed to use the root cause analysis to develop a solution. If the solution is obvious, select the best solution or mix of solutions that will lead to a robust, yet cost-effective, resolution. If solutions are not yet evident, follow the data trail. When solutions are not obvious, often the root cause has not been found.

Criteria for choosing the best solution (Corrective Action):

· Practical & Feasible

· Cost effective

· Robust & Error proofing

Validation of solution / Effectiveness of corrective action:

It is necessary to establish that the solution will make the problem go away without leading into other unwanted issues. That is why the 8D team should try out the solution with small quantities first to verify its effectiveness.

A design verification test (DVT) and/or a reliability demonstration test (RDT) may be required depending on the solution.

The solution is first to be tried on small lots to validate that it has indeed solved the problem prior to full implementation.

D6: Implement & validate permanent Corrective actions

Once the solution and its implementation are approved, the next step is to create an Action Plan.

The Action Plan outlines what steps are needed to implement the solution, who will do them, and when they will be completed.

A Simple Action Plan merely documents what needs to be done, who will do it, and when will it be done by.

A complex solution needs more thorough planning and documentation.

D7: Take preventive measures

The job of a problem-solving team is not complete once the solution is implemented. Preventing recurrence is an important part of a problem’s solution.

To prevent recurrence of the problem, the team must verify that the outcome of their Action Plan works and they must validate that the outcome is on-target.

Verification is testing that the solution produces the desired outcome; validation is ensuring that the outcome really solves the problem.

D8: Closure and team celebration

Once a team has completed implementing the solution and ensured that the solution works, all team members deserve to be congratulated. Team members need to know that their efforts are appreciated and that the organization knows about their accomplishments.

The organization (leadership group) shall recognize the team for their efforts in a timely manner.