Editing an Audit Trail

[RPR Consulting]

The integrity of the audit trail is the backbone of a validated data capture system since it records all changes to data, including who made the initial entry and when in addition to when, why and by whom any subsequent changes to data were made.

That being said, is it ever acceptable to modify an audit trail?

The question arises since I have seen this occur in an electronic data capture system and the justification provided for this action was that the edits made to the audit trail were also captured and so the practice was deemed acceptable, and indeed "defensible" in a regulatory inspection.

Personally, I think this unacceptable, but I would be interested to hear others' opinions, especially those from the Inspectorate.

[RPR Consulting]

By way of an update to those who may be following this thread I also has correspondence with FDA regarding the use of a date field in an audit trail as a data element and the editing of the audit trail through Data Clarification Forms. This is their response:

The audit trail in a part 11 compliant data capture system should automatically apply a date/time stamp to data elements entering the system. Modifications can be made to the source data and this is tracked by the audit trail. From your question it appears there may be linkage between the date as a data element and the date in the audit trail, which is not appropriate.
If a date in a source record is to become part of the data in the EDC, it should become a separate data element with its own date/time stamp in the EDC (See FDA Guidance Electronic Source Data in Clinical Investigations). Changing the audit trail based on changes in the source document would be considered a violation of our part 11 requirement.

[JOeuf]

In some cases - such as patient confidentiality breaches - then what other choice do you have? The offending data is in both the study record and the audit trail - and any normal means of cleansing the audit trail is going to propagate the problem, since the audit trail is supposed to contain 'old' and 'new' values.
But in most other cases then no.

[WillC]

I think the fundamental problem here is that someone is able edit the audit trail, which brings into question the integrity of the audit trail itself. There must be another way to achieve what you desire - maybe a file note? Or is this audit trail edit being made by a system vendor? Either way, it doesn't look good.

[Sunny]

Hello. Having established that a number of changes have been made to a 'live' audit trail, I am now in the process of working out whether or not these changes were ethical and within the current uk law.

It is my view as an IT professional that an audit trail should never be altered as that compromises the integrity of the audit trail itself, which surely compromises the integrity of the associated record.

It would help if you could explain what you mean by confidentiality breaches. Do you mean unauthorised accesses ?

[Sunny]

I agree with you. Any attempt to edit the audit trail compromises not only the integrity of the audit trail itself but that of the associated record.

Do you have any examples where a system vendor provides this functionality ?

[WillC]

Yes, I don't think the issue here is about confidentiality, it's about data integrity. I cannot think of a justification for updating an audit trail 'through the back end' unless, say, a generic system bug meant that recorded data was incorrect and had to be updated by the vendor. You'd expect quite a lot of documentation to cover such a fix though. An end user should always be editing data through the front end and/or API whereby the audit trail would be created automatically. This is one of the central tenets of data integrity.

[RPR Consulting]

"It would help if you could explain what you mean by confidentiality breaches. Do you mean unauthorised accesses ?"

No, I think what JOeuf means is the (likely unique) case whereby data are recorded in a GxP system which identify a Participant and the data should never have been recorded in the first place (e.g., breaks EU GDPR laws). In such a case there should be a process to expunge the actual identifying data, since leaving teh original data in teh audit trail would not satisfy the relevant privacy law(s).