Audit trails are a common LIMS feature required for regulated laboratories, but they are generally a useful tool for any laboratory – regulated or not. For those of you who are new to LIMS, audit trails are like breadcrumbs that you leave behind on a path, so you can find your way back to the start. They tell you who did something, when they did it, what they did, and if it’s out of the routine process, it can record why the user did it. In this article, we discuss scenarios where audit trails are best used.
Analysing samples in your laboratory as a routine process will have defined stages such as sample receipt, work allocation, results entry and approval. We then introduce electronic systems such as LIMS to automate and control this process, and like any system, there is a level of data and user access configuration. Viewing the audit trail at results review and sample approval is good practice for quality review. When you view the audit trail at sample approval, you can see if tests have been added or removed, if the user has edited test results, and if the user performed actions under the appropriate role. This gives you the opportunity to raise any anomalies that you may find and implement corrective action to continually improve your sample analysis process.
When a result is out of limits, an investigation is normally raised. LIMS gives us the ability to compare results against specification, so we know when it ventures outside limits, and it also gives us the ability to record details of investigations. This flags the sample or test so that anyone working on this sample is aware of the investigation. All of these activities are recorded in the audit trail, and will be readily available should an inspector review investigatory data during an audit.
When using electronic systems, a probable cause for results outside limits could include static data setup. This is where the configuration of the system is not appropriate for the sample being tested. Errors in static data setup can happen, and therefore, it’ is important to have a static data approval process to minimise the impact to operational use of the system. However, if you do find yourself in a situation where static data setup is the root cause to the error, your system should also have the audit trail to review what changes were made by who, when and why.
A periodic review can be instigated through multiple channels. Whether it forms part of your internal audit schedule, or you received a customer complaint, a periodic review helps us to continually improve our processes. A periodic review shouldn’t be used to find as many deficiencies as possible, but to look for opportunities to introduce efficiencies and implement more effective ways of working.
During a periodic review, the audit trail plays a key part to provide information on what happened at a particular date and time. You can then assess whether the actions taken were correct and in accordance with procedures and user access rights. It’s unrealistic to expect anyone to remember exactly what happened two years ago with sample ID 550, and that’s why leaving breadcrumbs is a good idea to help you trace it back to the start.