In Part 1 of this post we traced a brief history of the requirement for audit trail review back from GCP to GMP.  In this post, we'll look at some guidance for performing audit trail reviews in GCP.

As a reminder, the new Data Governance section in E6 R3 says, 

Procedures for review of trial-specific data, audit trails and other relevant metadata should be in place. It should be a planned activity, and the extent and nature should be risk-based, adapted to the individual trial and adjusted based on experience during the trial (III.4.2.3).

EMA's Guideline on Computerized Systems gives us much more to go on:

6.2.2 Audit Trail Review. Procedures for risk-based trial specific audit trail reviews should be in place and performance of data review should be generally documented. Data review should focus on critical data. Data review should be proactive and ongoing review is expected unless justified. Manual review as well as review by the use of technologies to facilitate the review of larger datasets should be considered. Data review can be used to (among others) identify missing data, detect signs of data manipulation, identify abnormal data/outliers and data entered at unexpected or inconsistent hours and dates (individual data points, trial participants, sites), identify incorrect processing of data (e.g. non-automatic calculations), detect unauthorised accesses, detect device or system malfunction and to detect if additional training is needed for trial participants /site staff etc. Audit trail review can also be used to detect situations where direct data capture has been defined in the protocol but where this is not taking place as described.

However...it's a bit confusing. The section is titled "Audit trail review," but two terms are used:  "data review" and "audit trail review." Some of the uses of "data review" - identifying missing data, identifying outliers, etc. - are achievable through review of data without resorting to the review of the audit trail.  For example, we can identify missing data by looking at a missing data report or a data listing - we don't need to dive into the audit trail.  Other activities - for example, identifying data entered at inconsistent hours and dates, or detecting unauthorized access - could only be performed using the audit trail.  Is this entire paragraph intended to describe audit trail review (per the title), or a mix of data review and audit trail review?

We don't know, but this paragraph helps us focus on the context the audit trail provides that data listings do not:

• Who performed each operation in the system
• When they performed it
• The history of what happened before the data were finalized - previous entries, queries, and and reasons for change

Simply put, the audit trail helps us identify both fraud and misuse of the data capture system. During a clinical study, we're not reviewing the audit trail to verify that the audit trail works properly; rather, we're reviewing the audit trail to verify that the system users are using the system properly. 

With that in mind, we'll look at some potential uses for audit trail review in Part 3.