REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATION SUBMISSION FOR BLOOD ESTABLISHMENT COMPUTER SOFTWARE FINAL PUBLISHED January 13, 1997 Center for Biologics Evaluation and Research Office of Blood Research and Review Division of Blood Applications ______________________________________________________________ REVIEWER GUIDANCE FOR A PREMARKET NOTIFICATION SUBMISSION FOR BLOOD ESTABLISHMENT COMPUTER SOFTWARE SCOPE: This guidance applies to software products intended for use in the manufacture of blood and blood components or for the maintenance of data that blood establishment personnel use in making decisions regarding the suitability of donors and the release of blood or blood components for transfusion or further manufacture. INTRODUCTION: A premarket notification [510(k)] is an application 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 legally marketed device that was or is currently on the U.S. market. This guidance presents an overview of the type of information FDA reviewers should expect to be included in 510(k) submissions for such devices and the approach FDA reviewers should take in 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 of Federal Regulations (CFR) Part 807. This guidance is intended to be used as a supplement to the Reviewer 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 for or on any person and does not operate to bind the United States Food and Drug Administration or the public, it does represent the Agency's current thinking with regard to review of premarket notification submissions for blood establishment software. __________________________________________________________________ Information that should be included in the 510(k) submission as related to blood establishment computer software is identified by Roman numerals below: I. The device name, including trade or proprietary name, and common or usual name This information should include the product name and software version number. II. Establishment Registration number III. Device class determination The product code is 81MMH, and the device class has not been determined by a classification panel. IV. Performance standards There are no FDA performance standards promulgated for this device. V. The proposed labels, labeling, and advertisements must be sufficient to describe the device, the intended use, and the directions for use The intended use should be specific to the device and reflect the claimed indications. The labeling should include, but is not necessarily limited to: A. User's manual or other operating instructions B. Installation procedures C. Hardware requirements 1. Hardware platform (manufacturer, type/model, etc.) 2. Operating system (manufacturer, version and/or release, etc.) D. Special requirements E. Specifications sufficient to describe the device's operating characteristics, precautions, limitations, and maintenance information. VI. A statement of substantial equivalence A. Substantial equivalence may be claimed to: 1. A legally marketed preamendments device (one which was marketed prior to May 28, 1976). For purposes of documenting preamendments status in regard to intended use and commercial distribution, information provided should be adequate to document that the preamendments 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, catalog pages, other promotional material dated prior to May 28, 1976, shipping documents, e.g., invoices, bills of lading, receipts, etc., showing the interstate transit of the device dated prior to May 28, 1976. 2. A device that has been cleared by the Food and Drug Administration as substantially equivalent to a preamendment device for the same intended use(s). B. Identifying information relative to the predicate device, i.e., manufacturer, common name, trade name including version and release numbers, and any reference number assigned by the Food and Drug Administration should be included. C. The computer software modules, e.g., donor management, viral marker testing, component preparation, distribution, etc., may be disjoined for the purpose of identifying the predicate device(s). It may be necessary to cite multiple predicates. D. A table should be submitted comparing the intended use(s) of the devices to the intended use(s) of the predicate device to which substantial equivalence is claimed. VII. Safety and effectiveness of the device A 510(k) summary or statement should 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 information, but excluding all patient identifiers, and trade secret and confidential commercial information, as defined in 21 CFR 20.61." VIII. A truth and accuracy statement The following statement should be included in the 510(k) submission: "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." IX. Functional requirements The requirements should be grouped by functionality and preferably submitted in a table format which: A. Includes functionality as described in the operator's manual, e.g., Donor Management, Deferral Management, Component Processing, etc.; B. References the Code of Federal Regulations, Food and Drug Administration Memoranda, other industry standard(s), etc., applicable to blood establishments; C. Identifies any activities, processes, etc., normally associated with any function(s) listed above in "A" that will not be performed by the software device, e.g., manual entry of confirmatory testing results, updating of deferral 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 donor safety; E. Identifies the design safeguard, e.g., algorithms, truth tables, error checking, record locking, etc., to ensure that the safety critical requirement(s) is met; and F. Traces the design safeguard to the logic routine. A. FUNCTIONALITY: B. REFERENCED REGULATION/STANDARD: C. LIMITATIONS: D. SAFETY CRITICAL REQUIREMENT E. DESIGN SAFEGUARD F. TRACE TO LOGIC ROUTINE X. Software design and development The 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 storage capacity; 4. A list of all of the software components in the computerized system, including the version number. Software components include the operating system, databases, etc.; 5. A list and definition of all interfaces that are part of the computerized system; and 6. A list of any specific performance requirements that the computerized system must meet, e.g., transactions per second, transmission rate, number of users, etc. B. A description of the software design and development process, and related procedures C. A diagram and description of the software architecture XI. Hazard analysis A. The analytical process used to identify the hazardous elements related to donor/blood product safety should be described. The hazard analysis should include the intended use hazards and the hazards resulting from the implementation of the functional requirements in the computer and software 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 critical requirement(s) specified in section IX and the safety critical function(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 XII. Verification, validation, and testing Verification, validation, and testing should be submitted for all of the different hardware 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; and C. Representative data generated from both testing environments described above for each of the following functions if performed by the software: 1. Donor deferral 2. Labeling 3. Quarantine/Release 4. Laboratory testing, i.e., ABO/Rh, infectious disease XIII. Anomalies All anomalies ("bugs") or anything observed in the documentation or operation of the software that deviates from expectations based on previously verified software products or reference documents should be listed. XIV. Configuration management and change control The 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; and C. The procedure(s) for the maintenance of the device history and the device master record. XV. Submission format The 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; and E. Submitted to: FDA/CBER Document Control Center Suite 200 North, HFM 99 1401 Rockville Pike Rockville, Maryland 20852-1448