R.C. McDowall is the principle of McDowall Consulting and director of R.D. McDowall Limited, and "Questions of Quality" column editor for LCGC Europe, Spectroscopy's sister magazine.

R.D. McDowall

The U.S. Food and Drug Administration (FDA) recently issued an updated version of its Compliance Policy Guide for Pre-Approval Inspections (PAI). If you are not aware of the impact on analytical procedures and data included in regulatory submissions, then please read on.

	One of the U.S. FDA’s Compliance Program Guides (CPG), numbered 7346.832, is entitled Pre-Approval Inspections. This document is used to guide and inform inspectors conducting this type of inspection before granting a license to market an active pharmaceutical ingredient (API) or medicinal product for the U.S. market. The Able Laboratories fraud case in 2005 was a turning point for this document. The Agency had conducted seven PAIs of Able and not found any evidence of falsification. A whistle-blower in the quality-control (QC) laboratories at Able then informed the local FDA field office of the data integrity issues in the company. The following day, a posse of inspectors rode into town and camped at the Able facility looking at electronic data and comparing these records with the printouts that had been the focus of earlier inspections. Their findings are summarized in the 483 observations issued in July 2005 that resulted in the company’s going bankrupt. The Able 483 is still available on the FDA web site (1).

	The FDA realized that their inspection approach of paper review was inadequate, and that inspections had to focus on the electronic records in laboratory computerized systems. As a result, paper records became incidental to the inspection of computerized systems. This required rewriting the existing CPG 7346.832 (yes, there is a “Star Trek” fan working at the FDA!), and the new version was issued in May 2010 and became fully effective in May 2012 (2). This gap allowed time for industry to understand the new inspection approach, as well as time to train inspectors on ways for inspecting electronic records within the various data systems used in regulated GMP laboratories.

	The key changes in the rewritten version were the three inspection objectives (2):

		Objective 1: Readiness for Commercial Manufacturing

		Objective 2: Conformance to the Application

	Reading this list of objectives, one could be forgiven for  assuming that the only data integrity focus was objective 3. However, you would be mistaken; data integrity runs throughout all three objectives. This inspection approach, coupled with how to inspect electronic systems, has been used since 2012, and as a result there have been an increased number of 483 observations and warning letters issued to laboratories concerning data integrity.

Updating CPG 7346.832, Take 2: September 2019

	September 2019 saw the issue of an updated version of CPG 7346.832 that still contains the three objectives, but the reason for the revision is stated on the front of the document as (3):

	Program revised to add instructions for potential official action indicated (pOAI) reporting responsibilities and to align with the Center for Drug Evaluation and Research (CDER) and Office of Regulatory Affairs (ORA) agreement Integration of FDA Facility Evaluation and Inspection Program for Human Drugs: A Concept of Operations.

	On the front of the document, the implementation date is September 16, 2019, with completion by September 16, 2022. Thus, the document is effective now, but I think that inspectors will need training in the additional scope and content, and therefore it will be fully effective later rather than sooner. Before we discuss the new CPG in more detail, we need to understand what a pOAI is. Readers who know the classification of 483 observations can skip the next section.

Understanding a Form 483 Inspectional Observation

	To the uninitiated, let me take a short detour to explain how the Agency classifies non-compliances on an FDA Form 483–Inspectional Observations. The completed Form 483 (typically shortened to a 483) is left with senior management at the close out meeting of an FDA investigation, and it lists the non-compliances found during an inspection. The inspector does not classify them at the closing meeting; classification is undertaken after the inspection, and is subject to Agency review that takes into account each non-compliance, its seriousness, and compliance history of the inspected organization.

	There are three classifications that can be given by the FDA to each 483 observation; these can be found in the exotically titled Field Management Directive 86 (FMD 86) Establishment Inspection Report Conclusions and Decisions (4):

		NAI–No Action Indicated: No objectionable conditions or practices were found during the inspection, or the significance of the documented objectionable conditions found does not justify further FDA action.

		VAI–Voluntary Action Indicated: Objectionable conditions were found and documented, but the District and/or Center is not prepared to take or recommend any of the regulatory actions, because objectionable conditions do not meet the threshold for regulatory action. The district may request a written response from the establishment, but this is not necessary. Any corrective action is left to the establishment to take voluntarily.

		OAI–Official Action Indicated: Objectionable conditions were found and regulatory action should be recommended. Includes inspections resulting in recalls where the district has decided conditions warrant regulatory action.

	You can see the spectrum of potential classifications for each 483 citation. Typically, a classification of OAI results in a warning letter sent to the company and exhibited in all its glory on the FDA website. For a foreign company (outside of the USA) their products may also be placed on import alert; oh, joy of joys. You can now see that is better to be compliant than not. Furthermore, the cost of compliance (the cost of doing it right) is always cheaper than the cost of non-compliance (the cost of getting caught) (5).

	Returning to the reason for the new version of CPG 7346.832 above, you can see that one of the reasons for updating the document is to add instructions for potential official action indicated (pOAI) reporting responsibilities (3). These are instructions to inspectors on how to report serious non-compliances that could result in a warning letter to the organization.

	You may ask why we should discuss this document now, given that it doesn’t become fully effective until September 2022. A good point. However, consider that any analytical development work conducted that is part of a regulatory submission to the FDA comes under this new version of CPG 7346.832 (3), hence such work may be inspected against these more detailed requirements.

	The structure of CPG 7346.832 is shown in Figure 1, and discussed in the following sections of this column. Please note that while in Figure 1 there are areas of reformatting and enhancement, much of the 2010 wording has been retained in the new version. This column looks specifically at the high-level impact on a regulated laboratory, but to gain a full understanding of all of the changes, you will need to read and compare both versions of this document.

	Let us look in more detail at each of the objectives in the new CPG document. Remember that I mentioned that the old version has three objectives with data integrity running through them? Now is your opportunity to see and understand the impact of this new version of the document.

Objective 1: Readiness for Commercial Manufacturing

	Objective 1 in the new version simply states:

	Determine whether the establishment has a quality system that is designed to achieve sufficient control over the facility and commercial manufacturing operations (3).

	You may be thinking from the title that this objective only applies to the manufacturing side, and analytical scientists can relax and put their feet up. Sorry, the new version of CPG 7346.832 retains the five sub-objectives from the old version that focus on the overall Pharmaceutical Quality System (PQS). All of these sub-objectives have impacts on a regulated laboratory, from cleaning validation through sampling to release testing (3):

Manufacturing and laboratory changes, deviations, and trends relating to the development of drug substance and drug product manufacturing have been adequately evaluated.

	There is an inspection focus on the changes, deviations, and trends within the laboratory on the PAI menu. While this is a feature of all inspections now, it is the changes around a new product that will be subject to scrutiny.

A sound and appropriate program for sampling, testing, and evaluating components (including active pharmaceutical ingredients [APIs]), in-process materials, finished products, containers, and closures for purposes of releasing materials or products has been established, including a robust supplier qualification program.

	The laboratory does not escape from this sub-objective; you are in it up to your collective necks. If you outsource any analytical work, then how did you select the facility, how much due diligence was performed, and what do the quality and technical agreements cover? A good overview of the requirements for outsourcing is EU 

Sufficient facility and equipment controls are in place to prevent contamination of and by the application product (or API).

	If your laboratory conducts cleaning validation, guess what? This one’s for you.

Adequate procedures exist for batch release, change control and investigating failures, deviations, complaints, and adverse events, and for reporting this information to FDA.

	How are batches released, and what is the role of laboratory data in this process? Here, the inspector asks whether the procedures for various investigations are adequate rather than investigating deviations for the product itself, which is covered in Objective 1a. Obviously, there will not be any complaints or adverse events, as the product has not been licensed yet; the inspection will focus on determining if the procedures are adequate and meet applicable regulations.

The proposed commercial process and manufacturing batch record, including instructions, processing parameters, and process control measures, are feasible and scientifically and objectively justified. This objective is linked to the firm’s process validation program across the product lifecycle.

	Do your analytical procedures have sufficient detail? Do you collect all records in an analysis? How do you process your analytical data to generate the reportable result? Where are the analytical records stored? What data integrity and good documentation practices are there, and how are staff trained?

	Objective 1 in total is pervasive throughout both the organization and specifically any laboratories involved in method development, validation of analytical procedures, sampling, testing, product release, supplier qualification (contract analytical laboratories), change control, deviations and investigations. And by the way, everything the laboratory does must be scientifically sound, including any investigations for invalidating out of specification (OOS) results.

		Where is the documented evidence that you follow these procedures?

Objective 2: Conformanceto the Application

	Verify that the formulation, manufacturing or processing methods; analytical (or examination) methods; and batch records are consistent with descriptions contained in the CMC section of the application. This may include CMC information relevant to exhibit batches, biobatches, other pivotal clinical batches, and the proposed commercial-scale process (3).

	Unlike the first objective, with a neat and structured list of sub-objectives, the areas for inspection under this objective are presented like a shopping list. Table I lists the pertinent inspection areas for a regulated laboratory together with the inspection focus within each area. Please note that Table I is an edited list; please read the actual document for the full scope of Objective 2. Note that there is a recurring theme in this objective of checks from laboratory data on-site back to the application submitted by the organization.

	Some of you may be confused by the term 

 in Table I; this refers to the manufacturing batch used to make supplies for pivotal clinical studies. It can also be called a 

and is different from commercial batches as the amount synthesized is smaller, and typically there is no predetermined shelf life; rather, the product stability is determined as an ongoing process. As such, it is an inviting inspection target, especially for data integrity.

	Analytical procedures that will be high on a list of targets in a PAI will be those that are unique to the product under inspection rather than pharmacopoeial methods. In particular, have any procedures been modified since the application was submitted?

	One of interesting asides in the new CPG is the concept of factual and contextual data integrity discussed in a footnote at the end of Objective 2. In the context of a PAI, these terms are defined as:

		Information that has factual integrity is original and corresponds directly to that submitted to FDA (for example, a chromatogram showing a peak area that directly calculates to an assay value submitted in a data summary sheet in the application) (3).

		Information that has contextual integrity supports submitted information about the testing or manufacturing area and related products or processes (for example, a chromatographic sequence that shows all the assayed samples and that does not reveal failing assay values).

		Missing records (batch or testing) and unexplained losses of inventory of components used in production may call into question the contextual integrity of the information filed in an application (3).

	Figure 2 shows a hybrid spectrometer system at the bottom that has generated data and records that have been included in an application to the FDA at the top of the page. The journey from the instrument to the application takes two routes; one for factual integrity, and the other for contextual integrity. 

 ensures a match between data and information in the application and the electronic records and associated paper printouts (for hybrid systems) in the data systems of the organizations’s laboratory. In contrast, 

is an assessment that the organization has not been selective or fraudulent in including data in an application. This concept of factual and contextual integrity provides a bridge between Objectives 2 and 3, as data integrity issues identified in the former provide an input to the latter.

	Audit and verify raw data at the facility that are associated with the product. This information can, among other things, help to authenticate the data submitted in the CMC section of the application as relevant, accurate, complete, and reliable for CDER assessment (3).

	Similar to Objective 2 and dissimilar to Objective 1, there is a shopping list of items that have been extracted, edited, and ordered into topic areas below and as shown in Figure 1.

	Audit the accuracy and completeness of data reported by the facility for the product (3):

		Select key data sets from drug development or randomly select data from the application. Generally, data on finished product stability, dissolution, content uniformity, and API impurity are good candidates for this audit.

		Compare raw data-hardcopy or electronic-such as chromatograms, spectrograms, laboratory analyst notebooks, and additional information from the laboratory with summary data filed in application. Raw data files should support a conclusion that the data/information reported by the site are complete and accurate.

		When data discrepancies are observed, identify the firm personnel involved. Determine which actions or inactions contributed to the data integrity problem, and whether corrective actions were or are to be taken.

		Also determine whether data that should have been reported in the application were not reported.

	The new version of the CPG shows some indicators of possible laboratory data integrity problems and I have collated them in Table II. The aim of Objective 3 is to demonstrate the reliability of the data in a submission. However, if data are unreliable, the new CPG version suggests that an inspector can expanding the coverage of the inspection to marketed products under Compliance Program 7356.002 for Drug Manufacturing Inspections (7), or that the FDA invokes the Application Integrity Policy (8). If either of these occur, the laboratory has begun the long and very uncomfortable decent into inspection hell.

	Reading this, you can see that the majority of data generated for a drug submission will come from the research and development (R&D) departments. Not all R&D records may be subject to GMP, which can give some R&D departments an air of the wild west, which only tends to come under control when QA comes calling. However, the tendency of R&D to be outside of GMP needs a note of caution as any records submitted to the FDA in Drug Master Files and New Drug Applications are subject to 21 

	This part applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in agency regulations. This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not specifically identified in agency regulations.

	R&D data included in FDA drug applications must comply with Part 11 requirements regardless, and GMP regulations where applicable. The validation of analytical procedures, any testing of components, APIs, and so forth must have the same regulatory approaches as QC.

	However, there are also key business reasons why R&D and QC should have the same approaches to instrument qualification, computerized system validation and validation of analytical procedures and testing:

Articles

The Food and Drug Administration (FDA) has issued an updated version of its Compliance Policy Guide for Pre-Approval Inspections (PAI). This article will guide you on this policy’s impact on analytical procedures and data included within regulatory submissions.

Do You Understand the FDA’s Updated Approach to Pre-Approval Inspections?

Data Quality and Data Integrity Are the Same, Right? Wrong!

Do the terms data integrity and data quality mean the same? As “maybe” and “yes” are not the correct answers, we will explore the differences between the two terms, and how data integrity is a key part of data quality. 

	
	Data integrity has been the subject of many “Focus on Quality” columns over the past few years (1–5). However, we have never mentioned, let alone discussed, data quality. In many people’s minds, 

 are terms that have equivalent meanings, hence the first part of the title of this month’s column. However, in reading the MHRA (Medicines and Healthcare Products Regulatory Agency, the UK regulator) GXP data integrity guidance, there is an indication from a regulator that the two terms are different (6). Newton and White have discussed the differences between data quality and data integrity in an ISPE blog in 2015 (7), and, in this column, we expand and explore the similarities and differences between the two terms.	

		The MHRA’s 2018 guidance has in the introduction section the following statement in clause 2.7:

		“This guidance primarily addresses data integrity and not data quality since the controls required for integrity do not necessarily guarantee the quality of the data generated (6).”

		Clearly, in the mind of the regulator, there is a difference between data quality and data integrity. But what exactly is it?

		Our data quality versus data integrity story starts toward the end of the last century with ALCOA-not the Aluminium Company of America, but an acronym standing for 

attributable, legible, contemporaneous, original,

. These criteria have has been discussed in several data integrity guidances from the Food and Drug Administration (FDA), MHRA, the World Health Organization (WHO), and the Pharmaceutical Inspection Convention and Pharmaceutical Inspection Co-operation Scheme (PIC/S) (6,8–10). The WHO guidance contains the most detailed discussion of ALCOA criteria in an appendix with a definition of each term, presentation of the expectations for paper and electronic records, plus special risk management factors (9).

		A European Medicines Agency (EMA) publication on electronic source data extended ALCOA to include an additional four terms of 

 (11). The extension of these four additional terms is known as ALCOA plus, or ALCOA+. A recent article in 

 discusses all nine ALCOA+ criteria in more detail (12).

		Reading further through the MHRA guidance, there is clause 3.10, a part of which is presented below, discussing ALCOA and ALCOA+ criteria:

		“….. ALCOA was historically regarded as defining the attributes of data quality that are suitable for regulatory purposes…. [6]”

	This is interesting; ALCOA criteria were originally defined as the attributes of data quality? How did this come about? The ALCOA acronym was invented by an FDA good laboratory practice (GLP) inspector named Stan Wollen, who developed it as an aide memoire to remember the key requirements of data quality. This is outlined in a publication entitled “Data Quality and the Origin of ALCOA” (13), available for download on the web. There is a lot of background information together with Wollen’s interpretation of ALCOA under the US GLP regulations 21 

 58 (14). For our discussion, ALCOA was originally associated with data quality, as noted by the MHRA in its GXP guidance document (6), long before it was stolen by various guidance documents for use as a cornerstone of data integrity.

	Before we go into more detail about the two terms, we need to define them. The definitions for both 

 are taken from the 2018 MHRA GXP Guidance for Data Integrity (6), and are presented in Table I. We will consider and discuss the data integrity definition first, and then spend time looking at data quality. I am not going to discuss the last paragraph in the right-hand column of Table I about sound science and risk management, although those are key inputs to data integrity, but not part of the data integrity and data quality debate in this column.

	What is interesting about the 2018 definition of data integrity is how far it has changed since the first MHRA guidance published in 2015. The earlier definition was:

	“The extent to which all data are complete, consistent and accurate throughout the data lifecycle (15).”

	This definition is a modification of a 1995 FDA definition of data integrity (16). The 2015 definition can be compared with that published in 2018, where the additions are highlighted in bold text:

 to which data are complete, consistent, accurate, 

trustworthy, reliable and that these characteristics of the data are maintained 

	There is the addition of two criteria (trustworthy and reliable), as well as a requirement to maintain all five data integrity characteristics throughout the data life cycle.

	What is not stated in this definition, but in the explanation for raw data, is that dynamic data must be maintained in this format throughout the data life cycle. We shall return to this regulatory expectation, and the total inability of industry and suppliers to meet it, in a future “Focus on Quality” column.

As discussed above and in Table I, we have additional criteria listed in the MHRA definition: complete, consistent, trustworthy, and reliable, in addition to the five original ALCOA criteria (6). Two are ALCOA+ criteria that will be discussed below, plus two new requirements. ALCOA+ on steroids perhaps? Let us look at these four criteria, which to make matters worse are not defined in the guidance document:

 This is one of the ALCOA+ criteria, and is also an FDA 

 regulatory requirement in 21 CFR 211.194(a) where 

 are mentioned (17). Put simply, every item of data and metadata collected during an analysis from sampling to generation of the reportable result is covered under “complete,” including (but not limited to) any instrument log entries, documentation of mistakes, investigations, deviations, and instrument and calibration failures. Of course, you won’t be allowing any laboratory user deletion privileges, will you?

 Another of the ALCOA+ criteria that requires that the data be consistent with the processes being followed, and that the time and date stamps reflect the creation, modification, and audit trail entries are as expected. The process (manual or automatic, hybrid or electronic) should ensure that the acquisition, transformation, or calculation of data is transparent and traceable.

This is a new data integrity requirement that, together with “reliable,” harks back to the last century and the requirements outlined in 21 

 11 for electronic records and electronic signatures (18). In essence, can you trust the data or records? In some respects, it is the reverse of the ALCOA criteria. For example, if a record is attributed to an individual (ALCOA requirement), did that person actually do the work? Was the person in the laboratory at the time the work was performed, or did somebody act on their behalf?

 Another new data integrity requirement that means that all records and data are suitable and can be depended upon. Where a true copy has been made of an original record, is the verification process acceptable? The record set is not the 

th iteration of testing to pass and that work has actually been performed as required under EU GMP Chapter 1.8 and 1.9 for in process and quality control testing, respectively (19)?

	The addition of trustworthy and reliable to the ALCOA+ criteria are good. So, what does this mean for data integrity as a whole?

	Data integrity provides assurance that the analytical work in the laboratory from the sampling to the calculation of the reportable result has been carried out correctly. In short, can you trust and rely on the analysis and the reportable results? If you cannot trust the analysis and the data, then you cannot make a quality decision based on poor, incomplete, or falsified data.

	It is the role of the analytical scientist and the second-person reviewer to ensure data integrity, but that also requires that the instruments, computer systems, analytical procedures, and laboratory environment are set up correctly, and that the organization within which they work ensures that they are not pressured to cut corners or falsify data.

	Therefore, ensuring the integrity of data is a major contributor to data quality. But, in focusing on data integrity, we must not lose sight of data quality.

in Table I that there are three main elements: Data produced is exactly what was intended to be produced       It is fit for its intended purpose

	Hmmmm, what do these mean in practice? Let us look at item 1, that data produced is exactly what was intended to be produced. The problem with this is the wording of the definition. Although a laboratory produces mountains of data, we abstract and use the information within them to make decisions. For a detailed discussion of this process together with the controlled and uncontrolled parameters, see the article by McDowall and Burgess (20). Therefore, the purpose of a laboratory is to generate information from the analysis of samples in order to make decisions. These decisions could be to aid product development or release a batch of product.

	To do this requires trained staff, qualified analytical instrumentation, validated software, and analytical procedures verified or validated under actual conditions of use, as required by 21 

 211.194(a)(2) (17). This is the same as the first three levels of the data integrity model discussed in earlier articles (21–23). Where the second item comes in is that the output of the analytical procedure must be fit for use. As a simple example, there is no point calculating results of an analysis to three significant figures if all that was required was the presence or absence of the analyte.

	Once you have ensured the integrity of data, we must consider data quality. In part, this focuses on the laboratory’s ability to deliver the results to the sample submitter and meet their requirements for the analysis such as:

		Precision and accuracy or measurement uncertainty of the result

		Supporting information for the analysis

		Speed of analysis (for example, for releasing a production batch or turnaround of analysis from a clinical trial)

	However, there is a compromise with data quality that is best illustrated by the data quality triangle.

There is a problem with the definitions of 

 that is not mentioned by the MHRA and the American Health Information Management Association (AHIMA); this is the data quality triangle, as shown in Figure 1. At each end of the triangle are the following attributes:

		Cost: cost in instrumental and human resources

		Quality: delivering data of acceptable quality to the end user of the information to make a decision.

	The problem is that you can only select two of the three at any one time. For example, if you want a fixed time and high quality, how much are you willing to pay or how much resource will you commit? Equally, if you want analysis performed quickly and at low cost, quality suffers. The quality triangle is applicable to any laboratory in any industry, but in a regulated laboratory you still must ensure data integrity as well. The influence of senior and laboratory management on managing the three criteria of the data quality triangle will directly impact both data quality and data integrity.

Integrity and Quality Use the Same Data Set

	It is imperative to realize, as mentioned earlier, that the data set for ensuring data quality and data integrity is the same, and not two different ones. Furthermore, data integrity is not ensured first and followed by a second pass to ensure data quality. To ensure data quality and data integrity, both must occur in parallel, simultaneously and on the same dataset.

	Because the two terms are different, as Newton and White (7) point out, you can have data integrity without data quality, and vice versa. A laboratory can have excellent data integrity, but if the analytical information to make a decision is delivered late, or not at all, then the data quality is useless. Alternatively, if each laboratory is permitted to create its local practices for data management, you can have integrity without quality (or, at least, very low levels of quality). All the data are there, but consolidating them requires a standardization project: good integrity, lousy quality. That is the one place where quality and integrity do differ, and where the regulations are weak (Newton, personal communication).

	Newton and White (7) present a case where an organization outsources analytical work to contract laboratories, but there is little oversight of the work, resulting in data integrity lapses. When the results are received by the organization, entry to the LIMS controlled and delivery of the results to the decision makers is rapid, and with good data quality.

	The similarities and differences between data quality and data integrity are shown in Figure 2. The similarities are:

		Application of ALCOA and ALCOA+ criteria to the record set

		The differences between the two terms are trusting the data versus making a decision using the results.

	The problem and potential conflict comes with the third element of the MHRA definition for data quality that states that data quality includes ALCOA. This is consistent with Wollen’s original view when devising the acronym ALCOA (13). However, when we see the MHRA definition of 

 in Table I, each ALCOA criterion is spelled out in the definition. Puzzled?

	Is ALCOA an integral part of data integrity, which in turn is a component of data quality, or is ALCOA applicable to both terms, as noted in the MHRA definition?

	Look at it from the perspective of the data and records being generated. Can you separate the data for data quality from data integrity? The answer is no, because the record set for both data integrity and data quality will be the same. Therefore, ALCOA criteria apply equally to data quality and data integrity. Think it through; otherwise you could have some data where all actions were attributable for data integrity, but not for data quality.

	Figure 2 shows the relationship diagrammatically; in the middle is the analysis workflow from sampling to a decision based on the reportable result from the analysis. Throughout this process, data and records are generated that comprise the complete data from the analysis. This record set is impacted by the ALCOA criteria (as well as the four additional requirements) for data integrity mentioned in the MHRA definition in Table I and the ALCOA criteria for data quality.

Data integrity has been the subject of many “Focus on Quality” columns over the past few years (1–5). However, we have never mentioned, let alone discussed, data quality. 

Analysis of 47 FDA Form 483 observations and warning letters for infrared spectrometers reveals a spectrum of data integrity problems and a lack of laboratory procedures for the technique. Is this your laboratory? 

	Since the Able Laboratories data falsification case in 2005 (1), there has been a regulatory focus on the lack of data integrity with chromatography data systems. This scrutiny has focused on inappropriate access privileges with conflicts of interest, deletion of data files, failure to configure the application, testing into compliance, and failure to review audit trail entries (2). More recently, inspection focus has moved to the use of peak integration to integrate into compliance and masking potential impurities (3). There have been many warning letters as a result of these noncompliances and poor data management practices; this is due to chromatography being a major technique that can comprise between 40–70% of a laboratory's workload. You may ask, "Why the focus on chromatography in a publication on spectroscopy?" Just think of chromatography as sample preparation for spectroscopy!

	In contrast, there are relatively few FDA warning letters involving spectroscopic techniques. An analysis of FDA warning letters citing infrared spectrometers was published in 2014 (4).

	Originally, we were going to write a column looking at some of the data integrity issues that could occur with Fourier transform infrared spectroscopy (FT-IR) analysis, with a few regulatory citations to illustrate each point. However, given the bonanza of Form 483 observations and warning letters that have been issued by the FDA, we realized that an analysis of these would provide a great overview of the current regulatory problems facing the technique, before discussing specific topics in the future.

	In this column, we present an analysis of 47 Form 483 observations and warning letters issued between 2012 and 2018 (5–51). It should be noted that many of these Form 483 observations are not generally available publicly. Therefore, these observations, the regulatory focus on infrared, and the conclusions we have drawn may be new to laboratories that only review FDA warning letters. We have taken each citation or observation and broken it down into one or more data integrity areas; therefore, a single observation can have one or more data integrity noncompliances. For example:

		The application does not have an audit trail. This is a single 483 observation and a single data integrity issue.

		In contrast, here is a more complex citation: System audit trails are not available on the two FT-IR instruments, and quality control (QC) operators have the option of not saving the IR data. This citation will be classified into two entries; one of no audit trail, and another of application software design because data are not automatically saved. This is a simple example of compound data integrity problems, but some citations can be far more detailed and complex.

	Therefore, there is not a one-to-one correlation between all non-compliances analyzed and the data classification presented here.

	The noncompliances have resulted in a total of 104 separate citations for IR analysis that have been classified and discussed below. Some of these are self-explanatory, and will not be discussed in part due to space considerations and because the solution is obvious (such as no software validation, for example). In the references, we have included the FDA Facility Establishment Identifier (FEI), which is the way the FDA identifies a specific site in a company. Where there are different FEI numbers for the same organization, this means that two sites or facilities were inspected.

	Our main challenge in this analysis is to interpret a regulatory citation, because we don't know all the circumstances at the time of the observation by an inspector. For example, we don't know the functionality of the application software, so the observation of no system audit trails available as shown above could be a true software design limitation, or, more likely, it could be that the users did not enable this function. We have used our experience and best judgement in classifying each citation in this analysis.

	We do not claim that this noncompliance review reflects the total number of 483 observations issued, but, based on the significant number, it is reasonably comprehensive to draw firm conclusions on regulatory gaps involving IR analysis. Enjoy reading about the calamities of others. If any noncompliance mentioned here applies to your laboratory, what are you going to do? We suggest that you remediate the problem before you are included in a future update of this article!

Citations Before the Operational Use of the Instrument 

	One of the surprises of our analysis is that 42% of the 483 citations occur before the instrument and the associated software application are supposed to become operational. You may doubt this statement, but look at both Table I and Figure 1 and you will see two main areas: inadequate software architecture, and design and failure to qualify, calibrate, or validate the system. The interpretation of these nonconformance data is based on the wording of the 483 observations.

	The biggest area, at 37% of the total noncompliances, appears to be due to inadequate architecture and design of the application software that has been purchased by the regulated laboratories. The main problems with the application software are that, as implemented, there are inadequate controls for ensuring data integrity, no audit trail, and the architecture where data files are stored in directories within the operating system and users can delete data without any record in the data system. Again, this is based on the wording inspectors included in each Form 483 report, which represents a high level conclusive summary of the inspection findings, and not a detailed analysis of the root cause associated with each observation. In particular, this represents the inspector's interpretation of what was found about how software was implemented, and not the full compliance capabilities of each software package. In line with FDA warning letters, in many instances, the manufacturer and name of the software was included in many of the examples we reviewed, but we have redacted these in this column.


	Figure 1: Infrared spectroscopy Form 483 citations occurring before operational use of the instrument and software.

	Some of the citations for poor software design are:

		The UV and FT-IR analytical instruments are both equipped with commercial software that does not prevent accidental or intentional deletion of files containing data.

		QC operators have the option of not saving the IR spectra.

		With the FT-IR instrument (QC/FT-IR/201), it was noted that the redacted software had an option to enable or disable automatic saving of measurement available to the chemist.

		FT-IR spectrophotometers used in identity testing were observed to have a "delete" option available to the user.

		The lack of an audit trail was one of the largest number of citations; there was no audit trail in 16 out of 104, or 15%, of all citations.

	The use of directories in the operating system for data storage where a user can delete spectral files without any record in the application software (assuming there is a function capable of this) gave rise to 17 citations out of 104, or 16%.

		There were no controls to prevent deletion of data and deleted FT-IR data was observed in the computer recycle bin.

		Data can be deleted off the FT-IR used in the testing of active pharmaceutical ingredient (API). The data can be deleted off the computer systems hard drive, outside of the system software, and therefore not captured by the systems audit trail.

		Laboratory personnel can change and save changes to the date and time setting in the Windows operating system.

	The first problem is that regulated laboratories are purchasing IR application software that appears not to have any or inadequate data integrity controls. For example, all data should be saved, and there must be an audit trail built into the system which, once implemented, cannot be turned off. However, suppliers are market driven, and if users don't ask for these features, or help into how to implement them, then they won't be delivered. The responsibility of the supplier to help customers implement a compliant solution is becoming increasingly important. There is also the overall market that a supplier is developing its software for both regulated and unregulated industry sectors. What should occur is that suppliers should be selling configurable software, and also providing assistance in the form of white papers informing users how to configure the software or providing professional services to help implement compliant solutions. The second issue is the overall architecture of the system: Almost all IR software is designed for standalone operation, or can be implemented as a standalone system. Many standalone systems involve files storage in directories in an operating system, and not a database. If the software is designed to support networked implementation, using database storage on a secure network server, this should be implemented. This would remove many of the limitations of standalone systems, such as backup, as this would be performed by the IT department.

	Part of the problem is that many software applications require a range of expertise to implement compliant solutions, so that an expert in the analytical technique, someone with a detailed understanding of the software capabilities and strong IT and Part 11 knowledge, is required. From the number of Form 483 observations, it is clear that this multidisciplinary collaboration has not occurred.

What are Performance Qualification Tests for IR Instruments?

	The second area for noncompliance before operational use of the instrument (6%) is due to failure to qualify or calibrate the instrument or validate the software. This is a fairly straightforward area, and we were not going to discuss this, with the exception of two citations about the performance qualification of an IR instrument, one of which is:

	No Performance Qualification (PQ) is required before use to ensure the performance of the <redacted> FT-IR; only the . . . operation qualification is performed. In addition, the SOP # <redacted> does not require such a test.

(USP) general chapter <1058> on Analytical Instrument Qualification (AIQ) was recently updated (52), and contains new requirements compared with the 2008 version. The key issues are that:

		Users must write a user requirements specification (URS) that contains the operating parameters for the IR spectrometer and the instrument software.

		These parameters are verified in the Operational Qualification (OQ).

		Performance Qualification (PQ) needs tests that either directly or indirectly confirm that the instrument continues to operate in compliance with the operating parameters in the URS (52).

	The difference between an instrument OQ and PQ is typically the area of greatest discussion when considering analytical instrument qualification. It is important to first understand that, because an OQ and PQ test different attributes of instrument performance, both are required.

	Uniquely for FT-IR, the subject of calibration also needs to be considered because of confusion that can arise around interpretation of this word. First, in simple terms, the instrument performance attributes that are associated with an OQ and PQ are:

		OQ: Documents how the instrument satisfies user requirements before operational release and at regular intervals, typically after an annual preventative maintenance service.

		PQ: Demonstrates the instrument continues to work under actual conditions of use as documented in the user requirements specification.

	The reader must consider what these terms mean for an FT-IR instrument, and be able to defend this interpretation during regulatory inspections.

	For an FT-IR instrument, apart from replacing the internal desiccant that removes water vapor from sealed instrument enclosure, there are typically no user serviceable components. Therefore, it would be more appropriate to label regular testing of instrument as performance verification checks for wavelength accuracy, resolution, and signal-to-noise, rather than calibration. However, for an FDA inspector, calibration is most likely to be the name used for instrument performance checks, because this is specified in the Good Manufacturing Practice regulations in 21 

	Tests performed on analytical instruments during qualification typically fall under the following categories:

		metrology-based tests (not needed for an FT-IR instrument, unless temperature controlled)

	We will return to this topic in a later "Focus on Quality" column, where we will address OQ and PQ requirements for FT-IR in more detail.

	The main citations for IR systems found by FDA inspectors during the operational phase are listed in Table II, and shown diagrammatically in Figure 2. In general, these citations mirror those found with chromatography data systems (CDS) such as:


	Figure 2: Infrared spectroscopy Form 483 observations as found by FDA inspectors during operational work. 

		Poor Security and Access Control: This is the biggest problem with issues identified such as no security, all users have the same identity, and password thus making attribution of action impossible and conflicts of interest where all laboratory users have administrator rights. Some people will never learn! This is especially true when these citations against CDS have been made for the past 10–15 years. What is interesting in this case is that some laboratories have been cited because management had administrator access, confirming a requirement for application administration to be independent of the laboratory.

		Data Falsification/Testing into Compliance: This is another classic area for citations that is not limited to CDS, and are also found with IR systems. Citations here include data deletion, and retesting until a passing result is obtained. Some people never learn.

		No Audit Trail Review: Even when you have an audit trail in the application, it is ether turned off or if it is turned on the entries are not reviewed. There is even one citation where the audit trail is stored on a secure network, but the laboratory and QA staff cannot access it!

		Failure to Backup Data: This is a major problem when a laboratory is left to backup its own GMP records, and fails to do so. It is always better to get the IT department to back the data up on secure network drives.

	In addition, there are the following gems of noncompliance:

		Work Not Scientifically Sound: A variety of novel and unscientific approaches to charm FDA inspectors, such as use of IR analysis for cleaning validation where lack of sensitivity to detect an analyte was the issue (for example, using an identification algorithm to compare spectra of cleaning wash samples with pure solvents). On the bright side, every cleaning validation passes.

		Inadequate Instrument Log Book Entries: The instrument log book was featured in an earlier "Focus on Quality" column (54); here there were five citations for inadequate log book entries, including the failure of a second person to review them.

		Lack of Procedures: Another evergreen classic of noncompliance. No procedure or work instruction available, and naturally no training records, either-two citations for one noncompliance! Come on, how easy do you want to make it for an auditor or inspector?

		Failure to Maintain Complete Data: Although closely associated with data falsification, the writing of the citations indicate that this is due to a laboratory error, such as losing rather than deleting electronic records. Also, there are signed paper printouts, but no accompanying electronic records-oops!

		Raw Data Defined as Paper: One of the main data integrity messages is that paper cannot be raw data when a computerized system is involved (55); unsurprisingly, this message has not got through to some laboratories, who then receive a 483 observation.

		Inadequate OOS Investigations: Invalidated OOS results are a key quality metric that the FDA have selected for GMP laboratories as part of their quality metrics program (56), and it is the lack of root cause analysis or finding a scientifically sound assignable cause for invalidating an OOS result that gains an inspector's attention.

	Some of the factors that contributed to the observations reported in this article are:

Analysis of FDA Form 483 observations and warning letters for infrared spectrometers reveals a range of data integrity problems and a lack of laboratory procedures for the technique. Is your laboratory in the same situation?

Analysis of FDA Infrared 483 Citations: Have You a Data Integrity Problem?

If a laboratory does not have the workload, spectrometer, or the resources for a spectroscopic analysis, then contract analysis is the way to go. But is outsourcing a universal panacea in the current data integrity-centric world? Are you feeling lucky?

	The topic of this month's column is outsourcing analytical work to a third party, typically a contract organization such as a Contract Research Organization (CRO). It can also encompass outsourcing the whole analytical workload to a bioanalytical laboratory (non-clinical and clinical development studies) or quality control laboratory (when the whole manufacturing process is outsourced to a Contract Manufacturing Organization [CMO]). Managing contract analysis was one of my roles when I had a real job working in the pharmaceutical industry, rather than as a consultant to this industry. Outsourcing work sounds great. You send off the samples, put your feet up, relax, and wait for the report to come back, but let's look at the reality. All organizations outsource analytical work, so we can't be wrong? Right? Well, let's see....

	There may be several reasons for outsourcing analytical work to a CRO:

		Lack of capacity or expertise in your laboratory

		Insufficient workload to justify purchase of a specific instrument

		Company policy when a development project reaches a particular phase

		Your organization is virtual, and therefore all work is performed by third parties

In the current data-integrity–centric world, is outsourcing your spectroscopy work a good idea? To answer this question, one must consider several factors.

Author | R.D. McDowall

Articles

Do You Understand the FDA’s Updated Approach to Pre-Approval Inspections?

Data Quality and Data Integrity Are the Same, Right? Wrong!

Analysis of FDA Infrared 483 Citations: Have You a Data Integrity Problem?

Outsourcing Spectroscopic Analysis?