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.
- Operator enters batch number into the system
- Operator presses the OK button or signed electronically with his user name & password – data is saved (version 1)
- Operator realizes a wrong batch number entry and need to change the initial batch number entry
- Operator reopens the data object and corrects the batch number
- 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)
- 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:
- Duplicate injections in sample set or sequence
- Aborted or interrupted injection in the sequence
- Unprocessed channels
- Rut time differences in between runs
- Delays in between injections
- 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:
- Reprocessed channels
- Faulty injections
- Processed with different processing methods
- Manual integrations
- 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.
No comments:
Post a Comment