5988-9343EN

  • Upload
    anhthoo

  • View
    213

  • Download
    0

Embed Size (px)

Citation preview

  • 8/12/2019 5988-9343EN

    1/6

    I n 1997, the US Food and Drug Administration(FDA) issued a regulation that details criteria thatmust be met for the acceptance of electronic records,electronic signatures and handwritten signatures. 1This regulation, entitled Rule 21 CFR Part 11,permits electronic records to be used in place of paper records and handwritten signatures.The ruleapplies to all industry segments regulated by FDAthat must adhere to good laboratory practice (GLP),good clinical practice (GCP) and current goodmanufacturing 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 andconfidentiality through limited authorizedsystem access

    use of secure electronic signatures for closed andopen systems

    use of digital signatures for open systems.Although the rule is well documented, informationtechnology (IT) professionals and analysts in labora-tories are often unsure about its implementation.The biggest problem is to find a compromisebetween doing too much and satisfying minimumrequirements.

    Frequently asked questions Exactly which records should be retained,

    particularly when data have to be re-evaluatedseveral times before they can finally be accepted?

    How should computer-generated audit trails beimplemented; what should be tracked and after

    To comply with the US Food and Drug Administrations 21 CFR Part 11 (and thedraft guidance published on 20 February 2003), reliable, robust and validatablecommunication between computers and analytical instruments has becomeincreasingly important. This article demonstrates that monitoring and feedback mechanisms for instrument control and communication can drastically simplifycompliance with Part 11, because they make the generation of electronic raw datarecords trustworthy and reliable. It also evaluates typical communication protocolsused, and lists selection criteria for instrument control and data acquisition systems.

    Instrument Control inPharmaceutical Laboratories Compliance with 21 CFR Part 11and the New Draft Guidance

    Wolfgang Winteris worldwide product manager,

    networked data systems.

    Tel.+49 7243 602 454

    Fax +49 7243 602 501

    [email protected]

    Ludwig Huberis worldwide product

    marketing manager, HPLC.

    Tel.+49 7243 602 209

    Fax +49 7243 602 501

    [email protected]

    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

  • 8/12/2019 5988-9343EN

    2/6

    which entries; and does the user of the system have to confirm theentries as being logged?

    How should signatures be linkedwith the electronic records?

    Is computerized instrumentcontrol in the scope of Part 11?

    What can be done with existinginstruments that lack theappropriate functionality?

    How can you ensure that long-term archiving allows thepossibility to replay data after10 or more years?

    In 1999, FDA published compliancepolicy guide 7153.17 2 and issued atotal of five draft guidance docu-ments relating to Part 11, which havebeen vividly discussed and com-mented on in the affected industries.However, on 20 February 2003, FDApublished a new guidance on Scopeand Applications (www.fda.gov/OHRMS/DOCKETS/98fr/03d-0060-gdl0001.PDF and www.labcompli-ance.com/conferences/s991.htm) andwithdrew all other draft guidances.The new draft guidance states FDAsintention of interpreting Part 11more closely in line with its cGMPinitiative, focussing on risk-basedinspections.According to the newdraft guidance, Part 11 will continueto apply to records that are requiredby the predicate rules, and which aremaintained in electronic format inaddition to paper, and are relied onto perform regulated activities.Typically, this is the case for recordsmanaged by chromatography datasystems used in analytical laborato-ries in industries regulated by FDA.The authors will discuss the impactof the new draft guidance in moredetail in the April 2003 issue of Pharmaceutical Technology Europe .

    Additionally, other associations inthe industry have also acted todevelop guidelines on how to imple-ment Part 11. For example, theParenteral Drug Association (PDA)has formed a task force on Part 11(PDAs Good Electronic RecordsManagement [GERM]) and a specialinterest group of the GoodAutomated Manufacturing Practice(GAMP) Forum has released a draftpaper. 3 FDA also plans to releasemore guidance documents;Part 11itself just defines the framework now that the industry is working onconcrete implementation plans to

    comply, many practical system andprocess issue arise. Ongoing updatesare important and can be found atwww.labcompliance.com undere-signatures (21 CFR 11).

    Who must comply with 21 CFR?

    Huber,Winter and Nickel havepublished a series of articles onthe implementation of Part 11 inanalytical laboratories. 4 9 Thesearticles demonstrate how access tothe system and to critical systemfunctions could be limited to autho-rized personnel.They also explainhow the integrity of data can beassured at the time of data analysisand evaluation and how creation,modification and deletion of recordsare logged in a computer-generatedaudit trail.They also discuss howdata can be archived and accuratelyretrieved after several years.Thesearticles focus mainly on complianceand management of data generatedby analytical data systems.

    A frequently asked question isshould computers that just controlanalytical instruments, but do notacquire data,comply with Part 11? If FDA ever looked at or asked forpaper printouts of the parameters,the answer is simply, yes. Withoutproper documentation of the instru-ment control parameters, it becomesdifficult to prove that a given resultwas generated according to theappropriate procedure or mono-graph. If a computer was used for thisprocedure,and if, at any time,thecontrol parameters are stored on adurable storage device (typically thecomputers hard disk or a storage cardfor the instrument),Part 11 applies.

    In this article, we will discuss levelsof instrument control and data acquisi-tion; electronic records associated withinstrument control; tracking of instru-ment characteristics,events and errorsin an electronic logbook; and cross-manufacturer instrument control.

    Levels of instrument controlAnalytical laboratories typicallyoperate a diversified installed base of instruments, often from a variety of manufacturers.As most moderninstruments need to be controlled bya computer system, the instrumentcontrol parameters have to betreated in the same way as the rest of the metadata.

    Instrument control of a device canbe implemented at varying levels of sophistication and complexity(Table I). Often, instrument para-meters have to be set manually usingthe instruments own panel and key-board, with the signal being recorded

    by an analoguedigital converter(Level 1).This is often the approachchosen to integrate an instrumentinto a system from a different manu-facturer. In these cases, it is typicallyimpossible to obtain a printout of theinstrument settings that are usedduring an analysis. Analysts areforced to document instrumentparameters manually. Furthermore,analoguedigital converters do notalways support BCD (binary-codeddecimal) or barcode input (from anautosampler) that can be used topositively correlate an injection witha given sample using the samplename or at least a vial number.

    Many systems implement arudimentary level of instrument con-trol (Level 2).This is often obtainedthrough reverse-engineering of thecommunication protocols foranother manufacturers instrument,and supports the basic parameters of an instrument, such as solvent com-position, flow, oven temperature anddetector wavelength. If the manufac-turer of the instrument did notdisclose the control codes, it may bemuch more difficult to obtain anofficially supported (that is, approvedand guaranteed) solution withappropriate validation documentsfrom the supplier.Also, additionaleffort should be planned to performqualification and other validationtasks on such a system. As themanufacturer of the originalinstrument may be neither awarenor responsible for the implementa-tion of the communication, instru-ment firmware updates may resultin non-functional communication tothe data system. The implementa-tion of error handling and logging is

    Although the rule is well documented,information technology (IT)professionals and analysts inlaboratories are often unsure about itsimplementation.

  • 8/12/2019 5988-9343EN

    3/6

    typically weak in this category.When selecting a system that issupposed to control instrumentationfrom other manufacturers, it isimportant to verify that the controlcodes were obtained from themanufacturer of the instrument and

    not reverse-engineered.In most cases, manufacturersimplement full instrument control(Level 3) for their own systems.Thisfacilitates keeping a complete set of raw and metadata together with theproper documentation. In thiscategory, one can also expect quitesophisticated error reporting andhandling, which makes it easier toverify that an analysis was indeedcompleted without technical failuresor to diagnose an error.

    Some manufacturers haveimplemented an additional level ofinstrument capabilities that can becontrolled from within the datasystem.These functions are the basis

    for the execution of detailed andsophisticated instrument diagnosticsas well as other service functions.Thisincludes provisions for preventivemaintenance and early maintenancefeedback (EMF), a techniqueinitially used in the aeronautics

    industry (to alert technical personnelto perform due maintenance jobsproactively before something fails),which is now used in the pharma-ceutical and other industries.

    More importantly, systemsimplemented at this level providesophisticated support for trackinginstruments or module serial num-bers and firmware revisions.Thisinformation is not only convenientand important for inventory trackingof validated equipment, but can alsobe used to verify some of the devicecheck functions required by Part 11.

    In Level 4 instrument controlimplementations, all communication(including commands and data

    transfer) is performed using a hand-shake. A handshake basically meansthat the recipient of a data recordmust actively acknowledge receipt of the record by notifying the sender.For example, the controller sends acommand such as STARTto the

    device, the device interprets thecommand and acknowledges OK,START. If, for any reason, thedevice is not able to execute thecommand, it sends a negative receiptsuch as NOT OK, NO START.This approach clearly avoidssituations in which the controller isunaware that instructions sent to thedevice have not been executed.

    Relevance of communicationprotocols for data integrityBelow is a discussion of widely usedinstrument communication protocolsand their strengths and weaknesses interms of data integrity and traceabilityaccording 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 beParameter set-up on the instrument, data acquisition). documented manually.synchronization using external contacts Device checks: positive ID of sample vialsto start and stop an analysis, analogue may not be available (using barcodes orsignal acquisition. BCD input).

    Level 2 Basic instrument parameter, for example, Audit trail: typically no instrument errorRudimentary 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 supportif reverse-engineered.

    Level 3 All control parameters, including injector Audit trail and metadata:full documentationFull digital instrument control for programme, method sequencing. of instrument parameters used toexample, 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 synchronizationindependently of the computer.

  • 8/12/2019 5988-9343EN

    4/6

    use GPIB (general purpose interfacebus) as an example, which is widelyused as the IEEE 488 standard.

    Contrasting examples arenetworking protocols, such as thewell-known and ubiquitous transmis-sion control protocol/Internet pro-

    tocol (TCP/IP) that is used for anyintranet or Internet communication.This discussion cannot,and is notintended to be, a detailed descriptionof the technology.A wide range of publications covers these aspectsaccurately and in greater technicaldetail. 1012

    Instrument communicationvia GPIBGPIB is a parallel communicationinterface that can connect up to15 devices on a common bus.Allcommunication, including commandsand data, is performed using a hard-ware handshake for every byte.Alldevices connected to the busparticipate in this handshake.

    As a consequence, every device onthe bus can influence the ongoingcommunication and cause severecommunication problems such as bushang-ups or data corruption.Theseproblems may be caused by afirmware error or a hardware failurein one of the participating devices(for example, the printer). But alsoswitching a seemingly idleGPIB

    device on or off during ongoing com-munication may generate a problem.Even though the electrical specifica-tions of GPIB do not prohibit thesescenarios, the combination of chip-set implementation, the firmwareand the application software often

    lead to that failure. (See Table II fora summary of GPIB characteristics.)

    Instrument communication viaLAN (TCP/IP)TCP/IP, often described as thelanguage of the Internet, enablesdevices to exchange information overa network (Table III).The key idea isto break information into pieces orpackets. The packets are specifi-cally structured to allow error detec-tion and error correction by usingredundancy mechanisms such aschecksums (this is how they differfrom the majority of GPIB imple-mentations described above).Achecksum is, in principle, a runningtotal of all transmitted bits that areattached to the packet and it is usedby the recipient to back-calculateand compare with the originalchecksum provided by the sender. If a mismatch is detected, retransmis-sion is requested.This techniqueguarantees an error-free data trans-port and represents an excellentbasis for the implementation of device checks and system

    checks mandated by 21 CFRPart 11. Figure 1 illustrates a typicalconfiguration of networked instru-ments in a distributed, client/serverenvironment.

    Communication in a TCP/IPenvironment is, by definition, highly

    dynamic. Addition or removal of idledevices in the network does notaffect ongoing communicationbetween the other participants. Incontrast to most GPIB implementa-tions, TCP/IP supports safety proce-dures requiring instrumentation thatis not in use to be switched off without the risk of data loss.

    Recommendations for selectinginstrument control and dataacquisition systems1. The level of control of instru-

    mentation used in the laboratorymust be assessed.

    2. If instrument communication usesproprietary interfaces, check foradherence to your internal ITsupport guidelines.

    3. Find out what levels of control areoffered by hardware manufacturers.

    4. For instrumentation not directlycontrolled by the data system(Level 1), plan the proceduresnecessary to documentinstrument parameters.

    5. For instrumentation claimed to becontrolled, 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/Aacquisition (for example, spectral data Restrictions on total data rate on the bus.from diode array or mass-selective Distance limitations (maximum of 2 mdetectors). between devices).

    GPIB permits bidirectional,addressed The standard does not define power on/off Avoid powering down idle GPIB devicesinformation to be sent (allows for the of idle devices during ongoing communication. while other devices are acquiring data,toimplementation of device checks As all devices must electrically participate in minimize the risk of data loss or dataaccording to 21 CFR Part 11). the handshake, switching a device off during corruption.

    communication may hang up the entirecommunication system.This can lead to data loss.

    N/A Remote monitoring of instrument functions Requires separate operational qualificationrequires a computer (instrument controller) of the instrument controller.that functions as an information brokernext to the instrument.

    N/A Requires proprietary GPIB interfaces in the Subject to (re)qualification particularlyinstruments as well as the computers. if PC models and operating systems change.

    Verify compatibility with supportguidelines from your IT support group.

  • 8/12/2019 5988-9343EN

    5/6

    communication protocols wereobtained with approval andsupport of the instrumentmanufacturer.

    6. For instruments for whichcommunication protocols wereapparently developed by reverseengineering, plan additionalqualification and acceptance teststo obtain a high degree of assurance that control andcommunication are accurateand reliable.

    7. Adapt internal procedures to takeadvantage of the additionaldiagnostics, maintenance andtracking functions to validate,maintain and document thesystem and the measurementsobtained with it.

    8. Define test cases for the boundaryconditions.

    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 detect ion 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 areRemote status information is available directly from the required (and where they are superfluous!) to supportinstrument 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 ITinterfaces (such as standard Ethernet LAN cards for the PC). support group.

    control. We have defined the differentlevels of instrument control capabili-ties that can exist in modern analyticaldata systems. Level 4 instrument con-trol not only supports an instrumentscommand set, but uses an advancedcontrol layer with handshake

    protocols between software andconnected instruments.This leveloffers advanced functions that allowautomatic tracking of instrumentidentification or configurationinformation, and it is a prerequisitefor the implementation of EMF.Electronic records generated by aninstrument are only reliable andtrustworthy if the communicationbetween instrument and the systemcontroller is reliable and trustworthy.Level 4 instrument control is anadequate mechanism to ensure this.

    References1. Code of Federal Regulations,Title 21,

    Food and Drugs, Part 11 ElectronicRecords;Electronic Signatures; Final Rule,Federal Register 62 (54), 1342913466.

    2. United States FDA, Compliance PolicyGuide: 21 CFR Part 11; ElectronicRecords, Electronic Signatures(CPG 7153.17).

    3. Good Automated Manufacturing Practice(GAMP) Special Interest Group,Complying with 21 CFR Part 11:Electronic Records and Signatures, FinalDraft, September 2000. Available fromthe GAMP website (www.gamp.org).

    4. L. Huber,Implementing 21 CFR inAnalytical Laboratories, Part 1: Overviewand Requirements, BioPharm 12 (11),2834 (1999).

    synchronize all devices requiredfor an analysis?

    Could a contact closure problemlead to a situation where it goesunnoticed that a device such as adetector did not start?

    If the instrument has a local userinterface, does it track parameterchanges performed at the localinterface while data are beingacquired by the computer?Alternatively, is the local interfacelocked while data are beingacquired?

    Does the system quickly detectpower failures of a connecteddevice or are data lost until atime-out situation occurs?

    ConclusionPart 11 enforcement practices havedrastically emphasized the importanceof reliable and traceable instrument

    Server

    Remote access

    Office PC

    Office PC

    Figure 1 Configuration of networked instruments in a distributed,client/server environment.

  • 8/12/2019 5988-9343EN

    6/6

    5. W.Winter and L. Huber,Implementing21 CFR Part 11 in Analytical Laboratories,Part 2: Security Aspects for Systems andApplications, BioPharm 13 (1), 4450(2000).

    6. W.Winter and L.Huber,Implementing 21CFR Part 11 in Analytical Laboratories,Part 3: Ensuring Data Integrity in ElectronicSignatures, BioPharm 13 (3),4549 (2000).

    7. L. Huber and W.Winter,Implementing21 CFR Part 11 in Analytical Laboratories,Part 4: Data Migration and Long-TermArchiving for Ready Retrieval, BioPharm13 (6), 5864 (2000).

    8. W. Winter and L. Huber,Implementing21 CFR Part 11 in AnalyticalLaboratories, Part 6: BiometricIdentification: 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 inAnalytical Laboratories, Part 6:MakingLegacy Systems Compliant, in

    Implementing 21 CFR Part 11 in

    Analytical Laboratories (2000) pp 4447,a supplement to BioPharm .

    10. W. Winter, Dynamic InterprocessCommunication between a Spectro-photometer and a Spreadsheet, Facultyfor Physical Electronics, University of Karlsruhe (TH),Germany (1989).

    11. M.F. Arnett et al ., Understanding BasicNetworking 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 AmericanNational Standard IEEE StandardDigital Interface for ProgrammableInstrumentation.

    Article Reprinted from the21CFR Part 11 supplement

    (March 2003) issue of:

    Article Reprint: 0548

    Agilent Publication Number: 5988-9343 EN