Ensuring data integrity by protecting original data from accidental or intentional modification, falsification, or even deletion is the key for reliable and trustworthy records that will withstand scrutiny during regulatory inspections. Many assessments and action plans stop at the system security level discussed in the "Access Security" article in this series. However, merely controlling and securing access to a data system does not address the real challenge for today's laboratories ensuring data integrity.
Data integrity means that data records are complete, intact, and maintained within their original context, including their relationship to other data records. To use an analogy from the paper world, a contract is valid only if all the pages of the document are complete, legible, and if it contains the required authentic signatures and properly states the terms and conditions. In this sense, integrity denotes validity.
In the case of a chromatography data system (CDS), data integrity gives a high degree of certainty that a given record (such as a calculated chromatographic result) has not been modified, manipulated, or otherwise corrupted after its initial generation.In the context of CDSs, data integrity requires automatic change management of metadata (for example, storage of method setpoints), including "revision control" for reanalyzed data. Data integrity also means that data cannot be entered out of context. Operational checks enforced by a computerized system should check user permissions and enforce a certain sequence of permitted steps according to a defined workflow.
Another technical challenge for data management systems is to ensure referential integrity, that is, the integrity of the record's relationships (dependencies). A database record is traceable, reliable, and trustworthy only if the complete set of related (dependent) records is available.
Think of the following scenario: Sample XYZ needs to be analyzed using Method A, revision 4 (the current revision). Due to a shortage of solvent during the analysis, chromatogram 1 of sample XYZ is invalid, and the sample must be re-injected. The system stores revision 2 of the binary chromatogram without deleting or overwriting the original. (Check whether your data system can really do this!) Chromatogram 2 is now processed, generating the result XYZ.2-A4-1. One of the points on the calibration curve is subsequently marked invalid because the reviewing analyst found a previously undetected sample preparation error. Chromatogram 2 must be reprocessed a second time, generating result revision XYZ.2-A4-2. The results are reviewed, approved, and archived. Over the course of the following months, method A is updated to revision 5 due to a specification change. In the course of an FDA audit, the results for sample XYZ are revisited.
A system with appropriate measures for maintaining referential integrity will retrieve the requested revisions of those results, including the correct references to the revisions of the raw data (XYZ.2) and processing methods (A4). Many current systems will allow retrieving the final result and the original raw data. But will they show the correct version (A4 instead of A5) of the processing method used at the time? Will they really show the history of revisions? If your system does not do this, you should develop appropriate procedures to capture at least a paper trail of the iterative changes.
Audit Trails and Change After security, traceability is one of the first prerequisites for the trustworthiness of a record. The computerized audit trail of a laboratory's data system holds the evidence of who did what to a record and when. According to McDowall, "audit trail is a software utility that monitors changes to selected data sets within the main application."1
Section 11.10 (e) of 21 CFR Part 11 requires an audit trail for "actions that create, modify, or delete electronic records" and that it be "secure, computer-generated, time-stamped."2 It is neither new nor surprising that previous entries in the audit trail must not be obscured, a practice well known to the keepers of paper records in a cGMP environment.
During FDA inspections, auditors typically refer to laboratory logs for the sequence of analysis and manufacturing steps. Similarly, audit trails help to manage, control, and also inspect the history of changes made to raw data and intermediate results that are used to calculate final results. However, the audit trail is only a subset of the change management of electronic records. Change management for electronic records requires both an audit trail (frequently called logbooks) and revision control of records. Logbooks merely describe what happened and when, but keeping the record under revision control establishes the exact details (for example, the chromatographic result before and after the change). When implemented properly, change management therefore can be used to answer the following questions:
Obviously, the capability of attaching audit comments to an electronic record helps the originator as well as the reviewer in documenting an action and justifying why it was done. Part 11 does not explicitly require entering a reason for a change, but some predicate rules do (for example, Good Laboratory Practice regulations). Some modern data systems therefore offer a function for fixed or user-definable audit comments. The data system can record, for example, that a certain method parameter was changed from value X to value Y, and in the comment section the analyst may state that this was because of a revised SOP.
Finally, in addition to operational controls that enforce the sequence of permitted steps systemically, audit trails also play a role in preventing "pencil whipping," that is, "the entry of data before an action occurs or at the end of the day, as an afterthought."6