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 

 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

Table of Contents 

I. INTRODUCTION............................................................................................................. 1

II. BACKGROUND ............................................................................................................... 2

A. Description of Blood Establishment Computer System .................................... 2

B. Description of Blood Establishment Computer Software ................................. 2

C. Definitions and Terminology ............................................................................... 3

III. DISCUSSION .................................................................................................................... 4

A. Vendor Selection ................................................................................................... 4

B. Validation Coverage ............................................................................................. 4

C. Risk Assessment .................................................................................................... 4

D. Validation Procedures .......................................................................................... 5

E. Validation Plan...................................................................................................... 5

F. Validation Activities ............................................................................................. 5

G. Validation Report ................................................................................................. 7

H. Validation after a Change .................................................................................... 7

I. Integrated Package vs. Stand-Alone ................................................................... 8

J. System Documentation ......................................................................................... 8

IV. REFERENCES.................................................................................................................. 9

 i 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

1 

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. 

I. INTRODUCTION 

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. 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

2 

II. BACKGROUND 

A. Description of Blood Establishment Computer System 

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. 

B. Description of Blood Establishment Computer Software 

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: 

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

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: 

• 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. 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

3 

C. Definitions and Terminology 

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. 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

4 

III. DISCUSSION 

A. Vendor Selection 

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

B. Validation Coverage 

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. 

C. Risk Assessment 

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. 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

5 

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. 

D. Validation Procedures 

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: 

• 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 

E. Validation Plan 

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) 

F. Validation Activities 

Consider the following points as you prepare to perform validation activities: 

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

2. 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) 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

6 

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. 

3. 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 screenprints, where appropriate, be identified to link them to the specific test case. 

4. We recommend that you test at your peak production times and with the 

maximum number of concurrent users to assure proper system performance. 

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

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

7. You must establish procedures for the proper use of your system 

(21 CFR 211.100(a), 606.100(b)). 

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

9. 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 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

7 

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. 

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

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. 

G. Validation Report 

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. 

H. Validation after a Change 

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 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

8 

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. 

I. Integrated Package vs. Stand-Alone 

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. 

J. System Documentation 

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: 

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

2. 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 
Contains Nonbinding Recommendations 

Draft – Not for Implementation 

9 

• 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 

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. 

IV. REFERENCES 

1. General Principles of Software Validation; Final Guidance for Industry and FDA Staff 

(January 11, 2002), http://www.fda.gov/cdrh/comp/guidance/938.html. 

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

3. 510(k) Blood Establishment Computer Software, 

http://www.fda.gov/cber/products/510ksoft.htm. 

4. FDA Glossary of Computerized System and Software Development Terminology, 

http://www.fda.gov/ora/inspect_ref/igs/gloss.html. 

5. Warning Letters and Other Compliance Letters, http://www.fda.gov/cber/efoi/warning.htm 

6. Adverse Event Reports (Maude Database), 

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfMAUDE/search.CFM 

7. FDA Enforcement Reports Index, http://www.fda.gov/opacom/Enforce.html 

8. Recalls, Market Withdrawals and Safety Alerts, http://www.fda.gov/opacom/7alerts.html 

9. 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.* 

*This draft guidance, when finalized, will represent FDA’s current thinking on that topic.