21 CFR Part 11 -
Electronic Records and Electronic Signatures

Links to specific sections of the primer	Oher information in the tutorial
Introduction and Background Terminology Requirements of the Rule New Scope of 21 CFR Part 11 Justification and Documentation of Part 11 Applications Implementation Summary	References Links to Other Internet Sites Expert Advice Questions and Answers Not yet available About Labcompliance tutorials Warning letters/483s/EIRs

Forward this tutorial

Introduction

 

In 1997 the United States Food and Drug Administration (FDA) issued a regulation that provides criteria for acceptance by the FDA of electronic records, electronic signatures and handwritten signatures (1). This was done in response to requests from the industry. With this regulation, titled Rule 21 CFR Part 11, electronic records can be equivalent to paper records and handwritten signatures.

Such a regulation was important because electronic data handling offers noteworthy benefits in the manufacturing area and also for the huge amount of data generated in analytical laboratories. The use of fully electronic data acquisition, evaluation, management and archiving promises major improvements in the workflow.

The development of the rule was initiated around 1990 by the US Pharmaceutical Manufacturing Association (PMA, now Pharmaceutical Research and Manufacturing Association, PhRMA). Shortly after that the PMA and also the US Parental Drug Association (PDA) formed technical groups to address the subject. Industry representatives met many times with the FDA's task force under Paul J. Motise to determine how to accommodate paperless record systems under the current Good Manufacturing Practice (cGMP) regulations. The task force recommended publication of an “Advanced Notice of Proposed Rulemaking” (ANPRM) to obtain public comments on the issues involved.

The ANPRM was published in 1992. The FDA requested and received comments on a number of concerns. In 1994 the FDA published the proposed rule that incorporated many of the comments received to the ANPRM. Again, the FDA received comments from individuals, manufacturers and trade associations on the proposed rule. Finally, the rule became effective on Aug 20th, 1997 as 21 CFR Part 11. The rule is available on the FDA's website http://www.fda.gov/cder/esig/index.htm.

The new rule has high visibility and is the subject of discussion not only in the United States but also in many other countries. There are two reasons:

1. Many pharmaceutical companies located outside the US export drugs to the US market, and as such they have to follow US regulations. The FDA can inspect these companies according to US regulations. In case of non-compliance, the company is not allowed to export pertinent drugs to the United States, which can have a tremendous business impact.
2. Other countries have similar issues with electronic submissions and may use the US rule as a guideline for their local regulation. For example, in Japan a regulation on electronic signatures and records was released in April 2005.

The use of electronic records is expected to be more cost effective for the industry and the FDA. The approval process is expected to be shorter and access to documentation will be faster and more productive. Currently the use of electronic records as well as their submission is voluntary. Despite this voluntary character, pharmaceutical companies are already trying to implement the rule as quickly as possible because of three primary reasons:

1. In many situations using computers cannot be avoided, for example in analytical laboratories for automated data acquisition and evaluation. In this case the laboratories “must” comply with Part 11.

2. There may come a time when the FDA will no longer accept paper records and; Electronic records have some significant advantages vs. paper records: tangibly lower space requirements and easier retrieval are just two of those advantages.

The rule applies to all industry segments regulated by the FDA that includes Good Laboratory Practice (GLP), Good Clinical Practice (GCP) and current Good Manufacturing Practice (cGMP).

The rule has an impact on all FDA regulated industries that use computers for regulated activities.

Requirements of Part 11 are:

•  Use of validated existing and new computerized systems.
• Secure retention of electronic records and instant retrieval.
• User-independent computer generated time-stamped audit trails.
• System and data security, data integrity and confidentiality through limited authorized access to systems and records.
• Use of secure electronic signatures for closed and open systems
• .Use of digital signatures for open systems.
• Use of operational checks.
• Use of device checks.
• Determination that the persons who develop, maintain or use electronic systems have the education, training and experience to perform their assigned task

Implementing Part 11 has a significant impact on the instrumentation, the work processes and on the people in operations such as quality control laboratories and manufacturing operations.

• ·The current process of generating signatures has to be evaluated
  (Who has to sign what and when?).
• New procedures have to be developed in the company and in the laboratory for limited authorized access to systems and data (Who can do what?).
•  Computerized systems used for implementation must be updated or replaced to ensure correct functionality.
• The manner of using and handling I.D. codes and passwords as a basis for “legally” binding signatures may have to be changed.
• New specialists, for example, “electronic archivists”, may be required.

Although the rule is well-documented and the FDA gave an interpretation to 130 industry comments in their preamble, corporate IT professionals and analysts in laboratories are often unsure when it comes to implementation. Although in some areas the regulation is very specific, for example, it not only requires an electronic audit trail to demonstrate data integrity, it also specifies some attributes, but in other areas it leaves a lot of room for interpretations, for example, about the scope of Part 11. The biggest problem is finding a compromise between doing too much and satisfying minimum requirements.

Frequent questions are:

• Exactly which records should be retained? (Especially when data has to be re-evaluated several times before it can be finally accepted).
• When do we need computer generated audit trails and how do we implement them? What should be tracked and after which entries does the user of the system have to confirm the entries as being logged?
• How do you bind electronic and handwritten signatures with the electronic records?
• What do we do with existing computer systems that don't have the appropriate functionality?
• What records should we archive: original electronic records, standard files such as PDF or XML, or can we make printouts and delete the electronic records?
• The FDA promotes risk-based compliance, what does this mean for Part 11?

This ´tutorial will give an overview on key requirements and discuss the FDA’s new and narrower approach and the scope of Part 11. In the second part it will discuss specific requirements more in detail, for example, validation and long-term archiving and retrieval of electronic records. We will also discuss specific applications, for example, using the Internet and Intranet and Excel applications in FDA regulated environments.

 

Terminology

A clear understanding of the terminology is of utmost importance for a common understanding of the rule and its implementation. Therefore we will dedicate this chapter to terminology. All quotations come from 21 CFR Part 11 (1).

Electronic Records

Electronic records are "any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system".

Closed system

A closed system is defined as an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system.

Open system

An open system means an environment in which system access is not controlled by persons who are responsible for the content of electronic records that are on the system.

Practically all systems in analytical laboratories are closed systems. With an appropriate security system in place, the laboratory has full control on who will access the system. An open system in a laboratory would be one where the data is stored on a server that is under the control of a 3rd party. Other examples for open systems are websites where everyone has access.

Electronic Signature

An electronic signature is "a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual's handwritten signature".

Electronic signatures are the electronic equivalent to handwritten signatures on paper. They may be based on biometric identification methods like fingerprint scanners or facial and voice recognition, but a simple combination of a user I.D. and password is also sufficient. Within a company, the user I.D. must be unique to a specific person. Electronic signatures are sufficient for closed systems.

Digital signature

A digital signature is "an electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters such that the identity of the signer and the integrity of the data can be verified".

Digital signatures are required for open systems and as such need higher security levels. Therefore, in addition to electronic signatures, cryptographic methods have to be applied for authentication of the user and integrity of the record.

Biomeric

Biometrics is "a method of verifying an individual's identity based on measurement of the individual's physical feature(s) or repeatable action(s) where those features and/or actions are both unique to that individual and measurable".

Examples of biometrics include facial recognition, voice recognition and fingerprint scanners. Most of them need specific hardware and software. The biggest problem with such devices is validating that they work reliably for the specified user but not for anyone else.

Hybrid systems

Hybrid systems are a combination of electronic records and paper records. They are common systems in analytical laboratories today. Raw data are recorded electronically to reconstruct the analysis but the final results are printed and signed on paper. The FDA does not prohibit hybrid systems but has expressed some concerns about their acceptability.

Meta data

Meta data is important for reconstructing a final report from raw data. In chromatography it includes integration parameters and calibration tables.

Predicate rule

Predicate rule as referred in 21 CFR Part 11 are the 21 CFR Food and Drugs regulations (besides 21 CFR Part 11). They are basically promulgated under the authority of the Food, Drug and Cosmetic Act or under the authority of the Public Health Service Act.

t Specifications for Software and Computer Systems (E-153).

 

Requirements of the Rule

21 CFR Part 11 includes 36 pages out of which only 3 pages constitute the rule itself, the other 33 pages are a preamble with comments from the FDA on feedback from the industry. Part 11 has a total of 19 requirements. Some of them are specific to Part 11, others are more generic requirements of some or all FDA regulations. In this section we list the most important requirements and give some interpretations for implementation.

System Validation – 11.10(a)

"All computer systems used to generate, maintain and archive electronic records must be validated to ensure accuracy, reliability, consistent independent performance and the ability to discern invalid or altered records".

That condition applies to both new and existing systems. This is nothing new for operations using computers in a regulated environment. Validating computer systems has been very well described and most companies have developed strategies for implementation. The problem lies not as much with new or fairly new systems but more with older systems. They require a formal evaluation and a statement on their validation status. If an older system cannot be validated it should not be used under 21 CFR Part 11. Information on validating software and computer systems can be found in References 2 and 3. The extent of validation depends on the complexity of the system and impact of the system on product quality and data integrity.

Validation should include application specific functions as well as functions related to Part 11, electronic audit trail and electronic signatures. Recommended test procedures include:

1. Limited and authorized system access. This can be achieved by entering correct and incorrect password combinations and verifying if the system behaves as intended.
2. 2. Limited access to selected tasks and permissions. This can be achieved by trying to get access to tasks as permitted by the administrator and verifying if the system behaves as specified.
3. 3. Computer generated audit trail. Perform actions that should go into the e-audit trail according to specifications. Record the actions manually and compare and contrast the recordings with the computer generated audit trail.
4. 4. Accurate and complete copies. Calculate results from raw data using a defined set of evaluation parameters (e.g., chromatographic integrator events, calibration tables etc.). Save raw data, final results and evaluation parameters on a storage device. Switch off the computer. Switch it on again and perform the same tasks as before using data stored on the storage device. Results should be the same as for the original evaluation.
5. Binding signatures with records. Sign a data file electronically. Check the system design and verify that there is a clear link between the electronic signature and the data file. For example, the link should include the printed name or a clear reference to the person who signed, the date and time and the meaning of the signature.

Secure Retention of Electronic Records and Instant Retrieval – 11.10(b) and 11.10(c)

"Procedures should be in place to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Records must be protected to enable their accurate and ready retrieval throughout the records retention period".

The agency wants to be able to trace final results back to the raw data using the same tools as the user had when this data was generated. This is probably one of the most difficult requirements to implement. Knowing that in some instances the records must be kept for ten or more years, and as computer hardware and software have a much shorter lifetime, one can anticipate problems with this paragraph. While with the original interpretation of Part 11 this was required for each record and records had to be retained in their original form for the full retention period as required by the predicate rule, this has changed with the FDA’s new scope. Depending on a company’s business practices, on the value of the record over time and based on justified and documented risk assessment the new interpretation allows to copy the electronic records to paper or to standard electronic formats such as PDF (Portable Data Format).

Limited Access – 11.10(d)

"Procedures should be in place to limit the access to authorized users".

Limited access can be ensured through physical and/or logical security mechanisms. Most companies already have procedures in place. For logical security users typically log on to a system with a user I.D. and password. Physical security through key locks or pass cards in addition to logical security is recommended for high-risk areas, for example, for data centers with network severs and back-data. These procedures should be very well documented and validated.

User-Independent Computer Generated Time-Stamped Audit Trails – 11.10(e)

"Procedures should be available to use secure, computer generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying".

This paragraph has been the subject of many questions and discussions. The problem lies mainly in how it is implemented, especially which details are recorded. Most important is the word “independently”, which means independently from the operator. The main purpose is to ensure and prove data integrity. If the data has been changed the computer should record what has been changed and who made the change. The audit trail functionality should be built into the software and is especially important for critical computer related processes with manual operator interaction.

Use of Secure Electronic Signatures for Closed and Open Systems – 11.10(j)

"The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to determine record and signature falsification".

The main purpose of this requirement is to link electronic signatures to relevant electronic records and also to the signer of the records. The signer should be recognized by the system through user I.D. and password and procedures and technical controls should ensure that the signer is uniquely identified. This definitely requires not only the development of procedures but even more importantly behavioral changes on using I.D. codes and passwords. The taboo against sharing a password with a colleague is usually much lower than teaching somebody how to abuse a handwritten signature. But under Part 11 both have the same consequence. Software should also recognize any change to a signed record. Typically this is done through linking the electronic signature to the electronic audit trail.

Enforcement of Permitted Sequencing – 11.10(f)

"Procedures should be in place for the use of operational system checks to enforce permitted sequencing of steps and events, as appropriate".

This requirement should ensure that once permitted steps are specified for a sequence the steps are executed in the specified order. A system should either have a written SOP or built-in front-end software that only permits the user to perform a task in the appropriate prescribed manner. In addition, the software can also have limits so that only a value within a specified range (e.g. weight) or format (e.g. date) can be entered to let users continue. The use of operational checks is not required in all cases.

Use of Authority Checks – 11.10(g)

"Procedures should be available to use authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand".

Authority checks must be in place to ensure “authenticity, integrity and confidentiality” of electronic records, and to ensure that the signer cannot “readily repudiate the signed record as not genuine”. This requires procedural and technical controls. Procedures should be in place to assign access to systems and permitted tasks to individuals and the system should be able to verify that an individual is permitted or authorized to perform the requested function. Authority checks should be used when an individual attempts to: access a system.

•  Perform selected permitted tasks.
• Change a record.
• Electronically sign a record.

Use of Device Checks – 11.10(h)

"Procedures should be available to use device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction".

This requirement refers to automatically determining the identification and location of a piece of equipment hardware or another computer system. An example would be that a computer system controlling an instrument should automatically recognize the equipment as a valid input device through its serial number. If the serial number is not set up in the computer’s database the instrument cannot be used as an input device.

Device checks are not required in all cases but only “where appropriate”.

People Qualification – 11.10(i)

"Procedures should be available to determine that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks".

People qualification is a GxP requirement and not specific to Part 11. Procedures should be in place to document tasks and qualifications, to develop a gap analysis and to develop an implementation plan on the gaps that can be filled. This paragraph applies to users as well as developers of systems and also to people supporting all kinds of computer systems including network infrastructure. It also applies to part time employees as well as to 3rd parties, for example, external service providers supporting an IT infrastructure.

Individual Accountability – 11.10(j)

"Procedures should be available to establish, and adhere to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification".

Procedures should make employees aware that electronic signatures have the same meaning as handwritten signatures. The content of the procedures should be communicated in trainings and enforced. It is recommended that employees should sign a statement like: “I understand that electronic signatures are legally binding and have the same meaning as handwritten signatures”.

Controls Over System Documentation – 11.10(k)

"Procedures should be in place for appropriate controls over systems documentation including: (1) Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance. (2) Revision and change control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation".

System documentation includes all lifecycle documents from validation planning, vendor assessment, development documentation and specifications, to installation records, operation and test procedures and protocols, change control and procedures to ensure system security and the operator’s authenticity. All documentation should follow approved change control processes and should be under revision control. Controls should be in place to ensure that the most recent version of the document is always used.

Use of Digital Signatures for Open Systems – 11.30

"Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include those identified for closed systems, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality".

This requires software for document encryption and may also require hardware and software for generating digital signatures. Typically computer systems used in pharmaceutical operations are closed systems without a need for digital signatures. An example for an open system would be if analytical data generated by a contract laboratory is transmitted to the sponsor through the public Internet. Examples on how open systems can be used are described in Reference 5.

 

New Scope of 21 CFR Part 11

 

Although 21 CFR Part 11 has been in place for 10 years and enforced started eight years ago, there is still confusion in the industry on how to implement it. The regulation itself, earlier draft guidance documents and early interpretations of FDA staff defined an electronic record as "Electronic record means any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system". No distinction was made between the type of records or their criticality. Part 11 compliance was requested for all such records that have passed through any computer and the FDA could ask for such records at inspections. With this very broad interpretation full implementation turned out to be very expensive and for some applications almost impractical. In some cases, companies even decided against the use of new technology and stayed with paper because of the anticipated additional complexity and cost involved with the implementation of the technical control required by the rule. However, this was clearly not the original intent and spirit of the rule which was issued to protect and further public health while at the same time enabling the use of new technology!

With the release of the draft guidance on “Scope and Applications for Part 11” in February 2003 (5) the FDA promoted a new and narrower approach. With the final guidance released on September 3, 2003 and the FDA’s announcement to re-examine Part 11 and initiate a new rule-making process, this new approach became official and most probably will be the basis for an updated regulation in the future.

The guidance states that Part 11 applies when:

1. The record is required by a predicate rule, e.g., electronic batch records for 21 CFR Part 211 and electronic training records in 21 CFR Part 58.
2. The electronic records are used to demonstrate compliance with a predicate rule, e.g., electronic training records for compliance with 21 CFR Part 211.

Part 11 applies in one of the following situations:

1. When electronic records are used instead of paper.
2. When persons make printouts but still rely on the electronic records in the computerized system to perform regulated activities.
3. Records submitted to the FDA, under predicate rules (even if such records are not specifically identified in agency regulations) in electronic format.
4. Electronic signatures intended to be the equivalent of handwritten signatures, initials and other general signings required by predicate rules.

While 1, 3 and 4 are obvious, 2 requires some interpretation. It is related to hybrid systems where the computer is used to generate, evaluate and/or transmit electronic records and the final results are printed and the printout is maintained as the “master” record. The question is if the electronic records existing on the computer system must comply with Part 11.

FDA representatives interpreted this situation in various presentations. The recommendations are illustrated in Figure 1. First we check if the record is required by a predicate rule or used to demonstrate compliance with a predicate rule. Next, we determine if the record fits in the new, narrow scope. The main criterion is whether the record is maintained in electronic format in place of paper format, or if the record is maintained in electronic format in addition to paper records and if persons rely on the electronic record to perform regulated activities. A “regulated activity” is any activity that is required by a FDA regulation, for example, analytical test results are required to be recorded by the FDA’s 21 CFR Part 211. In this case the regulated activity is not limited to signing the record, for example, a paper printout of an electronic record, but it also includes all steps from data acquisition and evaluation. Finally, we make a risk assessment of the criticality of the Part 11 records and document the result. Based on the outcome appropriate Part 11 controls are implemented.

The last criterion is to evaluate the level of risk the record has on product quality and data integrity. Examples of high-risks records are electronic batch records and analytical records of final product testing. Errors at this stage will not be identified and can no longer be recovered before the product is shipped to the market. An example of a low-risk record would be electronic planning documents such as cleaning or maintenance schedules. Electronic standard operating procedures could fall into the medium or low risk category, depending on what impact the procedure has on product quality

 

Figure 1: Steps to determine if records are in the scope of part 11

 

The guidance makes a statement that the FDA will reexamine Part 11 and exercise enforcement discretion for certain Part 11 requirements until the new Part 11 is released: "While the re-examination of Part 11 is under way, we intend to exercise enforcement discretion with respect to certain Part 11 requirements". Four other paragraphs are equally important:

1. "That is, we do not intend to take enforcement action to enforce compliance with the validation, audit trail, record retention, and record copying requirements of Part 11 as explained in this guidance".
2. "However, records must still be maintained or submitted in accordance with the underlying predicate rules, and the Agency can take regulatory action for noncompliance with such predicate rules".
3. "Note that Part 11 remains in effect and that this exercise of enforcement discretion applies only as identified in this guidance".
4. "We will enforce all predicate rule requirements, including predicate rule record and recordkeeping requirements".

While everybody seems to read and understand the first part of #1 the words “as explained in this guidance” as well as the second, third and fourth paragraph are frequently overlooked. For example, validation and audit trail are requirements of many predicate rules and the FDA can always take actions if they find deviations from predicate rules.

In the next few chapters we will take a closer look at the requirements.

Validation

The guidance states:

1. "The Agency intends to exercise enforcement discretion regarding specific Part 11 requirements for validation of computerized systems (§ 11.10(a) and corresponding requirements in § 11.30)".
2. "Although persons must still comply with all applicable predicate rule requirements for validation (e.g., 21 CFR 820.70(i)), this guidance should not be read to impose any additional requirements for validation".
3. "We suggest that your decision to validate computerized systems, and the extent of the validation, take into account the impact the systems have on your ability to meet predicate rule requirements".
4. "We recommend that you base your approach on a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety, and record integrity".
5. "For instance, validation would not be important for a word processor used only to generate SOPs".

With #5 the guide gives an example on the meaning of enforcement discretion. With the old interpretation there were lots of discussions about Part 11 compliance of computer systems like word processing systems. With this statement the FDA would not expect that such systems should be validated.

While in the example of word processing systems the situation is quite obvious, in other examples it is not. The FDA expects a justification based on a documented risk assessment (see #4 of above) for all computer systems that are not validated or not fully tested.

Our recommendations are:

1. Define risk categories for computer systems, for example, high, medium or low.
2. For each validation phase define the extent of validation for each risk level. For example, vendor assessment for a high-risk system may require a vendor audit and for medium and low risk systems just documentation on the vendor’s reputation and experience.
3. Assign each individual computer system used for GxP applications to a specific risk level.
4. Define validation steps for each individual system.

The four steps are very well described in a reference paper “Risk-Based Validation of Commercial Off-the-Shelf Computer Systems” (7). We recommend developing a procedure for consistent implementation. An example SOP is shown in Reference 8.

 

Audit Trail

The guidance states:

1. "The Agency intends to exercise enforcement discretion regarding specific Part 11 requirements related to computer-generated, time-stamped audit trails (§ 11.10 (e), (k)(2) and any corresponding requirement in §11.30)".
2. "Persons must still comply with all applicable predicate rule requirements related to documentation of, for example, date (e.g., § 58.130(e)), time, or sequencing of events, as well as any requirements for ensuring that changes to records do not obscure previous entries".
3. "We recommend that you base your decision on whether to apply audit trails, or other appropriate measures, on the need to comply with predicate rule requirements, a justified and documented risk assessment, and a determination of the potential effect on product quality and safety and record integrity".
4. "Audit trails can be particularly appropriate when users are expected to create, modify, or delete regulated records during normal operation".

Audit trail is a requirement of some FDA predicate rules, for example 21 CFR Part 58 (GLP). Others don’t specifically mention audit trail but require changes to data to be recorded, for example 21 CFR Part 211 (drug cGMP) states in Paragraph 194b: "Complete records shall be maintained of any modification of an established method employed in testing. Such records shall include the reason for the modification and data to verify that the modification produced results that are at least as accurate and reliable for the material being tested as the established method". If the audit trail is not generated by the computer it should be generated manually, as a minimum. A record’s integrity is a basic requirement of regulations and users of computer systems must be able to demonstrate this, especially for critical records.

#3 above mentions “other appropriate measures”. This means you can use other techniques to demonstrate record integrity, for example to demonstrate file integrity through hash values.

#4 is important as it talks about manual interaction with the system. It is difficult to demonstrate record integrity if users sit in front of a computer and can change data on the screen if there is no electronic audit trail. This becomes really critical if a change of such data can have an impact on critical records, for example, accuracy of product test results. In this case the system should have a built-in electronic audit trail and the function should be validated. This is one example where discretion would not be exercised “as explained in this guidance”.

 

Copies of Records

The guidance states:

"We recommend that you supply copies of electronic records by":

1. "Producing copies of records held in common portable formats when records are maintained in these formats".
2. "Using established automated conversion or export methods, where available, to make copies in a more common format (examples of such formats include, but are not limited to, PDF, XML, or SGML)".
3. "In each case, we recommend that the copying process used produces copies that preserve the content and meaning of the record".
4. "If you have the ability to search, sort, or trend Part 11 records, copies given to the Agency should provide the same capability if it is reasonable and technically feasible".
5. "You should allow inspection, review, and copying of records in a human readable form at your site using your hardware and following your established procedures and techniques for accessing records".

Copies of records is one of the most heatedly discussed Part 11 requirements. During the generation, evaluation, transmission and storage of electronic records different types of data are generated: original digital data, sometimes also called raw data, meta data, intermediate results and final results. Final results are either kept in electronic form, or they are converted to paper or standard electronic files such as PDF or XML format.

In #1 and #2 the guide recommends different formats which typically is quite easy to comply with. The more stringent requirement comes in #3: preserve the content and meaning. Frequently it is not a problem to preserve the content and meaning when converting original data. For example, when converting a word document to a PDF file, most often the content and meaning is preserved. You may loose some of the property information but this does not change the meaning of the document. The situation looks different if you convert graphics with a variety of different resolutions. With a PDF file you may not be able to zoom into the details. If you need the highest resolution to demonstrate compliance you may need the original software.

Sometimes the question comes up if a firm can keep the original records and software for scientific reasons and make printouts for the inspector. #4 and #5 make it very clear that the FDA wants to have the same capabilities that the user has at the time of inspection, this means access to the database and software for data sorting, searching and most likely reprocessing.

Record Retention

The guidance states:

"We recommend that you supply copies of electronic records by":

1. "The Agency intends to exercise enforcement discretion with regard to the Part 11 requirements for the protection of records to enable their accurate and ready retrieval throughout the records retention period".
2. "We suggest that your decision on how to maintain records be based on predicate rule requirements and that you base your decision on a justified and documented risk assessment and a determination of the value of the records over time".
3. "FDA does not intend to object if you decide to archive required records in electronic format to nonelectronic media such as microfilm, microfiche, and paper, or to a standard electronic file format (examples of such formats include, but are not limited to, PDF, XML, or SGML)".
4. "Persons must still comply with all predicate rule requirements, and the records themselves and any copies of the required records should preserve their content and meaning".
5. "As long as predicate rule requirements are fully satisfied and the content and meaning of the records are preserved and archived, you can delete the electronic version of the records".

The issues with record retention are somewhat similar as with copying records. While the original interpretation of Part 11 required maintaining the records in original form with reprocessability throughout the entire retention period as required by the predicate rule, the new approach allows other options. Most important is the statement that decisions about the retention format should be based on the record’s value over time. The value of a record is at its highest at the time when it is created, processed and displayed or printed. The information is used to make decisions about a product release, for example. If there is any doubt about correct processing the data can be reprocessed either with the same or with different parameters, if this is scientifically justified.

The value remains fairly high after the product is shipped until it is fully accepted by the market, which means no complaints from clients. The record quickly looses its value in the first years and the main reason to retain it is to have it available for the next FDA inspection. In research and development companies the value of the original record with reprocessing capability remains high for a longer time for scientific reasons. Such facilities want to be able to go back and look at the data again if new scientific challenges come up.

The guide allows converting of the records into different formats such as paper, microfiche or standard PDF files as long as the new format can be used to preserve content and meaning and to demonstrate compliance with the predicate rule. The main question is whether a paper printout or PDF format has all the information to demonstrate compliance or if the original record and software for reprocessing is required.

For hybrid systems the FDA inspector will normally ask for the paper printout. If this includes all information original electronic records are not required. However, in many situations they do not include all information to preserve the content and meaning. An example is a computerized analytical instrument, for example, a computerized liquid chromatograph with spectral capability for peak purity and compound confirmation.

Figure 2 shows the records generated during and after an analysis and all this information should be recorded either because it is directly required by a predicate rule or to demonstrate compliance with a predicate rule. While clients are primarily interested in the analysis results with graphics showing the chromatogram and tables with sample amounts, the FDA may want to see traceability of the final results back to instrument and method parameters, instrument I.D., operator name, chromatographic parameters, peak integration marks and calibration tables and audit trails for re-integration. As it is inconvenient and very difficult to print all this information for each analytical result it is recommended to keep it in original electronic form together with the original software for reprocessing if the need arises.

 

Figure 2: Records in Chromatography

 

Problems arise when the original software is no longer supported or can no longer be used for other reasons. In this case records can be either migrated to work with updated or new software or can be converted to other formats, such as paper. The time frame for this is typically not less than 3 to 5 years and the records have already lost much of their value for the company and for the FDA.

 

Justification and Documentation of Part 11 Compliance

 

As explained in the previous paragraphs implementation of some Part 11 controls should be based on a couple of criteria such as:

• Is the record required by predicate rule?
• Is a regulated activity dependent on the record?
• What is the company’s business practice?
• Have operators or supervisors access to data, can they change data and can such data impact product quality?

If Part 11 controls are not implemented the FDA wants to see a documented justification as to why not. Therefore each company is advised to prepare such documentation. An example is shown in Figure 3 for a computerized analytical system used in a pharmaceutical quality control laboratory. The left upper part of the figure shows a graphical representation of the system. The right upper part lists the business practices.

The sample is injected into a computer-controlled liquid chromatograph. The signal is acquired by the PC (computer 1) and original data are stored on the computer as digital data. Data are automatically processed on this computer and results are transferred together with the evaluation parameters to a second PC with a database (computer 2) for storage and printout. The operator reviews the printout and depending on the findings may decide to manually reevaluate the data. Finally the records are maintained in electronic form because the company may need to reprocess the data later on for business reasons.

The left lower part of the figure shows a legend with information on who has access to the data on which computer and what data can be changed. In the right lower part of the figure we document the criticality of the record, if the record is required by a predicate rule and if the regulated activity depends on the record. In the middle lower part of the figure we document our decisions and justifications.

Both computer systems must be validated according to the high-risk categories. Computers 1 and 2 should have a built-in electronic audit trail because operators have access to the records and operators can change records, they are required by predicate rule and regulated activities depend on the record. We also keep the records in electronic form in addition to the paper printout because they may be needed to demonstrate compliance with the predicate rule and the company may also maintain the records in electronic form for other business reasons.

 

Figure 3: Documentation of Part 11 Controls

 

Applications

 

We frequently hear questions such as:

•  Does this software have to comply with Part 11?
• I am using a system xy from vendor xz, do I have to comply with Part 11?
• Our software does not have electronic audit trail, can I still use it for GxP applications?
• Can I use the Internet on the same computer where I run GxP applications?
• I print my GxP records right after acquisition without operator interaction, does Part 11 apply?
• I am using Excel templates as a sophisticated calculator. I don’t store records electronically. Does Part 11 apply?

Despite going through previous chapters of this primer, the answers are not readily available for all questions. Questions like this can only be answered when one has a good understanding of the application as well as a good understanding of Part 11 principles. There are three sources for getting information.

· In this chapter we will discuss the most commonly used applications.

Reference 11 includes an extensive list of questions and answers.

Spreadsheet Applications

Spreadsheet applications are popular in all kinds of businesses. Results generated are frequently used to make business decisions. They are also frequently used in regulated environments, for example, batch releases in pharmaceutical manufacturing can be based on calculations by spreadsheets. Spreadsheet programs were not designed for the regulated environment and without preventive actions the risk that they will generate errors is relatively high.

There are four possibilities to solve or reduce the compliance problem:

1. Perform the tasks using other software that better enable users to comply with regulations.
2. Change the way spreadsheets are developed and used and apply all functions built into the spreadsheet programs to increase the level of compliance. Develop a gap analysis and a corrective action plan. One action item can be step 3.
3. Evaluate and implement “add on” software packages that better enable users of spreadsheet programs to comply with regulations.
4. Use data management software with built-in Excel support and Part11/GxP functionality

While all four options are good alternatives we believe that #2 has the most long-term benefits. It requires a good understanding of the spirit of Part 11 and a good technical understanding of spreadsheet programs, for example, Excel. Most important is to understand the functions to ensure spreadsheet security and integrity.

We recommend the following steps:

1. Develop, communicate and enforce a company policy and master plan for spreadsheet calculations.
2. Prepare an inventory list with all computers that run spreadsheets.
3. Standardize “development and use” as much as possible.
4. Protect spreadsheets using built-in standard software and IT infrastructure (e.g., client/server).
5. Validate spreadsheet calculations.
6. Follow recommendations in Chapter 4 of this primer to define and document other Part 11 controls and extent of implementation.
   Document and justify your approach.

Labcompliance has developed a Macro & Spreadsheet quality package (9). In this package each step is explained in detail. The package also includes SOPs, templates and examples for easy implementation.
The package can be ordered from: www.labcompliance.com/books/macros.

Figure 4 shows the result from an Excel application. The Excel spreadsheet was optimized for highest data integrity, easy use and lowest failures raters. This was achieved through:

• Limited and authorized access to the spreadsheet through a secure server.
• The server directory is write-protected. Therefore the spreadsheet cannot be changed and saved on the same directory.
• The source directory, file name and revision number of the spreadsheet are printed together with the results. This demonstrates that only the original spreadsheet has been used.
• Cells for data entry are in green. This makes it easy for the user to only access cells for data entry.
• Cells that are not used for operators are protected and cannot be used.
• Cells with results that are in specifications are in green and cells with results that are out-of-specifications are in red.
• If there are out-of-specifications results operators get hints on what steps to take for corrective actions.
• Data input are validated for plausibility. Operators are alerted about input data that are outside allowed ranges. This reduces errors during data entry.
• Results are displayed in table and graphics form.
• All menu items have been removed. Operators are only able to start, print and exit.
• The entire spreadsheet is validated. The focus is more on checking limited access, retrieval of correct files and correct input and output locations than on verification of standard Excel calculations.

 Figure 4: Result of an Excel Application

 

Scanning Paper to Electronic Files for Archiving and Easier Search

Despite modern computer technology there are still many paper records generated. Archiving large numbers of paper records requires large storage capacities. Such paper archives are also more difficult to search than electronic databases. Therefore companies prefer to scan paper records into standard electronic files, such as PDF or XML and add meta data to facilitate any search.

This procedure complies with Part 11 and other regulations if specific controls are implemented. For example, 21 CFR Part 211.180 (d) allows to retain either original records or true copies: "Records required under this part may be retained either as original records or as true copies such as photocopies, microfilm, microfiche, or other accurate reproductions of the original records". Electronic standard files fall under the category “other accurate reproductions”.

To ensure compliance with Part 11 and other regulations, we recommend:

1. Develop a procedure for the entire process.
2. Validate the process to ensure “true copies”. This is best done by scanning a document that requires the highest resolution. Scan the document, print it and compare the printout with the original. Verify if the resolution is within previously specified acceptance criteria.
3. If an automated scanner is used, check if all pages have been scanned.
4. Convert the scan into a PDF file.
5. Save the PDF file with a high security option. This means users of the file can read but not change the file.

Internet

The Internet is increasingly used for all types of businesses. This also includes the healthcare business. Two main applications are the World Wide Web for all types of on-line transactions and e-mails for exchanging messages without and with attachments. An example where the Internet can be of significant advantage is shown in Figure 5. A pharmaceutical company outsources part of its clinical studies or laboratory analyses to a contract laboratory. The sample is sent through FedEx to the contract laboratory, analyzed and the data sent back to the sponsor through e-mail with attached reports.

 

Figure 5:

Figure 5: Internet Application

Other examples for using the Intranet or Internet in the healthcare business are:

• Release of batch approvals.
• · Approval and release of validation lifecycle checkpoints and validation and reports.
• · Electronic artwork transfer.
• Remote approval of Certificates of Analysis at contract laboratories.
• Updates, exchange and approval of training records and SOPs.
• Administration of electronic patient records.
• Billing information exchange between healthcare provider and insurance.
• Tele Medicine (remote surgery, diagnostics, imaging).
• Drug prescription online.
• Electronic patient card.
• Centralized and local patient data administration.

When transporting a clinical study or any other data as mentioned above, data traffic needs to adhere to:

• Confidentiality: The contents of the data should only be accessible by authorized persons.
• Integrity: The data should be exactly the same at source and destination computer.
• Authenticity: The authenticity of the sender of the data must be guaranteed.
• Non-repudiation: Sender and recipient of the data cannot deny to have sent or received the data.

The Internet by nature is an insecure and unreliable environment and therefore without special precautions it is not compliant with the requirements as mentioned above. However, when using the technical controls that are available today combined with procedures the Internet can be as “trustworthy” as paper systems. In this chapter we only give summary recommendations, more details can be found in the Labcompliance primer: “Using the Internet in Regulated Environments” (5).

1. Develop and enforce procedures for using the Internet. They should include:

• ·Training programs for theory and use of modern Internet technology.
• Security procedures.
• Procedures to protect computers from viruses.
• Procedures for downloading data from the Internet.

2. Encrypt all information sent through the Internet.

3. Use a Virtual Private Network (VPN) for remote access.

4. Validate applications on the sending and receiving computers.

5. Validate integrity of file transfer through checksum.

 

Program Logical Controller PLC

Program Logical Controllers (PLC) are used to control equipment used in manufacturing. Data are either entered manually or downloaded from a computer. Examples are temperature and pressure of an autoclave and valve positions. If data are entered through local controllers and actual conditions are printed through a local controller, such records are not in the scope of Part 11. However, if parameters are loaded from a computer and actual conditions are monitored and recorded through a computer with manual interaction through operators, Part 11 applies.

Networks

Most computer applications used in FDA regulated environments are probably supported by network infrastructure. In simple words the network can be seen as a big pipe where data are pumped through. Most important is to maintain trustworthiness of the data. There are a couple of considerations:

• Security: There are many connection points to the network. Connection through one port gives access to the entire network if there is no additional control to sections. Network security through physical and/or logical controls is of utmost importance. Technical controls should be validated and procedures enforced.
• Typically the network also supports high-risk applications such as back-up and archiving of high-risk records. Such applications should be validated and comply with Part 11.
• Loosing data or inaccurate file transfer is not only a business problem but also violates the requirement for trustworthiness. Therefore file transfer accuracy should be verified under normal and high load.
• Applications supported by the network should be validated. Examples include Electronic Batch Records (EBR) Systems, Enterprise Resource Planning (ERP) Systems and Laboratory Information Management Systems (LIMS). The test environment should include the same network components as the live environment.
•  Network infrastructure should be qualified. This mainly means good planning and documentation of the network through diagrams and inventory lists. It also means using a well-controlled procedures for changes.

In the following paragraphs the two steps for complete network qualification and system validation are briefly described. They have been extracted from Reference 10.

Steps to build a qualified network infrastructure:

• Specify network requirements.
  Specifications should include: network devices, software, computer hardware, computer peripherals and cables. Specifications are based on anticipated current and future use of the network.
• Develop a network infrastructure plan.
• Design network infrastructure and drawings.
• Select equipment and vendors for computers, NOS, network devices etc.
• Order equipment: computer hardware, software (OS, NOS), network devices, peripherals.
• Install all hardware devices according to design drawings and vendor documentation.
• Perform self-diagnostics, document hardware installation and settings (this completes the IQ part).
•  Document this as network baseline.
•  Make a back-up of installed software and network configurations. Whatever happens, it should be possible to return to this point.
• Test communication between networked computers and peripherals and access control including remote access control.
• Develop and implement rigorous configuration management and a change control procedure for all your network hardware and software. This should also include updates of system drawings if there are any changes.
• Before applying any system changes to a production environment they should be verified in a test environment to insure that they do not impact the intended functionality of the system.
• Monitor ongoing network traffic using a network health monitoring software.
  

Steps to validate a networked system:

• Develop a validation plan and schedule using your validation master plan as a guideline.
• Specify application software that runs on the qualified network e.g., networked data system.
• Select and qualify the vendor.
• Install application software and perform IQ set-up (define and document configuration settings, verify “proper” software installation through installation verification routines)
• Verify correct functioning of this application software. Apply common computer validation practices for this.
• Testing should include network transactions under normal and high load. For this test you can decide to refer to verifications done as a built-in TCP/IP transfer protocol. The advantage is that this is built into the system and done on an ongoing basis. However, this is not 100% accurate as there are rare situations where the test does not work. To be on the safe side, you should use something like MD5 hash calculation routines based on 128 bit strings. Ask the vendor of your application software as sometimes such tests are built-in.
• Monitor ongoing performance of your application. The type of performance test depends on the application.
• For networks supporting high-risk applications monitor network connections and traffic using a network health monitoring software.

As part of the installation system drawings and diagrams should be generated. They are an absolute must not only for setting up a network and networked systems but even more importantly for maintaining them. They should be part of the IQ documents and should include:

• Physical diagrams such as component locations and cabling.
• Logical diagrams like TCP/IP schemes and how components interrelate with each other.
• If dynamic IP addressing is used in the network scheme, a procedure should also be in place to indicate how this dynamic IP addressing is being utilized (including the procedure for sub-masking of the IP addresses). This will enable appropriate tracing of data or traffic flow, in case such a tracing is needed to prove the data integrity and security.

Networks change frequently, so maintaining these diagrams with documented version control is important. A good recommendation is to have procedures in place for regular review of these diagrams, for example quarterly

 

Implementation Summary

 

Implementing the regulation on electronic signatures and records will have major consequences. It is recommended to follow a step-by-step approach.

1. Form a task force with members from the IT department, if existing, QA personnel and laboratory staff.
2. Decide whether you intend to use electronic signatures. Report the decision to the FDA, for example: “This is to certify that "My Company" intends that all electronic signatures executed by our employees, agents or representatives, located anywhere in the world, are the legally binding equivalent of traditional handwritten signatures”.
3. Create awareness for Part 11 among all employees, especially on the accountability of electronic signatures. For example, people should sign something like this: “I understand that electronic signatures are legally binding and have the same meaning as handwritten signatures”.
4. Make an inventory of all computers in your organization or department that generate records required by a predicate rule or records that are used to demonstrate compliance with a predicate rule.
5. Develop a master plan and SOP for risk assessment.
6. Determine the risk category for each system.
7. Define a priority schedule to bring all computer systems into Part 11 compliance.
8. Develop a procedure on how to define Part 11 controls.
9. Define Part 11 requirements for each system.
10. Do a gap analysis to determine missing functionality and procedures for systems in 7.
    Develop an implementation plan to bring systems as identified in 7 into Part 11 compliance.
11. Estimate costs for the systems as identified in 7 and for the whole project.
    Develop procedures for limited system access to authorized individuals. This should include a password policy.
12. Develop procedures for implementing audit trails, to ensure data integrity and for long-term archiving with data retrieval throughout the entire retention period.
13. Get management support and funding for the project.

References

 

1. Code of Federal Regulations, Title 21, Food and Drugs, Part 11 Electronic Records; Electronic Signatures; Final Rule; Federal Register 62 (54), 13429-13466.
2. L. Huber, “Validation of Computerized Analytical and Networked Systems”, Interpharm Press, an IHS Health Group company, Englewood, Colorado, USA, ISBN 1-57491-133-3, approx. 250 pages, 2002.
3. GAMP 4 Guide: “Validation of Automated Systems”, ISPE, Brussels, 2001 (order from www.ispe.org).
4. Pharmaceutical Inspection Convention/ Pharmaceutical Inspection Co-operation Scheme (PIC/S): “Good Practices for Computerized Systems in Regulated GxP Environments”, 2003.
5. Labcompliance, Internet Quality Package, 2005.
   Order from www.labcompliance.com/books/internet.
6. FDA Guidance for Industry Part 11, Electronic Records; Electronic Signatures Scope and Applications (Draft February 2003, Final version August 2003). Available at http://www.fda.gov/cder/guidance/5667fnl.pdf.
7. L. Huber, “Risk-Based Validation of Commercial Off-the-Shelf Computer Systems”, Journal of Validation Technology, May 2005, Vol 11, No. 3.
8. Labcompliance Standard Operating Procedure; S-252. “Risk-Based Validation of Computer Systems”. Order from www.labcompliance.com/books/part11.
9. Labcompliance, Macro & Spreadsheet Quality Package, 2003.
   Order from www.labcompliance.com/books/macros.
10.  Labcompliance, Network Quality Package, 2005.
    Order from www.labcompliance.com/books/network
11. Labcompliance, “21 CFR Part 11: Electronic Records and Signatures”, Frequently Asked Questions. Order from www.labcompliance.com/books/part11
    
    

Links to Other Websites 

• FDA regulation and guidance documents related to Part 11
• International guidance documents related to computer systems
• FDA guidance documents related to computer systems
• FDA predicate rules
• Part 11 compliance package
• Computer system validation package

Expert Advice 

1. Recent FDA Inspection Findings Related to Part 11 and Computer Systems
   483's, Warning Letters, EIR's, Presentations: 2004-2007