Guidance for Industry
Blood Establishment Computer System Validation in the User's Facility
DRAFT GUIDANCE
This guidance document is for comment purposes only.
Submit comments on this draft guidance by the date provided in the Federal Register notice announcing the availability of the draft guidance. Submit written comments to the Division of Dockets Management (HFA-305), Food and Drug Administration, 5630 Fishers Lane, Rm. 1061, Rockville, MD 20852. Submit electronic comments to either http://www.fda.gov/dockets/ecomments or http://www.regulations.gov. You should identify all comments with the docket number listed 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, Suite 200N, 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 on the content of this guidance, contact Linda Weir, Office of Blood Research and Review, at 301-827-6136.
U.S. Department of Health and Human Services
Food and Drug Administration
Center for Biologics Evaluation and Research
October 2007
- INTRODUCTION
- BACKGROUND
- Description of Blood Establishment Computer System
- Description of Blood Establishment Computer Software
- Definitions and Terminology
- DISCUSSION
- Vendor Selection
- Validation Coverage
- Risk Assessment
- Validation Procedures
- Validation Plan
- Validation Activities
- Validation Report
- Validation after a Change
- Integrated Package vs. Stand-Alone
- System Documentation
- REFERENCES
Contains Nonbinding Recommendations
Draft - Not for Implementation
Guidance for Industry
Blood Establishment Computer System Validation in the User's Facility
| This draft guidance, when finalized, will represent the Food and Drug Administration's (FDA's) current thinking on this topic. It does not create or confer any rights for or on any person and does not operate to bind FDA or the public. You can use an alternative approach if the approach satisfies the requirements of the applicable statutes and regulations. If you want to discuss an alternative approach, contact the appropriate FDA staff. If you cannot identify the appropriate FDA staff, call the appropriate number listed on the title page of this guidance. |
- Description of Blood Establishment Computer System
- Description of Blood Establishment Computer Software
- use during the manufacturing process for determining donor suitability/eligibility and release of the blood or blood component as suitable for transfusion or further manufacture; and
- use in transfusion services to perform compatibility testing and other related functions.
- how certain provisions of Title 21 Code of Federal Regulations (CFR) (e.g., 21 CFR 211.68, 21 CFR 606.100(b), 21 CFR 606.160) apply to Blood Establishment Computer Systems,
- FDA's current approach to evaluating a Blood Establishment Computer System validation program,
- the elements FDA recommends for the validation of Blood Establishment Computer Systems, and
- answers to other frequently asked questions.
- Definitions and Terminology
- Vendor Selection
- Validation Coverage
- Risk Assessment
- Validation Procedures
- writing a validation plan
- performing a risk assessment
- writing a validation report
- addressing change control
- writing a test case
- amending a test case
- handling validation deviations
- validating after a change
- performing system maintenance
- Validation Plan
- Validation Activities
- We recommend that you perform validation in the "test environment" or "test partition" of your system. After successful validation, you or your software manufacturer should copy or move the file configuration on which you performed your validation into the production environment.
- We recommend that you follow a pre-defined written test plan. Each test case in the plan should include the input, expected output, actual output, acceptance criteria, whether the test passed or failed, the name or initials of the person performing the test, and the date the test was performed. Test cases should include normal results (results within the "normal range"), abnormal results (unacceptable results or those outside the "normal" range) and boundary results or values. Boundary testing is testing at the boundary of a specification, in other words, at the limit, just below the limit, and just over the limit. Boundary values are "off-by-one errors." An example of boundary testing is testing for a hematocrit of 37%, 38% and 39% if the cutoff (or boundary value) for hematocrit is 38%. You should also test for "absurd" results (invalid or nonsense results). Examples of absurd or unexpected values might be an alpha result in a numeric field, a hematocrit of 110% or a blank (or leading blank) in a result field.
- You must retain validation records (21 CFR 211.68(b), 211.100(b), 606.160(b)(5)(ii)). Your records should include documented evidence of all test cases, test input data and test results. Test results should include screen prints. For traceability purposes and to facilitate quality assurance review and follow-up, we recommend that any supporting documentation, such as screen-prints, where appropriate, be identified to link them to the specific test case.
- We recommend that you test at your peak production times and with the maximum number of concurrent users to assure proper system performance.
- We recommend that you test to assure you have correctly defined system security and that all users can log on with the correct security privileges.
- We recommend that you validate all interfaces, including those to a Hospital Information System (HIS) (e.g., admissions, discharges and transfers (ADT)); a Laboratory Information System (LIS) (e.g. order entry/results return (OE/RR)); and all instrument interfaces, as applicable. Monitoring of interface error files should continue subsequent to implementation as unforeseen transaction types or data elements may cause disastrous results (such as orders not being received, results posting to the incorrect donor/patient record, etc.)
- You must establish procedures for the proper use of your system (21 CFR 211.100(a), 606.100(b)).
- You must train personnel in the use of the system procedures (21 CFR 211.25(a), 606.160(b)(5)(v)). Training should include assessing the user's ability to understand and correctly use the system. You should evaluate the ability of computer operators to perform system maintenance procedures, such as backups, and their ability to respond in an appropriate and timely manner to all alarms, warnings and error messages.
- We recommend that you validate or verify the output of system reports. We recommend you include any reports containing donor or recipient history information, product quarantine reports, donor or patient merge reports, and patient chart reports (as applicable) in this effort. It is particularly important to ensure that reports print in lower and upper case if the system keeps records of red blood cell phenotype or antibodies.
- We recommend that you closely monitor the system for a period of time after installation of the new or upgraded software in the production environment to detect any discrepancies that were not identified by the test cases.
- Validation Report
- Validation after a Change
- Integrated Package vs. Stand-Alone
- System Documentation
- Items Supplied by the Software Developer, such as:
- hardware specifications and hardware requirements
- instruction manuals, e.g., User's Manual, Operations Manual, Installation Manual, System Administration Manual, etc.
- environmental requirements
- Items Supplied by the User, such as:
- system description
- network diagram
- list and location of peripheral devices such as printers and terminals
- processor type(s)
- operating system and version number
- system memory
- disk configuration
- type and location of backup media
- list of interfaces
- list of environments on system, e.g., test, training, production, etc
- SOPs
- validation records
- record of hardware and software maintenance, including date performed
- record of changes made to system hardware, software and peripheral devices, including date
- user training records
- problem reports and their resolution
- General Principles of Software Validation; Final Guidance for Industry and FDA Staff (January 11, 2002), http://www.fda.gov/cdrh/comp/guidance/938.html.
- Guidance for Industry and FDA Staff: Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (May 11, 2005), http://www.fda.gov/cdrh/ode/guidance/337.html
- 510(k) Blood Establishment Computer Software, http://www.fda.gov/cber/products/510ksoft.htm.
- FDA Glossary of Computerized System and Software Development Terminology, http://www.fda.gov/ora/inspect_ref/igs/gloss.html.
- Warning Letters and Other Compliance Letters, http://www.fda.gov/cber/efoi/warning.htm
- Adverse Event Reports (Maude Database), http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/search.CFM
- FDA Enforcement Reports Index, http://www.fda.gov/opacom/Enforce.html
- Recalls, Market Withdrawals and Safety Alerts, http://www.fda.gov/opacom/7alerts.html
- Draft Guidance for Industry and FDA Staff, Radio Frequency Wireless Technology in Medical Devices (January 3, 2007), http://www.fda.gov/cdrh/osel/guidance/1618.html.*
We, FDA, are issuing this guidance to assist you, blood establishments, in developing a blood establishment computer system validation program, consistent with recognized principles of software validation, quality assurance, and current good software engineering practices. This guidance addresses a blood establishment's validation of its Blood Establishment Computer System which incorporates Blood Establishment Computer Software (BECS). The BECS that is incorporated into a Blood Establishment Computer System may be manufactured either in-house or by a software manufacturer/vendor.
While this guidance may provide manufacturers of BECS with information about validation of computer systems in the user's facility, this guidance does not address the manufacturer's validation responsibilities, or the submission of a 510(k) premarket notification for BECS. For guidance on validation applicable to the manufacturer of medical device software, including BECS, see the guidance document entitled "General Principles of Software Validation; Final Guidance for Industry and FDA Staff" (Ref. 1). For guidance on the submission of a 510(k) for BECS, see the guidance document entitled "Guidance for Industry and FDA Staff: Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices" (Ref. 2).
FDA's guidance documents, including this guidance, do not establish legally enforceable responsibilities. Instead, guidances describe the FDA's current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word should in FDA guidances means that something is suggested or recommended, but not required.
A Blood Establishment Computer System (also referred to as "system") includes: computer hardware, computer software, peripheral devices, personnel, and documentation, e.g., User's Manuals, Standard Operating Procedures (SOPs). The computer software used in a Blood Establishment Computer System includes BECS, which is a medical device. FDA considers a Blood Establishment Computer System to be equipment under Title 21 Code of Federal Regulations (CFR) 606.60, and automated or electronic equipment under 21 CFR 211.68.
BECS is software designed to be used in a blood establishment that is intended for use in the diagnosis of disease or other conditions in donors, or in the prevention of disease in humans by the release of unsuitable blood and blood components. Some of the intended uses of BECS include:
FDA provides a list of 510(k) cleared BECS on their Internet Web site (Ref. 3). You should note that the version number listed is the version that received clearance; the manufacturer may have released an upgrade that did not require a new 510(k). The list is cumulative and includes BECS that may no longer be available or supported by the original manufacturer.
This guidance describes the following:
In addition to the following definitions used in this guidance, you may find other terms relating to Blood Establishment Computer Systems and BECS in the FDA Glossary of Computerized System and Software Development Terminology (Ref. 4). The use of some terms in this guidance or in FDA regulations may vary somewhat from some uses in the software industry. For example, the International Organization for Standardization (ISO 8402:1994) treats "verification" and "validation" as separate and distinct terms. However, many software engineering journals and textbooks use the terms "verification" and "validation" interchangeably, or in some cases, refer to software "verification, validation, and testing (VV&T)" as a single concept, with no distinction among the three terms. We provide the following definitions in an effort to clarify our meaning.
Accessory means something used in conjunction with or attached to a medical device. (The medical device with which the accessory is used or to which it is attached is the "parent device.") Accessory is also included in the Act's definition of "device" (section 201(a)(h)). An accessory is regulated like the parent device. Examples of accessories to a BECS include an interface or data management system. Note that while hardware and other peripherals, (CPUs, monitors, and printers) are part of the Blood Establishment Computer System, they are not considered accessories to the BECS.
Blood establishment means a place of business under one management at one general physical location. The term includes, among others, human blood and plasma donor centers, blood banks, transfusion services, other blood product manufacturers and independent laboratories that engage in quality control and testing for registered blood product establishments.
Establish means define, document, and implement.
Software validation means confirmation by examination and provision of objective evidence that the particular requirements for the software's intended uses can be consistently fulfilled (Ref. 1). In other words, validation of BECS in the user's facility should assure that the software is suitable for your specific operations and workload, and can accurately and repeatedly meet your needs as defined in your requirements document.
Software verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled (Ref. 1). In a software development or manufacturing environment, software verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase.
While not strictly part of system validation, we recommend that you evaluate and compare the available BECS with the needs of your blood establishment and select BECS that meets your requirements. We further recommend that you monitor reports of adverse events and recalls applicable to your BECS (Refs. 6, 7, 8).
Validation of your Blood Establishment Computer System should reflect and anticipate the system's actual use in your establishment. You should validate your system using your own personnel and your own test plans written for your specific intended use of the software. You may wish to retain a consultant for direction and assistance for this project.
We also recognize that it is a common practice for the software manufacturer to provide test cases to blood establishments for use in system validation. We recommend that you carefully consider your own intended use of the software and your internal policies and procedures and add or change test plans as appropriate to ensure that the software will accurately and repeatedly meet your requirements.
Software validation is difficult because you cannot test forever, and it is hard to know how much evidence is enough. Mostly, software validation is a matter of developing a "level of confidence" (Ref. 1) that the device meets all requirements and user expectations for the software automated functions and features.
The level of confidence and, therefore, the level of validation effort needed, vary depending upon the potential hazards posed by the automated functions of the system. Your test plan and test cases should be developed based on a risk assessment. We, therefore, recommend that you perform a risk assessment early in the validation process. After performing that assessment, you should determine the degree of validation necessary based on the identified risks, and then develop your test plan and test cases accordingly. For example, because of the potentially fatal consequences of a transfusion based on an improper crossmatch between donor and recipient, the validation of the electronic or computer crossmatch would require a higher degree of testing.
Because of the complexity of Blood Establishment Computer Systems, especially the BECS, it is difficult to predict the probability of hazard occurrence. Therefore, when you conduct your risk assessment, we recommend you consider that with software, if it can happen, it will happen.
You must develop SOPs for your validation activities as indicated by 21 CFR 211.68(a), 211.100(a), and 606.100(b)(15). We recommend that your validation SOPs include, but not necessarily be limited to, the following:
You should define and control how you will validate BECS through the use of a plan. The validation plan defines "what" the validation effort should accomplish. Validation plans specify areas such as scope, approach, resources, schedules, the types and extent of activities, tasks, and work items, and the approval process. (Ref. 1)
Consider the following points as you prepare to perform validation activities:
If your Blood Establishment Computer System includes the use of wireless radio frequency (RF) technology, we recommend that you evaluate the device for wireless coexistence, performance, data integrity, security, electromagnetic compatibility (EMC), and electromagnetic interference (EMI) in the setting in which you will use it. For further information, see the draft guidance document entitled, "Guidance for Industry and FDA Staff, Radio Frequency Wireless Technology in Medical Devices" (Ref. 9). When finalized, this draft guidance will represent FDA's current thinking on this topic.
Although not a function of your Blood Establishment Computer System, we recommend that you validate the data conversion from your legacy system to your new BECS to avoid problems such as duplicate donor records and deferral codes.
You must document your validation activities pursuant to 21 CFR 211.68, 211.100(b), and 606.160(b)(5). Your validation report should include a summary of the test results, including any variances or failed tests, any amendments made to the test cases or the validation plan, an evaluation of the outcome of your testing, and approvals or sign-offs by management.
Due to the complexity of Blood Establishment Computer Systems and BECS, a seemingly small local change may have a significant global system effect. When any change (even a small change) is made to the software on the Blood Establishment Computer System, a validation analysis should be conducted, not just for validation of the individual change, but also to determine the extent and impact of that change on the entire system. Based on the analysis, you should then conduct an appropriate level of software regression testing to show that unchanged but vulnerable portions of the system have not been adversely affected. Appropriate regression analysis and testing provide the confidence that the system is validated after a software change (Ref. 2). We recommend that you perform regression testing, when indicated by your analysis, by re-running test cases that previously passed.
When the BECS manufacturer provides modifications to the software, the manufacturer should inform you of other functions that might be affected. We recommend that your contract with a software manufacturer address this. However, you are ultimately responsible for assuring that the Blood Establishment Computer System used in your establishment has been validated for its intended use.
If your Blood Establishment Computer System or BECS is part of an integrated package on a Laboratory Information System (LIS) or Hospital Information System (HIS) rather than a stand-alone system, you should also consider how changes made to functionality shared by the LIS or HIS and BECS (such as ADT, orders, etc.) might affect your BECS. You should determine what functions or files your LIS or HIS and your BECS share by discussing this with your BECS manufacturer.
You must maintain documentation for the Blood Establishment Computer System (21 CFR 211.68, 211.100(a), 606.160(b)(5)). You should ensure that the documentation is current, accurate, and as detailed as necessary to ensure proper use and operation of the system, and ensure that all components that should be validated are validated. We recommend you include, but not necessarily limit this to, the following, as applicable to your blood establishment:
Note: Although a remote access log is not part of validation records, you may consider keeping a log of remote access to any part of your system, such as the BECS or instruments. We recommend this log include the date, time, reason for the access and the name of the person connecting to your system.
*This draft guidance, when finalized, will represent FDA's current thinking on that topic.