Audit Trail Review for Devices with "Standard Audit Trail" Functions

Recommendation

7/8 May 2024

Audit Trail Review for Computerised Systems in Analytical Laboratories - Live Online Training

Devices and equipment often have standard audit trail functions. There is a huge amount of data being recorded (on/off), and only a fraction of this data is critical and relevant for audit trail reviews. What is the best way to proceed with a review?

Solution Approach

Especially with regard to the audit trail, the view has changed. Before the revision of the EU GMP Guideline Annex 11, the general view was that of the conservation of evidence in order to have further data available in case of a deviation. Statements made by the US American FDA in its dockets also nourished this view: "Audit Trail... we may use it for an useful purpose e.g prosecution". Consequently, the emphasis in the software was not put on later evaluability, but on the recording. For this reason, the audit trail data was simply stored sequentially in tables.
So far there are only a few systems that fully support the new requirements. Now, with the additional demand also after the reason of the change, there are further demands on the systems and also further sorting criteria. In addition, it has been clarified that the audit trail can be limited using a risk-based approach. Here, the opportunity lies in the limitation to the essential data. What these are is described both in Annex 11 §9 and in Chapter 4 of the EU GMP Guidelines. Further information can be found in the "Aide-Memoire" (Aide-mémoire 07121202) published in the German ZLG, where the following quotation can be found:

S. 26 2.4.5 Audit Trails - "1 - 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"). 2 - If GMP relevant data are changed or deleted, the reason should be documented. 3 - Audit Trails must be available, must be able to be converted into a generally readable form and must be checked regularly".

It is therefore advisable to first derive the definition of the relevant data for the audit trail from the definition of the raw data, and then to determine for which data a review must be performed and which criteria of the assessment must be created. This is in line with the requirements of Chapter 4, where it is stated that at least the data on which a quality decision is based must be named as raw data.

As the data itself is usually not changeable even in the case of control systems (PLC) and process control systems, it can also be argued, if necessary, that no audit trail is carried out, precisely because the data cannot be changed. However, this argumentation must be supported by appropriate validation with evidence of the raw data protected by proprietary formats or strong access protection. This means that there must be test scenarios that prove that these defined raw data cannot be changed accidentally or with simple effort.

For such systems that do not have an audit trail, the Aide-Mémoire mentioned above points out that for legacy systems without an audit trail, in exceptional cases it can be regulated, e.g. by an SOP, to document the corresponding change in a logbook and have this verified by a second person. It should be noted here that only those systems are defined as old systems that were installed before Annex 11 (1992) came into force (see Aide-Mémoire 07121202, page 28, running no. 2.4.5.9). There you will also find the sentence: "First of all it must be clarified whether data can be changed at all (e.g. electronic recorders). If not, no audit trail is required."

For those systems where there is a simple audit trail, a reporting tool should be used to perform the query based on the definition of the raw data. As a minimum, the entries that belong to process values that are needed for a quality decision should be displayed. If the data, e.g. temperatures, are directly related to the batch release, it should be checked whether the associated audit trail must also be evaluated before the batch is released. In systems that also record the reason for the change, groups can be sorted by reason and clusters can be recorded and valuated according to reason. The evaluation should always be prioritized according to the risk for the product and thus the patient. In the second instance, the accumulation of reasons can also give cause to question technical defects.

It is not possible to derive from the laws and guidelines themselves the requirement for a technical audit trail which gives reason for virtually all configurations and records them in the audit trail. The change control procedure exists for these processes. Consequently, no reviews of this data are expected at this point. However, this view is not uncontroversial, since many companies and also some inspectors derive the requirement for monitoring the configuration (technical audit trail) from the Data Integrity Guidance recently published. Here, each company must decide for itself what acceptance risk is taken. It seems appropriate to take a risk-based approach here as well. Since a configuration always has an impact on the future and does not change any data already recorded, this should serve as an approach to decide where monitoring of the software itself is or is not necessary. This is certainly different for an HPLC than for a controller. However, if the configuration parameters (e.g. limit values and set points) are known and printed out, for example, the data generated from them can also be evaluated in context. Not to forget that in general a rigid change control applies which, if necessary, also proves with a regression test that the new configuration meets the requirements. Another aspect is that the cycles of the review for the technical part are certainly different from cycles for the data review, where under certain circumstances the audit trail should be considered for each batch release (e.g. MES), depending on the risk for the release and thus for the patient. A final note on this point is that many systems do not currently support the "technical audit trail", especially for individual controls. The good news is that changes are rather rare here and a well-running, validated process is changed more rarely. The control here is done by a rigid change control and the periodic review which also records the incidents and logbook entries.

It should be noted that the guidelines always assume that values have changed, so the initial entry only records who entered it, in the sense of a hand signal for paper documents. This distinction is very well described in Vote V1100302. There it says in section B, second last paragraph: "Automatic logging of the user is suitable to replace a hand signal".

In order to meet the requirement for audit trail review, further technical functions will be necessary in the future, which, for example, allow configurable selection menus for determining the reason for the change and also offer standard reports and at least descriptive statistics.

Source (German)

Aide-Mémoire 07121202  on monitoring compurterised systems
 

Votum V 1100302