Preparing for a data integrity inspection
Pharmaceutical quality assurance is characterized by new issues emerging at regular intervals and being adopted as the focus of regulatory inspections. Such areas of interest have included, for example, regulations on electronic signatures and records, cleaning validation, OOS, risk management, and, for the past several years, data integrity. Surprisingly, the latter issue has been addressed with great vigor since about 2012, with no end in sight at this time.
The U.S. FDA and European surveillance authorities initially started their inspections in this regard with the discovery and analysis of fraudulent data falsifications, especially in India and China. After uncovering many manipulations in these countries and training the majority of inspectors in this area, compliance was assessed among global players in the pharmaceutical industry. In the meantime, inspectors are also taking a closer look at medium-sized and smaller companies, which often have very thin staffing levels.
Given the large number of guidelines, all of which lack clear legal status and often provide conflicting guidance, a smaller company is at a loss without external assistance, as there are few references to pragmatic approaches to implementing data integrity. External consultants are often more interested in selling as many consulting hours as possible than pragmatic solutions.
Program
Most companies have now launched their own data integrity program that includes management involvement. However, convincing senior management of the need for such an approach is often difficult, as questions are raised about the purpose and potential cost savings resulting from such a program. In any case, implementing data integrity in the company will not bring short-term savings. Management should therefore be made aware of the potential negative impact on the company's revenue and reputation if data integrity problems become public. The following overview (Fig. 1) is suitable for bringing about a management decision.
Structuring
In the event of an inspection by the local or international supervisory authority, all organizational and technical measures taken to ensure data integrity in the company must be demonstrated. It is necessary to demonstrate a clear structure of these activities together with internal control, for example by QA. All measures should be planned on a risk basis, i.e. taking into account product, process and patient risk.
Fig. 1: Fictitious example: Estimation of resources and budget in a company
Risk analysis
Based on the system inventory (see Fig. 2 for an example of a graphical representation), all computer-based systems must first be considered and assessed according to a number of criteria - here is an excerpt:
1. static data / dynamic data
2. impacting quality (release of batches)
3. management/generation of raw data
4. system used for validated/compendial methods (QC) or validated production processes
5. change of parameters/limits described
6. critical data from the system transcribed reading to paper records by individuals
7. number of interfaces with other systems
8. ratio department members / system users
9. complexity of the application
10. data or metadata can be changed / modified
11. system malfunctions or bugs can be discovered
12. parameters/limits/setpoints can be changed or deleted by the operator
13. segregation of duties
14. user and admin in one person
15. number of administrators
16. audit trail compliant to regulations
17. no. of malfunctions of application per year
18. no. of malfunctions of sys. environment per year
19. annual change history
20. user account management
Recommendation
Berlin, Germany23 April 2024
Computerised System Validation: Introduction to Risk Management
These criteria allow the determination of the overall risk to data integrity and the criticality of the audit trail in a short period of time (a few minutes). It is imperative that the experts (Process Owner, System Owner, User) perform this assessment as a team, as only these individuals can confidently answer the questions listed in Tab. 1; if such system knowledge is not available, the assessment will not provide sound results. During the discussion of the individual predefined questions, the participants can also define immediate measures for the individual applications in order to promptly close any major compliance gaps that may become apparent during the discussion.
With the result of this initial, very time-saving risk analysis, the priority and sequence of further measures can - depending on the risk - be entered into a staged schedule and the CAPAs defined accordingly. The completion of the individual CAPAs can be defined on a risk basis over a period of approximately two years. Figure 4 (on the next page) shows examples of a corresponding risk analysis based on the aforementioned criteria.
Fig. 3: Example of an implementation schedule
The next step is a detailed analysis of each computerized system using a checklist. Such checklists are all very similar in structure and consist of approximately 50-80 questions.
Immediate measures
If there is neither time nor capacity for a risk analysis, a number of immediate measures can be taken in preparation for an inspection. These are listed accordingly in the MHRA Guideline of the British authority, for example:
- Eliminate generic user accounts for Windows login and instrument software login.
- Lab staff must not have access to the local drive, e.g. to delete or change data; this also applies to access to the "Recycle Bin".
- Always activate virus protection, extreme caution with USB memory sticks, especially from external service providers
- Laboratory staff must not have the ability to delete or change data in the instrument software within their authority
- Employees must not have access to change the system date/ time
- All standalone systems must have the audit trail feature enabled; this must not be able to be turned off by employees
- Electronic records (including metadata) must be reviewed by a second person for accuracy and completeness
- An SOP should ensure that a log-off is performed even if the system is left alone for a short period of time to prevent unauthorized access to data
- Documentation management: SOPs and instructions must not be stored locally
- etc.
Fig. 2: System landscape
Data Governance
Beyond the risk analyses mentioned above, it is of course advisable to draft a Data Integrity Policy, i.e., a statement by the company management on compliance with the DI principles. In this context, it should be noted that the policies of the large pharmaceutical companies hardly differ from each other, so that a corresponding statement of one's own can be formulated without much effort. However, a pharmaceutical inspector will be less interested in the policy than in a detailed SOP on data integrity. Such a document is often called "Data Integrity Principles" with a length of usually 10- 15 pages and lives from the numerous references to instructions that have an impact on data integrity in the company. A selection of the documents to be referenced there is listed below:
- Handling of Data (GMP, GLP, GCP)
- Good Documentation Practice
- General description of handling of logbooks
- General procedure for analytical procedure validation
- Performance, approval and documentation of analyses in GxP laboratories
- Retention of documentation in <COMPANY>
- Global Business IT Backup & Restore Procedure
- Business Continuity Management (BCM)
- Procedure for Computerised System Validation
- Change Management
- Qualification and Validation Principles
- Procedure for Data Audit performed by QA
- Procedure for Data Audit performed by Clinical Data Monitors
- Procedure for Data Audit performed by GLP auditors
- Technical agreements
- Quality Document Management
- General procedure for analytical procedure validation
- Procedure for training
- Handling of Deviations
- Handling of Case Record Forms (CFR)
- Handling of Corrective and Preventive Actions (CAPA)
- Handling of Informed Consent Forms (ICF)
Audit Trail Review
The most important issue related to data integrity for a pharmaceutical company is the audit trail review. This requirement has been common knowledge since the amendment of the Annex 11 EU
GMP Guideline, which has been in force since 2011, but has been questioned very hesitantly by inspectors. This practice has changed considerably in the last two years, so that even medium-sized and small companies are being asked for an audit trail review. The basis for this is, of course, again the risk analysis mentioned above and a precise knowledge of the data fields that could be changed/manipulated/ deleted if necessary. Provided the user no longer has access to the data after the initial entry, the Audit Trail Review question can be answered fairly quickly. Unfortunately, most computer systems allow data changes by the user.
The general practice of the audit trail review (roles, responsibilities, documentation, frequency) is defined in an SOP that applies to the entire review process. The details of the review are described in checklists that are specific to each system and identify all data fields to be reviewed. During the review, the reviewer will enter his result into a checklist, sign it and send it to the Qualified Person (QP). The QP uses the result of the audit trail review as a criterion for batch release.
Fig. 4 Example of a risk analysis
Stand-Alone Systems
During an inspection by the authorities, stand-alone systems are also frequently scrutinized. These are often older computer-based systems that are fairly simple in design and have no connection to the corporate network or Internet. User administration, data storage and data backup often do not meet the requirements of modern systems (generic user accounts and passwords); in some cases, the configuration is even done by the user.
Recommendation
Berlin, Germany24-26 April 2024
Computerised System Validation: The GAMP 5 Approach
If these are so-called "embedded systems" that control, for example, simpler machines in production and are directly connected to the equipment, replacing the control system is only possible in conjunction with a new machine and is therefore very expensive. Here, the company should think about pragmatic solutions that ensure higher security of data integrity and can be implemented cost-effectively until sufficient funds are available to replace the entire system. In the case of generic user accounts, for example, a solution is conceivable in which the users must enter their details in a logbook provided together with the time window of use. Such documents should also be available to the QP for batch approval, provided that quality-relevant batch data have been processed. The handling of stand-alone systems should be described in an SOP together with the various problems and their solutions.
Summary
When preparing for an authority inspection, it is very important to provide an overview of all measures taken to date to ensure data integrity. A pragmatic risk analysis, which does not take much time, supports a reasonable prioritization over a period of time that is acceptable for the company and acceptable for the authority representative. By implementing the immediate measures, it becomes apparent that the company has already started to put them into practice.
Author:
Dr Wolfgang Schumacher
... was head of the Quality Computer Systems department at F. Hoffmann-La Roche AG. He is a DGQ auditor and has undergone
personnel certification in accordance with DIN 10011 Part II.
