 is the director of R.D. McDowall Limited and the editor of the “Questions of Quality” column for 

R.D. McDowall

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.

Specific DI Considerations for Computerized Systems

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.

FIGURE 1: Specific data integrity considerations for computerized systems (from PIC/S PI-041)

Role of the PQS 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:

Evaluation and control of computerized systems to meet GMP regulations (essentially Chapter 4 and Annex 11 [3, 4])

Knowledge of the data integrity risks and vulnerabilities of each system and the ability to manage them.

Knowledge of the impact each system has on product quality and the criticality of the system

Ensuring that data generated by a system is protected from accidental and deliberate manipulation

An assessment that suppliers of computerized systems have an ad- equate understanding of applicable regulations, and that understanding is reflected in the applications that they market

An assessment of the criticality and risks to the data and metadata generated by each system. Data process mapping is one way to understand how the system operates, the meta-data used to acquire and manipulate data, how the data are stored, and the access allowed to each user role.

These areas are discussed in more detail in the remaining subsections in this part of the PI-041 guidance.

Data Integrity and Compliance Starts with System Purchase

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:

Purchasing systems that have been properly evaluated, including their data integrity controls, and validating them for intended use is a key expectation that most people will ignore totally. We will revisit this later. Software configuration settings must be documented, as this is a key part of validation. This section also covers legacy systems and where data integrity controls are lacking “additional controls,” meaning SOPs and training should be implemented.

There should be an inventory of all computerized systems, with risk assessments and data vulnerability assessments. Now, we have an inconsistency with clause 3.7 that states that this guide is not mandatory or enforceable under law. However, there is a legal requirement in Annex 11 for an inventory in clause 4.3, as well as application of risk management in clause 1 (3). Data process mapping to identify data integrity vulnerabilities, and then remediating them, is common sense in today’s regulatory environment (8).

For new systems, a Validation Summary Report (VSR) is expected, along with a shopping list of items that need to be included, including a list of all users, configuration details, etc. (1). The writers of this document appear to have forgotten the middle word of what is being written: summary. A VSR is a concise document that should point to where such information can be found in the suite of validation documents. Who in their right mind would include a list of all current users in a VSR, especially for a large networked application? “Bonkers” is the politest word I can use.

The validation and testing approach outlined is based on Annex 15 on Qualification and Validation (9), rather than Annex 11 for Computerized Systems (3). As such, it is a poor and apparently inflexible approach being focused on manufacturing rather than laboratory systems, as it lists user requirement specifications (URS), design qualification (DQ), factory acceptance test (FAT), site acceptance test (SAT), installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ) documents (1). How many laboratories perform FAT and SAT testing in their validations? This approach ignores clause 2.5 in Annex 15 allowing the merger of documents (9), and, furthermore, does not reference clause 1 of Annex 11 (3) regarding the use of risk management to determine the extent of validation work required. The list omits the configuration specification ,and, if custom software is being developed, functional and design specifications. In all, a poor set of expectations.

Periodic review is another concept not mandatory or enforceable under law. However, we now reach the point where this becomes audience participation time in a British pantomime, where the evil regulatory villain shouts to the audience it’s not enforceable by law—and the laboratory audience shout back, “Oh, yes it is!” Have you ever read Annex 11 clause 11 on periodic evaluation (3)?

We now come to the point in PI-041 where the regulatory enthusiasm for regular system updates (such as, for example, patches and application upgrades) meets the buffers of pharmaceutical reality—requirements for timely update of security patches (1). We assess this in a separate section. 

Another pantomime moment arrives when we consider section 9.4 and data transfer.

The “not mandatory” or “enforceable under law” statement is inconsistent with item 1 about the need to validate data transfer. This is a specific requirement of clause 5 of Annex 11 (3).

A good point regarding PI-041 is when software is updated, the laboratory should confirm that old data can still be read (1). This may be in the existing data format, or may require migration to a new data format, but this is another specific requirement in clause 4.8 of Annex 11 (3) that is legally enforceable.

Now we come to what we say in English is the pièce de ré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).

Audit Trails Are Critical for Data Integrity

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.

Don’t Touch the System – It’s Validated!

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:

9.7.1 Critical data entered manually should be verified by a second person or a validated process (clause 6 of Annex 11) (3)

9.7.2 Changes to data need to be authorized and controlled. I’m not certain that “authorized” is the correct word, as the regulations merely use the word “reviewed.” However, these are regulations in Chapter 4.9 (4), Chapter 6.17 vii (15), and Annex 11.9 (3).

9.8.1 requires a risk assessment to identify all GMP critical data (1). Whoa! We performed an analysis, but, before we review the data, we need to identify critical data. We are in the process of reviewing data, and we need a risk assessment? This should have been undertaken during evaluation and validation!

There is the requirement to write an SOP to review audit trails (1). This is wrong. Look around your laboratory; how many different systems are there? There are basic regulatory requirements for audit trails, but there is no standard implementation. You won’t have one SOP for audit trail review; you will have as many review procedures as you have computerized systems (assuming that each one has an audit trail). A far better approach would be to have a single SOP for second person review that calls the appropriate procedure or work instruction for audit trail review, as shown in Figure 2. This is an easier way to review audit trails rather than have a generic SOP that will be useless, as it will not have enough detail for each system’s audit trail review.

An expectation is the need for quality oversight of audit trail review that should be incorporated into the Chapter 9 self-inspections (16) in an organization.

Back to regulations disguised as expectations; most of the items in section 9.9 can be derived from clause 7 of Annex 11 (3):

Backup must include all data and associated metadata, and be capable of recovery

In the absence of alternatives, backup using USB devices must be carefully controlled. Backup must be performed automatically and must not use either drag and drop or copy and paste. The backup must not allow data deletion (1), which implies that it should be performed by an independent person.

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.

FIGURE 2: Procedure for second person review with linked specific work instructions for individual system audit trail review.

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):

Critical: Impact to product with actual or potential risk to patient health

Major: Impact to product with no risk to patient health 

Major: No impact to product, evidence of moderate failure

Other: No impact to product, limited evidence of failure

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 12.1.1.1 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.

FIGURE 3: Process for investigation of data integrity failures (PIC/S PI-041).

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:

Data in a product license submission are falsified

Data manipulation resulting in a risk to patient health, necessitating a batch recall

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):

A thorough and open investigation of the issue, and how to implement effective CAPA actions

Having open communications with clients and other regulators

Evidence of open communication of the DI expectations, and processes for open reporting of issues and opportunities for improvement across the organization

Resolution of the DI violations, and remediation of computerized system vulnerabilities

Implementation of data integrity policies with effective training

Implementation of routine data verification practices

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).

Articles

We continue our explanation of the new PIC/S data guidance.

Are You Ready for the Latest Data Integrity Guidance? Part 2: Computerized Systems, Outsourcing, Quality, and Regulatory Oversight

	When I walk around laboratories as an auditor, I usually stop at an instrument and check to see that it has an identity number, that it has been qualified, and that there is a calibration sticker on it. Then down the side of the instrument I often notice a scruffy, dog-eared, chemically stained book that looks as if it should be residing in a museum or the waste bin. Then the truth slowly dawns-it's the instrument logbook!

	This column is dedicated to a discussion about the humble logbook for analytical instruments. Why do we need one and what needs to be entered in it? Finally, we'll look at why we can't automate the functions of a logbook. If we have complex computer-controlled spectrometers, why can't we dispense with the quill pen and cellulose and have an automated function that logs all work generated by the data system?

	This is a good question to begin with: Why do we need any instrument logbook? One answer is required by either the good laboratory practice (GLP) or good manufacturing practice (GMP) regulations. Another answer is that it provides a history of the instrument, including information about the following events:

		calibration to demonstrate that the instrument is working correctly,

		preventative maintenance visits from a service provider (or in some cases the angel of death),

		repairs and maintenance carried out in-house or by a service provider, and

		qualification and requalification of the instrument.

	As such, a logbook is essential to demonstrate that an analytical instrument is under control, works correctly, and the results generated can be relied upon.

	An instrument logbook is also one of the essential documents for data integrity. It is typically a bound and paginated paper book that is completed manually. It cannot be loose-leaf sheets or a ring-bound notebook purchased from a local supermarket, but instead must be a real book. You would be surprised by the number of laboratories that cannot get even this basic element right. The logbook is issued by a document control function, typically the quality assurance (QA) department, and when completed the log is returned to document control and then archived. To ensure that it is completed correctly, a written procedure must be available with training for making entries in an instrument logbook, and also for reviewing them. There needs to be a means of referencing the reports from service visits and any qualification of the instrument, and both need to be accommodated to ensure a complete record for each instrument. The other item that is often neglected is who is going to review the entries and when.

	What Needs to Be Entered in the Logbook?

	Since we all work to the same regulations, you would think that the contents of an instrument logbook would be easy and straightforward. Unfortunately, optimism falls at the first hurdle. We use the same regulations, but everyone interprets the words differently. At this point it is important to remember one of the corollaries of Murphy's Law-Cahn's Axiom-when all else fails read the regulations. Table I lists the GLP and GMP requirements for an instrument maintenance and use log.

	Summarizing these regulations, the logbook entries must be

		linked to the use of the instrument (that is, they should include information about practices such as use, calibration, maintenance, and so forth);

		chronological, which implies that the entries must be dated and must be made contemporaneously in the sequence they are performed on a day-the best advice is do not separate the tasks of use, calibration, and so forth, but list them all chronologically;

		checks for correct operation of the instrument; and

		a description of the analytical work undertaken by the instrument.

	In addition to the elements listed above, you also need to consider any pharmacopoeia requirements. For example, pharmacopoeia requirements could include system suitability test results or sound science such as point of use checks made on the day to show that the system is working correctly (such as calibration of a balance or pH meter or running a standard spectrum for a spectrometer).

	You would think that from this list it would be simple, right? Wrong! How will use of the instrument be interpreted? Does each use mean just the work package performed or individual runs within that package? It depends on the interpretation by an individual organization of the regulations. But, we now have additional requirements for the logbook that potentially cloud the issue:

		The Food and Drug Administration's (FDA) Part 11 Scope and Application Guidance (5) allows laboratories to record audit trail information if an application does not have such functionality.

		Data integrity requirements mean that the logbook takes on an increased importance for recording the work, potentially resulting in increased granularity for the entries. This increased level of detail may include verification by a second person of an instrument reading where output is not captured electronically or by an attached printer. Or entries in lieu of an audit trail for corrections to data.

	And yes, you've guessed it-all entries are handwritten!

	The importance of the instrument logbook has been known by regulatory agencies for a long time. Enter stage left my North American advertising agency . . . the FDA.

	FDA Guidance on Inspection of Pharmaceutical Quality Control Laboratories

	The FDA guidance for inspectors on the "Inspection of Pharmaceutical QC Laboratories" was issued in 1993, following the Barr Laboratories case, and has an interesting approach that is also very useful for second-person reviews and data integrity audits (6). The guidance states "Laboratory records and logs represent a vital source of information that allows a complete overview of the technical ability of the staff and of overall quality control procedures."

		overall quality control (QC) procedures.

	Why does the FDA think this about a humble instrument logbook? The reason is that a logbook is not humble, but a vital link between the analytical instrument, the data system, and the work carried out as shown in Figure 1. The logbook links the instrument or spectrometer system with the work performed by or on the instrument and the data system, such as qualification and requalification work, method development, method validation, calibration checks, system suitability tests, routine work, repairs, and preventative maintenance. The aim is to have a complete record to identify issues and aid in troubleshooting issues. Data from some system suitability test or point of use checks should be trended to identify any instrument or method issues that could result in an out-of-specification result. A few laboratories do this via the instrument logbook for simple instruments such as balances and pH meters. However, this is an area that should be automated by the instrument data system and linked to an automated logbook.


	Figure 1: Relationship between the instrument logbook, the analytical instrument, and the work performed.

	Now let's compare the theory with the practice as found in inspections.

	483 Observations for Laboratory Logbooks

	In May 2016, Akorn AG received a 483 citation for discrepancies in the sample logbook entries used to document storage conditions as either ambient or 2–8 °C (7):

		Between February 17 and May 18 there were 24 instances where a single sample was noted as being stored at both temperatures, so it was not known if samples were correctly stored before analysis.

		Write-overs of entries where dashes were changed to X's

		Review of the logbook by a supervisor only consisted of checks for empty spaces. Discrepant entries (such as write overs) had not been identified or investigated for their impact on stored samples or the corresponding analytical data.

	The Aarti warning letter of July 2013 included the following citation (8):

		On October 27, 2012, our investigator noticed that a QC analyst was performing a loss on drying (LOD) analysis for <redacted> and had recorded the completion time as <redacted> and total time as <redacted> in the usage logbook for the LOD oven usage logbook although the step was not yet completed.

	How do these citations compare with the criteria identified in a quarter of a century-old FDA guidance document? Consider the following questions:

		What do you think of the technical ability of the staff (or more accurately, the inability of the staff)?

		Are the written procedures adequate or even followed?

		If you were an auditor or an inspector, what would be your view of the technical competence of this laboratory?

	Just from these two citations you can start to see the importance of a correctly completed and reviewed instrument logbook.

	Typically, the majority of instrument logbooks are paper based using bound books with sequentially numbered pages to prevent pages from being removed and replaced. You would be surprised that I still find instrument logbooks that fail to meet these simple requirements-bound but without numbered pages, books that have loose leaf pages, or ring-bound books from which pages can be torn out without leaving a record of what they contained.

	An instrument logbook requires all users to complete the entries manually, consistently, and contemporaneously. The way the use of an instrument is recorded will depend on the interpretation of the regulations in Table I by each individual organization. However, because the logbook is paper it is always difficult to know if an entry has been made contemporaneously or before or after the event.

	As an auditor, one item that is usually overlooked is that each instrument logbook in any analysis should be subject to second-person review to ensure that the work is correctly documented. As can be seen in the 483 observations earlier, some reviews can be superficial and ineffective. The second-person review may look at a single entry or connected entries, but there is also the need for the instrument owner to check all entries periodically to confirm that over time the instrument is operating correctly. What do you mean you don't have an instrument owner? Get one appointed-now!

	Role of the Instrument Logbook in the Second-Person Review

	One of the important stages of analysis is the second-person review-the third and fourth eyes of the four eyes principle. Primarily, it is good science to have a check of results to ensure that procedures have been followed, samples have been analyzed correctly, data have been interpreted correctly, calculations were right, and the reportable result was accurate. Increasingly, the second-person review is a means of ensuring data integrity and preventing poor data management practices or falsification of data. An outline of a second-person review is shown in Figure 2. Here there are three key sources of information for the reviewer: paper printouts, electronic records in the data system, and the instrument logbook. The reviewer needs to check all three to see that records are complete, consistent, and accurate and that the three are congruent and there are no discrepancies. Omissions or discrepancies with anything between the three parts need to be investigated thoroughly: Is a discrepancy the result of a mistake or is it something more sinister?


	Figure 2: Role of the instrument log in a second-person review.

	An instrument logbook is often a repository of data about the day-to-day performance against a reference or calibration standard. Over time it can tell you if an instrument is continuing to perform acceptably. However, because this information is stored on paper there is often little attempt made to trend the data to see if there is a potential problem and stop it from getting worse either though service or repair. This oversight is a shame because often out-of-specification situations could be mitigated or even prevented if these data were plotted and trended-even if only the results were visualized over time against acceptance and warning limits. This is one of the roles of the instrument owner-to confirm that the instrument is working as expected. In addition, the individual may also be responsible for coordinating service and repair of the instrument.

	When we move our attention to laboratory computerized systems we return to the medieval age. We have the ridiculous situation where a lot of money has been spent on a spectrometer with great resolution complete with (mostly) an amazing software application to control it. What about the instrument logbook? Paper! The application software has the sequence file, the work performed, a record of the samples, the analysis method, and so forth, but what does the poor analyst have to do? Write all this information into the instrument logbook complete with typos and mistakes. What an amazing waste of time and effort when the information-in probably more detail than is required by local procedures-already exists in the instrument data system.

	Why can't we have an electronic instrument logbook that is generated automatically by the instrument control software? It would be protected and secure like an audit trail and could be viewed as part of a second-person review with a function to document when selected entries have been reviewed. The instrument log function could not be turned off, which like an audit trail will result in a true record of the work performed by and on the instrument. The log would be an additional source of information to ensure the integrity of the work performed by an instrument. In addition, there should be the ability to cross-reference between the audit trail and logbook entries and drill down into the underlying data and metadata.

	Qualification and maintenance work may be more difficult to document, but this challenge should be surmountable by instrument companies because many instrument data systems can identify an instrument down to the serial number. Therefore, some linkage between qualification work and the online instrument logbook is also required, and that linkage should extend to any paper records of service visits outside of the log. This may be done via a controlled user input to the instrument log.

	We have looked at the humble instrument logbook, which is really not so humble-it is a vital source of information about the instrument and the work undertaken by it. Unfortunately, virtually all logbooks are based on paper and completed manually, which is a shame when all the information available in an instrument data system could be abstracted and used for an automated logbook.

	Is this concept too simple, and you still want the comfort of your cellulose instrument logbooks? For those that don't, what are you going to do about it? Will you suffer in silence or start to request this functionality from the suppliers of your software? The reason you don't have this functionality is that suppliers are market driven-if the market does not require it then nothing happens. Over to you . . .

	I would like to thank Kevin Roberson and Mark Newton for helpful comments made in the preparation of this column.

	(1) European Commission Health and Consumers Directorate-General, 

EudraLex: The Rules Governing Medicinal Products in the European Union. Volume 4, Good Manufac turing Prac t ice Medicinal Products for Human and Veterinary Use

 211 "Current Good Manufacturing Practice for Finished Pharmaceutical Products" (Food and Drug Administration, Sliver Spring, Maryland, 2008).

 58 "Good Laboratory Practice for Non-Clinical Laboratory Studies" (Food and Drug Administration, Washington, D.C., 1978).

	(4) Organsation for Economic Co-operation and Development (OECD), 

Series on Principles of Good Laboratory Practice and Compliance Monitoring Number 1

 (OECD Principles on Good Laboratory Practice, Paris, France, 1998).

Guidance for Industry, Part 11 Scope and Application

Good practice (GxP) regulations require an instrument maintenance and use log. Have spectroscopy laboratories and software suppliers emerged from the Middle Ages yet?


The Humble Instrument Logbook?

general chapter <1058> “Analytical Instrument Qualification” has been updated and became effective August 1, 2017. So, what has changed in the new version?

	In the regulated world of good manufacturing practice (GMP) we have regulations that define what should be done, but leave the interpretation to the individual organization on how to do it. However, when we come to the regulated analytical or quality control (QC) laboratory we also have the pharmacopoeias, such as the 

 to provide further information to help interpret the regulations. These tomes can have monographs for active pharmaceutical ingredients, finished products, and general chapters that provide requirements for how to apply various analytical techniques, such as spectroscopy.

has a general chapter on analytical instrument qualification (AIQ) (1). This chapter came about with a 2003 conference organized by the American Association of Pharmaceutical Scientists (AAPS) on analytical instrument validation. The first decision of the conference was that the name was wrong and it should be analytical instrument qualification (AIQ). The conference resulted in a white paper (2) that after review and revision became 

general chapter <1058> on AIQ effective in 2008. This chapter described a data quality triangle, general principles of instrument qualification, and a general risk classification of analytical equipment, instruments, and systems. General chapter <1058> did not specify any operating parameters or acceptance limits because those can be found in the specific general chapters for analytical techniques.  
	
	This column is written so that you will understand the changes that come with the new version and the impact that they will have on the way that you qualify and validate instruments and the associated software, respectively.

	Why Is Instrument Qualification Important?

	The simplest answer to this question is that qualification is important so that you know that the instrument is functioning correctly and that you can trust the results it produces when it is used to analyze samples.  
	
	However, there is a more important reason in today’s world of data integrity–integrated instrument qualification and computer validation is an essential component of a data integrity model. The complete four-layer model can be viewed in my recent book, 

Validation of Chromatography Data Systems 

(3), but the analytical portion of the model is shown in Figure 1 and is described in more detail in an earlier “Focus on Quality” column (4).

		Foundation: management leadership, policies and procedures, culture, and ethos

		Right instrument and system for the job: instrument qualification and computer validation

		Right analytical method for the job: development and validation of analytical procedures

		Right analysis for the right reportable result: analysis from sampling to reporting the result 

	
	The model works from the foundation up with each layer providing input to the next. As shown in Figure 1, AIQ and computerized system validation (CSV) come after the foundation layer, illustrating that if the instrument is not qualified and any software is not validated, the two layers above (method validation and sample analysis) will not be effective and can compromise data integrity. Interestingly, AIQ and CSV are missing from many of the data integrity guidance documents but you can see the importance in the overall data integrity framework of Figure 1.

<1058> had several issues that I presented during a session co-organized by Paul Smith at an AAPS conference in 2010 and published in this column (5). There were three main problems with the first version:

		Problem 1: The true role of the supplier was missing. The supplier is responsible for the instrument specification, detailed design, and manufacture of the instrument but this responsibility is not mentioned in <1058>. The reason is that the section on design qualification (DQ) mentions that a user can use the supplier’s specification. However, a user needs to understand the conditions under which the specification was measured and how relevant it is to a laboratory’s use of an instrument.

		Problem 2: Users are responsible for DQ. 

<1058> places great emphasis on the fact that in the design qualification stage is the responsibility of the supplier, “Design qualification (DQ) is most suitably performed by the instrument developer or manufacturer.” This is wrong. Only users can define their instrument needs and must do so to define their intended use of the instrument and comply with GMP regulations (§211.63) (6).

		Problem 3: Poor software validation guidance. The software qualification and validation description in 

<1058> is the poorest part of this general chapter as software is pervasive throughout Group B instruments and Group C systems. 

	Although the approach to handling embedded software in Group B instruments where the firmware is implicitly or indirectly validated during the instrument qualification is fine, there are omissions. Users need to be aware that both calculations and user defined programs must be verified to comply with GMP requirements in 211.68(b) (6). Note that the qualification of firmware, which is a simple and practical approach, is now inconsistent with Good Automated Manufacturing Practice (GAMP) 5, which has dropped Category 2 (firmware). 

	Software for Group C systems is the weakest area in the whole chapter <1058>. The responsibility for software validation is dumped on the supplier: “The manufacturer should perform DQ, validate this software, and provide users with a summary of validation. At the user site, holistic qualification, which involves the entire instrument and software system, is more efficient than modular validation of the software alone.”

	In the days of data integrity, this approach is completely untenable. The United States Food and Drug Administration (FDA) guidance on software validation (7), quoted by <1058>, was written for medical device software, which is not configured unlike much of the laboratory software used today.

	To try and rectify some of these issues, the revision process of 

<1058> started in 2012 with the publication of a “Stimulus to the Revision” process article published in 

 written Chris Burgess and myself (8). This article proposed two items:

		An integrated approach to analytical instrument qualification and computerized system validation (AIQ-CSV), and

		More granularity for Group B instruments and Group C computerized systems to ensure that calculations and user defined programs were captured in the first group and an appropriate amount of validation was performed by the users for the second group.

	We used the feedback from that article to draft a new version of 

 <1058> in the summer of 2013, which was circulated to a few individuals in industry and suppliers for review before submission to the 

	Proposed drafts of the new version were published for public comment in 

in 2015 (9) and 2016 (10) and comments were incorporated in the updated versions. The approved 

<1058> final version was published in January 2017 in the 

 40 (11). The chapter became effective on August 1, 2017. There was an erratum published in February, but the only change was reference of the operational qualification (OQ) testing to the intended use definition (user requirements specification [URS]).

	First let us look at the overall scope of changes between the old and new versions of 

	The following items were omitted from the new version of <1058>:

		Differences between qualification and validation. This was omitted because qualification and validation activities are integrated in the new version, so why describe the differences? You need to control the instrument and any software and if you can demonstrate this through the 4Qs process described in the new <1058>, why bother with what the activity is called? 

		Table I in the old version of <1058> describes the timing, applicability, and activities of each phase of AIQ and it has been dropped from the new version. Rather than give a fixed and rigid approach to AIQ, as the table did, there is more flexibility in the new version of <1058> and omitting this table reinforces the new approach.

		Standalone software: Because standalone software has nothing to do with AIQ, not surprisingly this section has been omitted from the new version. The GAMP 5 (12) and the accompanying good practice guide for laboratory computerized systems (13) or my chromatography data system (CDS) validation book (3) will be adequate for this task.

		Examples of instruments in the three categories: Because the instrument classification depends on the intended use there is no need to give a long list of instruments or systems in Groups A, B, and C. It is the intended use of the instrument that defines the group and providing a list produces anomalies. For example, in the old version of <1058> a dissolution bath is listed in Group C when it should be in Group B if there is only firmware and the instrument is calibrated for use. To avoid these arguments the list of examples has been dropped from the new version.

	Of greater interest to readers will be the changes and additions to the new general chapter, again these can be seen in Table I. Below I will discuss the following three areas that reflect the main changes to the general chapter:

		Changes to DQ, installation qualification (IQ), and OQ phases and how this impacts your approaches to AIQ

<1058> update to the “Roles and Responsibilities” section makes users ultimately responsible for specifying their needs, ensuring that a selected instrument meets them and that data quality and integrity are maintained (11). The manufacturer section now includes suppliers, service agents, and consultants to reflect the real world of instrument qualification. One new responsibility is for the supplier or manufacturer to develop meaningful specifications for users to compare with their needs. Incumbent on both users and suppliers is the need to understand and state, respectively, the conditions under which specifications are measured to ensure that laboratory requirements can be met. We will discuss this further under the 4Qs model in the next section.

	Finally, there is a requirement for a technical agreement between users and suppliers for the support and maintenance of any Group B instrument and Group C system. The agreement may take the form of a contract that both parties need to understand the contents of and the responsibilities of each.

 <1058> uses the same 4Qs model as the 2008 version. Yes . . . but there are some significant differences. Look at Figure 2, which presents the 4Qs model in the form of a V model rather that a linear flow. This figure was also published in a “Questions of Quality” column authored by Paul Smith and myself (14). However, Figure 2 has now been updated to reflect the changes in the new version of 

 <1058>. Look at the green-shaded boxes to see the main changes:

	Design qualification now has two phases associated with it. 

		The first phase is for the users to define the intended use of the instrument in a user requirements specification: Users must define functional and operation specifications and intended use (11). Although the new <1058> notes that this definition is expected to be minimal for commercially available instruments it does not mean slavishly copying supplier specifications-especially if you do not know how any of the parameters have been measured. The output from this process is a URS or your intended use definition.

The new version of United States Pharmacopeia general chapter  “Analytical Instrument Qualification” became effective August 1, 2017. What does this mean for you?

R.D. McDowall

Articles

Are You Ready for the Latest Data Integrity Guidance? Part 2: Computerized Systems, Outsourcing, Quality, and Regulatory Oversight

The Humble Instrument Logbook?

What’s New in the New USP ?

Understanding Data Governance, Part II

What's New with the FDA's Data Integrity Guidance?

Understanding the Layers of a Laboratory Data Integrity Model