In today’s validated lab environment, knowing the differences between an audit log versus an audit trail in computerized laboratory systems is just one of the integral qualification tasks that the ProPharma Group CSV practice focuses on for our Customers. In this blog, we will briefly go over why it is important to provide assurances that your new or existing instrument software has a full audit trail versus a system audit log.
First, a little history behind the need for a data audit trail. Almost six years ago the FDA announced it would be conducting Part 11 audits alongside normal CGMP inspections to assess how industry interprets 21 CFR 11. According to FDA’s Pre-Approval Inspection Program 7346.832,1the FDA inspector has to “audit the raw data, hard copy or electronic, to authenticate the data submitted in the [Chemistry, Manufacturing and Controls] CMC section of the application, and to verify that all relevant data (e.g., stability, bio batch data) were submitted in the CMC section such that CDER product reviewers can rely on the submitted data as complete and accurate.”2
In the world of computerized system validation, there exists an array of standalone PC based laboratory systems. The companies that manufacture and sell these systems bring efficiencies to the tasks of scientists, researchers and engineers. However, ensuring that data integrity needs are being met is typically a secondary objective when developing the application’s software. It is proving ever more difficult for Compliance organizations to grasp the myriad ways in which these systems are configured to address the issue of data integrity.
Which leads us to the question, is the instrument’s operational software and file structure truly capable of providing the needed data audit trail? Remember, it is not only the system that must be validated but also the ability to trace the history of the data from its inception, thru analysis, and potential reporting. The FDA defines an audit trail as, “a secure, computer generated, time-stamped electronic record that allows reconstruction of the course of events relating to the creation, modification, and deletion of an electronic record.”3A recent qualification effort where I was tasked with qualifying a particulate analysis lab system illustrates how the vendor of the software provided an audit log vs as a true audit trail.
The system’s legacy PC was replaced with a 64 bit, Windows 7 Enterprise edition. The Vendor provided an upgraded version of their software that was compliant with the new OS. The audit component did indeed meet the NIST standards definition for audit trails 4;
However this metadata that is being provided is no different than an event (audit) log that the Windows7 operating system provides thru Microsoft’s Event Viewer, (Figure 1)
A pre-check prior to performing a scheduled supplemental IOQ revealed that no electronic record of the data’s lifecycle, e.g. creation, modifications, and / or deletions existed. Further investigation with the software supplier confirmed that their auditing was limited to system log files.
So what do you look for to address this in a more compliant way? Well in this case, the primary limitation was that the data was stored in a flat file structure (Figure 2) as opposed to a RDBMS, (Figure 3)
Figure 3 illustrates the concepts of a relational database, (e.g. MS Access, SQL). An RDBMS provides the capability of creating libraries. Libraries allow there to be individual data sets for auditable events such as data management and user management, but others can be configured as well. This allows the application architect to collaborate with the database architect to ensure that a fully compliant audit trail can be generated.
Still the best way to avoid finding yourself in the example given is to confirm with the Vendor that the data is stored in a RDBMS. If so, then ask if their standard audit queries the data’s event log. Answering yes to both of these questions will most likely mean happy audit trails for you.