By Bill Burke, President, Merit Solutions
As a one-time internal controls auditor, I can tell you that the last thing an FDA auditor wants to see is an unstructured pile of symbology that it would take several weeks to plow through to discover a particular transactional history selected for an audit sample. There’s a word for such audits — “FAILED”. Yet, many companies still attempt to implement Part 11 audit trails using plug in database tools that aggregates ALL database changes into large, unstructured data files.“Does this really happen?”,
you ask.You bet this happens, whenever a company grappling with FDA 21 CFR Part 11 doesn’t make the leap from “paper think” to a true understanding of how relational databases really work. Let’s backtrack a bit to get an understanding of how this not-so-mythical company ended up with a pile of computer code in lieu of a true audit trail. “Paper Think” might be defined as the mistaken notion that manual compliance methods are the guide or standard that automated processes follow, but just do a lot quicker. So, for example, in a “Paper Think” mindset, an audit is just like what you do in a manual audit. First you go to the binder where the procedure is written, then you make a copy and change it, initial it, and refile in the binder and a control binder. When the FDA auditor comes, you simply show them the paper trail of the “before” and “after”. So when you automate processes the computer is doing the equivalent of setting up all these before and after documents. Right?Wrong! Although the wording of 21 CFR Part 11 says that you need to “reassemble the electronic document” to prove the audit trail, the truth is THERE IS NO ELECTRONIC DOCUMENT in a database-driven business system! Rather, data is in a relational database and that is where the audit trail needs to be created and protected.
There are 3 basic criteria in 21 CFR Part 11 of what an audit trail needs to do. First, there needs to be the capability of building an audit trail of any data changes that occur in any “significant processes”, i.e. those that can have a clinical effect. Second, the audit trail has to capture the “before” and the “after” data associated with a change. Although there is no electronic document per se, the changes are stored in a data table, and you have to be able to say “here’s what the change was” and “here’s what the series of screens looked like before and after the change was made.” Third, you need to ensure that you have a secure, tamper-proof “closed system”.
So that company that hopes to satisfy an FDA audit by presenting a mountain of symbology masquerading as an audit trail is most likely taking the need to document “before” and “after” seriously enough, but doing it on the cheap to such an extent that they can’t make this pile of “before” and “after” data into little more than one big data garbage pail. Every time data changed, they are likely throwing a string of characters documenting the change into a huge database. Let me restate that – a huge database that is not readily sorted into data, user or transaction types. If you can’t access data stored in a structured way, you can’t logically reassemble a trail. There’s just too much garbage there, and in fact, most of it, maybe as much as 80% of it, has NOTHING to do with the significant processes that the FDA is concerned about.
A more intelligent and workable way to be compliant with FDA 21 CFR Part 11 is to design a database level tool that intercepts transactions between the storehouse of data tables, which you might picture as a Rubik’s cube type structure, and the software logic for significant processes, and puts it into its own secure but organized database. And secure really means secure! Once a system is set up, controls are cranked around it that prevent changes to the database, even by the IT person who originally set it up. And the FDA requires this. They want to know that if someone died as a result of taking the serum you manufacture that you will be able to go in and create a true record of just what happened without worrying if someone went in to erase incriminating evidence.
So what you need from your audit trails software is nothing more or less than the three criteria explained above-1) all significant processes, from an FDA standpoint, need to be recorded and tracked; 2) all “before” and “after” data must be captured and accessible and 3) the audit trail has to be tamper-proof.
Sound like a tall order? Actually, if you understand the underlying architecture of the business system being deployed, building an audit trail system is relatively straightforward and the prices that you pay for these audit trail systems are correspondingly reasonable. Full audit trail automation for Microsoft Great Plains(tm) for example would cost as little as $6,000 such that the average company would get a complete return-on-investment in little more than a month, because it will remove at least one quality assurance worker’s time for the tasks of manual audit trail. Larger companies using business systems made for multi-location, multi-division enterprises will likely pay $100,000+ for audit trail functionality, but perhaps decrease their headcount by as much as three.
Granted, you won’t get this kind of return-on-investment if you haven’t done your homework. You really do need to be methodical when you are building up to audit trails. You need to identify your significant processes, you need to have pre-built datasets and rigorously test your systems (IQ, OQ, PQ). When you do this upfront preparation correctly, setting up fully functional electronic audit trail processes will usually only take a few days, perhaps with the help of consultants who designed the proprietary aspects of the audit trail systems and who have an in-depth understanding of the underlying architecture of business systems.
The better electronic audit trail systems will actually give you capabilities that go beyond simple 21 CFR Part 11 compliance. They might let you export data into an Excel spreadsheet, for example, so that you can do statistical analyses and tie into tools that enable you to measure productivity of particular processes. While “Paper Think” can lock you into thinking of compliance as the albatross at the door, an appreciation of what electronic systems really can unleash your thinking about how to get the most out of them.
Bill Burke is President of Merit Solutions (www.meritsolutions.com), that specializes in software for full FDA CFR 21 Part 11 compliance for pharmaceutical manufacturers and other Life Sciences firms using Microsoft Business Systems. Questions can be forwarded to Bill Burke at bburke@meritsolutions.com, 630 – 510 – 3238.
