The Role of 21 CFR Part 11 in the Laboratory

The benefit of 21 CFR Part 11 (hereafter referred to as Part 11), per se, concerning the use of electronic records in laboratories is minimal compared with the benefits of computers themselves. Its advantage comes from the provision of a definition of what it takes for the US Food and Drug Administration (FDA) to trust electronic records when they are submitted to or viewed by FDA reviewers and investigators. Without such a legal definition, inconsistencies would abound. When electronic records and the systems used to realize those records into a meaningful form substantially meet the Part 11 criteria, they are 'trustworthy' to FDA. Furthermore, they should be deemed trustworthy to the many other 'customers' of this data. This is not a trivial point. It means we now have a definition of trustworthy computing, which can be used in all new system designs and as guidance in the remediation of existing systems for all types of computing applications.

The requirements of Part 11 are highly relevant to the electronic records and computer systems found in GCP, GLP and GMP (good clinical, laboratory and manufacturing practice - collectively referred to as GxP) regulated laboratories. This relevance arises from

• the nature of laboratory data (often so complex that paper copies do not capture the full richness of the information contained in the electronic form)

• the importance of the data (likely to be highly product- and/or patient-critical)

• the nature of the computerized systems producing and processing these data (typically specialized, requiring expertise in operation and often connected to other hardware thereby requiring logical device checks)

The requirement to keep all GxP raw data and original records (including electronic data) and ensure that their integrity throughout the prescribed retention period existed before Part 11 and continues to exist in GLP and GMP environments not subject to Part 11 (such as GLP preclinical laboratories and GMP quality control [QC] laboratories outside the US dealing with drug products not intended for or marketed in the US).

Similarly, the requirement for validation is merely restated in Part 11, validation having been clearly stipulated in the GMPs and GLPs for some time. It is therefore important that a broader, quality-centric view is kept when dealing with the concept of electronic records compliance and validation.

In my opinion, the purpose of laboratory systems is to provide 'valid analytical data,'1 a concept comprising two parts. First, a valid analytical measurement is made and second, the original records of this measurement are created, modified, processed, copied and stored in a reliable manner. When these are electronic records, we should use systems and processes that substantially meet the spirit and letter of Part 11. In other words, as shown in Figure 1, through a valid analytical measurement with the security of Part 11-style procedures providing valid analytical data.

Figure 1: Schematic showing how the aspects of digital data security surrounding the electronic records of a valid analytical measurement form the basis of valid analytical data.

How to ensure a valid analytical measurement in itself is outside the scope of this article but has been explored in depth elsewhere.1 However, some ways of ensuring that valid analytical measurements remain as valid analytical electronic data are explored below.

A solutions approach to compliant computer systems

To echo the recent statements of Paul Motise,2 trying to gain compliance alone is insufficient. I believe the slavish, line-by-line, narrow approach to compliance in many Part 11 assessment projects I've seen is expensive, sometimes purely academic, often misses the wider issues and actually brings a company more slowly into compliance than the solutions approach proposed below. As Motise states: "There is plenty of software available right now . . . " to provide the technical solutions to Part 11 compliance in the laboratory. Most of these technical solutions can be employed in the other business sectors of the industry, but that is outside the scope of this article.

Security. Physical security of the laboratory, through 'swipe-card' accesses or similar is the first aspect to be considered. I suggest all GLP and GMP laboratories should be installed with such physical security measures. Logical access security of laboratory systems with Windows NT, 2000 or XP, Macintosh or Unix operating systems can be readily achieved with power-up passwords, login passwords, logout facility and password protected screen-savers. For older Windows operating systems such as DOS or 3.11/95/98, which do not have the security features of NT/2000/XP, then upgrading to these operating systems is one option. This task can be simple when all the analytical application software and data of the system have a certified upgrade path available from the supplier. Sometimes the supplier will not certify the use of its application on NT/2000/XP platforms. In these cases there are some available options:

• Repackage the application(s) using appropriate SMS scripting to allow its installation onto NT/2000/XP. The main technical problems here are with the instrument control part of the software and configuring the correct software drivers. Competent computer staff, with adequate information and support from the system supplier, should succeed in upgrading applications to NT/2000/XP environments in almost every case. It is worth remembering, with this task and the ones below, when it has been done once then replication is easy and cheap for repeat instances.

• 'Surround' the old system (operating system and application(s)) in the new NT/2000/XP operating system environment as regards access security and data security.

• Windows 95/98 systems can be made, with some effort, secure enough to meet Part 11 expectations. Competent use of operating system configuration, the Tweak

• UI program and policy editors can obtain adequate levels of security and permissions setting.

• If none of the above are feasible, simply add physical security measures such as locks and keys to the computer.

• Buy a whole new system that is designed with Part 11 compliant features and runs in NT/2000/XP. Remember to take account of data migration and record/software archiving in the decommissioning of the old systems.

The question of security of access to computers in continuous sessions of operation is usually addressed by password protected screen-savers which pop up after a certain idle time (typically 5-30 min), combined with the procedure of software locking the computer by pressing [ctrl][alt][delete] [lock computer] when leaving it unattended. However, a particularly difficult logical problem exists in laboratories with computer systems that run unattended overnight, then need attention by another person the next day, or have multiple shared users on a single terminal, or have shift working that overlaps ongoing computer runs. In these cases the classic NT/2000/XP login and logout or screen-saver lock-out would effectively grind the laboratory to a halt because with this lock-out it is necessary for the first user to login past the screen-saver.

Having a group login password (and therefore group screen-saver password) for the authorized users of the computer as a first security shell, then using the application software logical security for individuals as the second security shell solves this problem. The assumption here is that the application software has adequate password security logic built-in and that this login can provide correct records attribution (putting the individual's username to the records). Alternatively, you can use the NT/2000/XP login to enable correct attribution of the user but remove the NT/2000/XP screen-saver and [lock computer] function and add another outer logical security layer with a separate password protected screen-saver software. Thirdly, you could allow (controlled by standard operating procedures [SOPs]) the laboratory supervisor to unlock the computer (with temporary use of the administrator password) for new users to enter the computer.

The restriction of the rights of the users to change screen-savers, change the clock, unduly alter the system configuration (by adding or removing software applications, for instance) and change the rights of themselves and others is necessary for Part 11 compliance. This restriction is easily obtained in NT/2000/XP environments by defining users in the [user] or [poweruser] category. All software applications I have encountered can be made to run in this mode (sometimes, some extra effort is involved where applications were originally designed for local system administrator rights to work).

For systems that have non-standard proprietary software (which is not uncommon in QC laboratories and very common in research laboratories), more thought and specialist expertise is needed to gain adequate logical security. Don't forget the physical security option as the last resort. My colleagues and I have not yet been defeated by any computer-controlled laboratory system in the task of adding adequate security.

Audit trail. The requirements and definitions for audit trails in computers and software are fully met by many laboratory software products already. Many products provide highly sophisticated audit trail software with numerous choices of granularity (level of detail that can be controlled and accessed). So buying new software (or upgrades to existing versions) with these adequate features is the obvious remedy in many instances. However, many audit trails cannot track the most deviant possible modification of a record, namely - deletion of computer files. Therefore, I suggest the following simple approach to the 'audit trail issue' regardless of the sophistication of any audit trail software that may be available for some applications. Set up the computer system so that no files generated by users can be modified or deleted. Only system administrators, directed by laboratory supervisors, can purge and delete files in a controlled and recorded manner. Not only is this a simple and logical approach to the problem, it is also relatively simple to set up in NT/2000/XP environments (and only moderately difficult in most Windows 95/98 environments).

In this way, the audit trail of the electronic records is just the directory list of the electronic records themselves. There is no need for a separate audit list of record changes because there are no modifications or deletions by users to records. The computer files will have the username and creation time and date stamp automatically added to the file metadata. Part 11 does not require any 'reason for creation' of the files in the audit trail metadata. Note: many audit trail software modules include a field for adding text to describe the reason for the change. Part 11 does not specifically require this feature but, it is argued, predicate GMP and GLP rules on record modification require this. This omission may have been an oversight by the Part 11 law makers. By contrast, UK GLP regulations on computers used in GLP studies specifically ask for reasons for change in the audit trail.

Ability to make accurate copies of records and printouts for use by FDA. All electronic records that can be saved to a durable computer medium can be copied. For simple file structure systems, copying files is trivial. For object-oriented relational database systems, it is not trivial. Records in such databases are objects and combinations of objects that cannot be easily viewed outside the database structure itself. If FDA really wants to view data in a relational database, suggest that they visit the laboratory site and login to the database as a guest user. Remote access to such databases is possible but would require special software to be installed and configured in the FDA offices.

The requirement that audit trail records are available for agency review and copying (Part 11 Ref: 11.10[e]) is often interpreted to mean the ability to print audit trail information to paper. Some audit trail tables in software packages and databases do not have a [print] menu choice. This can be overcome because all information that shows on a computer screen can be printed to paper and as the last resort you can capture the screen view using [prnt scrn] or [alt][prnt scrn] and save the resultant clipboard image in a suitable file format ready for paper printing. On my computer I have installed software that allows the [prnt scrn] or [alt][prnt scrn] operation to print directly through Acrobat Distiller to make an accurate and secure PDF file copy of the screen image ([alt][prnt scrn] captures only the active window not the whole screen).

Some workers on Part 11 assessments have experienced difficulties on these two requirements and, as a result, have scored some of their computer systems as non-compliant regarding the making of copies and printing of records. My colleagues and I have not yet encountered a standard computer system that cannot be adapted to meet the copying and printing requirements of Part 11.

Electronic, digital and handwritten signatures captured electronically. As many of the raw data and original records generated in laboratories are in electronic format, these are 'electronic records' as defined by Part 11 (but only applicable if related to submissions or products marketed in the US). If, in addition, some of these records require a signature (which is the case for most GMP laboratory records) it follows that these signatures must be committed electronically to the electronic records. It would seem most workers to date - probably through fear of the consequences and the apparent lack of solutions - have avoided this logic.

As demonstrated by the title of the original FDA work "Electronic Identification/Signatures," they believed the key problem with electronic documents versus their paper equivalents was the inability to add signatures to the electronic versions. I believe that that technical problem is now substantially solved in the area of file structure documents.

The definitions at the start of the Part 11 law and Subpart C thereof describe all the attributes of and procedures required for electronic signatures. Digital signatures have the property of encryption into the electronic records which also provides "the ability to discern invalid and altered records" - useful for data transmission through 'open systems.' Electronic signatures, particularly non-biometric ones, have a long list of quite onerous procedural aspects needed to ensure compliance.

However, the third class, 'handwritten signatures executed to electronic records,' must only be safe from cut, copy and paste operations and not able to be used to falsify other records. The signature must link to the record securely and for the duration of the record. This type of signature is exempt from Subpart C.

I propose the use of a technology that provides handwritten signatures to be captured by a digitizing pad directly into the electronic record (or exact copy of that record) which is then embedded and encrypted into the electronic record. This has the multiple advantages of

• meeting the encryption definition and main goal of a Part 11 'digital signature' whereby data is secured through encryption and it allows systems to discern altered (but not deleted) records

• meeting the definition of a 'handwritten signature' in Part 11 including the signature linking requirement (Part 11 Ref 11.70)

• satisfying the meaning of a signature in GxP and all relevant wider legal definitions (the technology is used widely in the legal profession and insurance companies)

• not being an 'electronic signature' (password type or biometric type) according to Part 11 therefore does need to meet Subpart C, which is extremely onerous and expensive to implement.

The technology can be used to commit GxP-valid signatures to Adobe Acrobat PDF documents and Microsoft Excel workbooks (but I currently advise against using it in Microsoft Word for various technical and strategic reasons). All electronic records that can be saved to a durable computer medium can be converted to PDF documents as accurate copies. Nearly all paper records can be scanned into PDF format electronic records. (Oversize documents, staples, sticky tape and badly damaged specimens present the challenge!)

Another particular advantage of this technology is the ability to sign and encrypt Excel spreadsheets, which effectively solves the well-known problems of securely keeping Excel workbooks as original electronic records.

Electronic record archival

Although there are few column inches devoted to the problem of archiving electronic data in the Part 11 preamble and law, this subject represents by far the biggest technical challenge. The problem is at its most complex in the field of laboratory electronic records where a multitude of file formats and application software exists already, and the rate of change is high. In addition, many of the electronic record types (chromatography, spectroscopy and mass spectrometry files) absolutely need to be viewed in the original application software to gain the full information contained in them. There are technologies that convert many (but not all) of these specialist file formats to a more universal format but none of the current archiving technologies can as yet be confidently called 'proven.'

Proposed approaches to this problem are outside the scope of this article. Much more work needs to be done in this field and the reader should continue to look out for the latest developments because these may influence future strategies for computing procurement and subsequent validation efforts.

References

1 P. Coombes, "Valid analytical data. A valid analytical measurement is one with a known uncertainty where that uncertainty is smaller than the precision required to make a meaningful decision regarding the property being measured (the analytical requirement). Valid analytical data are records of the valid analytical measurement acquired, authenticated, stored and maintained in a way that preserves integrity and security," in Laboratory Systems Validation Testing and Practice (PDA/DHL, Bethesda, Maryland 20814, USA, 2002) ISBN: 1-930114-48-6.

2. "FDA's Motise Gives Preview of Part 11 in 2002," Part 11 Compliance Report 2(2) (23 January 2002).