FDAnews
www.fdanews.com/articles/88881-part-11-did-not-go-away-fda-official-says

'Part 11 Did Not Go Away,' FDA Official Says

November 7, 2006

While acknowledging that the original 1997 21 CFR Part 11 Rule was "broadly interpreted" and not risk-based, George Smith, consumer safety officer at the FDA, has reminded people in the past several months that the rule and the agency's commitment to edata integrity and retrievability are still important (see related story on page 5) (http://www.fdanews.com/Admin/issues/pir/6_22/fda/62356-1.html).

"Part 11 did not go away [and] some level of validation is still necessary," Smith said. He also noted that citations "should be made to the predicate rule, not specifically to Part 11." Consultants have told PIR in recent months that FDA inspectors have cited erecord-related issues in warning letters and other inspection documents without using the term Part 11.

Smith also noted that the 2003 revision of Part 11 emphasized that the predicate rule identified what records must be maintained, while "Part 11 addresses how those electronic records must be maintained."

Under the 2003 "narrow scope" reinterpretation of Part 11, the rule won't generally apply when computers are used to generate paper printouts of erecords if those paper records meet all predicate rule requirements and persons rely only on the paper records to perform regulated activities, Smith said. In addition, systems that don't generate erecords, such as programmable logic controllers, are also outside of the rule's scope.

However, Part 11 does apply if "you use electronic records to perform regulated activities, even if you generate a paper printout," he said.

FDA Submissions

For submissions to the FDA, Part 11 applies to erecords submitted if the records are not specifically identified in predicate rules, Smith said. However, Part 11 does not apply to those source records used in generating a submission unless a predicate rule requires those records to be maintained.

But the agency's commitment to its risk-based approach appears firm.

For example, Smith noted that validation and audit trails are both risk-based. When either is not covered in specific predicate rules, "a risk assessment should be performed to determine the level that is required to ensure record integrity," Smith said.

Copies of records do not need to be retained electronically, he said. They can be migrated to other formats, such as paper or microfiche, with appropriate controls. However, FDA-regulated life sciences companies must "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, he noted.

"If you have the ability to search, sort or trend records, copies given to [the] FDA should preserve [the] same capability if reasonable and technically feasible," Smith said.

Original erecords may be deleted after archiving if you comply with all predicate rule requirements and the archived copies preserve the "content and meaning of the original records," Smith said.

Legacy Systems

Management of legacy systems, or those systems in use before the rule was issued in 1997, are also risk-based. But this is another area where the FDA will apply enforcement discretion if the system has been operational before Aug. 20, 1997, complied with existing predicate rules as of that date, complies with current predicate rules and has documented evidence and justification that it is fit for its intended use.

"For legacy systems changed since Aug. 20, 1997, you should determine if the changes introduce possible risks to record security and/or integrity and apply Part 11 controls appropriately as per the scope and application guidance," Smith said. Changes that may invalidate Part 11 legacy status include change in intended use, functionality and use of collected data.

Generally, Smith said, the following types of changes won't impact Part 11 legacy status:

Hardware maintenance actions such as upgrades or replacements; Some software maintenance actions such as upgrades to an operating system; Software maintenance to resolve originally-intended use issues and functionality; and Relocation or redistribution of a system. -- Michael Causey