Level-4 Instrument Control - Why It's Relevant for Part 11

During the requirements analysis phase of analytical data systems used in regulated environments, one question is frequently posed: Does Part 11 require "compliant instrument control" functions in an analytical data system?

Actually, it is not the right way of asking the question in the first place. FDA has a broad charter to protect consumer safety and public health. Let us therefore take a look at the general principles of 21 CFR Part 11¹ and discuss what they mean for instrument control.

• FDA is applying risk-based principles to decide where to focus its effort. In the context of drug development and production, "risk" means potential problems for the safety and effectiveness of drugs.
• FDA expects regulated firms to use a risk-based approach when implementing their business practices, especially regulated activities.
• When scrutinizing a company's business processes and practices, FDA will inspect and enforce the requirements from predicate rules such as cGMP, GLP, GCP, and other relevant regulations, as illustrated by recent cGMP warning letters issued by FDA.
• Regarding Part 11 requirements, the agency will look at the relevant requirements from predicate rules and a firm's business practices to decide whether Part 11 requirements apply or not. The new guidance² makes it clear that FDA may take your business practices into account. Therefore, it is important to determine and document in advance whether the electronic record or the paper record will be used to perform regulated activities.
• The spirit and intent of 21 CFR Part 11 is to ensure trustworthy and reliable electronic records. It defines the ground rules for using electronic records instead of traditional paper records. Electronic records can only be trustworthy and reliable if they are managed in an environment and with technical controls that minimize risks to data integrity and maximize the probability of detecting data integrity problems.

What does this mean for instrument control functions in analytical data systems? Let us respond with another question: How can an analytical laboratory prove that a given result was generated according to the defined procedure without proper documentation of the instrument control parameters used during the analysis? How can the analytical laboratory ascertain the validity of the result without evidence that the instrument was really doing what the analyst thought it would do and that the instrument was within the specifications required for the analysis?

Without generating, storing, and managing the metadata, the trustworthiness and reliability of electronic records in an analytical data system are questionable. Instrument control, associated diagnostics, instrument events, alerts, logbooks, and other "sanity checks" are part of that metadata. In a way, this is similar to the voice recordings and other data stored in the famous "black box" of an aircraft, although it is collected for a different purpose. Without the black box, there would be hardly any raw data or metadata available to investigate an aircraft accident and learn how to prevent a similar disaster in the future.

Levels of Instrument Control

Table 1: Levels of Instrument ControlControl of devices and instruments can be implemented at varying levels of sophistication and complexity (see Table 2). When we first published our discussion of instrument control in the context of Part 11 compliance in

BioPharm

magazine in 2000,

³

most analytical laboratories operated a diverse installed base of instruments, often from a variety of manufacturers. In many cases, the data systems used at the time for the evaluation of the analytical measurements did not have any direct instrument control capabilities and data was recorded through an analog-digital converter. This we defined as level-1 instrument control. This approach is frequently used to integrate an instrument into a system from a different manufacturer. With level-1 control, analysts are forced to set parameters using the instrument's own panel or keyboard, as the control software cannot manage these setpoints. In such cases, it is typically impossible to obtain a printout of the instrument settings that are used during an analysis, so analysts are forced to document instrument parameters manually. Level-1 control also lacks mechanisms for documenting and detecting mismatches of injections with sample identification and vial numbers, which requires supporting binary-coded decimal (BCD) or direct barcode input (from an autosampler).

Since the original publication, the landscape has changed somewhat. We have observed a trend to replace level-1 systems with systems that implement full instrument control. Awareness of the value of electronic raw data has significantly increased since then. Throughout industry, strip-chart recorders and integrators generally have been replaced with computerized systems.

Table 2: Characteristics of networked instrumentsMany systems implement at least a rudimentary level of instrument control. Level-2 control supports the basic parameters of an instrument, such as solvent composition, flow, oven temperature, or detector wavelength. Level-2 implementations are typically not developed by the manufacturer of the instrument, but by third-party software developers. Oftentimes, the software developers do not have the official documentation of the instrument's communication protocol and instead use reverse-engineering, user experience, protocol analyzers, and snippets of unofficial memos. Obviously, instrument manufacturers cannot guarantee these so-called "solutions" developed by third parties without the official control codes. Therefore, firms using such systems should anticipate additional effort will be necessary to qualify and validate such systems. Since the manufacturer of the original instrument may be neither aware nor responsible for the implementation of the communication protocols, instrument firmware updates may result in non-functional communication between instruments and the data system. Level-2 instrument control can work. However, the implementation is not based on the documented properties of the instrument, so if it works, you don't really know why. Furthermore, the implementation of error handling and logging is typically weak for systems in this category. When selecting a system that is supposed to control instruments from other manufacturers, verify that the control codes were officially obtained from the instrument manufacturer to avoid significant additional qualification effort.

In most cases, manufacturers implement full instrument control (level 3) for their own systems. Provided the supplier has sufficient compliance experience, you can expect these systems to maintain complete sets of raw data and metadata along with the proper documentation. In this category, one also can expect quite sophisticated error reporting and handling, which makes it easier to verify that an analysis was indeed completed without technical failures or to diagnose an error if it occurred. Despite the lack of standard communication protocols to date, some systems offer "generic instrument control" capability. This allows integration of instruments using XML-based vendor specific instrument adapters (VSIA) through a de-facto standard serial interface (RS232) and data acquisition through an appropriate interface. This approach can be used for full control of any instruments with an RS232 control interface and analog data output.⁴

Some manufacturers have implemented an additional level of instrument capabilities that can be controlled from within the data system. These functions are the basis for the execution of detailed and sophisticated instrument diagnostics as well as other service functions. This includes provisions for preventive maintenance, remote diagnostics, and early maintenance feedback (EMF), a technique initially used in the aeronautics industry (to alert technical personnel to perform maintenance jobs proactively before failure). Systems implemented at this level provide sophisticated support for tracking device serial numbers, firmware revisions, EMF alerts, tagging of device components, service history, and diagnostics. This information is not only handy and important for inventory tracking of validated equipment, but it also conforms to the device check controls required by Part 11.

Level-4 instrument control implementations are based on bidirectional, handshake-based communication between the controller and the instrument. This means that the recipient of a data record actively acknowledges receipt of the record by notifying the sender, preventing loss of communication and "misunderstandings" between devices.

Networked Instrument Communication

TCP/IP is a widely used, standard networking protocol that enables devices to exchange information. The key to TCP/IP is the breaking of information into "packets" that are structured to allow error detection and correction (by using redundancy mechanisms such as checksums). This technique guarantees error-free data transport and represents an excellent basis for the implementation of the "device checks" and "system checks" mandated by 21 CFR Part 11. Communication in a TCP/IP environment is, by definition, highly dynamic. Addition or removal of idle devices in the network does not affect ongoing communication between the other devices. Figure 1 illustrates a typical configuration of networked instruments in a distributed, client/server environment.

Requirements for the qualification of computer network infrastructure are discussed in the "Qualifying Network Infrastructure" article in this series.

Conclusion

Figure1: Typical topology for a networked data systemElectronic records generated by an instrument are only reliable and trustworthy if the communication between instrument and the system controller is reliable and trustworthy. Level-4 instrument control uses advanced mechanisms for automatic tracking of instrument identification and configuration, and it is a prerequisite for the implementation of additional failure warning mechanisms such as EMF. Level-4 instrument control is a relevant and important measure to obtain trustworthy and reliable electronic raw data, metadata, and results that must be kept according to predicate rules such as GLP or cGMP and which are consequently subject to 21 CFR Part 11. Level-4 mechanisms implement operational system checks and device checks that are required according to Part 11 and reinforced by the Part 11 guidance released in August 2003.

Recommendations

1.Assess the level of control of instrumentation used in the laboratory.

2. Assess whether the data generated by the instrument is subject to a predicate rule.

3. Assess the risk of non-compliance for this instrument and document your risk assessment.

4.If instrument communication uses proprietary interfaces, check for adherence to your internal IT support guidelines.

5. For instrumentation not directly controlled by the data system (level 1), plan the procedures necessary to document instrument parameters.

6.For instrumentation claimed to be controlled, determine whether the instrument manufacturer officially supports the implementation. Some data system suppliers only implement instrument drivers under a mutual disclosure and support agreement with the original instrument manufacturer.

7. If the instrument manufacturer does not officially support the implementation of the control software, plan additional qualification and acceptance tests to obtain a high degree of assurance that control and communication are accurate and reliable.

8. Adapt internal procedures to take advantage of the additional diagnostics and maintenance, identification, and configuration information available in level-4 systems. Electronic records generated by an instrument are only reliable and trustworthy if the communication between instrument and the system controller is reliable and trustworthy. Level 4 instrument control is an adequate mechanism to ensure this.

9. Define test cases for boundary conditions. For example:

• Does the system reliably synchronize all devices required for an analysis?
• Could a device’s failure to start go unnoticed due to a contact closure problem?
• If the instrument has a local user interface, is it “locked” while data are being acquired by the computer? Alternatively, does it track parameter changes performed at the local interface while data are being acquired by the computer?
• Does the system quickly detect power failures of a connected device or are data lost until a time-out situation occurs?

References

1. FDA. Code of Federal Regulations, Title 21, Part 11; electronic records; electronic signatures; final rule.

Federal Register

1997; 62(54):13429-13466.

2. FDA. Guidance for industry: Part 11, electronic records; electronic signatures — scope and application. (draft February 2003, final version August 2003). Available at URL: www.fda.gov/cder/guidance/5667fnl.pdf.

3. Huber L, Winter W. Implementing 21 CFR Part 11 — electronic signatures and records in analytical laboratories, part 5 — the importance of instrument control and data acquisition. BioPharm 2000; 13(9).

4. Agilent Technologies. Generic instrument control. Cerity Networked Data System for Pharmaceutical QA/QC Handbook. Palo Alto (CA): Agilent; 2003.

5. Dickinson I, Eichberger H, Messaros D, Walter HD, inventors; Hewlett-Packard, assignee. User interface for a remote diagnostic device. US Patent 5588109. 1996 Dec 24.

6. Giuffre B, Winter W. New Part 11 guidance,network monitoring, network qualification. Proceedings of Agilent Technologies E-Seminar; 2003 Oct. Available at URL: www.agilent.com/chem/eseminars-compliance.