Audit Trail Review for Devices with "StandardAudit Trail"
Devices andequipment often have standard audit trail functions.There is a huge amount of data being recorded (on/off), and only a fraction ofthis data is critical and relevant for audit trail reviews. What is the best way to proceed witha review?
Especially withregard to the audit trail, the view has changed. Before the revision of the EUGMP Guideline Annex 11, the general view was that of the conservation ofevidence 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 anuseful purpose e.g prosecution". Consequently, the emphasis inthe software was not put on later evaluability, but on the recording. For thisreason, the audit trail data was simply stored sequentially in tables.
So far thereare only a few systems that fully support the new requirements. Now, with theadditional demand also after the reason of the change, there are furtherdemands on the systems and also further sorting criteria. In addition, it hasbeen 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 theseare 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) publishedin the German ZLG, where the following quotation can be found:
S. 26 2.4.5 Audit Trails - "1 - Based on a risk assessment, considerationshould be given to integrating the recording of all GMP relevant changes anddeletions into the system (a system generated "audit trail"). 2 - IfGMP 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 generallyreadable form and must be checked regularly".
S. 26 2.4.5审计追踪- "1 -根据风险评估，应考虑将所有GMP相关更改和删除的记录集成到系统中（系统生成的"审计追踪"）。2 -如果更改或删除GMP相关数据，应记录原因。3 -审核追踪必须可用，必须能够转换为一般可读的表单，并且必须定期检查"。
It is thereforeadvisable to first derive the definition of the relevant data for the audittrail from the definition of the raw data, and then to determine for which dataa review must be performed and which criteria of the assessment must becreated. This is in line with the requirements of Chapter 4, where it is statedthat at least the data on which a quality decision is based must be named asraw data.
As the data itselfis usually not changeable even in the case of control systems (PLC) and processcontrol systems, it can also be argued, if necessary, that no audit trail iscarried out, precisely because the data cannot be changed. However, thisargumentation must be supported by appropriate validation with evidence of theraw data protected by proprietary formats or strong access protection. Thismeans that there must be test scenarios that prove that these defined raw datacannot be changed accidentally or with simple effort.
For suchsystems that do not have an audit trail, the Aide-Mémoire mentioned abovepoints out that for legacy systems without an audit trail, in exceptional casesit can be regulated, e.g. by an SOP, to document the corresponding change in alogbook and have this verified by a second person. It should be noted here thatonly those systems are defined as old systems that were installed before Annex11 (1992) came into force (see Aide-Mémoire 07121202, page 28, running no.18.104.22.168). 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 systemswhere there is a simple audit trail, a reporting tool should be used to performthe query based on the definition of the raw data. As a minimum, the entriesthat belong to process values that are needed for a quality decision should bedisplayed. If the data, e.g. temperatures, are directly related to the batchrelease, it should be checked whether the associated audit trail must also beevaluated before the batch isreleased. In systems that also record the reason for the change, groups can besorted by reason and clusters can be recorded and valuated according to reason.The evaluation should always be prioritized according to the risk for theproduct and thus the patient. In the second instance, the accumulation ofreasons can also give cause to question technical defects.
It is notpossible to derive from the laws and guidelines themselves the requirement fora technical audit trail which gives reason for virtually all configurations andrecords them in the audit trail. The change control procedure exists for theseprocesses. Consequently, no reviews of this data are expected at this point.However, this view is not uncontroversial, since many companies and also someinspectors derive the requirement for monitoring the configuration (technicalaudit trail) from the Data Integrity Guidancerecently published. Here, each company must decide for itself what acceptancerisk 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 changeany data already recorded, this should serve as an approach to decide wheremonitoring of the software itself is or is not necessary. This is certainlydifferent for an HPLC than for a controller. However, if the configurationparameters (e.g. limit values and set points) are known and printed out, forexample, the data generated from them can also be evaluated in context. Not toforget that in general a rigid change control applies which, if necessary, alsoproves with a regression test that the new configuration meets therequirements. Another aspect is that the cycles of the review for the technicalpart are certainly different from cycles for the data review, where undercertain circumstances the audit trail should be considered for each batchrelease (e.g. MES), depending on the risk for the release and thus for thepatient. A final note on this point is that many systems do not currentlysupport the "technical audit trail", especially for individualcontrols. 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 rigidchange control and the periodic review which also records the incidents andlogbook entries.
It should benoted that the guidelines always assume that values have changed, so theinitial entry only records who entered it, in the sense of a hand signal forpaper documents. This distinction is very well described in Vote V1100302.There it says in section B, second last paragraph: "Automatic logging ofthe user is suitable to replace a hand signal".
In order tomeet the requirement for audit trail review, further technical functions willbe necessary in the future, which, for example, allow configurable selectionmenus for determining the reason for the change and also offer standard reportsand at least descriptive statistics.