parameters have to be treated as the rest ofthe metadata are treated. (See the “Learning21 CFR Part 11 Language” box for words in italics.)

Level 1. Instrument control can beimplemented at differing levels ofsophistication and complexity (Table 1).Often, instrument parameters are setmanually using the instrument’s own paneland keyboard, with the signal recorded by ananalog–digital converter (level 1). This isfrequently the approach chosen to integratean instrument into a system from a differentmanufacturer. In such cases, it is oftenimpossible to obtain a printout of theinstrument set points used during ananalysis. Analysts are forced to documentinstrument parameters manually.Furthermore, analog–digital converters donot always support binary coded decimal(BCD) or bar code input from anautosampler, which could be used topositively correlate an injection with a givensample using the sample name or vialnumber. In agreement with other authors, weview BCD communication with anautosampler as essential to ensuring samplecontinuity (6).

Level 2. Many systems implement arudimentary level of instrument controlobtained through reverse engineering:recreating the design of the communicationprotocols for another manufacturer’sinstrument by analyzing the final product(level 2). This method supports the basicparameters of an instrument (such as solventcomposition, flow, oven temperature, ordetector wavelength). If the control codes arenot officially disclosed by the particularinstrument manufacturer, it may be moredifficult to obtain an officially supportedsolution. Also, additional effort should beplanned for performing qualification andother validation tasks on such a system.Because the manufacturer of the originalinstrument may neither be aware of norresponsible for the implementation of thecommunication, instrument firmwareupdates may result in nonfunctionalcommunication with the data system. Errorhandling and logging are typically weak atthis level. When selecting a system that willcontrol instruments from othermanufacturers, it is therefore important toverify that the control codes are officiallyobtained from the manufacturer of theinstrument and not from reverse-engineering.

he first four parts of this series gavean overview of the requirements ofthe FDA rule (21 CFR Part 11) onelectronic signatures and records (1).

We focused on data security, data integrity,long-term archiving, and ready retrieval ofdata (2–5). We demonstrated how access tothe system and critical functions could belimited to authorized personnel. We alsodemonstrated how the integrity of data canbe assured at the time of data analysis andevaluation and how creation, modification,and deletion of records are logged in acomputer-generated audit trail. And we

showed the best method for archiving dataand accurately retrieving it after severalyears.

In those first four articles, we focused oncompliance of data generated by the system.Frequently, the question comes up whethercomputers that just control analyticalinstruments — those that do not acquire data— must comply with Part 11. The answer issimply, “Yes, if FDA has ever looked at orasked for paper printouts of the parameters.”Without proper documentation of theinstrument control parameters, it is difficultto prove that a given result was generatedaccording to the appropriate procedure orprotocol. If a computer was used in theprocedure, and if the control parameters arestored on a durable storage device (typicallythe computer’s hard disk or a storage card forthe instrument itself), then Part 11 applies.

Levels of Instrument ControlAnalytical laboratories typically operatewith a diverse base of instruments, oftenfrom a variety of manufacturers forhistorical or strategic reasons. Because mostmodern instruments are computercontrolled, the instrument control

Wolfgang Winter and Ludwig Huber

Implementing 21 CFR Part 11 in Analytical LaboratoriesPart 5, The Importance of Instrument Control and Data Acquisition

T

The time for compliance with 21 CFR Part 11 is now. Bringingdifferent laboratory instrumentsinto compliance takes planning.The key strengths andweaknesses of different levels ofcontrol and feedback foranalytical instruments and datatransfer systems are highlighted inthis fifth installment of our series.

Wolfgang Winter is worldwide product manager for networked data systems andcorresponding author Ludwig Huber is worldwideproduct marketing manager, HPLC, at AgilentTechnologies GmbH, PO Box 1280 D-76337,Waldbronn, Germany, +49 7243 602 209, fax+497243 602 501, ludwig_huber@agilent.com,www.agilent.com.

Regulatory IssuesRegulatory Issues

Regulatory Issues

Level 3. In most cases, manufacturersachieve full instrument control for their ownsystems (level 3). That makes it easier tocreate a complete set of raw and metadataand the proper documentation. At this level,the error reporting and handling are quitesophisticated, which makes it easier toverify that analyses were completed withouttechnical failures and to diagnose errorswhen they occur.

Going one better. Some manufacturers haveimplemented an additional level ofinstrument capability that can be controlledfrom within the data system. A data systemcontrols those functions that executedetailed and sophisticated instrumentdiagnostics and other service functions. Alsounder this instrument control are provisionsfor preventive maintenance and earlymaintenance feedback (EMF), a techniquefirst used in the aeronautics industry (to alerttechnical personnel to perform maintenancejobs proactively) and subsequentlyimplemented by companies such as AgilentTechnologies (Palo Alto, CA).

Systems implemented at this levelprovide sophisticated support for trackinginstrument or module serial numbers and forfirmware revisions. Such information ishandy for inventory tracking, and it alsoperforms some of the function checksrequired by Part 11.

Level 4. In level 4 instrument control, allcommunications (including commands anddata transfer) are performed using ahandshake. A handshake requires therecipient of a data record to activelyacknowledge to the sender that the recordhas been received. For example, thecontroller sends a command like “START” tothe device, the device interprets thecommand and acknowledges “OK, START.” Ifthe device is unable to execute thecommand, it sends a negative receipt like“NOT OK, NO START.” This approach preventssituations in which the controller thinks itsent the instructions to the device, but thedevice never executes them.

Protocols for Data IntegrityUnderstanding the strengths and weaknessesof some widely used instrumentcommunication protocols will help ensure thedata integrity and traceability required by 21CFR Part 11. One example can be drawn fromthe legacy world: a general-purpose interfacebus (GPIB), the well known and widely

spread “IEEE 488” standard. Contrast the GPIB to state-of-the-art

networking protocols like the well knownand ubiquitous TCP/IP protocol used forintra- or Internet communication. (Tables 2and 3 provide a detailed list of the strengthsand weaknesses of these two communicationsystems and recommendations for avoidingsome weaknesses.) We are not providing adetailed technical description of thetechnology itself. Many publications coverthose aspects accurately and in technicaldetail (7–9).

Instrument communication using GPIB. GPIB is aparallel communication interface that canconnect up to 15 devices on a common bus.All communications using GPIB, includingcommands and data, use a hardware

handshake for every byte. All devicesconnected to the bus participate in thathandshake. As a consequence, every deviceon the bus can influence the ongoingcommunication or cause severecommunication problems like bus “hang-ups” or data corruption. The reason for thatcan be a firmware error or a hardware failurein one of the participating devices (such asthe printer). But powering a seemingly“idle” GPIB device on or off during ongoingcommunication also can cause suchproblems. Even though the electricalspecifications of GPIB do not prohibit theactions that lead to those scenarios, thecombination of chip-set implementation,firmware, and application software oftenleads to that failure.

ComplianceLevel Parameters with Part 11

Level 1. Parameter set up on Start/Stop (no digital Metadata: Instrument the instrument, synchroniza- instrument control or parameters must be tion using external contacts data acquisition) documented manually; to start and stop an Device checks: Positive analysis, analog signal ID of sample vials mayacquisition not be available (using

bar codes or BCD input)

Level 2. Rudimentary digital Basic instrument parameters, Audit trail: Typically no instrument control (such as such as the flow rate of instrument error a LAN, RS232, or GPIB) an HPLC pump or the information available,

wavelength of an HPLC requires additional detector inspections to determine

the validity of the measurements; Validation: Could be more difficult to support and validate if reverse engineered

Level 3. Full digital instrument All control parameters Audit trail and Metadata:control (for example through including injector program Full documentation of a LAN, RS232, or GPIB) and method sequencing; instrument parameters

wavelength calibration; used to generate a resulterror recording

Level 4. Advanced functions Handshake protocol between Advanced error controller and device (active prevention and acknowledgment of correct detection; Validation:receipt); self-diagnostics and facilitates the executionearly maintenance feedback of instrument qualification (EMF); automatic tracking of and preventive serial and product numbers, maintenance; qualifies for electronic instrument log book; device checks required supports advanced tagging of by the rule; guaranteed components, such as column- and reproducible id tags; instrument performs execution of data real-time data acquisition and acquisition independent synchronization independent of the current data of the computer system load (facilitates

the qualification of data integrity and traceability)

Table 1. Levels of instrument control, the parameters that make up that level, and theconsequences of that level of control in complying with 21 CFR Part 11

Regulatory Issues

unaffected by the addition or removal of“idle” devices in the network. In contrast tomost GPIB implementations, TCP/IPsupports (without risking data loss) thesafety procedures of analytical laboratoriesthat require turning off instruments notcurrently in use.

Selecting a Good SystemWhen selecting and setting up instrumentcontrol and data acquisition systems, thefollowing recommendations should help.

1. Assess the level of instrument usedcurrently in your laboratory (level 1, 2, 3, or 4).

2. Find out what levels of control areavailable from the different manufacturersof that hardware.

3. Write a protocol documenting theinstrument parameters for instruments notdirectly controlled by the data system (level 1).

4. Determine whether the communicationprotocols were obtained with the approvaland support of the instrument manufacturerfor instruments that claim to be controlled.

5. Plan additional qualification andacceptance tests to obtain a high degree of certainty that the control andcommunications are accurate and reliablefor instruments for which communicationprotocols were apparently developed byreverse engineering.

6. Adapt your company’s internalprocedures to take advantage of additionaldiagnostics, maintenance, and trackingfunctions that validate, maintain, anddocument the system and the measurementsobtained from those functions.

7. Define test cases for boundaryconditions: Does the system reliablysynchronize all the devices required for ananalysis? Could a contact closure problemallow it to go unnoticed that a device, suchas a detector, did not start? If the instrumenthas a local user interface, does it trackparameter changes from the local interfacewhile data are being acquired from thecomputer? Alternatively, is the localinterface “locked” while data is acquired?Does the system quickly detect powerfailures of a connected device, or are datalost until a “time out” occurs? These are thekinds of questions to ask when bringingyour laboratory instrument control and dataacquisition systems into compliance with 21CFR Part 11.

and the majority of GPIB implementations. Checksums are, in principle, a running total

of all transmitted bytes attached to the packetand are used by the recipient to back-calculateand compare with the original checksumprovided by the sender. If a mismatch isdetected, a retransmission is requested. Thistechnique guarantees error-free data transportand is excellent for implementing the “devicechecks” and “system checks” mandated by 21CFR Part 11.

Communication in a TCP/IP environmentis, by definition, highly dynamic. Ongoingcommunication between other participants is

LAN Communication Using TCP/IPLocal area network (LAN) communicationusing the transmission control protocol/Internet protocol (TCP/IP), often somewhatcasually described as the “language of theInternet,” enables devices to exchangeinformation over a network. The centralidea of TCP/IP is the breaking ofinformation into pieces or packets. Thepackets are specifically structured to allowerror detection and correction by usingredundancy mechanisms like checksums.Redundancy mechanisms are the majordifference between more advanced systems

Strength Weakness Recommendation

Fast enough for high- Limited number of Not applicablespeed data acquisition devices on the same (for example spectral bus (15 maximum)data from diode array or mass-selective detectors)

GPIB allows sending of The standard does not Avoid powering “idle” GPIBbidirectional, addressed define power on/off on devices down while otherinformation (allows for the “idle” devices during ongoing devices are acquiring dataimplementation of device communication. Because all to minimize the risk of checks according to devices must participate data loss or data corruption.21 CFR Part 11) electrically in the handshake,

powering a device off during communication may hang the entire system, which can lead to data loss.

Not applicable Monitoring correct instrument Requires separate functions from remote devices operational qualification ofrequires a computer the instrument controller(instrument controller) that functions as an “information broker” next to the instrument.

Table 2. Strengths and weaknesses of instrument communication using GPIB, andrecommendations for meeting 21 CFR Part 11 with this level of instrument control

Strength Weakness Recommendation

Suited for high-speed data Not applicable Proactively plan network acquisition (for example infrastructure, especially inspectral data from large laboratories with manydiode array or mass- instrumentsselective detectors)

Inherent mechanisms for Not applicable Reliable instrument communication error detection and correction should be verified during system (an important measure for data qualification; turn off “idle” integrity and the basis for instruments not currently in usedevice checks according to 21 CFR Part 11)

Remote status information is Not applicable Covered by system qualificationavailable directly from the instrument and does not necessarily require an extra instrument controller as “information broker”

Table 3. Strengths and weaknesses of instrument communication using TCP/IP, andrecommendations for meeting 21 CFR Part 11 with this level of instrument control

Migration and Long-Term Archiving for ReadyRetrieval,” BioPharm 13(6), 58–64 (2000).

(6) R. D. McDowall, “Chromatography DataSystems: Part 1, The Fundamentals,” LCGCNorth America 18(1), 56–67 (2000).

(7) W. Winter, “Dynamic InterprocessCommunication between a Spectrophotometerand a Spreadsheet,” diploma thesis andpresentation for faculty for physical electronics,University of Karlsruhe (31 July 1989).

(8) M. F. Arnett et al., “Understanding BasicNetwork Concepts,” Inside TCP/IP (NewRiders Publishing, Indianapolis, 1994) pp. 51–54.

(9) ANSI/IEEE Std. 488.1-1987: Standard DigitalInterface for Programmable Instrumentation(The Institute for Electrical and ElectronicsEngineers, New York, 1987). BP

Electronic Records; Electronic Signatures, Title21, Part 11 (U.S. Government Printing Office,Washington, DC), issued March 2000. Availableat www.fda.gov/ora/compliance_ref/ part11.

(2) L. Huber, “Implementing 21 CFR Part 11 inAnalytical Laboratories: Part 1, Overview andRequirements,” BioPharm 12(11), 28–34(1999).

(3) W. Winter and L. Huber, “Implementing 21CFR Part 11 in Analytical Laboratories: Part 2,Security Aspects for Systems andApplications,” BioPharm 13(1), 44–50 (2000).

(4) W. Winter and L Huber, “Implementing 21CFR Part 11 in Analytical Laboratories: Part 3,Ensuring Data Integrity in ElectronicRecords,” BioPharm 13(3), 45–49 (2000).

(5) L. Huber and W. Winter, “Implementing 21 CFRPart 11 in Analytical Laboratories: Part 4, Data

Looking AheadIn the next article, we will discussbiometrics devices for system access andelectronic signatures. In computer security,biometrics are authentication techniques thatrely on measurable physical characteristicsthat can be automatically checked, such asfingerprints, retinas and irises, voicepatterns, facial patterns, and handmeasurements for system access andelectronic signature.

References(1) Office of Regulatory Compliance, Code of

Federal Regulations, Food and Drugs:

Bus is a collection of wires through whichdata travel within a computer. In thiscontext, bus means an interface andcommunication system for peripheraldevices (such as connections, cables,and the communication protocol).

Byte is an abbreviation for binary term. Itis a storage unit capable of holding eightbits or the space required for a singleletter or number, a single character.

Checksums are a running total of alltransmitted bytes that are attached to apacket and are used by the messagerecipient to back-calculate and comparewith the original checksum provided bythe message sender. If a mismatch isdetected, a retransmission is requested.This technique facilitates detection ofdata transport errors.

Chip-sets are a number of integratedcircuits designed to perform one or morerelated functions. For instance, theintegrated circuit components of aspecific GPIB interface card.

Device is any machine or component thatattaches to a computer, such as diskdrives, printers, mice, and modems.Those particular devices fall into thecategory of peripheral devices becausethey are separate from the maincomputer. Display monitors andkeyboards are also devices, butbecause they are integral parts of thecomputer they are not considered

peripheral. Most devices, whetherperipheral or not, require a programcalled a device driver that acts as atranslator, converting generalcommands from an application intospecific commands that the deviceunderstands.

Durable storage device is typically thecomputer’s hard disk or a storage cardfor a particular instrument.

Early maintenance feedback (EMF) is atechnique that automatically alertstechnical personnel to performmaintenance jobs proactively.

Firmware is a combination of hardwareand software written in read-onlymemory.

Handshake requires the recipient of a datarecord to actively acknowledge to thesender that the record has beenreceived.

IEEE is the Institute of Electrical andElectronic Engineers that developsstandards for computers and theelectronics industry.

Legacy systems are hardware and softwareapplications in which a company hasalready invested considerable time andmoney. Legacy systems typically performcritical operations in companies for manyyears even though they may no longeruse state-of-the-art technology.Replacing legacy systems can be

disruptive and therefore requires carefulplanning and appropriate migrationsupport from the manufacturer.

Local-area networks (LANs) are networkswith computers geographically closetogether (that is, in the same building),and wide-area networks (WANs) havecomputers farther apart and connectedby telephone lines or radio waves.

Metadata is complete data withprocessing parameters and audit traillogs.

Networking: A group of two or morecomputer systems linked together.

Packet: A piece of a transmitted messagethat contains both the data and thedestination address. In TCP/IPnetworking, packets are calleddatagrams. When you send an emailmessage, the message can be brokeninto several packets, each packet canbe transmitted separately, each packetmay travel different routes, and all thepackets can be put back together at therecipient’s site.

Reverse engineering: Recreating the designof hardware or software by analyzing thefinal product and working backward.

TCP/IP: Transmission controlprotocol/Internet protocol, enablesdevices to exchange information over anetwork.

Regulatory Issues

Learning 21 CFR Part 11 Language

©Reprinted from BIO PHARM, September 2000 AN ADVANSTAR � PUBLICATION Printed in U.S.A.Copyright Notice Copyright by Advanstar Communications Inc. Advanstar Communications Inc. retains all rights to this article. This article may only be viewed or printed (1) for personal use. User may not actively

save any text or graphics/photos to local hard drives or duplicate this article in whole or in part, in any medium. Advanstar Communications Inc. home page is located at http://www.advanstar.com.

Agilent Publication Number5988-0946EN