-
CRISIS PREVENTION AND RECOVERY, LLCSOFTWARECPR
www.softwarecpr.com 781-721-2921
SoftwareCPR Blood Banking
Medical Device Software Reference Manual
*NOTE: These are selected key FDA documents and SoftwareCPR
training aides -- not a comprehensive set of all possible relevant
documents. Other potential relevant documents are available in the
website library.
http://www.softwarecpr.com
-
CRISIS PREVENTION AND RECOVERY, LLCSOFTWARECPR
®
SoftwareCPR Blood Banking Medical Device Software Reference
Manual Table of Contents FDA CBER Reviewer Guidance for a Premarket
Notification Submission for Blood Establishment Computer Software
……………………………………………………………………………………............................................3
FDA CBER March 31, 1994 BECS Manufacturer Letter
………………………………………………………………………….10 FDA CBER Presentation:
“Computerizing Collection Centers FDA Submission & Approval” –
Slides on contents for each type of 510(k) submission
………………………………………………..…………..…...…..13
FDA CBER Requirements for Premarket Submissions: In vitro
Diagnostic Instrumentation and Software Related to Donor Screening
and HIV Diagnostic Assay Systems
……………………………………………………………………..……………..18 FDA CBER Guidance for FDA
Reviewers Premarket Notification Submissions for Automated Testing
Instruments Used in Blood Establishments – Draft Guidance
…………………………………………………...………..……………..……………....26 AABB Book 21 CFR Part
11 Chapter by Alan Kusinitz of SoftwareCPR
…………………………………….……..…...…..….38 FDA CBER “Computer” Crossmatch
Reviewer’s Checklist ……………………………………………………………..…....…..79 FDA CBER
Guidance For Industry: Recognition and Use of a Standard for the
Uniform Labeling of Blood and Blood Components
……………………………………………………………………………………………...……..…83 FDA CBER Guidance For
Industry United States Industry Consensus Standard for the Uniform
Labeling of Blood and Blood Components using ISBT 128
………………………………………………………………………..……..…88 FDA CBER Guideline for Quality
Assurance in Blood Establishments ………………………………………………..…..….…89 FDA
CDRH General Principles of Software Validation
……………………………………………………………….….………127 FDA CDRH General Principles of
Software Validation Preamble ……………………………………………….……….….….174 FDA
CDRH Guidance for the Content of Premarket Submissions for Software
Contained in Medical Devices
……………………………………………………………………………………………………………….……..181 FDA CDRH
Guidance for Off-the-Shelf Software Use in Medical Devices
…………………………………………….………204 FDA CDRH Deciding When to Submit a 510(k)
for a Change to an Existing Device …………………………………..…....229 Health
Canada - Blood Establishment License Amendment Requirements for
Information Technology Submissions …..273 Compliance Program
Guidance Manual Inspection of Source Plasma Establishments -
7342.002 …………………………302 Compliance Program Guidance Manual – Blood
and Blood Products – 7342.001…………………………………………….359 .
-
1
REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATIONSUBMISSION FOR
BLOOD ESTABLISHMENT COMPUTER
SOFTWARE
FINAL PUBLISHED January 13, 1997
Center for Biologics Evaluation and ResearchOffice of Blood
Research and ReviewDivision of Blood Applications
-
2
REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATION SUBMISSION
FORBLOOD ESTABLISHMENT COMPUTER SOFTWARE
SCOPE:This guidance applies to software products intended for
use in the manufacture of blood andblood components or for the
maintenance of data that blood establishment personnel use inmaking
decisions regarding the suitability of donors and the release of
blood or bloodcomponents for transfusion or further
manufacture.
INTRODUCTION:A premarket notification [510(k)] is an application
submitted to the Food and DrugAdministration (FDA). The purpose of
a 510(k) is to demonstrate that the medical device to bemarketed is
substantially equivalent to a legally marketed device that was or
is currently on theU.S. market.
This guidance presents an overview of the type of information
FDA reviewers should expect tobe included in 510(k) submissions for
such devices and the approach FDA reviewers should takein reviewing
premarket submissions for blood establishment computer
software.
The content and format required for a 510(k) submission may be
found in Title 21 Code ofFederal Regulations (CFR) Part 807. This
guidance is intended to be used as a supplement to theReviewer
Guidance for Computer Controlled Medical Devices Undergoing 510(k)
Review,issued by the Center for Devices and Radiological Health,
August 29, 1991.
Although this guidance document does not create or confer any
rights, privileges, or benefits foror on any person and does not
operate to bind the United States Food and Drug Administration
orthe public, it does represent the Agency’s current thinking with
regard to review of premarketnotification submissions for blood
establishment software.
-
3
Information that should be included in the 510(k) submission as
related to blood establishmentcomputer software is identified by
Roman numerals below:1. The device name, including trade or
proprietary name, and common or usual name
This information should include the product name and software
version number.
2. Establishment Registration number
3. Device class determinationThe product code is 81MMH, and the
device class has not been determined by aclassification panel.
4. Performance standardsThere are no FDA performance standards
promulgated for this device.
5. The proposed labels, labeling, and advertisements must be
sufficient to describe thedevice, the intended use, and the
directions for use
The intended use should be specific to the device and reflect
the claimedindications. The labeling should include, but is not
necessarily limited to:A. User’s manual or other operating
instructionsB. Installation proceduresC. Hardware requirements
1. Hardware platform (manufacturer, type/model, etc.)2.
Operating system (manufacturer, version and/or release, etc.)
D. Special requirementsE. Specifications sufficient to describe
the device’s operating characteristics,
precautions, limitations, and maintenance information.
6. A statement of substantial equivalenceA. Substantial
equivalence may be claimed to:
1. A legally marketed preamendments device (one which
wasmarketed prior to May 28, 1976). For purposes of
documentingpreamendments status in regard to intended use and
commercialdistribution, information provided should be adequate to
documentthat the preamendments firm’s device was labeled, promoted,
anddistributed in interstate commerce for the same intended use
towhich the submitter of the premarket notification (510(k))
isclaiming substantial equivalence. This may be accomplished
byproviding copies of the firm’s advertisements, catalog pages,
otherpromotional material dated prior to May 28, 1976,
shippingdocuments, e.g., invoices, bills of lading, receipts, etc.,
showing theinterstate transit of the device dated prior to May 28,
1976.
2. A device that has been cleared by the Food and
DrugAdministration as substantially equivalent to a
preamendmentdevice for the same intended use(s).
-
REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATION SUBMISSION
FORBLOOD ESTABLISHMENT COMPUTER SOFTWARE
4
B. Identifying information relative to the predicate device,
i.e., manufacturer,common name, trade name including version and
release numbers, andany reference number assigned by the Food and
Drug Administrationshould be included.
C. The computer software modules, e.g., donor management, viral
markertesting, component preparation, distribution, etc., may be
disjoined for thepurpose of identifying the predicate device(s). It
may be necessary to citemultiple predicates.
D. A table should be submitted comparing the intended use(s) of
the device tothe intended use(s) of the predicate device to which
substantialequivalence is claimed.
7. Safety and effectiveness of the deviceA 510(k) summary or
statement should be included. If a 510(k) statement isincluded,
then the following statement should be submitted on a separate page
of the premarket notification submission, clearly identified as the
“510(k)statement,” signed and dated by the certifier.
“I certify that, in my capacity as (the position held in company
by person requiredto submit the premarket notification, preferably
the official correspondent in thefirm), of (company name), I will
make available all information included in thispremarket
notification on safety and effectiveness within 30 days of request
byany person if the device described in the premarket notification
submission isdetermined to be substantially equivalent. The
information I agree to makeavailable will be a duplicate of the
premarket notification submission, includingany adverse safety and
effectiveness information, but excluding all patientidentifiers,
and trade secret and confidential commercial information, as
definedin 21 CFR 20.61.”
8. A truth and accuracy statementThe following statement should
be included in the 510(k) submission:“To the best of my knowledge,
the data and information submitted in thispremarket notification
are truthful and accurate, and no material fact has
beenomitted.”
9. Functional requirementsThe requirements should be grouped by
functionality and preferably submitted ina table format which:A.
Includes functionality as described in the operator’s manual, e.g.,
Donor Management, Deferral Management, Component Processing,
etc.;
-
REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATION SUBMISSION
FORBLOOD ESTABLISHMENT COMPUTER SOFTWARE
5
B. References the Code of Federal Regulations, Food and
DrugAdministration Memoranda, other industry standard(s), etc.,
applicable toblood establishments;
C. Identifies any activities, processes, etc., normally
associated with anyfunction(s) listed above in “A” that will not be
performed by the softwaredevice, e.g., manual entry of confirmatory
testing results, updating ofdeferral status, etc.;
D. Identifies a safety critical requirement(s) implemented to
ensure the safety,quality, identity, potency, and purity of
blood/blood products and/or donorsafety;
E. Identifies the design safeguard, e.g., algorithms, truth
tables, errorchecking, record locking, etc., to ensure that the
safety criticalrequirement(s) is met; and
F. Traces the design safeguard to the logic routine.
A. FUNCTIONALITY:
B. REFERENCED REGULATION/STANDARD:
C. LIMITATIONS:
D. SAFETY CRITICALREQUIREMENT
E. DESIGN SAFEGUARD F. TRACE TO LOGICROUTINE
10. Software design and developmentThe design and development
documentation should include the following:A. The Software
Requirements Specification (SRS) document which
should include:1. A description of the software product;2. A
list of functions that the software controls, monitors, or
implements with the safety critical functions identified;3. A
definition of the hardware platform on which the software will
be installed, including the computer/processor type and
storagecapacity;
4. A list of all of the software components in the
computerizedsystem, including the version number. Software
componentsinclude the operating system, databases, etc.;
5. A list and definition of all interfaces that are part of
thecomputerized system; and
6. A list of any specific performance requirements that
thecomputerized system must meet, e.g., transactions per
second,transmission rate, number of users, etc.
-
REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATION SUBMISSION
FORBLOOD ESTABLISHMENT COMPUTER SOFTWARE
6
B. A description of the software design and development process,
and related procedures
C. A diagram and description of the software architecture
11. Hazard analysisA. The analytical process used to identify
the hazardous elements related to
donor/blood product safety should be described. The hazard
analysisshould include the intended use hazards and the hazards
resulting from theimplementation of the functional requirements in
the computer andsoftware environment, e.g., user interfaces,
external system interfaces,internal hardware/software interfaces,
hardware/software architecture,design/development process, etc.
B. The hazard analysis, preferably in a table format, should
include:1. A description of the hazard;2. The cause(s) of the
hazard;3. The level of concern based on a qualitative estimate,
including the
definition of terms used;4. The likelihood of occurrence based
on a qualitative estimate,
including the definition of terms used;5. The method(s) of
control used to eliminate or mitigate the hazard,
e.g., change in design specification, alarms,warning and/or
error messages, manual process/workaround, etc.;and
6. A trace of the method of control to the safety
criticalrequirement(s) specified in section IX and the safety
criticalfunction(s) in the SRS, or to the user’s manual.
1. HAZARD 2. CAUSE(s) 3. LEVEL OF CONCERN
4. LIKELIHOOD 5. METHOD (s) OF CONTROL
6. TRACE
12. Verification, validation, and testingVerification,
validation, and testing should be submitted for all of the
differenthardware configurations identified in the labeling and
should include:A. The plan and a summary of all in-house
verification, validation, and
testing performed at the module/integration/system levels;B. The
plan and a summary of the results from the testing performed in
a
user’s environment prior to final release; andC. Representative
data generated from both testing environments described
above for each of the following functions if performed by the
software:
-
REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATION SUBMISSION
FORBLOOD ESTABLISHMENT COMPUTER SOFTWARE
7
1. Donor deferral2. Labeling3. Quarantine/Release4. Laboratory
testing, i.e., ABO/Rh, infectious disease
XIII. AnomaliesAll anomalies (“bugs”) or anything observed in
the documentation or operation
of the software that deviates from expectations based on
previouslyverified software products or reference documents should
be listed.
XIV. Configuration management and change controlThe 510(k)
submission should include:A. The procedure(s) for approving,
implementing, and recording
proposed changes;B. The procedure(s) for maintaining and
identifying versions; andC. The procedure(s) for the maintenance of
the device history and the device
master record.
XV. Submission formatThe 510(k) submission should be:A. Bound
into a volume(s);B. Submitted in triplicate on standard size paper,
including the original and
two copies of the cover letter;C. Submitted separately for each
product the manufacturer intends to market;D. Designated “510(k)
Notification” in the cover letter; andE. Submitted to:
FDA/CBERDocument Control CenterSuite 200 North, HFM 991401
Rockville PikeRockville, Maryland 20852-1448
-
1
Requirements for Premarket Submissions:
In vitro Diagnostic Instrumentation and Software Related to
Donor Screening and
HIV Diagnostic Assay Systems
Diane GubernotScientific Reviewer
DETTD/OBRR/CBER
2
Issue:
• Software/instruments are becoming increasingly complex due to
the development of automated platforms for testing
• Some manufacturers have expressed confusion regarding
pre-market submission requirements for software related to blood
typing, donor screening and HIV diagnostic assay systems
-
2
3
Objectives of this presentation:
• To summarize the regulations and guidance documents applicable
to the submission of BLAs/PMAs/510(k)s for these software
systems
• To provide specific information to the manufacturers on the
content of submission to expedite the review process
4
Objectives of this presentation:
• To inform manufacturers of the standards for level of concern
determination which apply to CBER-regulated donor screening and HIV
diagnostic assay systems
-
3
5
Software Development:
• Quality System Requirements (QSR), found in 21CFR 820s
• General Principles of Software Validation; Final Guidance for
Industry and FDA Staff (available at www.fda.gov/cdrh)
6
When Submitting Software/Instrument Applications to CBER:
• Manufacturers should follow the Guidance for the Content of
Premarket Submissions for Software Contained in Medical Devices,
May 29, 1998. (available at www.fda.gov/cdrh)
• In addition: Manufacturers of blood bank software should
follow Reviewer Guidance for a Premarket Notification Submission
for Blood Establishment Computer Software - 1/13/1997(available at
www.fda.gov/cber/).
-
4
7
Applications:
• Premarket Notifications (510(k)s)
• Premarket Approval Applications (PMAs)
• Biologic License Applications (BLAs)
8
Blood Bank & HIV Diagnostic Instrument/Software Devices may
be:
• Stand-alone software
• Software that is used in conjunction with automated
instruments
• Automated & semi-automated instruments containing
firmware– Accessories (e.g. barcode scanners) that
interface with any of the above devices
-
5
9
The Guidance for Premarket Submissions includes:
• Definitions for Major, Moderate, and Minor Level of
Concern
• A flowchart for determining the Level of Concern for your
device
• Required documents to be submitted based on the Level of
Concern determination
10
Level of Concern
• Level of Concern is a term used by FDA and industry to
determine which software design documents are required to be
submitted in an application.
• The required verification, validation and testing activities
performed by a firm are not limited to the scope of the application
submission.
-
6
11
Major Level
Operation of the software associated with device function
directly affects the patient so that failures or latent flaws could
result in death or serious injury, or indirectly affects the
patient such that incorrect or delayed information could result in
death or serious injury of the patient.
12
Moderate Level
• Operation of the software associated with device function
directly affects the patient so that failures or latent flaws could
result in non-serious injury, or indirectly affects the patient
such that incorrect or delayed information could result in
non-serious injury of the patient.
-
7
13
Minor Level
• Failures or latent design flaws would not be expected to
result in any injury to the patient.
14
-
8
15
HIV Diagnostic Instruments and Software:
• FDA has determined these to be a Major Level of Concern.–
Devices that diagnose, monitor (viral load
assays) or genotype HIV (resistance assays) meet the 21CFR809.3
definition of an in vitrodiagnostic device.
– Incorrect test results from use of the devices could mislead
physicians regarding treatment decisions, resulting in serious
injury.
16
Summary:• All software/instrument systems, regardless of
the determined Level of Concern, must follow the QSR for system
development. General Principles of Validation Guidance document
should also be referenced.
• The Guidance for the Content of Premarket Submissions for
Software Contained in Medical Devices should be followed to
expedite the review process.
• Seek guidance from CBER prior to submitting an
application.
-
Guidance for FDA Reviewers
Premarket Notification Submissions for Automated Testing
Instruments Used in
Blood Establishments
DRAFT GUIDANCE
This guidance is being distributed for comment purposes only.
Comments and suggestions regarding this draft document should be
submitted by the date provided in the Federal Register notice
announcing the availability of the draft guidance. Submit comments
to Dockets Management Branch (HFA-305), Food and Drug
Administration, 5630 Fishers Lane, rm. 1061, Rockville, MD 20852.
All comments should be identified with the docket number in the
notice of availability that publishes in the Federal Register.
Additional copies of this draft guidance are available from the
Office of Communication, Training and Manufacturers Assistance
(HFM-40), 1401 Rockville Pike, Rockville, MD 20852-1448. Or by
calling 1-800-835-4709 or 301-827-1800, or from the Internet at
http://www.fda.gov/cber/guidelines.htm For questions regarding this
draft document, contact Leonard Wilson, Division of Blood
Applications, 301-827-3524.
U.S. Department of Health and Human Services Food and Drug
Administration
Center for Biologics Evaluation and Research (CBER) August
2001
http://www.fda.gov/cber/guidelines.htm
-
Draft-Not for Implementation
i
TABLE OF CONTENTS
[Note: Page numbering may vary for documents distributed
electronically.]
I. INTRODUCTION
................................................................................................................
1
II.
BACKGROUND...................................................................................................................
1
III. RECOMMENDATIONS FOR REVIEWERS
...................................................................
2
-
Draft-Not for Implementation
1
GUIDANCE FOR FDA REVIEWERS
Premarket Notification Submissions for Automated Testing
Instruments Used in Blood Establishments
This guidance document represents the agency’s current thinking
on the review of premarket notification submissions for automated
instruments used for testing in blood establishments. It does not
create or confer any rights for or on any person and does not
operate to bind FDA or the public. An alternative approach may be
used if such approach satisfies the requirements of the applicable
statutes and regulations.
I. INTRODUCTION This guidance is intended to assist FDA’s staff
in the review of premarket notification submissions for automated
instruments intended for use in establishments that manufacture
blood and blood components (e.g., in testing for blood borne
pathogens, blood grouping/typing, pre-transfusion compatibility,
etc.). It was prepared by the Biological Devices Branch, Division
of Blood Applications, Office of Blood Research and Review, Center
for Biologics Evaluation and Research. Additional information
regarding software for such instruments is available in the
“Guidance for FDA Reviewers and Industry: Guidance for the Content
of Premarket Submissions for Software Contained in Medical
Devices,” final document issued by Office of Device Evaluation,
Center for Devices and Radiological Health, May 29, 1998. II.
BACKGROUND Section 510(k) of the Food, Drug, and Cosmetic Act (the
Act), 21 U.S.C. 360(k), states that each person who is required to
register under that section of the Act and who proposes to begin
the introduction or delivery for introduction into interstate
commerce for commercial distribution of a device intended for human
use shall, at least ninety days before making such introduction or
delivery, report to the Secretary (in such form and manner as the
Secretary shall by regulation prescribe). Title 21 of the Code of
Federal Regulations (CFR) Part 807 identifies the requirements for
the content and format of the 510(k) notifications that are to be
submitted to the Food and Drug Administration (FDA). The purpose of
a 510(k) is to demonstrate that the medical device to be marketed
is substantially equivalent to a device that is already legally
marketed. This guidance presents an overview of the type of
information FDA reviewers should expect to be included in premarket
notifications submitted for such devices and the approach FDA
reviewers normally should take in reviewing premarket submissions
for automated instruments used for testing in blood establishments.
The detailed requirements for premarket notifications in 21 CFR
Part 807 should also be consulted.
-
Draft-Not for Implementation
2
III. RECOMMENDATIONS FOR REVIEWERS Part 807 identifies the
following as information to be included in a 510(k) submission: A.
The device name, including trade or proprietary name, and common or
usual name
This information should include the product name, model, and
software version number.
B. Establishment Registration number
This information should include the establishment registration
number.
C. Device class determination This information should include
the product code with the device classification. D. Performance
Standards
There are no FDA performance standards promulgated for these
devices.
E. Proposed labels, labeling, and advertisements sufficient to
describe the device, the
intended use, and the directions for use.
The requirements for labeling in vitro diagnostic products are
identified in 21 CFR 809.10. The intended use should be specific to
the device and reflect the claimed indications. The labeling should
include, but is not necessarily limited to:
1. User’s manual or other operating instructions; 2.
Installation procedures; 3. A list that identifies any
reagent(s)/kit(s) or device(s), recommended but not provided,
and
claimed to be compatible with the instrument; and 4.
Specifications sufficient to describe the device’s operating
characteristics, precautions,
limitations which should include the user controlled functional
requirements as identified in the hazard analysis, and calibration
maintenance information.
-
Draft-Not for Implementation
3
F. A statement of substantial equivalence
1. Pursuant to 21 CFR 807.92(a)(3), the submission must contain
a statement that the device to be marketed is substantially
equivalent to a legally marketed device that was or is on the U.S.
market. Substantial equivalence may be claimed to:
a. A legally marketed pre-amendments device (one which was
marketed prior to May
28, 1976). For purposes of documenting pre-amendment status in
regard to intended use and commercial distribution, information
provided must be adequate to document that the pre-amendment firm’s
device was labeled, promoted, and distributed in interstate
commerce for the same intended use to which the submitter of the
premarket notification (510(k)) is claiming substantial
equivalence. This may be accomplished by providing copies of the
firm’s advertisements, catalogue pages or other promotional
material dated prior to May 28, 1976 and shipping documents such as
invoices, bills of lading, receipts, etc. showing the interstate
transit of the device dated prior to May 28, 1976; or
b. A device that has been cleared by the FDA as substantially
equivalent to a pre-
amendment device for the same intended use(s). 2. Pursuant to 21
CFR 807.92(a)(3), the statement must identify the predicate
device.
Information about the predicate device should include
manufacturer, common name, trade name including model, version,
and/or release numbers and any reference number assigned by the
FDA.
3. The statement should include a comparison of the intended
use(s) of the device to the
intended use(s) of the predicate device to which substantial
equivalence is claimed.
G. Safety and effectiveness of the device Pursuant to 21 CFR
807.92(b)(2), a 510(k) summary or statement must be included. If a
510(k) statement is included, then the following statement should
be submitted on a separate page of the premarket notification
submission, clearly identified as the “510(k) statement,” signed
and dated by the certifier:
“I certify that, in my capacity as (the position held in company
by person required to submit the premarket notification, preferably
the official correspondent in the firm), of (company name), I will
make available all information included in this premarket
notification on safety and effectiveness within 30 days of request
by any person if the device described in the premarket notification
submission is determined to be substantially equivalent. The
information I agree to make available will be a duplicate of the
premarket notification submission, including any adverse safety and
effectiveness
-
Draft-Not for Implementation
4
information, but excluding all patient identifiers, and trade
secret and confidential commercial information, as defined in 21
CFR 20.61.”
A 510(k) summary should be sufficient to provide an
understanding of the basis for a determination of substantial
equivalence. It must contain the elements discussed in 21 CFR
807.92.
H. A truth and accuracy statement
The following statement must be included in the 510(k)
submission and be signed and dated by the certifier:
“To the best of my knowledge, the data and information submitted
in this premarket notification are truthful and accurate, and no
material fact has been omitted.”
The following additional items should be included in the
submission in order to make the substantial equivalence
determination: I. Financial Certification or Disclosure
A financial certification or disclosure statement or both must
be included in the submission as required by 21 CFR Part 54.
The following additional items should be included in the
submission in order to make the substantial equivalence
determination:
J. Functional requirements
The functional requirements should include the hardware and
software functional requirements and identify the following: 1. Any
activities, processes, procedural steps of the test, etc. that are
performed by the
instrument (e.g., pipetting samples and/or reagents, diluting,
incubation time and/or temperature control, washing, sealing of
reaction chambers, the calibration of equipment, calculating,
etc.);
2. The functions that are controlled by the software; 3. Any
limitations of the test (procedure and/or any activities,
processes, etc.) normally
associated with any function(s) that will not be performed by
the instrument (e.g., manual entry of duplicate samples, etc.). Any
method of control that is specified as user controlled is
considered to be a limitation and should also be included in this
document and in the labeling provided the user;
-
Draft-Not for Implementation
5
4. The safety critical requirement(s) implemented to ensure the
safety, quality, identity,
potency, and purity of blood/blood products (e.g., positive
sample identification, equipment calibrations, dilution of reagents
and/or samples, pipetting volumes, incubation times and/or
temperatures, wavelengths, etc.);
5. Any instrument design safeguard (e.g., algorithms, truth
tables, error checking, door locking
while the instrument is in use, sampling error alarm, warning,
or message, liquid level sensing/dispensing, device operation
suspended upon error, etc.), to ensure that the safety critical
requirement(s) is met; and
6. A matrix of cross-references that traces each functional
requirement to the appropriate
detailed design specification(s).
K. Design and development
The design and development documentation should include the
following: 1. A description of the design and development process,
related Standard Operating
Procedures (SOPs), and applicable industry standards (e.g.,
AABB, ANSI, ASA, ASME, ASTM, FDA, IEEE, ISA, ISO, NEC, NEMA, NRC,
OSHA, UL, etc.) used during development;
2. A description of all of the hardware components in the
instrument, their performance
characteristics, and specifications; 3. Diagrams and
descriptions of the instrument that demonstrate the relationship of
the major
components, including the software; 4. Explanation of the
procedure for calculations, such as, cutoffs, controls and test
samples,
examples of calculations, and the number of significant digits
appropriate for the answer; 5. Instrument printouts that are
indelibly recorded and sequentially numbered for the life of
the
machine, including all of the following items, as applicable:
the run date, time of printout, software and test release/version
number, raw signal value, blank value, results (positive, negative,
reactive, nonreactive), instrument and test title, sample number,
flag on reactives/abnormals, positive/negative control values,
cutoff value, control acceptability criteria and outcome, run
valid/invalid statement, test kit lot number, wavelength read,
calculation for cutoff, and differentiation between the original
read and rereads;
6. An audit trail that automatically records all instrument/test
run modifications and/or changes;
-
Draft-Not for Implementation
6
7. Test methodology, principles of operations, calibration
procedures, specimen requirements, etc.; and
8. Detailed design specifications which implement the functional
requirements and provide the
technical definition of all the software requirements (e.g.,
data requirements for inputs, performance requirements, interfaces,
data flow, etc.) and include the following: a. A description of all
of the software components, such as, operating system,
databases,
etc.; b. A diagram and description of the software that includes
a list and definition of all
interfaces that are part of the computerized system; c. A list
of any specific performance requirements that the instrument or the
computerized
system must meet (e.g., transactions per second, a transmission
rate, maximum number of users, etc.); and
d. The current plan as to how the instrument will conform to the
conversion to the ISBT
128 barcode standard.
L. Hazard analysis
1. The analytical process used to identify the hazardous
elements related to blood product safety should be described (e.g.,
Failure Modes and Effects Analysis, Failure Modes and Effects
Criticality Analysis, Fault Tree Analysis, etc.).
2. The hazard analysis should address (1) the intended use
hazards (functional requirements
that if not achieved may result in testing errors), and (2) the
hazards that may result from the implementation of the functional
requirements in the instrument (mechanical failure), and the
software environment [e.g., user interfaces (operator), external
system interfaces (interfaced to a computer system), internal
hardware/software interfaces (compatibility), incorrect
sequencing/timing, algorithm/truth table errors, data
loss/corruption, alarm/error message malfunction, duplicate
records, etc.].
3. The hazard analysis, preferably in a table format, should
include:
a. A description of the hazard; b. The cause(s) of the hazard;
c. The level of concern based on a qualitative estimate, including
the definition of terms
used;
-
Draft-Not for Implementation
7
d. The likelihood of occurrence: 1. The failure rate for
mechanical hazards should be expressed as a ratio of the number
of challenges, cycles, etc.; and 2. The occurrence of software
hazards should be based on a qualitative estimate,
including the definition of terms used; 5. The method(s) of
control used to eliminate or mitigate the hazard (e.g., change in
design
specification, alarms, warning and/or error messages, manual
process/workaround, etc.); and
6. A trace of the method of control to the safety critical
design specification and the
appropriate verification, validation, and testing.
-
Draft-Not for Implementation
8
The following provides an example of a possible format and
content for a hazard analysis table:
Hazard Cause Level of Concern
Likelihood / Failure Rate
Method of Control Trace
Incorrect volume aspirated
Clot, plunger stuck, etc. (Hardware)
High 1:X Hardware Controlled Install sensor, level detector,
etc.
Design Specification # VV&T test plan #
High
Low
Software Controlled Algorithm, e.g., If level or volume is not
reached within “x” amount of time then perform an action (alarm,
shut down, etc.)
Design Specification # VV&T test plan #
Incorrect incubation time/ temperature
Incorrect thermostat setting, faulty thermostat (Hardware)
High
1:X
Hardware Controlled Redundant sensors, resistance temperature
devices, thermocouples, etc.
Design Specification # VV&T test plan #
High
Low
Software Controlled Algorithm, e.g., If difference between
temperature readings is “x” then perform action (alarm, shut down,
etc.)
Design Specification # VV&T test plan #
High Moderate User Controlled Visual inspection of
temperature
Limitation(s) in the User Manual
-
Draft-Not for Implementation
9
M. Validation
Verification, validation, and testing should be submitted to
substantiate labeling claims for test kit/reagent compatibility for
all of the different instrument(s) and/or computer
hardware/software configurations and should include: 1. Test
Plan
The unit level test plan should include structural testing
(e.g., branch, path, and statement testing) and functional testing
(e.g., normal, boundary, stress, etc.).
The integration test plan should include internal interface
testing (e.g., module to module, etc.) and external interfaces
(e.g., peripheral devices, other application software, and network
communications, etc.).
The system level test plan should ensure that all safety
critical intended use functions have been included in the system
level testing performed in both the developer’s (alpha) and the
user’s (beta) environments and should include evaluating the
results of this testing prior to the final distribution of the
instrument. These test plans should identify the input, the
expected result, and an evaluation of the acceptability based on
the comparison of the actual results to the expected results.
2. Populated Decision Tables User defined, safety critical,
decision tables, populated with results, utilized during the
verification, validation, and testing, should be provided.
3. Alpha testing (Developer’s environment)
The test plan and results summary of all in-house mechanical and
software verification, validation, and testing performed at the
unit/integration/system levels and representative data generated
during testing that includes validation of the functional
requirements and verification of the design specifications for both
the hardware (mechanical) and software.
4. Beta testing (Clinical field trials)
The test plan, results summary of clinical data, representative
instrument printouts, and all data generated during the clinical
field trials.
5. All safety critical anomalies (“bugs”) or anything observed
in the documentation or operation
of the instrument or the software that deviates from
expectations based on performance, previously verified software
products, or reference documents should be identified. Include a
description of the corrective action, regression testing, and the
summary of results.
-
Draft-Not for Implementation
10
N. Configuration management and change control
The 510(k) submission should include: 1. The procedure(s) for
approving, implementing, and recording proposed changes; 2. The
procedure(s) for maintaining and identifying model/versions; and 3.
The procedure(s) for the maintenance of the device history and the
device master record.
O. Submission format The 510(k) submission should be:
1. Bound into a volume(s); 2. Submitted in duplicate on standard
size paper, including the original and one copy; 3. Submitted
separately for each product the manufacturer intends to market; 4.
Designated “510(k) Notification” in the cover letter; and 5.
Submitted to:
FDA/CBER Document Control Center Suite 200 North, HFM-99 1401
Rockville Pike Rockville, Maryland 20852-1448
-
Chapter 6 21 CFR Part 11 A. Kusinitz Rev. 4-Oct-2002
Copyright 2002 AABB
1
CRISIS PREVENTION AND RECOVERY, LLCSOFTWARECPR
21 CFR Part 11 Electronic Records; Electronic Signatures
Chapter from AABB Book authored by A. Kusinitz of SoftwareCPR
may be used for SoftwareCPR training materials and clients.
This copy may not be circulated beyond those receiving it
directly from Alan Kusinitz of SoftwareCPR or the AABB Copyright
will be violated.
_____________________________
Alan Kusinitz, SoftwareCPR, Winchester, MA 20 Berkshire Drive
Winchester, MA 01890 Phone: 781 721-2921 [email protected]
www.softwarecpr.com
®
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz5-Mar-03 Notes
Alan Kusinitz
Alan KusinitzNotes added regarding subsequent Feb 2003 FDA Part
11 Redirection Federal Register Notice.
Alan Kusinitz
Alan Kusinitz
mailto:[email protected]://www.softwarecpr.com
-
Electronic Records andElectronic Signatures
AlanKusinitz
6Alan Kusinitz, ManagingPartner, SoftwareCPR,Winchester,
Massachusetts
-
Title 21 Code of Federal Regulations (CFR) 11—ElectronicRecords:
Electronic Signatures—is a Food and DrugAdministraiton (FDA)
regulation that establishes require-ments for electronic regulatory
records and signatures. Theregulation applies to all FDA-regulated
industries, includingbiologics, drugs, medical devices, food, and
cosmetics.
However, 21 CFR 11 does not identify what records or signa-tures
are required for regulatory purposes. It also does notrequire
industries to use electronic records or signatures. Itdoes
establish requirements to ensure record and signatureintegrity when
records or signatures required by other FDAregulations are in
electronic form. Those other FDA regula-tions that establish
specific recordkeeping and signature re-quirements are referred to
in the context of 21 CFR 11 as“predicate rules.”
The intent of the regulation is to ensure that electronic
re-cords and signatures have the integrity of traditional
paperrecords. Section 11.1(a) of the regulation states this
intentquite clearly:
The regulations in this part set forth the criteria un-der which
the agency considers electronic records,electronic signatures, and
handwritten signaturesexecuted to electronic records to be
trustworthy,reliable, and generally equivalent to paper recordsand
handwritten signatures executed on paper.[Italics added.]
One purpose of this regulation is to maximize the credibilityand
authenticity of electronic records and signatures for usein law
enforcement, including criminal and civil litigation.Section 11.10,
for example, states, “… and to ensure thatthe signer cannot readily
repudiate the signed record as notgenuine.” In section 11.100(c),
handwritten certificationsto the FDA are required to “certify …
that the electronic sig-natures … are intended to be the legally
binding equivalentof traditional handwritten signatures.”
This chapter highlights some key aspects of 21 CFR 11
andprovides references to other sources of information. It is
acompanion to the regulation and should not be used as asubstitute
for reading the regulation itself. The regulation isonly two and
one-half pages long without the preamble, andmost of its language
is easily understandable to informationtechnology (IT)
professionals.
116 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
Alan KusinitzIn Feb 2003 FDA announced a major redirection and
reexamination of its interpretation of Part 11 and approach to
electronic records.
This redirection narrowed the scope of records and systems that
Part will be applied to and indicated that FDA would not normally
enforce certain provisions while reexamining its approach.
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
-
Readers should be aware that federal regulations andguidances on
this subject are in flux. Thus, information pre-sented in this
chapter—while current at press time—may beupdated by the FDA at any
time.
The terms computer system, system, software, and applica-tion
are used interchangeably in this chapter. Any softwareor software
package used for electronic records may be sub-ject to 21 CFR 11,
whether it is a configurable, commercialoff-the-shelf package such
as a spreadsheet or database; acustom program; or an entire
computer system, such as adocument control system or a blood
establishment computersystem (BECS).
Questions to Ask
To understand and ensure compliance with the regulation,each
regulated entity should ask and answer the followingfive
questions:
✓ What records and signatures are subject to the regulation?
✓ What computer system functionality does the
regulationrequire?
✓ What must be provided to the FDA and in what form?
✓ What compliance requirements must be met before goinglive with
a use of the computer system?
✓ What compliance requirements must be met while using orafter
retiring the computer system?
What Records and Signatures Are Subject to the Regulation?
The regulation defines its scope quite broadly. Section11.1(b)
states:
This part applies to records in electronic form thatare created,
modified, maintained, archived, re-trieved, or transmitted, under
any records require-
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 117
Alan KusinitzFDA announced major changes/to reduce barriers to
automation and the cost of compliance in Feb 2003.
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
-
ments set forth in agency regulations. This part alsoapplies to
electronic records submitted to theagency under requirements of the
Federal Food,Drug, and Cosmetic Act and the Public Health Ser-vice
Act, even if such records are not specificallyidentified in agency
regulations. [Italics added.]
As the FDA currently interprets this wording, simply creatingand
retaining paper copies of electronic records will not besufficient
to exempt a computer system from the require-ments of the
regulation. Also, the regulation applies to elec-tronic records
whether or not electronic signatures are used.
The records and signatures subject to the regulation dependon
three factors:
1. The record and signature requirements of the predicaterules
that apply to the specific regulated entity (for ex-ample, for
blood bank establishments, 21 CFR 606,640, 210, and 211).
2. The entity’s interpretation of the predicate rules as
de-fined by its internal procedures.
3. The specific computer systems and applications usedby the
entity.
Therefore, each regulated entity needs to evaluate each ofthose
factors to determine what computer systems, applica-tions, and data
are within the scope of the regulation.
What Computer System FunctionalityDoes the Regulation
Require?
It is extremely important to recognize that the
regulationincludes several functional requirements for computer
sys-
118 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
The regulations in 21 CFR 11.1(b) apply torecords in electronic
form that arecreated, modified, maintained, archived,retrieved or
transmitted under any recordsrequirements of predicate rules.
Alan KusinitzIn Feb 2003 a Federal Register notice and draft
Part 11 Scope and Application Guidance indicated FDA will more
narrowly define scope and paper records if maintained and used for
regulated purposes may make the systems used to create and revise
them outside of scope in many cases.
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan
-
tems and applications that are used for regulatory records.That
functionality (eg, computer-generated audit trails)must be built
into the computer system. Procedural controlsor duplicate hard copy
(eg, user- or administrator-gen-erated audit trails through
printing hard copy) alone willnot meet compliance requirements,
given current FDA inter-pretations. Although the regulation does
not provide de-tailed functional or design specifications, it does
establishseveral basic functional requirements. In particular, it
es-tablishes requirements for the following:
✓ Computer-generated audit trails
✓ Security
✓ Electronic signatures components and controls
✓ Signature and record linking
Whether building or buying a computer system (eg, a docu-ment
control system) or configuring an application (eg,spreadsheet), one
must include functionality as defined inthe regulation to achieve
full compliance.
What Must Be Provided to the FDA and in What Form?
Several requirements govern the type and form of informa-tion
regulated entities must provide to the FDA. First, ifelectronic
signatures are used, a paper certification state-ment must be
submitted directly to the FDA notifying it ofsuch use and attesting
to the equivalence of the electronicsignatures to handwritten
signatures.
Second, although in come circumstances FDA inspectors maybe
satisfied with printouts of electronic records and signa-tures, the
regulation requires that electronic copies of thoseitems are
provided to the FDA upon request. Those elec-tronic copies must
include all relevant information indicatedin the regulation (eg,
audit trail information). Because com-puter systems may maintain
large amounts of data organizedin numerous ways, it is important to
identify how the data inregulated electronic records will be made
available to theFDA. Otherwise, confidential information that is
not re-quired by the FDA may be inadvertantly submitted or
poorlyorganized data may be misleading to the FDA.
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 119
Alan KusinitzIn Feb 2003 FDA relaxed the requirements and
indicated that a risk based approach should be used and unless
predicate rules required such information it would not enforce the
requirement for computer generated audit trails.
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan Kusinitz
Alan KusinitzIn Feb 2003 FDA relaxed the requirements and
indicated that a risk based approach should be used and unless
predicate rules required such information it would not enforce the
requirement for computer generated audit trails.
Alan KusinitzIn Feb 2003 FDA relaxed the requirements and
indicated that that pdfs and paper could be acceptable if they
contained all information required by the predicate rules and that
any required filters and views needed related to regulatory
information are available.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
Although providing electronic copies when requested by theFDA is
required, the FDA does not have the right to operate
amanufacturer’s computer systems to search or scan for
infor-mation. The FDA Investigations Operations Manual (Chapter5,
section 527.4) states this quite clearly. Generally, it isbest to
respond to specific FDA requests for copies withprintouts or, if
requested, electronic copies in an agreed-upon media. As with paper
records, it is advisable to retainduplicate copies of electronic
records in exactly the formprovided to the FDA.
What Compliance Requirements Must Be Metbefore Going Live with a
Computer System?
Certain actions must be taken before a computer systemgoes live.
These are the primary requirements:
✓ The computer system must be validated, and validation
doc-umentation must be controlled.
✓ Written policies must hold individuals accountable for
ac-tions that they initiate using their electronic signatures.
✓ Developers, users, and administrators must have
adequatetraining and experience.
✓ Procedures for revision control must be in place.
120 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
The regulations require that upon request,the facility provide
electronic copies ofall relevant information indicated in
theregulation.
Written policies must exist holdingindividuals accountable for
actions theyinitiate using their electronic signatures.
Alan KusinitzIn Feb 2003 FDA indicated that it would generally
not enforce the validation requirement of Part 11. Only systems
that require validation under predicate rules would require
validation in most cases. Note that in most cases predicate rules
do require validation for most systems that were subject under Part
11.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
If purchased software is used, one should make certain thatthe
vendor and the software and system are qualified. Thisaction will
ensure that the product is capable of fulfilling allrelevant 21 CFR
11 functional requirements and will mini-mize the internal
validation work required. Generally, themore work the vendor has
done and documented, the lesswill have to be done internally.
What Compliance Requirements Must Be Met during Useor after
Retirement of the Computer System?
Numerous compliance requirements apply during and evenafter the
use of a system for electronic records and signa-tures. An
organization should consider using electronic re-cords and
signatures only if it can meet those requirements.Most important
are formal controls and documentation ofthe following:
✓ Change control and revalidation
✓ Security controls (eg, access rights, monitoring)
✓ User adherence to procedures related to ensuring data
andsignature integrity
In addition, electronic records and signatures must be
re-trievable for the data retention period of the records
in-volved. The longevity of storage media is an
essentialconsideration as systems are retired or replaced to
ensurethat electronic records and signatures remain available
insome form for the full retention period.
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 121
Careful planning is required to ensure thatelectronic records
and electronic signaturesare retrievable for the necessary data
retentionperiod.
AlanWith the changes in Feb 2003 simple archiving to paper or
pdf or similar forms appear sufficient in place of in the original
electronic form.
Mindy
Mindy
Mindy
Mindy
Mindy
-
Elements of the Regulation
Table 6-1 lists the elements of the regulation and can beused
for quick reference. Highlights of each subpart of theregulation
follow. Because the highlights are not compre-hensive, they should
not be used as a substitute for the reg-ulation itself. They
emphasize and interpret key issues onthe basis of the wording in
the regulation itself, commentsin the lengthy preamble to the
regulation, and other relatedinformation from the FDA.
Subpart A: General Provisions
Subpart A defines the scope of the regulation and provideskey
definitions.
Section 11.1—Scope
The scope section, the associated comments in the pream-ble, and
other information indicate that the regulation ap-plies to the
following:
✓ All records required by the FDA that are used and main-tained
in electronic form, whether or not they involve elec-tronic
signatures
✓ All automated systems within the scope of FDA regulationsthat
include electronic approvals in lieu of handwritten sig-natures on
paper documents
✓ Any records submitted to the FDA in electronic form
(eg,electronic premarket submissions)
It does not apply to paper records transmitted
electronically(eg, by fax) to the FDA or paper records created
using com-puters but at no point saved to durable media. The
regula-tion states,
(b) This part applies to records in electronic formthat are
created, modified, maintained, archived,retrieved, or transmitted,
under any records re-
122 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
AlanFDA narrowed scope in Feb 2003
Alan
AlanGenerally FDA prefers PDF files for submissions and these do
not include computer generated audit trails.As of Feb 2003 FDA
narrowed scope so saving to durable media is not a trigger point
and the mere fact that a record is created electronically is not an
issue.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 123
Table 6-1. 21 CFR 11 Summary
Subpart A—General Provisions
Subpart B—Electronic Records
Subpart C—Electronic Signatures
Section 11.1—Scopea. Sets forth criteria for
reliabilityb. Applies to electronic
records created underrecords requirements
c. States that electronicsignatures meetrequirements
d. States that electronicrecords meetrequirements
e. States that computersystems are subject toinspection
Section 11.2—Implemen-tation
a. Describes maintainedrecords
b. Describes application tosubmitted records
Section 11.3—Definitions
Section 11.10—Controls forClosed Systems
a. Discusses validationb. Discusses copies of
recordsc. Discusses protection and
retention of recordsd. Discusses limiting accesse. Discusses
audit trailsf. Discusses operational
system checksg. Discusses authority
checksh. Discusses device checksi. Discusses training usersj.
Discusses written policies
to hold signature usersaccountable
k. Discusses controls oversystem documentation
Section 11.30—Controls forOpen Systems
Requires measures to ensureconfidentiality and dataintegrity
Section 11.50—SignatureManifestations
a. Requires name, date andtime, and meaning
b. Requires ahuman-readable form
Section 11.70—Signature/Record Linking
Requires controls to avoidfalsification and copyingand to ensure
linkintegrity
Section 11.100—GeneralRequirements
a. Requires uniquenessb. Requires verification of
individual’s identityc. Requires certification to
be sent to the FDA
Section 11.200—ElectronicSignature Componentsand Controls
a. Lists nonbiometricrequirements
1. Requires twocomponents
i. One component reenteredfor each signing in asession
ii. Both componentsreentered for firstsigning of each
session
2. Requires use by genuineowner only
3. Otherwise, requirescollaboration by two ormore people
b. Gives biometricrequirements
Section 11.300—Controls forIdentification Codes andPasswords
a. Requires maintenance ofuniqueness of ID andpassword
combination
b. Requires periodic checksor revision
c. Requires lossmanagementprocedures
d. Requires transactionsafeguards
e. Requires token testing
Alan
Alan
Alan
Alan
Alan
Alan
AlanHighlighted items are affected by Feb 2003 changes
Alan
-
quirements set forth in agency regulations. Thispart also
applies to electronic records submitted tothe agency under
requirements of the Federal Food,Drug, and Cosmetic Act and the
Public Health Ser-vice Act, even if such records are not
specificallyidentified in agency regulations. [Italics added.]
It is important to note that the regulation applies to
appli-cations used to create electronic records. Maintaining
dupli-cate paper copies at various points while using
theapplication will not necessarily exempt one from the regula-tion
(particularly the requirement for electronic audit trailsand
security). The broad scope of the definition and the lackof any
provision for “grandfathering” old systems, togetherwith current
interpretation by the agency, have raised con-cern among regulated
entities, which view the regulation ashighly burdensome, with the
magnitude of remediation andcompliance similar to remediation
projects in the year 2000.
The phrase “even if such records are not specifically
identi-fied in agency regulation” refers to records that the FDA
in-terprets as regulatory in nature or that an organization
hasidentified as required to meet regulatory requirements.
Computer systems subject to this regulation include
theseexamples:
✓ Medical device reporting and complaint databases used
tocreate, process, and follow up on field issues
✓ Automated batch record systems
✓ Automated device history record (DHR) systems, in whichthe
data are collected and are maintained electronically forfuture
reference
✓ Blood establishment computer systems (BECS), becauseblood
establishments are regulated directly by the FDA
✓ Computer-aided design (CAD) systems used to design medi-cal
devices
✓ Spreadsheets used to perform quality control calculationsfor
product release
✓ Document and change control systems
✓ Clinical trials computer systems
124 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
AlanIn Feb 2003 FDA narrowed scope and is more flexible on when
Part 11 applies. If computer systems create paper records and the
paper record is used for regulated activities then the system will
be exempt from Part 11 (but still may be subject to validation
under predicate rules). FDA recommends specifying whether the paper
or electronic is used in a companies procedures and suggest a
risk-based approach taking into account product and record
integrity.
AlanFeb 2003 changes indicate even systems/applications subject
to Part 11 would not usually need computer generated audit trails.
Also spreadsheets if printed with all relevant information and with
decisions made based on the printouts normally would be outside the
scope of Part 11 per FDA's new guidance. This logic may also apply
to some uses of CAD systems.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
Electronic records within the scope of the regulation dependon
the record requirements in the predicate rules that applyto a
particular entity regulated by the FDA (eg, BiologicsRegulations—21
CFR 600–680, Drug Regulations—21 CFR211–226, and Medical Device
Quality System Regulation—21 CFR 820). If a rule requires a
particular record, or if inter-nal standard operating procedures
(SOPs) indicate particularrecords are required to satisfy a
regulation’s record require-ments, then 21 CFR 11 would apply,
provided that the re-cords are electronic.
Thus, there are differences between what is subject to 21CFR 11,
depending on which other rules apply. For example,the Quality
System Regulation for medical devices allowsthat “research” is
generally not within the scope of the reg-ulation, and, thus, one
can infer that research documentsare generally not subject to 21
CFR 11 (except, for example,if the research data are used for
submissions or validationpurposes), and the concept of some level
of uncontrolleddrafts is acceptable. The Drug Regulations are
different inthis regard, and the FDA has stated the concept of
exempt-ing some “research” and “draft” documents is not as clearfor
drugs as it is for devices.
Section 11.2—Implementation
Section 11.2 makes it clear that regulatory records can
bemaintained solely or in part in electronic form, providedthat
requirements of this regulation are met. Allowance for“in part”
provides one of the justifications for using “hy-brid” (part paper,
part electronic) record systems. The term“hybrid” is also used to
indicate situations where records areelectronic, but signatures are
on paper. Whether hybrid sys-tems can ensure record integrity and
can meet the require-ments of the regulation has been a subject of
muchdiscussion and some disagreement, but can be acceptable
ifproperly implemented.
Section 11.2 also clarifies that premarket or other
requiredinformation may be submitted to the FDA electronically
onlyif it is specifically identified by the FDA in Public Docket
No.92S-0251 as acceptable in electronic form. Otherwise,
thoseelectronic records must be printed and submitted in paper
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 125
AlanThe Feb 2003 redirection indicates that only records
required by predicate rules are within scope. Informal drafts would
not be within scope.
AlanFDA has asserted the acceptability of hybrid systems several
times as long as data integrity and linkage between paper and
electronic parts are credible.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
form. It also appears that companies can provide
premarketsubmissions to the agency in paper form even if the FDA
hasidentified electronic submission as acceptable. (Currently,the
FDA does not accept blood bank submissions in elec-tronic form.)
The FDA does reserve the right to request elec-tronic copies of any
record that is available electronically.
Section 11.3—Definitions
The definitions section of Subpart A includes definitionsthat
help clarify electronic signatures and the terminologyassociated
with them, including digital signature, electronicsignature, and
handwritten signature. The definitions andthe requirements of the
regulation are written to allow flexi-bility in the technology used
to implement electronic signa-tures.
The terms open system and closed system are also defined.The
regulation establishes more requirements for open sys-tems than for
closed systems. In addition, the definition ofthe term electronic
record is quite broad, including “text,graphics, data, audio,
pictorial, or other information,” andis not restricted to text and
numerical data.
Subpart B—Electronic Records
Subpart B defines controls required to ensure the
integrity,authenticity, and confidentiality of electronic records
andsignatures. Confidentiality may or may not be required,
de-pending on the type of electronic record involved.
Specificmention of confidentiality in this regulation ensures
thatelectronic records systems meet the confidentiality
require-ments of other regulations. Of particular importance is
theconfidentiality of individual patient and donor records.
Theeffect of the new Health Insurance Portability and
Account-ability Act (HIPAA) regulation on such confidentiality
re-quirements should also be considered.
126 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
-
Section 11.10—Controls for Closed Systems
Section 11.10 would be better titled “Required Controls forAll
Systems,” because controls required for closed systemsalso apply to
open systems. The distinction between anopen and a closed system is
based on whether access is con-trolled by the same organization
responsible for the contentof the electronic record. This
distinction will be discussedlater in this chapter.
Eleven subsections of requirements for controls are in
thissection, and they apply to both open and closed systems.They
can be grouped into the following categories: valida-tion,
functional and administrative requirements, and
otherrequirements.
Subsection 11.10(a) requires validation. Validation of com-puter
systems used by drug, device, biologics, and foodmanufacturers has
been a regulatory requirement for manyyears. Although terminology
and organization of documen-tation varies and the regulation is not
prescriptive in thisregard, the major elements of formal documented
computersystem validation include:
✓ Validation plans
✓ Requirements and design specifications
✓ Test plans and test cases
✓ Test results
✓ Validation and test summaries
✓ Configuration management (eg, code, executable,
platform,change control)
✓ Release and distribution control
✓ User and administrator training
✓ Monitoring, maintenance, and administration
There is a large body of knowledge on this subject, and
de-tailed treatment of the validation requirement is beyond
thescope of this chapter. It is, however, important to note that21
CFR 11 stresses that the validation should focus on recordintegrity
and/or the system’s ability to identify invalid or al-
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 127
-
tered records. The regulation establishes some
compliancerequirements (eg, audit trails, security) that can
beachieved only if appropriate functionality is built into
thecomputer system. Therefore, the requirements and
designspecifications, as well as the test plans and results,
shouldexplicitly address that this functionality is specified,
imple-mented, and verified as part of the validation. For
instance,the system’s security should be challenged by attempts
tomodify or delete records by users with inappropriate accesslevels
or invalid logins. Audit trails should be tested for dif-ferent
types of records or actions (eg, create, modify, de-lete), and they
should be verified to include all requiredinformational components
(eg, date and time stamps, iden-tification of the initiator).
Subsections 11.10(b) through (h) establish compliance
re-quirements that generally can be met only if an
electronicrecords system has adequate functionality and is
properlyadministered. The term functional requirements is used
inthis chapter to indicate requirements of 21 CFR 11 that
gen-erally can be satisfied only if specific features and
functionsare built into the computer system itself. Other sections
ofthe regulation establish added functional requirements foropen
systems and for electronic signatures and are dis-cussed later in
this chapter.
Some aspects of the regulation in these subsections haveboth a
functional and an administrative component. For in-stance,
subsection 11.10(d) requires “limiting system ac-cess to authorized
individuals.” To comply with this require-ment, the computer system
must have built-in security fea-tures to limit access to authorized
individuals, and adminis-tration of access lists must be formally
controlled as part ofan administrative procedure.
Subsection 11.10(b) requires the ability to generateaccurate and
complete copies of records in both human-readable and electronic
form. When designing a computersystem or selecting a commercial
off-the-shelf system, aregulated entity should consider functional
requirements fordisplay use, printouts, and electronic data files.
Not only isthe availability of all the required data important, but
alsothe clarity with which data are presented and the ability
toprovide just the required information to the agency shouldbe
considered.
128 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
AlanAs of Feb 2003 computer generated audit trails are not
normally required as long as integrity can be demonstrated. Manual
or semi-automated audit trails may be appropriate where such
information is required by predicate rules or for highly important
records. Note that if there is evidence of data integrity problems
then additional controls may be seen as having been necessary.
Clinical trials systems still require audit trails as they are
high risk containing critical data and subject to their own
guidance documents.
AlanThe Feb 2003 redirection makes explicit that provision of
paper or pdf copies is acceptable without having to provide the
original electronic format or application provided all information
required by predicate rules is included.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
Subsection 11.10(c) requires the ability to protect and
re-trieve the records throughout the retention period. This
sub-section deals with the integrity of electronic records and
theorganization’s ability to retrieve those records during
theperiod that they are legally required to be retained.
Simplyprinting out copies of records when a computer system
orperipheral is retired from use does not satisfy this
require-ment, but transferring electronic records to new
systemsmay, provided that the migration is formally controlled
andvalidated, and that the functionality is equivalent.
Choice of storage media, compatibility of new software ver-sions
with older data formats, and compatibility of newhardware with
older media types and formats should be care-fully considered in
light of the required retention period forthe electronic records
involved. In addition to retention,the protection aspect of this
requirement includes data in-tegrity checks, including virus
protection, disk checking(eg, Scandisk), and similar measures.
Subsection 11.10(d) requires that access be limited. Sub-section
11.10(g) requires authority checks so that when anindividual tries
to access electronic records, the computersystem checks his or her
identification and access rights andcompares them to the relevant
access lists. The user will beallowed to perform only the
operations for which he or she isauthorized. Subsection 11.10(h)
requires using appropriatedevice checks to provide security on the
basis of the sourceof the command or data input (eg, specific
communicationsinterface, terminal, and location).
Security measures should ensure that only people whoshould have
access do have that access. Hence, the systemmust have adequate
security setup and functionality as wellas security procedures for
administering access on an ongo-ing basis, including authorizing
access list changes. If con-fidentiality is not a concern, read
access is not as importantas write access (except when read access
could compromisedata integrity or authenticity, for example, read
access tologins, passwords, or other system information that
couldjeopardize security).
As a person’s need for access changes, security authoriza-tions
should be modified accordingly. A difficult aspect
ofadministratering access rights is removing write access forformer
employees and employees who have changed jobfunction.
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 129
AlanThe Feb 2003 redirection allows archiving of electronic
record to paper, pdf, microfiche or other forms and does not
require access to the original data or system provided all
information required by predicate rules (not by Part 11) is
included.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
Note that the words “as appropriate” are used in severalplaces
in this section. Those words indicate that a particularrequirement
does not apply in all cases. For instance, sec-tion 11.10(h)
requires devices checks as appropriate. Com-ment 85 of the preamble
states,
FDA advises that, by use of the term ‘‘as appropri-ate,’’ it
does not intend to require device checks inall cases. The agency
believes that these checks arewarranted where only certain devices
have been se-lected as legitimate sources of data input or
com-mands.
When not implementing a requirement, a regulated entity iswell
advised to document its rationale for determining thatthe
requirement was not appropriate. Doing so will enablethe
organization to defend the decision later to an FDA in-spector, if
necessary. One approach that would ensure ade-quate internal review
of such choices would be to include aspecific list of 21 CFR 11
requirements that are not to be im-plemented, if any, in the
requirements specifications of eachelectronic records system along
with the rationale.
Subsection 11.10(e) requires computer-generated audittrails.
Manual audit trails are not acceptable. The audit trailinformation
must include date and time of creation, modifi-cations and
deletions of an electronic record. The computeritself—not the
user—must provide the time and datestamp. In addition,
modifications must not obscure previ-ously recorded information, so
that the electronic recordcan be recreated for any point in time.
The audit trail infor-mation must be available for the full record
retention periodin both human-readable and electronic form.
The requirement for electronic audit trails has been of
par-ticular concern, and although solutions exist, it is some-times
viewed as problematic for legacy systems andsmall-configured
applications (eg, spreadsheets). Many sys-tems maintain records and
data that are subject to the regu-lation together with records and
data that are not. One ofthe keys to ensuring that an adequate
electronic audit trailwill exist is determining the specific
records and data fieldsthat are subject to the requirement, unless
an electronic au-dit trail is implemented for all data changes.
Another important issue is identifying the points at which
a“modification” is considered to have occurred and, there-
130 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
AlanThe Feb 2003 redirection relaxes the requirement for
computer generated audit trails as long as record integrity can be
demonstrated in other ways and as long as records include revision
histories in some form where required by predicate rules.
If companies are replacing systems solely to meet the computer
generated audit trail requirements of Part 11 this may not be
necessary in most cases.
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
Mindy
-
fore, at which an entry and electronic audit trail is
required.For instance, each keystroke and backspace during
initialdata entry need not be recorded in the audit trail. In
somesystems, confirmation of acceptance of a group of fieldsfilled
in on an on-screen form could be the point at whichentries are made
to the audit trail. In other systems, move-ment from field to field
is considered acceptance and is thepoint at which the audit trail
information is updated.
The audit trail requirement is intended to capture signifi-cant
operator-initiated actions—not all internal intermedi-ate steps in
the program logic, manipulation of temporarydata, or navigation
through the user interface. In responseto Comment 72 in the
preamble, the FDA states,
It is the agency’s intent that the audit trail providea record
of essentially who did what, wrote what,and when….
The agency believes that, in general, the kinds ofoperator
actions that need to be covered by an au-dit trail are those
important enough to memorializein the electronic record itself.
These are actionswhich, for the most part, would be recorded in
cor-responding paper records according to existing re-cordkeeping
requirements. The agency intends thatthe audit trail capture
operator actions (eg, a com-mand to open a valve) at the time they
occur, andoperator information (eg, data entry) at the timethe
information is saved to the recording media(such as disk or tape),
in much the same manner assuch actions and information are
memorialized onpaper. The audit trail need not capture every
key-stroke and mistake that is held in a temporarybuffer before
those commitments.
On the basis of this comment, it could be argued that com-puter
systems that log data in real time and provide no userinterface to
modify data might not require audit trails. How-ever, this has not
been explicitly acknowledged by the FDA.
Subsection 11.10(f) requires operational system checks
forsequencing where appropriate. Such checks are required if
arecord must be modified in a particular sequence for thedata to be
valid. A system that implements an electronicworkflow that
sequences requirements for data entry, re-view, approvals, or
changes to or record status would be re-
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 131
-
quired to have built-in checks to prevent users fromviolating
the sequence. (For example, a BECS may preventissuing blood for
transfusion or distribution if all mandatorytesting has not been
performed.)
Other provisions of this section include the following:
✓ Subsection 11.10(i) requires a regulated entity to
determinethat those who develop, maintain, or use the system
havethe proper training and background to do so properly.
✓ Subsection 11.10(j) requires “written policies that hold
in-dividuals accountable and responsible for actions initiatedunder
their electronic signatures.”
✓ Subsection 11.10(k) requires formal control of system
docu-mentation and formal change control procedures. Documen-tation
is specifically required that indicates the sequence ofdevelopment
and modification of system documentation toallow review of the
order of development and maintenanceactivities.
Section 11.30—Controls for Open Systems
The regulation distinguishes open and closed systems andrequires
additional controls for open systems. An open sys-tem is one in
which the organization that controls systemaccess is not also
responsible for record content. Systemsadministered by internal IT
groups, or locally by the user,generally qualify as closed systems.
Systems administeredby vendors can also qualify as closed sytems,
provided that1) they are maintained exclusively for a regulated
organiza-tion, 2) access is mutually agreed upon, and 3) access is
re-stricted to the regulated entity.
An example of an open system would be a virtual public net-work
or an application that is hosted by an Internet serviceor
applications provider, which determines access rights. Inblood
banking, a national deferral list could be consideredan open or
closed system, depending on who controls accessto it and to the
computers on which it resides and who hasaccess to modify it.
Section 11.30 does not specify additional procedures andcontrols
for open systems, but it does provide examples suchas encryption
and use of digital signature standards. The in-
132 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
-
tent is that there be mechanisms to ensure authenticity,
in-tegrity, and confidentiality that do not entirely depend
onproper control of an open system’s access rights.
Section 11.50—Signature Manifestations
Section 11.50 defines the information that must be createdand
retained as an electronic record each time an electronicsignature
is used. Specifically, signed records must includethe following
information in addition to the signature itself,and this
information must be displayed in human-readableform along with the
record:
✓ Printed name of the signer (an ID number is not
sufficient)
✓ Date and time of the signature
✓ Meaning of the signature (eg, review, approval,
responsibil-ity, authorship)
During the discussion of the draft of the regulation beforethe
Final Rule, the FDA expressed several concerns aboutelectronic
signatures:
✓ Some systems could create a signature when a user pressesan
ambiguous button such as “next.”
✓ User might not understand what they were signing for
✓ Users should apply their electronic signatures with the
samecare that they would apply their handwritten signature.
The FDA, therefore, wanted to ensure that users were explic-itly
informed of and clearly understood the meaning of theirsignature.
Training, procedures, and displays should makethe reasons for
signatures as explicit as possible.
Section 11.70—Signature/Record Linking
Section 11.70 states that the mechanism for linking a signa-ture
to a record must prevent easy removal of the signatureor its
transfer to another record. That requirement also ap-plies to
hybrid systems where some or all records are elec-tronic but
signatures are not. The method by which asignature is linked to the
signed record needs to be defensi-
ELECTRONIC RECORDS AND ELECTRONIC SIGNATURES 133
-
ble in terms of the integrity of the linkage and must
preventfalsification of signatures by removing them or
transferringthem to other records. The phrase “through ordinary
means”is used in the context of falsification and indicates that
theFDA allows that the method need not be foolproof but
alsorequires that falsification not be easy, especially for
ordi-nary users of a system. For example,
✓ A user should not be able (within the functionality of
thesystem) to delete his or her signature once it is applied to
aspecific record.
✓ A user should not be able to cut or copy the full
electronicsignature into, for example, the Microsoft Windows
clip-board and then paste it to another record in a manner thatthe
system cannot detect as invalid.
Subpart C—Electronic Signatures
Subpart C addresses issues specific to electronic signaturesand
provides a range of options for implementing them. Itdefines two
potentially acceptable types of electronic signa-tures: biometric
and nonbiometric. It provides general re-quirements for electronic
signatures regardless of their typeand additional requirements
depending on type. The regula-tion defines biometrics as:
A method of verifying an individual’s identity basedon
measurement of the individual’s physical fea-tures or repeatable
action(s) where those featuresand/or actions are both unique to
that individualand measurable.
According to that definition, identifying cards and
otherphysical tokens are not biometric signatures. The only
ex-plicit specific requirement for biometric signatures, beyondthe
general requirements for electronic signatures, is thatthey be
designed to ensure that they can be used only bytheir genuine
owner. As long as that requirement is met, theFDA has left open the
choice of technology. Fingerprint,face, voice, retinal, handwriting
recognition, and otheremerging technologies can qualify. Subpart C
establishesadditional requirements for nonbiometric signatures.
134 INFORMATION TECHNOLOGY IN TRANSFUSION MEDICINE
AlanAlthough FDA's Part 11 redirection has not changed specific
requirements of this section of the rule its narrowing of scope
could effect what is considered a regulated electronic
signature.
For example electronic signatures could be used online but a
printout with a handwritten signature could serve as the permanent
record if desired and could be sufficient provided it is made prior
use of the record for a regulated purpose. In such cases the
electron