I

n 1997, the US Food and Drug Administration

(FDA) issued a regulation that details criteria that
must be met for the acceptance of electronic records,
electronic signatures and handwritten signatures.
1
This regulation, entitled Rule 21 CFR Part 11,
permits electronic records to be used in place of
paper records and handwritten signatures. The rule
applies to all industry segments regulated by FDA
that must adhere to good laboratory practice (GLP),
good clinical practice (GCP) and current good
manufacturing practice (cGMP).
The new regulation requires analytical laborato-
ries to demonstrate the following:
use of validated existing and new equipment and
computer systems
secure retention of electronic records to instantly
reconstruct the analysis
user-independent, computer-generated
time-stamped audit trails
system and data security, data integrity and
confidentiality through limited authorized
system access
use of secure electronic signatures for closed and
open systems
use of digital signatures for open systems.
Although the rule is well documented, information
technology (IT) professionals and analysts in labora-
tories are often unsure about its implementation.
The biggest problem is to find a compromise
between doing too much and satisfying minimum
requirements.
Frequently asked questions
Exactly which records should be retained,
particularly when data have to be re-evaluated
several times before they can finally be accepted?
How should computer-generated audit trails be
implemented; what should be tracked and after
To comply with the US Food and Drug Administrations 21 CFR Part 11 (and the
draft guidance published on 20 February 2003), reliable, robust and validatable
communication between computers and analytical instruments has become
increasingly important. This article demonstrates that monitoring and feedback
mechanisms for instrument control and communication can drastically simplify
compliance with Part 11, because they make the generation of electronic raw data
records trustworthy and reliable. It also evaluates typical communication protocols
used, and lists selection criteria for instrument control and data acquisition systems.
Instrument Control in
Pharmaceutical Laboratories
Compliance with 21 CFR Part 11
and the New Draft Guidance
Wolfgang Winter
is worldwide product manager,
networked data systems.
Tel. +49 7243 602 454
Fax +49 7243 602 501
wolfgang_winter@agilent.com
Ludwig Huber
is worldwide product
marketing manager, HPLC.
Tel. +49 7243 602 209
Fax +49 7243 602 501
ludwig_huber@agilent.com
Agilent Technologies GmbH,
PO Box 1280,
D-76337 Waldbronn, Germany.
a
r
t
w
o
r
k

W
a
r
r
e
n

J
o
n
e
s

o
r
i
g
i
n
a
l

i
m
a
g
e
s

P
h
o
t
o
d
i
s
c
which entries; and does the user of
the system have to confirm the
entries as being logged?
How should signatures be linked
with the electronic records?
Is computerized instrument
control in the scope of Part 11?
What can be done with existing
instruments that lack the
appropriate functionality?
How can you ensure that long-
term archiving allows the
possibility to replay data after
10 or more years?
In 1999, FDA published compliance
policy guide 7153.17
2
and issued a
total of five draft guidance docu-
ments relating to Part 11, which have
been vividly discussed and com-
mented on in the affected industries.
However, on 20 February 2003, FDA
published a new guidance on Scope
and Applications (www.fda.gov/
OHRMS/DOCKETS/98fr/03d-0060-
gdl0001.PDF and www.labcompli-
ance.com/conferences/s991.htm) and
withdrew all other draft guidances.
The new draft guidance states FDAs
intention of interpreting Part 11
more closely in line with its cGMP
initiative, focussing on risk-based
inspections. According to the new
draft guidance, Part 11 will continue
to apply to records that are required
by the predicate rules, and which are
maintained in electronic format in
addition to paper, and are relied on
to perform regulated activities.
Typically, this is the case for records
managed by chromatography data
systems used in analytical laborato-
ries in industries regulated by FDA.
The authors will discuss the impact
of the new draft guidance in more
detail in the April 2003 issue of
Pharmaceutical Technology Europe.
Additionally, other associations in
the industry have also acted to
develop guidelines on how to imple-
ment Part 11. For example, the
Parenteral Drug Association (PDA)
has formed a task force on Part 11
(PDAs Good Electronic Records
Management [GERM]) and a special
interest group of the Good
Automated Manufacturing Practice
(GAMP) Forum has released a draft
paper.
3
FDA also plans to release
more guidance documents; Part 11
itself just defines the framework
now that the industry is working on
concrete implementation plans to
comply, many practical system and
process issue arise. Ongoing updates
are important and can be found at
www.labcompliance.com under
e-signatures (21 CFR 11).
Who must comply with 21 CFR?
Huber, Winter and Nickel have
published a series of articles on
the implementation of Part 11 in
analytical laboratories.
49
These
articles demonstrate how access to
the system and to critical system
functions could be limited to autho-
rized personnel. They also explain
how the integrity of data can be
assured at the time of data analysis
and evaluation and how creation,
modification and deletion of records
are logged in a computer-generated
audit trail. They also discuss how
data can be archived and accurately
retrieved after several years. These
articles focus mainly on compliance
and management of data generated
by analytical data systems.
A frequently asked question is
should computers that just control
analytical instruments, but do not
acquire data, comply with Part 11? If
FDA ever looked at or asked for
paper printouts of the parameters,
the answer is simply, yes. Without
proper documentation of the instru-
ment control parameters, it becomes
difficult to prove that a given result
was generated according to the
appropriate procedure or mono-
graph. If a computer was used for this
procedure, and if, at any time, the
control parameters are stored on a
durable storage device (typically the
computers hard disk or a storage card
for the instrument), Part 11 applies.
In this article, we will discuss levels
of instrument control and data acquisi-
tion; electronic records associated with
instrument control; tracking of instru-
ment characteristics, events and errors
in an electronic logbook; and cross-
manufacturer instrument control.
Levels of instrument control
Analytical laboratories typically
operate a diversified installed base of
instruments, often from a variety of
manufacturers. As most modern
instruments need to be controlled by
a computer system, the instrument
control parameters have to be
treated in the same way as the rest of
the metadata.
Instrument control of a device can
be implemented at varying levels of
sophistication and complexity
(Table I). Often, instrument para-
meters have to be set manually using
the instruments own panel and key-
board, with the signal being recorded
by an analoguedigital converter
(Level 1). This is often the approach
chosen to integrate an instrument
into a system from a different manu-
facturer. In these cases, it is typically
impossible to obtain a printout of the
instrument settings that are used
during an analysis. Analysts are
forced to document instrument
parameters manually. Furthermore,
analoguedigital converters do not
always support BCD (binary-coded
decimal) or barcode input (from an
autosampler) that can be used to
positively correlate an injection with
a given sample using the sample
name or at least a vial number.
Many systems implement a
rudimentary level of instrument con-
trol (Level 2). This is often obtained
through reverse-engineering of the
communication protocols for
another manufacturers instrument,
and supports the basic parameters of
an instrument, such as solvent com-
position, flow, oven temperature and
detector wavelength. If the manufac-
turer of the instrument did not
disclose the control codes, it may be
much more difficult to obtain an
officially supported (that is, approved
and guaranteed) solution with
appropriate validation documents
from the supplier. Also, additional
effort should be planned to perform
qualification and other validation
tasks on such a system. As the
manufacturer of the original
instrument may be neither aware
nor responsible for the implementa-
tion of the communication, instru-
ment firmware updates may result
in non-functional communication to
the data system. The implementa-
tion of error handling and logging is
Although the rule is well documented,
information technology (IT)
professionals and analysts in
laboratories are often unsure about its
implementation.
typically weak in this category.
When selecting a system that is
supposed to control instrumentation
from other manufacturers, it is
important to verify that the control
codes were obtained from the
manufacturer of the instrument and
not reverse-engineered.
In most cases, manufacturers
implement full instrument control
(Level 3) for their own systems. This
facilitates keeping a complete set of
raw and metadata together with the
proper documentation. In this
category, one can also 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.
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 and early maintenance
feedback (EMF), a technique
initially used in the aeronautics
industry (to alert technical personnel
to perform due maintenance jobs
proactively before something fails),
which is now used in the pharma-
ceutical and other industries.
More importantly, systems
implemented at this level provide
sophisticated support for tracking
instruments or module serial num-
bers and firmware revisions. This
information is not only convenient
and important for inventory tracking
of validated equipment, but can also
be used to verify some of the device
check functions required by Part 11.
In Level 4 instrument control
implementations, all communication
(including commands and data
transfer) is performed using a hand-
shake. A handshake basically means
that the recipient of a data record
must actively acknowledge receipt of
the record by notifying the sender.
For example, the controller sends a
command such as START to the
device, the device interprets the
command and acknowledges OK,
START. If, for any reason, the
device is not able to execute the
command, it sends a negative receipt
such as NOT OK, NO START.
This approach clearly avoids
situations in which the controller is
unaware that instructions sent to the
device have not been executed.
Relevance of communication
protocols for data integrity
Below is a discussion of widely used
instrument communication protocols
and their strengths and weaknesses in
terms of data integrity and traceability
according to 21 CFR Part 11. We will
Level Parameters Impact on Part 11
Table I Levels of instrument control.
Level 1 Start/stop (no digital instrument control and Metadata: instrument parameters must be
Parameter set-up on the instrument, data acquisition). documented manually.
synchronization using external contacts Device checks: positive ID of sample vials
to start and stop an analysis, analogue may not be available (using barcodes or
signal acquisition. BCD input).
Level 2 Basic instrument parameter, for example, Audit trail: typically no instrument error
Rudimentary digital instrument control flow rate of an HPLC (high performance information available requires additional
for example, through LAN (local area liquid chromatography) pump or the inspections to determine the validity of
network), RS 232, GPIB. wavelength of an HPLC detector. the measurements.
Validation: could be more difficult to support
if reverse-engineered.
Level 3 All control parameters, including injector Audit trail and metadata: full documentation
Full digital instrument control for programme, method sequencing. of instrument parameters used to
example, through LAN, RS 232, GPIB. Wavelength calibration. generate a result.
Error recording.
Level 4 Handshake protocol between controller and Advanced error prevention and detection.
Advanced functions. device (active acknowledgement of correct Validation: facilitates the execution of
receipt). instrument qualification and preventive
Self diagnostics and early maintenance maintenance.
feedback (EMF). Qualifies for device checks required by the
Automatic tracking of serial and product rule.
numbers, electronic instrument logbook. Guaranteed and reproducible execution
Supports advanced tagging of components, of data acquisition independent of
for example column ID tags. current data system load (facilitates the
Instrument performs real-time data qualification of data integrity and traceability).
acquisition and synchronization
independently of the computer.
use GPIB (general purpose interface
bus) as an example, which is widely
used as the IEEE 488 standard.
Contrasting examples are
networking protocols, such as the
well-known and ubiquitous transmis-
sion control protocol/Internet pro-
tocol (TCP/IP) that is used for any
intranet or Internet communication.
This discussion cannot, and is not
intended to be, a detailed description
of the technology. A wide range of
publications covers these aspects
accurately and in greater technical
detail.
1012
Instrument communication
via GPIB
GPIB is a parallel communication
interface that can connect up to
15 devices on a common bus. All
communication, including commands
and data, is performed using a hard-
ware handshake for every byte. All
devices connected to the bus
participate in this handshake.
As a consequence, every device on
the bus can influence the ongoing
communication and cause severe
communication problems such as bus
hang-ups or data corruption. These
problems may be caused by a
firmware error or a hardware failure
in one of the participating devices
(for example, the printer). But also
switching a seemingly idle GPIB
device on or off during ongoing com-
munication may generate a problem.
Even though the electrical specifica-
tions of GPIB do not prohibit these
scenarios, the combination of chip-
set implementation, the firmware
and the application software often
lead to that failure. (See Table II for
a summary of GPIB characteristics.)
Instrument communication via
LAN (TCP/IP)
TCP/IP, often described as the
language of the Internet, enables
devices to exchange information over
a network (Table III). The key idea is
to break information into pieces or
packets. The packets are specifi-
cally structured to allow error detec-
tion and error correction by using
redundancy mechanisms such as
checksums (this is how they differ
from the majority of GPIB imple-
mentations described above). A
checksum is, in principle, a running
total of all transmitted bits that are
attached to the packet and it is used
by the recipient to back-calculate
and compare with the original
checksum provided by the sender. If
a mismatch is detected, retransmis-
sion is requested. This technique
guarantees an error-free data trans-
port and represents an excellent
basis for the implementation of
device checks and system
checks mandated by 21 CFR
Part 11. Figure 1 illustrates a typical
configuration of networked instru-
ments in a distributed, client/server
environment.
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 participants. In
contrast to most GPIB implementa-
tions, TCP/IP supports safety proce-
dures requiring instrumentation that
is not in use to be switched off
without the risk of data loss.
Recommendations for selecting
instrument control and data
acquisition systems
1. The level of control of instru-
mentation used in the laboratory
must be assessed.
2. If instrument communication uses
proprietary interfaces, check for
adherence to your internal IT
support guidelines.
3. Find out what levels of control are
offered by hardware manufacturers.
4. For instrumentation not directly
controlled by the data system
(Level 1), plan the procedures
necessary to document
instrument parameters.
5. For instrumentation claimed to be
controlled, determine whether the
Strength Weakness Recommendation
Table II Characteristics of GPIB.
Fast enough for high-speed data Limited number of devices on the same bus (15). N/A
acquisition (for example, spectral data Restrictions on total data rate on the bus.
from diode array or mass-selective Distance limitations (maximum of 2 m
detectors). between devices).
GPIB permits bidirectional, addressed The standard does not define power on/off Avoid powering down idle GPIB devices
information to be sent (allows for the of idle devices during ongoing communication. while other devices are acquiring data, to
implementation of device checks As all devices must electrically participate in minimize the risk of data loss or data
according to 21 CFR Part 11). the handshake, switching a device off during corruption.
communication may hang up the entire
communication system. This can lead to data loss.
N/A Remote monitoring of instrument functions Requires separate operational qualification
requires a computer (instrument controller) of the instrument controller.
that functions as an information broker
next to the instrument.
N/A Requires proprietary GPIB interfaces in the Subject to (re)qualification particularly
instruments as well as the computers. if PC models and operating systems change.
Verify compatibility with support
guidelines from your IT support group.
communication protocols were
obtained with approval and
support of the instrument
manufacturer.
6. For instruments for which
communication protocols were
apparently developed by reverse
engineering, plan additional
qualification and acceptance tests
to obtain a high degree of
assurance that control and
communication are accurate
and reliable.
7. Adapt internal procedures to take
advantage of the additional
diagnostics, maintenance and
tracking functions to validate,
maintain and document the
system and the measurements
obtained with it.
8. Define test cases for the boundary
conditions.
Does the system reliably
Strength Weakness Recommendation
Table III Characteristics of TCP/IP.
Suited to high-speed data acquisition (for example, spectral data N/A Proactively plan network infrastructure and segmentation,
from diode array or mass-selective detectors). particularly in large labs with many instruments.
Inherent mechanisms for error detection and correction N/A Reliable instrument communication should be verified
(an important measure for data integrity and the basis for during system qualification.
device checks according to 21 CFR Part 11). Turn off idle instruments not in use.
Networked instruments help eliminate PCs from the lab bench. N/A Proactively plan lab layout and where computers are
Remote status information is available directly from the required (and where they are superfluous!) to support
instrument and does not necessarily require an extra the workflow.
instrument controller (computer) as information broker.
Allows the use of cheaper, widely used, standard N/A Ask for a list of recommended models from your IT
interfaces (such as standard Ethernet LAN cards for the PC). support group.
control. We have defined the different
levels of instrument control capabili-
ties that can exist in modern analytical
data systems. Level 4 instrument con-
trol not only supports an instruments
command set, but uses an advanced
control layer with handshake
protocols between software and
connected instruments. This level
offers advanced functions that allow
automatic tracking of instrument
identification or configuration
information, and it is a prerequisite
for the implementation of EMF.
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.
References
1. Code of Federal Regulations, Title 21,
Food and Drugs, Part 11 Electronic
Records; Electronic Signatures; Final Rule,
Federal Register 62(54), 1342913466.
2. United States FDA, Compliance Policy
Guide: 21 CFR Part 11; Electronic
Records, Electronic Signatures
(CPG 7153.17).
3. Good Automated Manufacturing Practice
(GAMP) Special Interest Group,
Complying with 21 CFR Part 11:
Electronic Records and Signatures, Final
Draft, September 2000. Available from
the GAMP website (www.gamp.org).
4. L. Huber, Implementing 21 CFR in
Analytical Laboratories, Part 1: Overview
and Requirements, BioPharm 12(11),
2834 (1999).
synchronize all devices required
for an analysis?
Could a contact closure problem
lead to a situation where it goes
unnoticed that a device such as a
detector did not start?
If the instrument has a local user
interface, does it track parameter
changes performed at the local
interface while data are being
acquired by the computer?
Alternatively, is the local interface
locked while data are being
acquired?
Does the system quickly detect
power failures of a connected
device or are data lost until a
time-out situation occurs?
Conclusion
Part 11 enforcement practices have
drastically emphasized the importance
of reliable and traceable instrument
Server
Remote access
Office PC
Office PC
Figure 1 Configuration of networked instruments in a distributed, client/server environment.
5. W. Winter and L. Huber, Implementing
21 CFR Part 11 in Analytical Laboratories,
Part 2: Security Aspects for Systems and
Applications, BioPharm 13(1), 4450
(2000).
6. W. Winter and L. Huber, Implementing 21
CFR Part 11 in Analytical Laboratories,
Part 3: Ensuring Data Integrity in Electronic
Signatures,BioPharm 13(3), 4549 (2000).
7. L. Huber and W. Winter, Implementing
21 CFR Part 11 in Analytical Laboratories,
Part 4: Data Migration and Long-Term
Archiving for Ready Retrieval, BioPharm
13(6), 5864 (2000).
8. W. Winter and L. Huber, Implementing
21 CFR Part 11 in Analytical
Laboratories, Part 6: Biometric
Identification: Limits and Possibilities, in
Implementing 21 CFR Part 11 in
Analytical Laboratories (2000) pp 4043,
a supplement to BioPharm.
9. C. Nickel, W. Winter and L. Huber,
Implementing 21 CFR Part 11 in
Analytical Laboratories, Part 6: Making
Legacy Systems Compliant, in
Implementing 21 CFR Part 11 in
Analytical Laboratories (2000) pp 4447,
a supplement to BioPharm.
10. W. Winter, Dynamic Interprocess
Communication between a Spectro-
photometer and a Spreadsheet, Faculty
for Physical Electronics, University of
Karlsruhe (TH), Germany (1989).
11. M.F. Arnett et al., Understanding Basic
Networking Concepts, in Inside TCP/IP
(New Riders Publishing, Indianapolis,
USA, 1994, ISBN 1-56205-354-X)
pp 5154.
12. ANSI/IEEE Std 488.1-1987 revision of
ANSI/IEEE Std 488-1978: An American
National Standard IEEE Standard
Digital Interface for Programmable
Instrumentation.
Article Reprinted from the
21CFR Part 11 supplement
(March 2003) issue of:
Article Reprint: 0548
Agilent Publication Number: 5988-9343 EN