SoftwareCPR Blood Banking Medical Device Software...

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


®

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).


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.;


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.


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:


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


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.


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.


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


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;


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;


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;


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.


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.)


Incorrect incubation time/ temperature

Incorrect thermostat setting, faulty thermostat (Hardware)

High

1:X

Hardware Controlled Redundant sensors, resistance temperature devices, thermocouples, etc.


High

Low

Software Controlled Algorithm, e.g., If difference between temperature readings is “x” then perform action (alarm, shut down, etc.)


High Moderate User Controlled Visual inspection of temperature

Limitation(s) in the User Manual


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.


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


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-


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.


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.


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.


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-


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


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


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


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.


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-


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.


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.


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-


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-


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-


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-


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.


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

SoftwareCPR Blood Banking Medical Device Software...

Documents

Transcript of SoftwareCPR Blood Banking Medical Device Software...