OR WAIT null SECS
The new PIC/S data guidance document PI-041 was published in July 2021. This column is the second part of a review looking at the expectations for computerized systems, outsourcing, regulatory actions, and remediation of data integrity failures. Spoiler alert: You won’t like this column if you use hybrid systems.
The final version of the PIC/S guidance on Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments with a document number PI-041 (1) was published in July of 2021. The document scope covers all activities under the remit of both Good Manufacturing Practice (GMP) and Good Distribution Practice (GDP) regulations. This column will only focus on laboratories working to GMP.
The last “Focus on Quality” column reviewed the first part of the document covering scope, data governance, organizational influences on data integrity (DI) management, general DI principles, and specific DI considerations for paper records (2). In this second part of the review, we focus on the requirements for computerized systems and take a high-level look at outsourcing, regulatory actions, and remediation of data integrity failures.
Section 9 of PI-041 is focused on specific considerations for ensuring data integrity for computerized systems (1). Section 9 is probably the most pertinent section for Spectroscopy readers because the majority of spectrometers have a workstation attached with application software to control the instrument and acquire, process, report, and store spectroscopic data. PI-041 section 9 consists of 10 subsections, as shown in Figure 1. This column covers the key sections from this guidance, starting with the Pharmaceutical Quality System, and the role it should (but often does not) play in controlling computerized systems.
To ensure overarching control of computerized systems and the processes automated by them, the Pharmaceutical Quality System (PQS) needs to ensure the following:
These areas are discussed in more detail in the remaining subsections in this part of the PI-041 guidance.
Do you have a death wish to keep perpetuating data integrity problems? If you are a DI team member, a CSV expert, or a consultant, you may have answered “Yes.“ However, if you work in the laboratory and must trudge through miles of procedural controls to ensure data integrity, the answer should be a resounding “No.” See the discussion on the hidden factory in your laboratory for a detailed description of the pain that paper can cause (5). But that lovely shiny new spectrometer that has just been delivered has arrived to resolve problems has the same old issues you have with the current one—a lack of data integrity controls. If you want to make money out of data integrity, buy shares in paper companies. You focused on the instrument and not the software during the selection process, you naughty people!
To avoid perpetuating data integrity problems, it is essential that any new analytical instruments and computerized systems have adequate technical controls in the software to protect the electronic records. Clause 9.1.4 of PI-041 notes that laboratories must ensure that suppliers have an adequate understanding of regulations and data integrity requirements, and, as noted in 9.3 item 1, specific attention should be paid to the evaluation of data integrity controls (1). Purchase of inadequate instruments is still a problem, as shown by Smith and McDowall, who analyzed over 100 FDA citations for infrared instruments. Over 40% of the citations were because of lack of software controls present before the instrument was purchased, such as no security, conflicts of interest, or no audit trail (6). Although there is the regulatory expectation that one should not purchase inadequate systems, as laboratories focus on the instrument and not the software data, integrity problems will be perpetuated.
Don’t forget how the Purchasing department can screw up data integrity. You may have spent time and effort in the evaluation of a specific instrument, and the software and the capital expenditure justification goes through the approval process. You await delivery of a shiny new red spectrometer but a yellow one you rejected due to inadequate software turns up instead. The gnomes of Purchasing have struck again, saying, “I got this one $1,000 cheaper on eBay!” The excuse goes along the lines “Its only an FT-IR, isn’t it?” Purchasing needs to be brought into the data integrity loop; otherwise what hope is there for your organization?
Clause 9.2.2 make an excellent point that a system may be validated, but the data may still be vulnerable (1); for more discussion on this point, please read a previous “Questions of Quality” column on this topic (7).
Section 9.3 has the first mention of the expectation and potential risk of not meeting regulatory expectations, with six topics for validation and maintenance (1). Listed below are the expectations and my comments; for the risks of not meeting them, you’ll have to read the document itself:
Another pantomime moment arrives when we consider section 9.4 and data transfer.
Now we come to what we say in English is the pièce de résistance: When conversion to the new data format is not possible, the old software should be maintained. Aargh! Computer museum, here we come! The problem is that the life of the data exceeds the life of the instrument that created them. One way of keeping a system on life support could be virtualization, provided that the software does not have a dongle or requires the instrument to be connected to operate. Expectation 3 also looks at the problem further, and suggests conversion to a different file format while acknowledging that data could be lost as a result, but that the process needs to be controlled and validated. The problem is that spectroscopic data are mainly dynamic, and guidance documents expect dynamic data to remain dynamic (1,10–12).
Section 9.5 covers five pages as it sets the expectations for system security, appropriate access to user functions, configuration to ensure data integrity, network protection, and restrictions on use of USB devices (1). Rather than go though the shopping list of non-mandatory expectations, I’ll cherry pick the key items from my perspective. In doing this, I’m making the assumption that you know about individual user identities with appropriate access privileges. Please read the guidance document to gain the full picture of the regulatory expectations here.
Strict segregation of duties is essential so that administrators are independent of laboratory users, which is reflected in several other regulatory guidances (1,10–12). However, one of the common questions that arises during training is if a laboratory has a standalone system with only a few users, how should this be achieved? The PIC/S guidance recognizes that this is a potential problem for smaller organizations, and suggests that a user can have either two user identities or roles:
However, if this option is selected, it is critical that the audit trail records the respective activities to demonstrate no conflict of interest (1).
The format and use of passwords must be controlled. This subject was discussed at length in a previous “Focus on Quality” column (13); don’t have complex passwords that are difficult to remember but string easy to remember words together. Doing so will save those groveling calls to the help desk saying you have forgotten your password and locked your account.
In expectation 1, it is noted that a system should generate a list of successful and unsuccessful login attempts, with dates and times plus a session length if a user has successfully logged in. For the latter expectation in a document that is purportedly non-mandatory and not legally enforceable requirements, this is going too far—you can work this out by log-on and log-off times.
There are many security expectations reading as a list of system requirements that most users won’t have read, or even bother with, during selection of an instrument and its data system. For example, can a system generate a list of users with user identification and their role? Most networked systems can generate a similar list, but not many standalone systems can, as this does not feature on the horizon of supplier requirements. If you use spreadsheets, forget it!
Network protection, including antivirus software, intrusion detection, and firewalls, is covered in table 9.5.3; as noted earlier, operating security patching was mentioned in table 9.3.6 (1). Personally, there should have been a separate section on cybersecurity that merges both these elements instead of separating them.
Table 9.5.3 discusses electronic signatures and notes that records must be permanently linked to their respective record, along with the date and time of signing (1). Again, in contrast to clause 3.7, this is a legal requirement lifted directly from clause 14 of Annex 11 (3). An extension to the requirements of Annex 11 is the expectation to revoke an electronic signature, but show on the record that it is now unsigned. Finally, there is encouragement to use biometric and digital signatures, I have doubts this will be implemented on small laboratory systems until the market requires it, and the technology reduces in price. The placing of this discussion is strange: security. I would have positioned it as a way of improving data integrity and process efficiency by eliminating paper in Section 9.8, as many systems are still hybrid. Hybrid systems will be discussed later. Another spoiler alert! You won’t like the comments.
There is a specific section on the control of USB devices, either as sticks or thumb drives, but also cameras, smartphones, and other similar equipment (1). This section is to ensure that malware is not introduced into an organization, and devices are not used to copy and manipulate data. See the discussion on the use of USB sticks in an earlier “Focus on Quality” column this year (14).
In contrast with the security section, the one for audit trails is shorter, which is surprising given how critical an audit trail is for ensuring traceability of actions and data integrity. The first expectation is that a laboratory purchases a system with an audit trail. However, there is an alternative option available in EU GMP Annex 11 clause 12.4 that management systems for data and for documents should be designed to record the identity of operators entering, changing, confirming, or deleting data, including date and time (3). Therefore, if an application can meet 12.4 requirements, then an audit trail is not required.
The guidance reiterates that proper system selection should ensure that software should have an adequate audit trail that users must verify the functionality of during the validation (1). Some applications may have more than one audit trail, and it is important to know which ones are important for monitoring changes to data. A good point is that the guidance suggests looking at entries for changes to data with a focus on anomalous or unauthorized activities to allow review by exception. With software having more than one audit trail, the review of any noncritical audit trails can be performed in periodic reviews at longer time intervals.
The guidance reiterates the issue with proper selection of software, as systems that prevent users from changing parameters or permission settings can reduce the need for detailed review of all audit trail entries. This allows a laboratory to implement an effective review by exception approach—but only where there are effective controls that have been implemented, documented, and validated.
The guidance is very clear, along with the WHO and MHRA guidances (10,11), that laboratories must know the criticality of data generated by any computerized system, as well as any vulnerabilities (1). Data process mapping (8) is suggested as a way of identifying vulnerabilities such as shared user identities, or data files stored in directories that can deleted outside of the application with no audit trail entry. The regulatory expectation is that these vulnerabilities should be fixed using technical controls, although the guidance acknowledges that legacy systems may require procedural controls to ensure data integrity before these are updated or replaced. Clause 9.2.2 makes the point that a system may be qualified, calibrated, and validated, but there is no guarantee that the data contained within it are adequately protected (1), hence the need to identify and mitigate any data vulnerabilities.
The traditional approach to validation of a computerized system in a regulated laboratory is once validated, no changes to the system are made. In contrast, in the security section the PIC/S guidance takes a more pragmatic approach on page 37, and suggests that computerized systems should be updated in a timely manner, including security patches and new application versions (1). This is good in principle, but there needs to be a different mindset within industry to commit and follow this in practice. For example, it is easier to update an application incrementally with minor re-validation rather than wait until the application goes out of support, and panic as a full validation and possible data migration project may be required. However, the detail provided here appears to be more of an inspector’s checklist with little flexibility.
Sections 9.7 to 9.9 cover the operational use of a computerized system from data entry, through data review, data storage, and finally destruction of the e-records (1). Yet again, there are regulatory expectations listed that are regulatory requirements, such as:
Some other nuggets of gold are:
There is an assumption that data will be archived offline; however, networked systems can archive data on-line by making the data read only, and only accessible by designated users.
For those that use hybrid systems, Section 9.10 does not make for comfortable reading; such systems are not encouraged, and should be replaced as soon as possible (1). They also require additional controls, due to the complexity of the record set and increased ability to manipulate data. This is essentially the same as the stance taken by the WHO guidance (10).
A potentially onerous requirement is a detailed system description of the entire system that outlines all major components, how they interact, the function of each one, and the controls to ensure the integrity of data. How many hybrid systems do you have in your laboratory, including spreadsheets?
To read further about hybrid systems, and why they need to be replaced, see the following references (17–19).
When GMP work is outsourced, such as API production, con- tract manufacture, or contract analysis, the same principles of data integrity are expected. After an adequate assessment of the facility, technical ability, and approaches to data integrity, requirements for DI and escalation of data integrity issues to contract giver need to be included in agreements between the two parties, as required by Chapter 7 (20). Limitations of summary reports were discussed in Part 1 of this review, as well as ways of reviewing analytical data remotely by video conference (2).
Section 11 has a section where the various PIC/S regulations and guidance documents are mapped to the ALCOA+ criteria. Of most use is a classification of data integrity deficiencies in four categories (1):
Examples given for each of the above deficiency categories are given to help during inspections. It may be prudent to adopt the same approach for classifying DI findings in internal audits or supplier assessments.
The last section is guidance of how an organization should investigate data integrity failures. The process is shown in Figure 3 that is taken from Section 126.96.36.199 in PI-041 (1). What the guidance does not state is that a data integrity investigation is a very detailed process and time-consuming process. From personal experience, it is unlikely that any root cause will be determined at stage 2 of the investigation (interviewing employees). Root cause determination comes at stage 6 of Figure 3, when the investigation team has a complete picture of the extent and depth of the data integrity problems.
In addition to identification of data integrity problems, a data integrity investigation will also identify poor data management practices. Don’t ignore them, they need to be identified, classified, and remediated in parallel, as they could be the source of the next data integrity investigation. These will also be included in the data investigation report.
PI-041 makes the assumption that all data integrity problems are caused by evil people. This is not so. I have been involved with one investigation that was caused by a software error (18).
The only other data integrity guidance that goes into detail about investigations is the FDA data integrity guidance in Question 18 (12) that calls out the agency’s Application Integrity Policy (21), which is broadly similar to that shown in Figure 3.
Some of the outcomes of an investigation could be:
Is there a material impact that requires the company to inform one or more regulatory authorities? The classic data integrity case is that of AveXis, a subsidiary of Novartis, and data integrity lapses found during the development of the biological Zolgensma for treating muscular atrophy. The company was granted a product license for the product, and then told the FDA there were data integrity problems. Understandably, the FDA were not happy campers, and in July 2019 went on site and subsequently issued a 483 (22). The issue is that a company needs to have a good understanding of all of the data integrity issues, and have at least a draft report available before approaching a regulatory authority to discuss the lapses.
Section 12 ends with a discussion on the indicators of improvement following an onsite inspection to verify that the CAPA actions have been effective. Indicators of improvement are listed as (1):
The best advice I can offer is to ensure that DI principles are infused throughout the organization, the PQS, and computerized systems, and your staff are trained in the DI policies. The effort and cost, along with loss of reputation with regulatory authorities, is not worth any efforts to save money. The cost of noncompliance is always much more expensive than the cost of compliance (23).
This two-part column has focused on the section of the new PIC/S PI-041 guidance on Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments dealing with computerized systems. It is a good guidance, with a wide scope and a lot of detail, but it had the potential to be much better. The reason is that it veers in places from guidance with room for interpretation to a regulatory checklist list, especially for computerized systems. Some of the requirements, such as to be up to date with patching, won’t meet with reality, as there are many laboratory systems using obsolete operating systems that will be unable to be patched. As a result, some requirements cannot be implemented.
(1) PIC/S PI-041 Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments (Pharmaceutical Inspection Convention/Pharmaceutical Inspection Cooperation Scheme, Geneva, Switzerland, 2021).
(2) R.D. McDowall, Spectroscopy 36(11), 16–21 (2021).
(3) EudraLex, Volume 4 Good Manufacturing Practice (GMP) Guidelines, Annex 11: Computerised Systems (European Commission, Brussels, Belgium, 2011).
(4) EudraLex, Volume 4 Good Manufacturing Practice (GMP) Guidelines, Chapter 4: Documentation (European Commission, Brussels, Belgium, 2011).
(5) R.D. McDowall, LCGC Europe 34(8), 326–330 (2021).
(6) P.A. Smith and R.D. McDowall, Spectroscopy 34(9), 22–28 (2019).
(7) R.D. McDowall, LCGC Europe 30(1), 93–96 (2016).
(8) R.D. McDowall, LCGC N. Am. 37(2), 118–123 (2019).
(9) EudraLex, Volume 4 Good Manufacturing Practice (GMP) Guidelines, Annex 15: Qualification and Validation (European Commission, Brussels, Belgium, 2011).
(10) WHO Technical Report Series No. 996 Annex 5: Guidance on Good Data and Records Management Practices (World Health Organisation, Geneva, Switzerland, 2016).
(11) MHRA GXP Data Integrity Guidance and Definitions (Medicines and Healthcare Products Regulatory Agency, London, United Kingdom, 2018).
(12) FDA Guidance for Industry Data Integrity and Compliance With Drug CGMP Questions and Answers (FDA, Silver Spring, MD, 2018).
(13) R.D. McDowall, Spectroscopy 33(11), 20–23 (2018).
(14) R.D. McDowall, Spectroscopy 36(4), 14–17 (2021).
(15) EudraLex, Volume 4 Good Manufacturing Practice (GMP) Guidelines, Chapter 6: Quality Control (European Commission, Brussels, Belgium, 2014).
(16) PIC/S PI-023-2 Aide-Memoire Inspection of Pharmaceutical Quality Control Laboratories (Pharmaceutical Inspection Convention/Pharmaceutical Inspection Co-Operation Scheme, Geneva Switzerland, 2007).
(17) GAMP Guide Records and Data integrity (International Society for Pharmaceutical Engineering, Tampa, FL, 2017).
(18) R.D. McDowall, Data Integrity and Data Governance: Practical Implementation in Regulated Laboratories (Royal Society of Chemistry, Cambridge, United Kingdom, 2019).
(19) R.D. McDowall, LCGC N. Am. 37(3), 180–184 (2019).
(20) EudraLex, Volume 4 Good Manufacturing Practice (GMP) Guidelines, Chapter 7: Outsourced Activities (European Commission, Brussels, Belgium, 2013).
(21) FDA Application Integrity Policy: Fraud, Untrue Statements of Material Facts, Bribery, and Illegal Gratuities (Compliance Policy Guide Section 120.100) (FDA, Rockville, MD, 1991).
(22) FDA 483 Observation AveXis Inc. (FDA, Silver Spring, MD, 2019).
(23) R.D. McDowall, Spectroscopy 35(11), 13–22 (2020).