by Joseph Cassella

The way in which regulatory data is generated has continued to evolve in line with the introduction and ongoing development of supporting technologies, supply chains, and ways of working.

Systems to support these ways of working can range from manual processes with paper records to the use of computerized systems. However, the primary purpose of the regulatory requirements remains the same; having confidence in the quality and the integrity of the data generated and being able to reconstruct activities remains a fundamental requirement.

Data Integrity Audits

There are common areas of concern regarding your implementation of data integrity procedures that an auditor may focus on. A majority of the lifecycle of bringing a product to market, from basic research through pre-clinical trials, to Phase I and II trials; post-approval manufacturing to sales and tracking adverse events post marketing is under some form of regulatory control (GLP, GCP, GMP).

Regulatory emphasis on data access controls tends to focus on laboratory systems. This graphic shows opportunities for compromised data in typical lab functions.

Examples of specific problematic observations:

  • OOS results were not reported or adequately investigated, and the raw data was discarded.
  • HPLC instruments do not have adequate restrictions in place to prevent any change or deletion of raw data.
  • QC lab personnel shared the same username and password for the operating systems and analytical software on each workstation in the QC lab.
  • QC computer users are able to delete data acquired.
  • QC HPLC raw data files can be deleted from the hard drive using the same login credentials used by all analysts.  

Where would an auditor or regulator look for data integrity issues?

  • Where there is manual data transcription, i.e., with the lab notebook and/or datasheets
  • Where spreadsheets might be used to calculate data downstream (data transformation)
  • Workflow management; activities must happen in a particular order
  • Data modification; retesting, where data is not deleted or overwritten (audit trails showing data history) 

Manual data access controls:

  • Asked to show where test data is captured and stored; show that data cannot be deleted from the system. Directories are locked down from user manipulation. Metadata also needs to be secured from manipulation. Metadata such as sample information, date/time stamps, etc.
  • The backup of data is critical and also needs to be equally secured. If this is a manual operation, then it must be shown that this activity is owned and periodically verified and documented.
  • In the case of automated backups, it can be difficult as instrument vendors typically provide proprietary software that may or may not allow security configurations to be set appropriately. 

Data loss or corruption of data is what must be prevented:

  • Intentional deletion
  • Catastrophic events (events of nature)
  • Equipment failure (if a failure, do we have contingencies in place?)
  • Preparedness
    • Backup and recovery
    • Disaster recovery and business continuity
    • Documented and approved (SOP’s)
    • Tested and verified
    • Periodically reviewed 

Where ‘cloud’ or ‘virtual’ services are used, particular attention should be given to understanding the service provided, ownership, retrieval, retention, and security of data. The physical location where the data is held, including the impact of any laws applicable to that geographic location, should be considered. The responsibilities of the contract giver and acceptor should be defined in a technical agreement or contract. This should ensure timely access to data (including metadata and audit trails) to the data owner and national authorities upon request. Contracts with providers should define responsibilities for archiving and the continued readability of the data throughout the retention period. Appropriate arrangements must exist for the restoration of the software/system as per its original interactive validated state, including validation and change control information to permit this restoration. Business continuity arrangements should be included in the contract and tested.

Along with evaluating the above activities, the data integrity audit report typically includes any discrepancies between data or information identified in approved applications (including Drug Master Files), and the actual results, methods, or testing conditions submitted to the Agency. A corrective action plan must be provided describing the specific procedures, actions, and controls that the firm will implement to ensure the integrity of the data in each application going forward.

A data integrity audit need not be an overly stressful experience. If your data governance is established and followed, data is reviewed adequately, security and controls are in place, then a data integrity audit can be viewed as an opportunity to address situations or processes that may have changed over time, or may have been missed during your company’s initial implementation of your overall quality system.

Related Content

Services: Data Integrity Services
Services: Product Master Data Management
Blog: Regulated Data Migration Guidance
Case Study: Improved UDI Data Integrity with Single Source of Truth
Case Study: Quality System Upgrade to Meet EU MDR and EU IVDR

About the Author

Joseph Cassella is the Director of Regulatory Compliance at USDM Life Sciences. With over 25 years of experience in the pharmaceutical, biotech, and medical device industries, Joe’s background is both broad and deep in Information Technology, Laboratory and Analytical Applications, and Quality Systems. He has led many projects inclusive of IT Infrastructure, Research & Development, QA/QC, Manufacturing, Compliance, and Sales and Marketing. 

Want our experts to work on your project?

Take the first step towards creating more value with USDM today.

Connect Now

We use cookies to understand how you use our site and improve your experience. This includes personalizing content and advertising. Learn more.