Audit Trails: Patterns and Part 11 Compliance
Audits - 22 April 2014
The requirement for audit trails has not come about with the evolution of electronic systems. The ability to audit multiple sorts of operations has always been a major concern with regulatory authorities. It can be quite demanding to maintain audit trails in a “paper world”. Computer systems can facilitate the process of auditing operations such as creating raw data in laboratories, approving documents or signing-off on training records.
In order to satisfy regulatory requirements, computer systems must adhere to a set of rules for electronically performed operations. We believe there are basically two approaches to tackling this problem that will comply with regulation requirements such as FDA’s 21 CFR Part 11.
”Audit Everything” Approach
This approach requires using a pattern based on standard modelling techniques and mechanisms offered by databases. As most of the systems today use relational databases, this approach is suitable for many systems. Without going into much detail, the idea here is to create a mirror plus table for each database table e.g. user and user_audit. The “plus” refers to the fact that the operation (update, insert, delete), user_id and time_stamp will be added to the second table. Thus every insert and update in the first table is replicated in the second table. The first table is kept up to date with the most current information, while the audit table has the entire history of every operation. This “audit everything” pattern can easily be extended to all tables within a system using a relational database.
Although this approach can be very useful for simple systems, we do not feel it is suitable for complex systems. It does satisfy the Part 11 demand that electronic records be audited, however it will eventually impose limitations on your system. When you use many tables with complex links between them to store all the system information, it eventually becomes very difficult to extract, in readable format, the audit trail of specific elements.
The targeted approach is based on the understanding that only specific operations truly require an audit trail. 21 CFR Part 11 compliance demands audit trails on electronic records but it does not define what a record is – that is left to the system creators/owners. Looking at trace-ability practices on paper is a good starting point to develop a common sense approach to audit trails in electronic systems. It also allows you to better define what is truly considered a record from a regulatory standpoint.
Take for instance, an email notification feature in your system where the end-user has control over their personal delivery preferences. Would you really consider this an auditable record from a regulatory standpoint? Certainly not!
In order to be able to implement a system with meaningful audit trails, we recommend defining, on a per system basis, what is considered ‘a record’. Chances are you will focus on 2-8 major system functions and will then have the ability to define an appropriate model for your audit trails.
Our clients consider controlled documents, such as Standard Operating Procedures, to be records. That covers the question, “Is this a record?” From there, the history that can be built on a document can be quite complex if you consider all the work and exchanges required to move a document from Version 1.0- Approved and Effective status, to Version 2.0- Approved and Effective status. We have decided to keep what is truly significant for regulatory audits. This means, we keep all the official versions of a document, its metadata, and all the records of approval.
As you can see, your needs will determine the approach taken, but for complex systems the targeted approach will give you the ability to create clean and concise audit trails of electronic records. This targeted approach can also be used more broadly in computer system validation to provide a rationale on the operational qualification tests when dealing with audit trails.
In conclusion, the information you would want kept in the electronic environment is often similar to what is kept in the “paper world”.
Software developers have the responsibility to understand the criticality of audit trails. They are also tasked with helping companies implement systems with robust audit trails. For now, we hope that this article can provide guidance to anyone who struggles with this task.
Philippe Gaudreau, CEO, SOLABS
About the Author
Philippe Gaudreau co-founded SOLABS in 1999 and serves as its Chief Operating Officer (CEO). He is a member of Quebec’s OIQ Engineering Association and has a Bachelor of Science degree in Chemical Engineering from Laval University. Philippe has an expertise in compliance practices and the automation of quality operations for Life Sciences companies, as well 15+ years experience with business process management and their optimization, and document life cycle management.