R.D. McDowall

	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

Articles

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 second phase is the qualification of the instrument design. This means that you confirm that the selected instrument meets your design specification or intended use. If looking outside of the analytical laboratory, medical device manufacturers call this process 

-ensuring that the users’ current requirements are in the system and any omissions are mitigated, where appropriate.

	These two sections are where most laboratories get it wrong for reasons such as we know what we want (therefore why bother to document it) or we believed the supplier’s literature. This is where most qualifications fail because there is no specification upon which to base the testing in the OQ phase of the process as shown in Figure 2. Executing an OQ without a corresponding URS or design document is planning to fail any qualification. This is one of the major changes in the new version of USP <1058>.

		Note that when the new <1058> talks about minimal specifications for commercial instruments, it does not include minimal specifications for software used to control them for Group C systems. Here you not only need to consider the control of the instrument, but also the acquisition, transformation, storage, and reporting of data and results that includes how data integrity and quality is assured. This activity is not expected to be minimal-especially in today’s regulatory environment.  

		There is also the possibility, for Group B instruments, of merging the laboratory user requirements and the DQ: the decision to purchase being made on the URS (with the proviso that the contents are adequate).

		Risk management is implicit in the <1058> classification of the instrument groups and the subgroups of B and C instruments and systems but more needs to be done in the specification and configuration of the software. For example, access controls, data acquisition, and transformation are key areas for managing data integrity risks.

		What is also shown in Figure 2 is that if there is any change of use during the operation of the instrument or system, it must trigger a review of the current specifications with an update of them, if appropriate.  

	In the new version of <1058>, installation qualification now includes

		The installation of software and the involvement of the IT function to interface an instrument to a network 

		The requirement for conducting an IQ for nonqualified instruments is replaced with a requirement to gather available information and conduct a risk assessment to determine if an IQ should be conducted. In many cases, if an instrument has been installed and maintained by a supplier with records of these activities, but has not been formally qualified, the risk assessment may determine that no IQ should be performed, placing increased emphasis on the OQ phase to demonstrate fitness for intended use. 

		The introduction to <1058> mentions that activities can be merged-for example, IQ and OQ (11). I would see suppliers taking advantage of this option to have a single IQ and OQ document for ease of working, because both phases are typically conducted by the same individual. The combined protocol must be preapproved by the laboratory and then post-execution reviewed by them. However, the post-execution review needs to be conducted while the engineer is still on site so that any corrections can be done before the individual leaves the site.

	Operational qualification has also been extended to include

		A new section on software functions and the differences between software configuration and customization for Group C systems.   

		It is important to configure software (and document the settings) before an OQ is conducted, otherwise you’ll be repeating some tests. In practice, however, there may be a differentiation of duties because a supplier may only perform a basic qualification of the unconfigured software leaving the laboratory to configure the application and then conduct further verification of the whole system. This point is critical because data integrity gaps are usually closed through configuration of the application. However, unless the application is known or a copy is already installed and configured, it is unlikely that the OQ will be performed on a configured version because the laboratory may not know the process to be automated (for example, hybrid operation, electronic operation, or incorporate spreadsheet calculations into the software).

	The major changes to this General Chapter occur in the section on software validation. They are shown diagrammatically in Figure 2. Because the instrument examples have been removed in the new version of <1058> and replaced with the need to determine the group based on intended use, a formal risk assessment now needs to be performed and documented. A risk assessment, based on Figure 3 to classify instruments based on their intended use has been published by Burgess and myself (15) and is based on the updated classification used in the new version of 

<1058> (11). As can be seen from Figure 2, the risk assessment should be conducted at the start of the process in the DQ phase of work because the outcome of the risk assessment can influence the extent of work in the OQ phase.

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

What’s New in the New USP ?

Data integrity requires a multilayered approach that runs throughout a regulated organization. Here we discuss the laboratory level.

	In the first part of this series (1), I spoke about data governance at the corporate level. For the second part, I will focus on the laboratory and discuss the impact of the data governance scheme as it cascades down to the processes and systems at the bench.

	Line management will be responsible for ensuring that the corporate policies and procedures as well as the requirements for an open culture are communicated down the line to the operational staff as outlined in Table II in Part I. My main focus here will be on data ownership and data stewards because the Internation Society of Pharmaceutical Engineering (ISPE) paper only has a single passing reference to data owners (2), but data ownership is mentioned in the Medicines and Healthcare Products Regulatory Agency (MHRA) and World Health Organization (WHO) data integrity guidance documents (3,4).

	How do we get from data governance to data ownership? The WHO data integrity guidance (4) states in Section 4.10, “To ensure that the organization, assimilation, and analysis of data into a format or structure that facilitates evidence-based and reliable decision making, data governance should address data ownership and accountability for data process(es) and risk management of the data life cycle.”

	As we can see, a part of data governance is data ownership and accountability for data processes and associated risk management in any data life cycle. Since we are dealing with spectroscopic analysis, we will focus on computerized systems that control a spectrometer. However, do not forget any manual processes in your laboratories that also need assurance of the integrity of records generated.

	How do we know who are data owners, and what are their responsibilities? The guidance documents are not much help here, so let’s return to the definitions of data governance in Table I from Part I for some assistance. The nonpharmaceutical definitions listed in the right-hand column show that data governance focuses on defining the rules, roles, and responsibilities for acquisition and management of data. In my opinion, data owners should be responsible for these functions because they should know the process that is automated by the spectrometer. However, there are already two roles for a computerized system defined in 

Good Automated Manufacturing Practice (GAMP) 5 

 (6): the process owner and the system owner. These two roles were originally defined in 

		The person ultimately responsible for the business process or processes being managed (5).

		The person responsible for the business process (6).

		The person ultimately responsible for the availability, support, and maintenance of a system, and for the security of the data residing on the system (5).

		The person responsible for the availability and maintenance of a computerized system and for the security of the data residing on that system (6).

	These are the two roles that are defined in the regulations. The split in responsibilities above gives rise to the concept of process owner in the business and system owner in IT. Note that for stand-alone systems, the two sets of responsibilities are merged and the process owner is also the system owner. Hands up for those lucky individuals in this situation!

	How should these regulatory roles fit within a data governance framework? Let’s start with the data owner. The obvious fit is for the process owner to be the data owner as well because data are generated and converted to information in the business. Therefore, we could modify the 

 definition of process owner and encompass data ownership as follows: “The person responsible for the business process including the data generated, transformed, and reported by a manual process or a computerized system.”

	So, who should be a process or data owner? 

 gives some guidance that is self-explanatory (5): “This person is usually the head of the functional unit or department that uses the system, although the role should be based on specific knowledge of the process rather than position in the organization.”

	One potential area of confusion concerns the name “data owner,” which implies that an individual owns the date rather than the organization that owns the system and the data generated by it. That situation is not so-the organization owns the data, and the data owner is merely the custodian of the data in the system who acts on behalf of the organization. Perhaps 

 may be a better title for this individual.

	Other Data Governance Roles at the System Level

	We will look in some more detail within our regulated analytical laboratory at the other roles involved in data ownership. In addition to the data owner, there are two other roles as follows:

 Responsible for enabling the requirements of the data owner for the system. (These people would typically be the power users or system administrators in the laboratory.)

 Responsible for enabling the IT requirements of the data owner and a person or persons who, for a networked system, is the system owner or reports to the system owner. This role is essential for the segregation of duties and to avoid conflicts of interest when administering the system. Note that this role will not be found in a paper-based process because it is only used when a computerized system is involved.

	The responsibilities of each role are listed in Table I and the interactions between these two roles and the data owner are shown in Figure 1. Subject matter experts, some of whom may be either data or technology stewards, are also mentioned in Table I and quality assurance input is only shown in Figure 1 but the responsibilities are many of those presented in Table II from Part I. To map from data governance roles to those currently used in laboratories, I have put titles in brackets in Table I-for example, a data steward is a laboratory administrator.

	Looking at the three main roles above, you will find two of them are not mentioned in any data integrity guidance document: data steward and technology steward. The role of these stewards, and others, can be seen in the book by Plotkin (7). Why is there a need for data and technology stewards? The answer can be found in the discussion of who should be a process owner in 

 (5) and outlined above. Typically, the data owner is the head or a section head of a laboratory, but often the work to be done in administering the system will be devolved to others such as super users or lab administrators and IT support staff if the system is connected to the network. This is the normal business process and these individuals are the data and technology stewards. Furthermore, because the data owner will specify the security, data quality, and data integrity requirements for the system, who better to ensure that they have been implemented than the second-person reviewers, another group of data stewards? You’ll remember my comment earlier in this column about the need to integrate data integrity roles with normal business operations. Here is a very good example of that. Take the normal situation and simply reinforce or overlay the data integrity responsibilities on top.

	It is important to realize that data integrity and data quality begin at the point of data acquisition by the process and not in the computer center. If data acquisition is compromised by poor working practices or by using an uncalibrated instrument, data integrity is compromised or lost from this point forward. Therefore, the data owner’s responsibilities for a regulated computerized system from the business side include

		Defining what is required of a system in terms of data quality, data integrity, and data security. This process will result either in inputs to the configuration specification for the setting of application policies, writing of standard operating procedures (SOPs) for using the system, or the agreement with IT to support the system (for example, backup, user account management, and so on). This step begins from the start of the analytical procedure.

		Assessment of the system to determine if there are vulnerabilities of the records contained therein. Although a system may be validated, record vulnerabilities may exist that have to be managed (8).

		Development of a remediation plan with the data and technology stewards for any remediation to secure the records and reduce or eliminate data vulnerabilities following the assessment.

		Approve access to the system for new users and changes in access privileges for existing ones for IT administrators to implement.

		Approval or rejection of change control requests.

		Approval for archiving data and removing them from the system.

		Receive feedback from the data stewards of the system of issues involving quality, integrity, and security of the spectroscopic data and implement any modifications of procedures for the data stewards to implement.

	The data stewardship concept is defined in the literature as the enabling capability of data governance. Defining different types of stewardship addressing different aspects of the data governance process is also described in the literature (7), but the focus in this column is only on data and technology stewards.

	Because the data owner probably will not have the time or the training to implement the requirements for data integrity and quality that they have mandated, implementation is the role of the data stewards for the system:

		The data stewards, in the form of power users or super users, are the first point of contact for user questions for help with the system.

		The stewards will also be instrumental in ensuring the smooth running of the system with processes such as developing custom reports or custom calculations.

		As expert users of the system, they will be responsible for ensuring that the requirements for data integrity and data quality set by the data owner have been implemented and are working.

		They are also responsible for data queries and monitoring data integrity from a system perspective-for example, they are responsible for a regular review of system-level audit trails for system-related issues rather than data integrity problems or aiding quality assurance data integrity audits.

	In monitoring the system from the business perspective, data stewards can raise issues for discussion with the data owner to resolve as noted earlier in this section.

	Although data stewards are involved with data governance outside of the pharmaceutical industry, we need to see how this role can be overlaid onto the situation in a regulated laboratory. For most systems, either stand-alone or networked, the data owner may not be involved in some of the technical administration of the application such as the generation of spectral libraries, creation of custom reports, and custom calculations or macros. Technical administration is the role of the laboratory administrators. You can see that adding the responsibilities involved for data stewardship in Table I would be a logical step within an overall data governance framework and to integrate governance within the current roles typically used in a laboratory.

	Recall the definition of system owner from 

 as the person who is responsible for the availability and maintenance of a computerized system and for the security of the data residing on that system. This role, in my view, should be performed by the IT department. In particular, the system owner could be the head of the functional IT group responsible for system support. An alternative approach is that the system owner could be in the laboratory or business, but that would only work with larger organizations that have the capacity for the headcount. In smaller organizations, the role of system owner would need to be delegated directly to the IT department under an agreement with the process or data owner.

	For a networked application, technology stewards are members of the IT department who would be responsible for the administration of a networked application, logical security, backup or recovery, and other support functions and carry out the responsibilities outlined in Table I. However, if the spectroscopy system is stand-alone and has few users, then the data owner is also the data steward and the technology steward. Three hats and no pay rise.

	In this data governance framework, it is important that there is a segregation of duties. For example, there needs to be separation of administrator functions for configuration of the application from the normal analytical users of the system. In addition, access to data files in operating system directories, the system clock and the recycle bin needs to be restricted for laboratory users.

	Look around any regulated laboratory and you will see a data integrity disaster in operation. There are your lovely toys-sorry, spectrometers-that are operated by a software operating on a stand-alone workstation. Do you want the good news or the bad news? Good news? OK, there is none! The bad news comes in a variety of forms:

		You, the data owner, are now also the system owner because the computer is not connected to the network-you are now doing user account management, documenting the configuration of the software, and backing up the data, and this is a conflict of interest.

		It is highly likely that you are using the system as a hybrid by generating electronic records and signing paper printouts.

		Most of your electronic records are stored in directories within the operating system that any user can access by going outside of the operating system and deleting files. Moreover, such users can also access the system clock, which may not be checked; they can also access the recycle bin.

	Life is wonderful, if you don’t think about the problems with your software and the electronic records. How do we resolve this situation?

	Defining Data Integrity and Security of a System

	You may remember from Table I in Part I that the focus was on the access to data and hence the records generated, interpreted, and reported by it. Therefore, you as the data or process owner are responsible for assessing the processes and systems for which you are responsible for the vulnerability of the records over the lifetime of the data. This assessment will be coordinated by the corporate data governance steering committee or their local equivalent.

	The aim of this assessment is to identify the vulnerabilities of the records and remediate in two ways:

		Short-term remediation: This process involves quick fixes to ensure that records are protected, such as implementing operating system security to prevent access to the records, the system clock, and the recycle bin. Electronic records with associated metadata should be transferred to the network and be backed up by the IT department. Adding a network card to the workstation should enable the data to be backed up to secure network storage.

		Long-term remediation: This process ensures that the system and the process it automates acquires and manages data to ensure quality, reliability, and integrity of the records. Let’s explore this area briefly now.

	A hybrid system is the worst possible situation because the data owner has to ensure that the electronic records created by the software are linked to the signed paper printouts. Managing and coordinating two disparate media forms over the lifetime of the data is difficult. However, don’t just take my word for it, look at what the WHO data integrity guidance (4) says:

		“Data integrity risks are likely to occur and to be highest when data processes or specific data process steps are . . . hybrid, . . .

		“The use of hybrid systems is discouraged . . .

		“The hybrid approach is likely to be more burdensome than a fully-electronic approach; . . .

Understanding Data Governance, Part II

In April 2016, the United States Food and Drug Administration (FDA) issued a draft guidance for industry called “Data Integrity and Compliance with cGMP (current good manufacturing practice).” What does this mean for a regulated laboratory?

	Data integrity is currently the hottest topic in regulated good practice (GxP) laboratories as readers of this column will know. So far, this year has seen the publication of the final version of the World Health Organization (WHO) guidance on “Good Data and Records Management Practices” (1) as well as a draft from the United States Food and Drug Administration (FDA) guidance for industry entitled “Data Integrity and Compliance with cGMP (current Good Manufacturing Practice)” (2). These publications now join the United Kingdom’s Medicines and Healthcare Products Regulatory Agency (MHRA) data integrity guidance issued in March 2015 (3). As this column was being written, the MHRA issued an update on their data integrity guidance for consultation where the overall scope is expanded to GxP (4). Not to be outdone, the European Medicines Agency (EMA) (5) and Pharmaceutical Inspection Convention/Pharmaceutical Inspection Cooperation Scheme (PIC/S) (6) also issued data integrity guidance in August as this column went to press.

	A veritable cornucopia of data integrity regulatory advice and guidance is upon us! Or perhaps another perspective is a tsunami of advice from the regulators? This abundance of regulatory guidance is shown graphically in Figure 1, and you can see that the FDA has more guidance and advice for data integrity than any other regulatory source:

		Guide to the Inspection of Pharmaceutical Quality Control Laboratories (7)

		Compliance Program Guide (CPG) 7346.832 for Pre-Approval Inspections (PAI) (8) Level 2 guidance on the FDA website (9)

		Draft Guidance for Industry, Data Integrity, and Compliance with cGMP (2)

					Figure 1: Data integrity guidance from regulatory sources.

	Although “Guide to Inspections of QC Labs” (7) is more than 20 years old, it is still worth reading because most laboratories have not changed their working practices greatly in the intervening time since its publication. For example, it includes the statement, “The authority to delete files and override computer systems should be thoroughly examined.”

	For the purposes of this column, we focus our discussion on the FDA guidance document on data integrity although the discussion will also bring up some of the other FDA guidances in Figure 1 as well as some other documents issued by the agency. This column installment is not a comprehensive review of the data integrity guidance (2)-the focus here is on those sections that impact on the regulated good manufacturing practice (GMP) laboratory. The principles discussed here can be extended to any regulated or quality laboratory.

In April 2016, the FDA issued a draft guidance for industry on data integrity and compliance with cGMP. What does this mean for the laboratory?

Author | R.D. McDowall

Articles