![](media/image1.png){width="0.6597222222222222in"
height="0.5590277777777778in"}

*EDUcation: QUality Engineering, Science, and Technology*

> 1896 Urbana Pike, Suite 14
>
> Hyattstown, Maryland 20871
>
> July 8, 2004

[VIA E-MAIL AND FACSIMILE (301-827-6870)]{.underline}

U.S. Food and Drug Administration

Division of Dockets Management (HFA-305)

5630 Fishers Lane (Room 1061)

Rockville, Maryland 20852

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_**

**)**

**U.S. Department of Health and Human Services )**

**)**

**Food and Drug Administration )**

**)**

**Electronic Records; Electronic Signatures; Public Meeting ) \[Docket
No. 2004N-0133\]**

**)**

**Notice of Public Meeting and Request for Comments )**

**)**

**69 Fed. Reg. 18,591 (April 8, 2004) )**

**\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_)**

**[EduQuest, Inc. Comments on FDA's Re-examination of 21 CFR Part
11]{.underline}**

EduQuest, Inc. respectfully submits these written comments in response
to FDA's April 8, 2004 Federal Register notice (69 Fed. Reg. 18,591)
concerning the ongoing re-examination of the 21 CFR Part 11 regulation
on electronic records and electronic signatures.

**[Background]{.underline}**

EduQuest is in a relatively unique position to comment on the issues
raised in the above-referenced Federal Register notice. During his
tenure at FDA, our company President, Martin Browning, co-chaired the
working group that drafted Part 11, served as one of the agency's
national experts on computerized systems, and was centrally involved in
establishing many of FDA\'s

regulatory approaches, guidance documents, and internal training related
to software and computerized systems. Our staff also includes other
former senior FDA officials, including several Investigators, a Director
of an Investigations Branch, and another of FDA's national experts on
computerized systems who also served as both an Investigator and a
District Director of Information Resource Management. In addition,
several of our consultants have extensive FDA-regulated industry
experience, with expertise in software development, validation, quality,
compliance, manufacturing, and clinical research. Based on our
background and depth of expertise in this area, FDA hired EduQuest in
2000 to train the agency's field investigators, analysts, and
headquarters compliance staff on Part 11 and the auditing of
computerized systems.

As former FDA investigators, industry experts, and now as consultants to
regulated firms and trainers of both the regulated industry and FDA, we
have seen the best and worst of what companies have done with regard to
software and computerized systems from both sides of the inspection and
enforcement fence. As a result, we are able to provide first-hand
insights on the following key issues in FDA's re-examination of Part 11
--

-   The initial objectives and the simplicity of the original intent of
    Part 11;

-   The need to ensure data integrity;

-   The reality of the current confusion and problem areas;

-   The issues that are now subject to the enforcement discretion
    described in FDA's September 2003 Part 11 Scope and Application
    guidance document; and

-   Clarifying the link between these issues and the common sense
    approach to applying the basic requirements of good software and
    systems development and maintenance (i.e., good software and systems
    engineering) practices in the FDA-regulated industries.

**[Executive Summary]{.underline}**

Our comments address what Part 11 was originally intended to accomplish
and how FDA can ensure data integrity by adopting a common sense
approach to the application of the basic concepts and requirements of
good software and systems development and maintenance practices in the
regulated industries. In this regard, we recommend that any changes in
either the language of

the regulation or FDA's stated interpretation be focused on
simplification and a rational return to the original intent. These kinds
of changes would be sensible and would substantially improve the level
of understanding between FDA and the industry. This suggested approach
also would further clarify that most of the Part 11 requirements --

-   Were already (and still are) required under the applicable predicate
    rules for pharmaceutical, medical device, and biologics
    manufacturing, clinical, laboratory, and other regulated activities;
    and

-   Are consistent with the well-established basic requirements of good
    software and systems engineering practices that are routinely
    employed in many other industries.

We believe that all of FDA's Part 11 re-examination analyses and
decisions should be based upon, driven by, and judged against two
critically important concepts -- i.e., the assurance of data integrity
and good recordkeeping. The assured integrity of regulatory data and
records sits at the very core of FDA's public health responsibilities.
The assurance of data integrity is also one of the fundamental purposes
of the good practice standards for software and systems engineering. All
of these related underlying concepts -- data integrity, recordkeeping,
and good software and systems engineering practice -- can and should be
applied in accordance with risk and intended use.

FDA's statutory remit covers a broad and varied range of regulated
operations and products, and the regulated industries use an extensive
number and variety of computerized systems to perform tasks that span
the entire spectrum of regulatory concern. Given these realities, it
would not be practical or possible for the agency to establish detailed,
explicit interpretations that would address all of the industries'
various permutations and remove the need for regulated firms to make
subjective, scientifically justified decisions about the controls that
are needed to mitigate potential system hazards and assure an adequate
level of data and record integrity. We believe, therefore, that both
science and logic require FDA to re-focus its Part 11 efforts on a
flexible and scalable approach that is based upon intended use, good
software and systems engineering practice, and the need for data and
record integrity.

**[General Comments on Part 11 Simplification and a Return to the
Original Intent]{.underline}**

[FDA's Original Intent and Objectives]{.underline}

FDA's original intent in defining and drafting 21 CFR Part 11 was based
on a set of straightforward and simple objectives --

-   To encourage and facilitate the adoption of technological
    improvements without a loss in data integrity;

-   To provide for no less integrity of electronic data and electronic
    signatures than for paper-based data and signatures; and

-   To accomplish the above within the existing regulatory framework.

In defining how it would meet this original intent, FDA sought to avoid
"reinventing the wheel" and chose to --

-   Rely on existing FDA recordkeeping regulations;

-   Draw from industries that were already experienced in dealing with
    electronic data integrity (e.g., the financial, banking, and legal
    industries); and

-   Apply "common sense" (sometimes referred to as a "risk-based"
    approach).

It should be noted that these original goals are completely consistent
with the agency's currently stated objectives in its re-examination of
Part 11 -- i.e., "\[t\]o prevent unnecessary controls and costs, yet
retain the objectives of the rule"; "\[t\]o clarify the scope of Part 11
(e.g., how it relates to other FDA regulations)"; and "\[t\]o ensure
that Part 11 provides an adequate level of record security,
authenticity, and integrity, and encourages innovation and technological
advances." 69 Fed. Reg., at 18,592.

[Departures from FDA's Original Intent and the Nature of the Current
Problems]{.underline}

Despite the simplicity of FDA's original intent, Part 11 has resulted in
a controversial and difficult set of problems since the final rule was
issued in 1997. The current problem areas are all related to significant
disconnects in some of FDA's pre- and post-issuance decisions and
implementation approaches, and in the regulated industries' application
of a number of the clearly and simply stated requirements of Part 11.

One of the key reasons for these disconnects was that both FDA and the
regulated industries failed to recognize that there were substantial
differences between their perceptions and reality. For example, FDA did
not realize that there was a significant gap between what the agency
perceived (or presumed) to be the existing level of software and systems
engineering practices in the regulated industries in 1997 and the
reality of those practices. At the same time, many FDA-regulated firms
had not yet fully understood and implemented many of the basic,
fundamental concepts of good practice that were now explicitly required
by Part 11. In addition, many companies were not fully aware of the
number of systems (many of which were later determined to be
non-compliant) that would be subject to the requirements of the final
rule. As a consequence, the common level of practice within regulated
companies was far below what FDA perceived as the industries' starting
point, and FDA's stated expectations far exceeded the industries'
perception of what companies had previously considered to be acceptable
practice. This "reality gap" set the stage for all of the controversy,
confusion, and debate that followed. It also begins to explain why and
how both FDA and the industries so drastically underestimated the
economic impact of the new regulation, and why many firms have struggled
to understand, consistently comply with, and sought to clarify some of
the key requirements over the past seven years.

Although progress certainly has been made since 1997, the reality of the
current problems surrounding Part 11 are directly related to the
following points --

-   Industry management was taken by surprise, in terms what the final
    rule actually required and the sheer magnitude of the work and
    resources that would be needed to bring hundreds or -- in many
    companies -- thousands of systems into compliance;

-   Regulated firms varied in their degree of realization that Part 11
    is not a "quality" problem -- i.e., that compliance with Part 11 was
    not something that could simply be referred to and achieved by the
    company's quality unit;

-   A continued lack of full and consistent understanding of --

    -   The logical and scientific bases for some of the key
        requirements (such as validation). This incomplete understanding
        continues to drive some companies' resistance to adopt practices
        that will routinely meet those requirements; and

    -   The scope and both the explicit and implicit (i.e., the logical
        extension of and the interpreted and/or enforced meaning of)
        requirements of the "predicate" regulations;

-   Some people in the industry continue to have the view that many of
    the predicate rule and Part 11 requirements (such as validation) are
    externally imposed add-on activities that are driven by the desire
    to generate documentation simply for the sake of its being available
    for FDA review during an inspection, rather than being clearly
    understood as key fundamental components of basic good software and
    systems engineering practice that can also deliver real business
    benefits; and

-   Prior to the current re-examination of Part 11, FDA had disseminated
    piecemeal guidance in both official (but draft) guidance documents
    and in numerous "unofficial" statements and opinions from agency
    officials at meetings and conferences. During that time, FDA's
    interpretations of the requirements changed (sometimes in a creeping
    fashion and other times in significant step changes), and some of
    those shifting interpretations resulted in irrational and
    unnecessary extremes that went far beyond the original intent and
    objectives. The more it appeared to the regulated industries that
    FDA was vacillating or making up the meaning of the rules as it went
    along, the more firms struggled and became entangled in their own
    internal debates about the basic expectations and how to effectively
    meet them. Because many firms still did not fully understand or
    adhere to basic good software and systems engineering practices,
    companies often expected FDA to be much more explicit and definitive
    in its Part 11 guidance. This expectation continues to exist, even
    though it clearly is not reasonable or realistic to expect that FDA
    would or even could teach the industry about software and systems
    engineering practices. This is especially true because the concepts
    and standards of practice are not new and the regulated industries
    have much more substantial technical capabilities and resources than
    the regulatory authorities could ever apply to these issues.

Some of the current problem areas and controversies can be summarized as
follows --

-   [Validation]{.underline} -- inconsistently and often poorly
    understood and defined (in accordance with FDA's stated definition),
    especially in the software industry;

-   ["Documents" versus "records"]{.underline} -- no distinction was
    made in Part 11;

-   [Audit trails]{.underline} -- Part 11 did not clearly define an
    audit trail as data change documentation (as it is commonly defined
    in the financial industry, and which would have established a
    clearer conceptual link to long-standing predicate rule requirements
    for creating and maintaining documentation of changes to recorded
    data);

-   ["Grandfathering" of legacy systems]{.underline} -- FDA chose not to
    allow it under Part 11 (an unrealistic approach given the
    disconnects discussed above);

-   [Archiving]{.underline} -- FDA created unnecessary confusion and
    complexity by interpreting new requirements into the regulation
    (that went beyond the original intent) with regard to the archiving
    of both records and systems;

-   [Time stamps]{.underline} -- a classic "red herring" issue that
    could have easily been addressed using a simple, common sense
    approach;

-   [Electronic copies of electronic records]{.underline} -- another
    example of a sensible requirement that became overly and
    unnecessarily complicated by FDA's interpreting more new
    requirements into the regulation (that also went beyond the original
    intent); and

-   [A glossary]{.underline} -- FDA did not generate a clear glossary of
    terms and definitions under Part 11, leaving the regulated
    industries and FDA Centers and personnel to reach varying
    interpretations of terms that FDA has defined in different ways over
    the years.

[The Path Forward -- Simplification and a Return to the Original
Intent]{.underline}

We firmly believe that the best way for FDA to move forward and achieve
a reasonable, sensible, and justified position on Part 11 is to simplify
the interpretation of the regulation by --

-   Returning to the original intent;

-   Adopting a scientific approach that is based on common sense; and

-   Refocusing on the basic objectives of meeting the agency's public
    health responsibilities to ensure --

> \(1\) Data integrity (the primary basis for all of the requirements);
>
> \(2\) The quality and reliability of software and computerized
> systems, in accordance with their intended uses; and
>
> \(3\) An appropriate degree of contemporaneously-developed objective
> evidence that supports and demonstrates that the first two objectives
> have been met.

In our view, FDA should follow this simple and rational path forward. We
further believe that FDA can meet most of the intent and objectives
outlined above by taking the following steps --

-   Define "computerized system validation" as establishing documented
    evidence of the use of good software and systems development and
    maintenance practices, applied according to the intended uses --
    i.e., the risks -- of the system;

    -   It should be noted that this is entirely consistent with the
        definition of validation used in FDA's internal training on Part
        11 and the auditing of computerized systems -- "establishing
        documented evidence that provides a high degree of assurance
        that a specific process will consistently produce a product
        meeting its predetermined specifications and quality
        attributes";

-   Distinguish between documents and records and the way in which they
    are created and maintained;

-   Clarify that an audit trail is a data change record that is required
    by many of the predicate rule requirements for creating and
    maintaining records of changes to recorded data;

-   Grandfather systems that were in use prior to the effective date of
    Part 11 (August 20, 1997), as long as all of the applicable
    predicate regulations are met and until those systems are retired or
    replaced;

    -   This is another area where FDA should focus upon and require the
        use of hazard control (i.e., the documented and scientifically
        justified identification, evaluation, and mitigation of risks)
        to ensure that additional technical and procedural safeguards
        (i.e., controls) are implemented in the interim, if needed, to
        achieve and maintain each system's compliance with the predicate
        rules;

-   Clarify that the purpose and utility of archived electronic records
    are the same as they are for archived paper records -- i.e.,
    documenting what happened, and not replaying, redoing, or
    reprocessing the event;

-   Apply common sense to issues such as time stamps, password use,
    etc.;

-   With regard to electronic copies of electronic records --

    -   Stick with the concept that a copy is an exact copy, not a
        reinterpretation of data, not data modified into a "universal"
        format, and not a different representation of the data;

    -   FDA will find the ability to use, interpret, and analyze an
        exact copy of an electronic record just as it did for many years
        prior to Part 11;

    -   An exact copy will also have the benefit of being recognized as
        "evidence" without confusing or making the industry validate
        otherwise unnecessary conversion processes; and

-   Develop a proposed glossary of terms under Part 11, to clarify FDA's
    current interpretive definitions of key concepts, including the
    suggested definition of "computerized system validation" discussed
    above. In order to avoid unnecessarily duplicating previous efforts,
    FDA should use its existing Glossary of Computer Terminology
    (published in 1995) as the starting point for many of the
    definitions.

If FDA follows this suggested approach to revising and simplifying its
interpretation of Part 11, we do not believe that there would be a need
to change any of the text of the regulation itself. All of these issues
can be dealt with by republishing the text of Part 11 and making sure
that the agency's interpretation takes the scope and nature of the
current problems into account and matches what was originally intended.

**[Specific Comments in Response to Questions Posed in the Federal
Register Notice]{.underline}**

In addition to our general comments discussed above, we offer the
following specific comments in response to some of the questions posed
by FDA in the April 8 Federal Register notice. Because many of the Part
11 issues raised by FDA are interrelated, we have not provided specific
comments on each question. We believe that our general and specific
comments, as a whole, address each of the significant issues currently
under re-examination.

[FDA Question 1, Part 11 Subpart A -- General Provisions (69 Fed. Reg.,
at 18,592)]{.underline}

*"In the part 11 guidance document, we clarified that only certain
records would fall within the scope of part 11. For example, we stated
that under the narrow interpretation of its scope, part 11 would apply
where records are required to be maintained under predicate rules or
submitted to FDA, and when persons choose to \[use\] records in
electronic format in place of paper format. On the other hand, when
persons use computers to generate paper printouts of electronic records,
those paper records must meet all the requirements of the applicable
predicate rules, and persons rely on the paper records to perform their
regulated activities, FDA would generally not consider persons to be
'using electronic records in lieu of paper records' under Sec. 11.2(a)
and (b). In these instances, the use of computer systems in the
generation of paper records would not trigger part 11. We are interested
in comments on FDA's interpretation of the narrow scope of part 11 as
discussed in the part 11 guidance and whether part 11 should be revised
to implement the narrow interpretation in the guidance."*

[EduQuest Comments]{.underline}

We agree that Part 11 should only apply to required records (a category
of records for which we have suggested a definition in response to
another of FDA's questions below) and certain types of records that are
submitted to FDA in electronic format. We believe, however, that the
remainder of FDA's stated interpretation is unnecessary and that,
without further qualification, it lacks a sound scientific rationale.

Computerized systems are used in the regulated industries in a wide
variety of contexts and settings. These uses range from simple word
processing features used to create hard-copy SOPs, to originally
recording raw data and processing conditions and calculating quality
control data (e.g., the calculated area under an empirical curve) that
will be used to make batch release decisions, just to name a few
examples. FDA's current interpretation establishes a blanket position
that does not take any of those various contexts and potential
complexities into account. In our view, there is no need for the agency
to establish a blanket interpretation that could create further problems
by being subject to confusion and varying context-irrelevant
conclusions. We also believe that FDA should not take interpretive
positions that could predictably lead to results that would undermine
the goal of encouraging the advancement and widest use of technology (in
this specific case, we believe that

the agency's stated interpretation could encourage firms to not take
advantage of the powerful technology and added precision and
productivity that electronic systems can provide, simply in order to
avoid the reach of the Part 11 requirements).

As a general statement, in the absence of 100% data verification, the
agency's current interpretation is also inconsistent with the need (for
both FDA and regulated firms) to adequately ensure the integrity of what
is printed on the paper records and thus used for regulatory purposes.
FDA has made it clear that it intends to adopt and apply a "risk-based"
(what otherwise might be stated as a hazard control) approach to Part
11. The proper use of a hazard control methodology would result in the
development of documented, scientifically justified bases for the design
and level of controls to be applied to a specific computerized system,
in accordance with its intended regulatory use. In other words, each
system would be required to be appropriately designed and controlled
based on justified use- and risk-based scientific reasoning. In this
regard, a word processing system that is used to generate hard-copy SOPs
that are then 100% verified by proofreading, review, and approval would
require far less controls around its design and use than systems that
are used for purposes that have a greater potential to impact product,
process, record, and data integrity and are less capable of being fully
verified.

[FDA Question 3, Part 11 Subpart B -- Electronic Records (69 Fed. Reg.,
at 18,592)]{.underline}

*"Under the current part 11, the controls that apply to electronic
records that are maintained also apply to electronic records that are
submitted to FDA. Should the requirements for electronic records
submitted to FDA be separate from electronic records maintained to
satisfy predicate rule requirements?"*

[EduQuest Comments]{.underline}

We believe that the phrase "submitted to FDA" is vague and unnecessarily
over-inclusive, in that does not establish any distinctions based on the
purpose of the submission and the related need for data integrity and
accuracy. Records are submitted to FDA for many reasons, and the data
integrity and accuracy risks associated with the various types of
submissions -- and the potential penalties that can attach to erroneous
information -- are not all equal.

Data integrity issues can have a widely varying impact on regulatory
concerns, depending on the nature of the submission and the purpose of
the submitted data. For example, data integrity problems in a cover
letter for an NDA or similar approval-related filing would be of
marginal (if not negligible) concern, whereas the integrity of the
content of the filing itself (which would include analyses of
pre-clinical and clinical study data and chemistry, manufacturing, and
control specifications for the process and product) would be of
substantial concern. A related but somewhat different spectrum of
regulatory concerns would apply to potential problems in the accuracy
and scientific substantiation of conclusions, statements, and claims
made to FDA in a submission.

It would be useful for FDA to reduce the current level of subjectivity
and provide more instructive guidance that associates the specific Part
11 requirements for electronically submitted records with the purposes
and risks related to specific types of submissions. This probably would
require FDA to generate an explicit list of examples of submissions that
warrant Part 11 controls, based on the agency's view of the related data
integrity and accuracy risks.

[FDA Question 1, Part 11 Subpart B -- Individual Controls (69 Fed. Reg.,
at 18,593)]{.underline}

*"The part 11 guidance identified validation as one of the four areas
where we intend to exercise enforcement discretion in the manner
described in the guidance. Should we retain the validation provision
under Sec. 11.10(b) . . . to ensure that a system meets predicate rule
requirements for validation?"*

[EduQuest Comments]{.underline}

We firmly believe that the validation provision in Part 11 should be
retained, in order to reiterate the need for adequately ensuring system
and data integrity, and to avoid further confusion driven by the
less-than-explicit nature of many of the predicate rules.

For decades prior to its re-examination of Part 11, FDA consistently
took the sensible scientific position that all systems should be
validated -- according to their intended use. This position is entirely
consistent with a "risk-based" hazard control approach as noted above.
FDA should not use the past and continued struggles and controversy over
validation concepts as a reason for withdrawing or reducing the explicit
requirement for firms to properly validate software and computerized
systems that impact their regulated operations and products. Some of the
difficulties have resulted from the fact that FDA's current expectations
regarding software and computerized systems validation were derived
largely from process validation concepts and large-scale software
development projects. In contrast, most of the industries' current
systems are configured or assembled from standard software components,
either commercial-off-the-shelf applications, or a package of functions
and modules that can be switched on or off and customized by specifying
certain parameters. This technological reality is one of the important
factors that should and can be appropriately considered as part of a
hazard control based determination of what constitutes "adequate"
validation of a specific system.

We noted in our general comments above that the concepts and standards
of good software and systems engineering practice are not new. The same
can be said with regard to formal hazard control methodologies, which
were originally developed by the U.S. military in the 1940s. They
include a number of different long-standing and common engineering
methods that involve the systematic identification and evaluation of
potential hazards in a system or process, and the careful consideration,
development, and implementation of design changes or other controls
intended to avoid the occurrence or mitigate the consequences of each
identified hazard. The application of these methods admittedly becomes
more difficult and complex in instances where there is limited knowledge
of the details of the software design, structure, and data flows (which
is often the case with vendor developed and supplied software,
especially for large complex systems like enterprise resource planning
or ERP systems) and where subjective (but scientifically supportable and
rational) assumptions must be made and included in the analysis. It also
should be recognized that the full scope of FDA's definition of a
"computerized system" (i.e., software, hardware, procedures, and people)
needs to be taken into account, so that control mechanisms and other
safeguards beyond those designed into the software (such as additional
procedural controls, confirmatory checks, etc.) are understood and
incorporated into the system's use.

We believe that FDA should require regulated companies to validate all
systems that impact any regulated activities, with those validation
efforts being defined and justified according to the intended use of
each system and its potential effects on (or potential hazards to)
regulated data, processes, products, records, and decision-making. Why?
Because no other approach makes sense in light of FDA's public health
responsibilities and the broad and varied range of regulated

operations and products that fall within the agency's remit. Validation
simply needs to be more widely understood as a flexible, scalable,
subjective concept that must, by definition, be based on the potential
impacts and risks of each specific system and thus cannot be reduced to
an all-or-nothing approach. The continued lack of understanding of the
nature of validation causes many firms to waste tremendous effort and
resources in straining to avoid it and/or in going above and beyond what
is reasonably and rationally necessary based on intended use.

FDA should also retain validation as a requirement in Part 11, because
it helps to clarify the need for adequately ensuring system and data
integrity, beyond what is and what is not explicitly stated in the other
various regulations in Title 21 of the CFR. FDA certainly understands
that validation is and has been required and enforced for decades in
areas where the published language of the predicate rules does not
include the term "validation" (e.g., the Part 211 pharmaceutical GMP and
Part 58 GLP regulations). It should be clear by now that many of the
predicate rules implicitly require validation under provisions like
those that include requirements for equipment to be of "appropriate
design" (a phrase used in both Part 211 and Part 58), where the term
equipment has been interpreted to include computers and validation is
the way to demonstrate that a computer is of "appropriate design." In
our experience, however, regulated firms vary greatly in their degree of
understanding of these implicit requirements, and some adhere to the
mistaken assumption that if the predicate rules do not explicitly
mention validation, then validation is not required. FDA needs to
recognize this disparity, and exercise care in making simple references
to the "validation requirements of the predicate rules."

[FDA Question 3, Part 11 Subpart B -- Individual Controls (69 Fed. Reg.,
at 18,593)]{.underline}

*"Should audit trail requirements include safeguards designed and
implemented to deter, prevent, and document unauthorized record
creation, modification, and deletion?"*

[EduQuest Comments]{.underline}

We believe that the existence of an audit trail does provide some degree
of deterrence against unauthorized electronic activities. In our view,
however, both FDA and the regulated industries have placed too much
emphasis on the deterrence and detection-of-wrongdoing aspects of

audit trails, as those audit trail functions are far less important from
a quality and compliance perspective than the need to ensure
appropriate, accurate, contemporaneous, and reliable recordkeeping. In
addition, it is doubtful that additional audit trail requirements would
materially increase the deterrence effect, and any such requirements
would probably increase the difficulty of compliance without materially
increasing system security or data integrity.

The function of an audit trail is to record various change activities,
such as creating, modifying, or deleting data and records; enabling or
disabling system privileges and functions; and other change events.
Audit trails are often misunderstood and viewed as an additional,
technically unnecessary and unreasonable requirement that has been
imposed by FDA simply to facilitate inspections and to deter and detect
fraud. If, as we have suggested above, FDA clarifies that an audit trail
is focused on recording data changes (a requirement that is found in
many of the predicate rules), it will increase the likelihood that audit
trails will be more appropriately understood as a rational, basic
component of good software and systems engineering practice, the primary
purpose of which is for the company's benefit, not the regulators'.

An audit trail can be used to monitor recordkeeping to assure that it is
appropriate and accurate, and that records are created and completed
when they should be and by the persons who are authorized and
responsible for the recorded actions. An audit trail also enables
retrospective reviews for patterns of activity that may be of both
business and regulatory concern (e.g., process control). In failure
investigations, an audit trail can identify the time and type of
activities that could have resulted a process or product failure. An
accurate and complete audit trail is critically important to the
pharmaceutical firm, for example, when a manufactured product fails to
meet its final release specifications and must be rejected. When this
occurs, the company has to be able to conduct a detailed failure
investigation to determine what went wrong and when. Smart companies
even recognize that this is as much a matter of good business practice
as it is a clear requirement under the GMP regulations. If an accurate
and complete audit trail is not available, the firm may not be able to
pinpoint a definitive root cause of the failure and thus not be able to
assure itself or FDA that it can continue to manufacture without running
into the same unacceptable variation in the process and the finished
product.

[FDA Question 4, Part 11 Subpart B -- Individual Controls (69 Fed. Reg.,
at 18,593)]{.underline}

*"Section 11.10(k) requires appropriate controls over systems
documentation. In light of how technology has developed since part 11
became effective, should part 11 be modified to incorporate concepts,
such as configuration and document management, for all of a system\'s
software and hardware?"*

[EduQuest Comments]{.underline}

The concepts of configuration management and document management are
basic, long-standing components of good software and systems engineering
practice that are not dependent on the available technology and always
should have been viewed as incorporated in the "appropriate controls"
required under section 11.10(k). For many years before Part 11 was
issued, FDA expected and issued inspectional observations under the
predicate rules regarding the appropriate management and control of
system configuration, documentation, and other related issues (e.g.,
software and document version control). We believe that FDA should
explicitly clarify its stated interpretation of Part 11, in order to
eliminate any further confusion or lack of understanding of the
requirements for systems documentation controls.

[FDA Question, Part 11 Subpart C -- Electronic Signatures (69 Fed. Reg.,
at 18,593)]{.underline}

*"Within the context of subpart C, we would like interested parties to
address the following: Section 11.10(d) requires that system access be
limited to authorized individuals, but it does not address the handling
of security breaches where an unauthorized individual accesses the
system. Should part 11 address investigations and followup when these
security breaches occur?"*

[EduQuest Comments]{.underline}

We do not believe that it is necessary for FDA to include an explicit
requirement in Part 11 with regard to investigations and follow-up
responses to system security breaches. Those obligations should be clear
under the predicate rules on corrective and preventive actions and other
GxP requirements. In addition, it makes perfectly logical sense that a
detected security breach in a

system that involves or otherwise could impact a regulated function
would trigger the need to conduct an investigation to address the
potential effects of the breach on regulatory data and decisions and the
related need for both corrective and preventive action. We believe that
FDA should explicitly clarify its stated interpretation of Part 11,
however, in order to eliminate any further confusion or lack of
understanding of these requirements.

[FDA Question 1, Additional Questions for Comment (69 Fed. Reg., at
18,593)]{.underline}

*"What are the economic ramifications of modifying part 11 based on the
issues raised in this document?"*

[EduQuest Comments]{.underline}

As discussed above, we believe that the initial and ongoing divergence
of views of the economic impact of Part 11 were based on the following
key reasons --

-   FDA and the regulated industries failed to recognize that there were
    substantial differences between their perceptions and reality
    concerning the existing level of software and systems engineering
    practice and what Part 11 required; and

-   There were a number of significant disconnects in some of FDA's pre-
    and post-issuance decisions and implementation approaches, and in
    the regulated industries' application of a number of the clearly and
    simply stated requirements of Part 11.

We believe that FDA can ensure a more realistic and shared understanding
of the true economic impact of Part 11 by rationally simplifying its
interpretations as suggested in our general comments, providing further
clarification, and strongly emphasizing the importance of applying basic
good software and systems engineering practice and ensuring data
integrity.

> [FDA Question 2, Additional Questions for Comment (69 Fed. Reg., at
> 18,593)]{.underline}

*"Is there a need to clarify in part 11 which records are required by
predicate rules where those records are not specifically identified in
predicate rules? If so, how could this distinction be made?"*

[EduQuest Comments]{.underline}

FDA's question highlights a corollary problem to the one described above
with regard to the confusion created over predicate rule validation
requirements in cases where the applicable predicate regulations do not
explicitly include the term "validation." The agency could try to
address this by generating an exhaustive list of all of the records
required under each of the sets of predicate rules that apply to all of
the various industries and products that FDA regulates, but this would
be impractical and probably not reasonably achievable in the near term.
Alternatively, we believe that FDA could clarify and substantially
reduce this ongoing confusion and debate by stating its interpretation
that the term "records required under the predicate rules" includes the
following --

-   Records that are explicitly required by the language of a predicate
    rule;

-   Records that are necessary to establish compliance with a predicate
    rule requirement. This would include situations where complying with
    a predicate rule requirement is achieved and evidenced by the
    generation and maintenance of a record (i.e., where compliance
    logically can only be achieved by establishing documented objective
    evidence of that compliance -- for example, where compliance with
    the requirement that personnel be properly qualified is established
    through records related to their education, training, and
    experience); and

-   Records that are required under the firm's policies and procedures
    for purposes of ensuring compliance with the predicate rules and any
    other commitments made by the firm regarding its compliance and
    quality requirements (such as process requirements and quality
    control and product release specifications established in an
    application or similar filing submitted to FDA -- e.g., NDA, ANDA,
    IND, PMA, 510(k), IDE, PLA, etc.).

[FDA Question 7, Additional Questions for Comment (69 Fed. Reg., at
18,593)]{.underline}

*"Should part 11 address record conversion?"*

[EduQuest Comments]{.underline}

As noted above in our general comments regarding FDA's approach to
archiving records under Part 11, we do not believe that Part 11 should
require record conversion in order for firms to provide electronic
copies of electronic records to the agency. If, however, a regulated
firm chooses to convert electronic records for the purpose of archiving
records or migrating data from one system to another, then the
conversion process should be validated if the converted data cannot or
are not going to be 100% verified.

\* \* \* \* \*

Thank you in advance for considering our comments and suggestions.
Please contact us at 301-874-6031 if you have any questions or need any
further information or clarification of our views.

> Respectfully submitted,
>
> ***Signature provided on facsimile copy***
>
> Martin Browning
>
> *President*
>
> ***Signature provided on facsimile copy***
>
> Gordon B. Richman
>
> *Vice President, Strategic Compliance Consulting and General Counsel*