Audit trail in EU GMP Annex 11 and EMA Concept Paper on Annex 11
The current EU GMP Annex 11 contains a mere three sentences on the audit trail in section 9 Audit Trails. These few references have repeatedly caused problems during implementation. In this respect, there is indeed a need for action for a new Annex 11. Whether the information in the "Concept Paper on the revision of Annex 11 of the guidelines on Good Manufacturing Practice for medicinal products - Computerized Systems" is sufficient or even useful will be discussed below.
Why audit trails?
First of all, the purpose of the audit trail requirement should be explained. The requirement is derived from the specifications for paper documentation in EU GMP Chapter 4 and the AMWHV (German Ordinance on the Manufacture of Medicinal Products and Active Pharmaceutical Ingredients). Let us first look at EU GMP Chapter 4:
EU GMP Chapter 4, 4.9
Every change to an entry in a document should be signed and dated. Despite the change, the original information should remain legible. If indicated, the reason for the change should be recorded.
It is interesting to note that the reason for the change is not mandatory. This has not been implemented in the same way in Annex 11 Section 9 Audit Trail.
We also find a corresponding requirement in the AMWHV:
AMWHV Section 10 General documentation
The original content of an entry must not be made illegible. No changes may be made that do not reveal whether they were made at the time of the original entry or at a later date.
Based on these requirements, we therefore need software functionality that allows us to implement these requirements for paper documentation (fig. 1 on p. 23).
Fig. 1
The current content of EU GMP Annex 11
Currently, the following requirements can be found in connection with the audit trail:
9. Audit Trails
Based on a risk assessment, consideration should be given to integrating the recording of all GMP-relevant changes and deletions into the system (a system-generated audit trail). When GMP-relevant data is changed or deleted, the reason should be documented. Audit trails must be available, be able to be converted into a generally readable form and be checked regularly.
The first sentence causes us the most problems in terms of interpretation. The other two sentences are straightforward, but not sufficient for adequate regulation.
There are always different interpretations of what the risk assessment is supposed to achieve. Is it only about critical data and, if so, which data is critical? Or is it about determining which data is GMP-relevant? Or is it about whether it is possible to change data at all?
The wording "all GMP-relevant changes and deletions" gives us no leeway. This means that it cannot just be about critical data, although GMP data can hardly be uncritical anyway. The risk assessment is used to decide whether an audit trail is needed at all. In most cases, it will ultimately be necessary. An audit trail functionality could be dispensed with in the following cases, for example:
A database is used in which the data cannot be changed but can only be read.
Recommendation
25-28 February 2025
Computerised System Validation: Legacy Systems + Maintaining Compliance during Operation - Live Online Training
A field instrument that forwards data to another system (e.g. MES) and the instrument only records the measured value. In this case, the instrument itself does not require audit trail functionality, but the MES does.
A simple controller (PLC or microcontroller), for example, a washing machine with three predefined programs and a connected printer that supplies the raw data.
Other than that, the systems and equipment used today should always include audit trail functionality (URS). This requirement can also be found, for example, in PIC/S PI 041:
9.6 Audit trails for computerized systems
Companies should select software that includes appropriate electronic audit trail functionality. Companies should endeavor to purchase and upgrade older systems to implement software that includes electronic audit trail functionality.
Another recurring problem arises from the different requirements for the audit trail. EU GMP Annex 11 is unambiguous. It is about changing and deleting all GMP-relevant data. The US FDA Part 11 goes further in this regard (21 CFR Part 11 - 11.10(e)). It also requires the input of data (create) to be recorded in the audit trail. From an EU perspective, this is not necessary and does not necessarily make the audit trail any less confusing. Who records which data must of course be known, but has nothing to do with the audit trail functionality.
Audit trail vs. system log
In addition to the changes and deletions required in section 9, a lot of other data can be recorded. This then takes place in the system log or in so-called event logs. Both have nothing to do with the audit trail in accordance with EU GMP Annex 11.
Log files (also known as system logs) contain all possible internal system information (operating system or software). Independent of this are log files (logging) that register information about users, specifically when a user has logged in or logged out (log in and log off). Such log files are specifically required in EU GMP Annex 11 under 12.4 (fig. 2).
Fig. 2
This note can also be found in the GAMP® Records and Data Integrity Guide:
EU GMP Annex 11 [7] also requires that electronic systems record the identity of the person creating an electronic record together with the date and time. This is required even if no audit trail exists.
GAMP® 5 2nd Edition also refers to the differences between audit trail and system log:
Data audit trails, as required by various regulations, record operator actions that create, modify, or delete GMP records during normal operation, and should be clearly distinguished from other system and technical logs.
Audit Trail - The reason for the change
The second sentence under 9 Audit Trails requires documentation of the reason:
When modifying or deleting GMP-relevant data, the reason should be documented.
Here, the requirement from the paper documentation that the reason should only be documented if necessary has actually been ignored (EU GMP Chapter 4, 4.9 ... If indicated, the reason for the change should be recorded). This should definitely be adapted in the revision.
The reason for the change is also addressed in the AIM of EFG 11 (Aide-Mémoire of EFG 11 - Monitoring of computerized systems):
9-9 How is the justification for a change or deletion documented? The justification can take the form of a free text. Drop-down/pulldown menus are also acceptable. In any case, the content of the justification must be comprehensible. The entry of a justification should be enforced by the system.
Audit trail - The final requirement
EU GMP Annex 11, 9
Audit trails must be available, be able to be converted into a generally readable form and be checked regularly.
This means that the audit trails must be stored in such a way that they can be retrieved again easily. There is no way around an archiving concept. Audit trails are part of the GMP documentation. It makes sense to archive them together with the batch documentation.
The generally readable form is also aimed at the content. An audit trail should contain the following information:
- Old value
- New value
- Time stamp (time of change)
- Name of the person who changed or deleted
- Reason for change
The requirement for regular checks is generic and presents us with two problems in particular:
Within what time intervals should the audits be performed and who should review the audit trail?
Neither is regulated. However, there are a number of references to both points in the current guidelines on data integrity.
PIC/S PI 041-1
9.6 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.
Batch release certainly plays a central role. For example, if a release-relevant content determination is carried out with an HPLC, the audit trail of this HPLC will be checked before batch release. It is more difficult with all other audit trails. Here, the time intervals should be determined via a risk assessment.
PIC/S PI 041-1:
9.6 Non-critical audit trails reviews can be conducted during system reviews at a pre-defined frequency. This review should be performed by the originating department, and where necessary verified by the quality unit (e.g. during batch release, self-inspection or investigative activities).
However, this raises the question of which audit trails are not critical when it comes to changing or deleting GMP-relevant data.
Information on this can also be found in the AIM of EFG 11:
9-11 How often is the regular review of the audit trail carried out? The functionality must be assessed regularly as part of the periodic evaluation and checked if necessary. The interval should be defined in a comprehensible manner, taking into account the process risk. Changes or deletions of critical data should be evaluated before batch release.
Who should carry out the check now? There is also a note on this in PIC/S PI 041-1:
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. The company’s quality unit should establish a program and schedule to conduct ongoing reviews of audit trails based upon their criticality and the system’s complexity.
A similar note can be found in GAMP® GPG on Data Integrity:
GAMP® GPG Records and Data Integrity Guide
Audit Trail Review should be performed by an individual who has an understanding of the business process and the impact of the actions recorded. They are an effective means of verifying that changes are made by authorized users an for detecting potential data integrity issues.
It is important here that you have defined basic instructions in an SOP:
- Who checks the audit trail (persons and department: QC, production, QA, system owner, process owner, ...)?
- Where do the responsibilities for the review lie in detail?
Concept paper on the revision of Annex 11
The concept paper on Annex 11 addresses a total of seven points, making it the most comprehensive section in the concept paper.
18 [9] An audit trail functionality which automatically logs all manual interactions on GMP critical systems, where users, data or settings can be manually changed, should be regarded as mandatory; not just 'considered based on a risk assessment'. Controlling processes or capturing, holding or transferring electronic data in such systems without audit trail functionality is not acceptable; any grace period within this area has long expired.
The need for a risk analysis has obviously been (mis)interpreted differently here. This has already been described in detail above. According to the current interpretation of Annex 11, an audit trail is always required if GMP data can be changed or deleted. A risk-based approach for audit trails means:
If the system does not allow the operator/user to change values, no audit trail is required. Controlling processes has nothing to do with the audit trail and is therefore not necessary (in the audit trail).
19. [9] The audit trail should positively identify the user who made a change, it should give a full account of what was changed, i.e. both the new and all old values should be clearly visible, it should include the full time and date when the change was made, and for all other changes except where a value is entered in an empty field or where this is completely obvious, the user should be prompted for the reason or rationale for why the change was made.
This is actually already sufficiently regulated. What is missing, however, is the need to state a reason. This is not always necessary with paper documentation. See EU GMP Chapter 4, 4.9 ... If indicated, the reason for the change should be recorded.
20. [9] It should not be possible to edit audit trail data or to deactivate the audit trail functionality for normal or privileged users working on the system. If these functionalities are available, they should only be accessible for system administrators who should not be involved in GMP production or in day-to-day work on the system (see ‘segregation of duties’).
The requirement is correct and actually reflects the need to comply with the principles of data integrity. It is not necessary to emphasize this separately in Annex 11. Segregation of Duties always applies and does not need to be mentioned separately.
21. [9] The concept and purpose of audit trail review is inadequately described. The process should focus on a review of the integrity of manual changes made on a system, e.g. a verification of the reason for changes and whether changes have been made on unusual dates, hours and by unusual users.
Here too, the question arises as to whether this must be described in a legal framework. This should actually be part of a corresponding SOP of the Regulated User. See also PIC/S PI 041-1:
9.8 Procedures should be in place to address and investigate any audit trail discrepancies, including escalation processes for the notification of senior management and national authorities where necessary.
22. [9] Guidelines for acceptable frequency of audit trail review should be provided. For audit trails on critical parameters, e.g. setting of alarms in a BMS systems giving alarms on differential pressure in connection with aseptic filling, audit trail reviews should be part of batch release, following a risk-based approach.
In principle, this is an important point. However, this should not actually be described in the legal framework either. It is up to the Regulated User to describe and define this accordingly in an SOP. No examples belong in a legal framework (setting of alarms in a BMS systems giving alarms on differential pressure in connection with aseptic filling).
Recommendation
Tuesday, 25 February 2025 9 .00 - 17.30 h
Computerised System Validation: Legacy Systems - Live Online Training
23. [9] Audit trail functionalities should capture data entries with sufficient detail and in true time, in order to give a full and accurate picture of events. If e.g. a system notifies a regulated user of inconsistencies in a data input, by writing an error message, and the user subsequently changes the input, which makes the notification disappear; the full set of events should be captured.
The question arises as to whether the traceability of typing errors is really necessary. This is going over the top.
24. [9] It should be addressed that many systems generate a vast amount of alarms and event data and that these are often mixed up with audit trail entries. While alarms and events may require their own logs, acknowledgements and reviews, this should not be confused with an audit trail review of manual system interactions. Hence, as a minimum, it should be possible to be able to sort these. This is generally an important note. Many systems generate a large number of alarms and events. These are often mixed with audit trail entries.
It makes sense to assign alarms and events to their own logs, confirmations and reviews. These reviews should not be confused with an audit trail review. It should at least be possible to sort them. However, the question arises as to how to implement this point in the text of Annex 11. It would be conceivable to state that the audit trail may only contain changes and deletions of GMP-relevant data and nothing else. Or at the very least a sorting function!
About the Author
Klaus Feuerhelm ... Regional Council Tübingen, Drug Monitoring Control Center Baden-Württemberg
