As global regulators sharpen their focus on data integrity, issues have emerged around practices observed in operations that generate data used to make drug product decisions. One such practice is “testing into compliance”-- repeatedly analyzing a sample until a desired result is obtained, then reporting this value while ignoring all previous values. Regulators expect manufacturers to show all test data and use it in calculations (1), unless a specific assignable cause of rejection is discovered and documented as part of an investigation. With electronic systems that have individual user identities and audit trails, regulators have learned to search these records, looking for data that has not been included in calculations. And they have found it (2). We should expect regulators to conduct such detailed inspections of our data systems.
Many people recognize this as being non-compliant; however, might there be other ways we could be “testing into compliance”? Answer this question: do you perform ANY activity to determine if a sample or a batch is ready to be tested? For example, do you inject a standard solution to see if the HPLC/GC column resolves the components, so you can start system suitability testing? Do you assess the quality of an IR pellet using a scan, before conducting the “official” identity scan? Do you put a weight on an electronic balance or scale to see if it responds correctly before an “official” weighing? These are examples of “data” that are often not considered as such by people performing the actions. These practices are used to make decisions (instrument acceptable for use?), but are not treated as such. These “undocumented practices”, if observed by an inspector, will result in a citation. “Testing into compliance” occurs anytime we create relevant data (data that leads to a decision) that is not: (1) documented in a procedure, and; (2) included in the official record, subject to review.
How to stay out of trouble? Critically look at every decision you make as part of your work process. Look at actual practice-not just what is written in the procedure/method. Is every decision or action written into a procedure or method? Is every data value captured in an official record, including values that have been invalidated? If not, change is required. If the action is valid, the method or procedure must be modified to include it in your process. This ensures that procedures are an accurate reflection of your activities, and that such actions will continue as new personnel enter the area.
We can be guilty of “testing into compliance” with the best of intentions—even attempting to practice what we believe to be good science. We must diligently review our practices and assure that we provide a process for capturing and managing all our data that has an impact on product quality decisions.
Data Integrity provides confidence that we will make quality decisions that result in safe, effective medicines and devices for the patients we serve.
Mark E Newton
Assoc Sr Consultant - QA, Global Quality Laboratories
Eli Lilly and Company
Mark is a Business Quality Assurance representative with experiences in LIMS design/implementation, validation of computer systems and computerized lab instruments, risk management and data integrity (detection, remediation, analytics).
Mark is active in ISPE/GAMP where he has published several blogs on data integrity topics for iSPEAK and have been a yearly presenter at ISPE/GAMP Conferences and workshops including:
Mark has been at Eli Lilly and Company for 33 years (14 in QC Labs, 19 in systems) with an academic background is Microbiology (BA, DePauw University 1982).