Who should validate computer software used in blood banks/transfusion services?

ADDENDA July 25, 2003

8. A colleague in Arizona reports that over the past two years a task force formed by the International Society of Blood Transfusion (ISBT) Working Party for Automation and Data Processing (WPADP), made up of blood banking professionals from around the world including the US, has been writing a document that consists of a set of guidelines for blood banks considering installing or changing an automated system. This guideline describes strategies for the Planning, Testing, Reviewing and Accepting, and Maintenance Phases of an automated system project. Of particular interest is a flow diagram on Page 9 of the guidelines which points out that the OQ (Operational Qualification including Worst Case Scenario Testing and Configuration Validation) portion of Validation should be performed by the User. The Vendor should provide to the blood bank documents that delineate Critical Control Points, Error Messages, System Mapping etc. In the reporting colleagues opinion, this approach reduces the possibility of inappropriate conflict of interest. These guidelines may be found here (PDF file).
   
   There are three other ways to obtain these guidelines:
   • They will be published as an addendum to the September 2003 issue of Vox Sanguinis (Official Journal of the International Society of Blood Transfusion)
   • Reprinted copies of the guideline will be available at the exhibit hall at the AABB Annual Meeting and TXPO 2003 in San Diego November 2-4, 2003, and
   • There will be a program entitled "ISBT 128" (101-TC) on Saturday, Nov. 1 from 10:30-12:00 Noon at the 2003 AABB Annual Meeting where colleagues can learn about these Validation Guidelines as well as validating the new barcode symbology ISBT 128.

ADDENDA Aug. 12, 2003

9. A software consultant in Tennessee reports that she has been a Medical Technologist for over 25 years, and that she is very concerned over what she perceives to be a resistance by certain software vendors to allow for third party validation of computer/software systems. She has worked in the general lab as well as in the blood bank as a supervisor. She was in charge of implementation/validation of her hospital's blood bank system and served as the system administrator. She left her hospital setting to work for a blood bank software company as a clinical implementation specialist in 1999, and has been working as a free lance consultant in the field since 2001. She reports that she has seen all sides of this question, and understands that software vendors/manufacturers have their own financial well being as a priority. She also understands that hospitals are under continuing mandates for better care/less cost and that the hospital staff is highly overworked and stressed. She views her role as a medical software (third party consultant) to make the process safer and more efficient for the hospital (the consultant's customer), which in turn makes it better for the patient. Where tension develops is that a third party consultant is not bound by the software vendor/manufacturer to keep a problem away from the hospital customer. On the contrary, she states that it is the third party consultant's responsibility to bring problems or potential problems to the hospital's attention. In her opinion, by allowing the software vendor/manufacturer, hospital staff and third party software consultant to all work together, the patient in the long run will receive a higher standard of care with respect to processes associated with the software. In her opinion, following the above paradigm by no means guarantees that all problems are discovered, but certainly increases the odds that more would be discovered than not.

ADDENDA Aug. 21, 2003

10. Another colleague (location not provided) reports that they, too, agree with the need for third party validation. The responding colleague states (verbatim) "The computer systems are designed for 'general' use, and only in the hands of the individual user can problems be detected. Each user has their own defined SOP's (usually for very specific reasons), and the system must stand up to these challenges. I find it less likely that the vendor will detect these faults. A third party, in concert with (and challenged by) the user, is more likely to detect and report these. I highly support third party vendors, since most blood banks, overloaded with regulatory matters and understaffed, do not have the time or personnel to do a proper validation."

ADDENDA Sept. 15, 2003

11. A colleague (location not provided) would like to mention that some hospitals expressed to one computer system vendor the need for that company to implement validation services. Test scripts and contracted execution of applicable scripts were especially requested. The responding colleague acknowledges that there is a minimal amount of time involved in making sure that the institution's policies and technical procedures are reviewed properly when the vendor customizes the test scripts, and that it can strongly be argued that the vendor is in the best position to understand and test their software modifications. Consequently, a management group at his facility made a decision to contract for the vendor's validation services based on these considerations as well as the consideration of sharing legal responsibility.

ADDENDA Sept. 17, 2003

12. Gregory Francis of Korchek Technologies (attribution used with permission) is of the opinion that this country was built on free enterprise. He comments (verbatim) "The Sherman Antitrust Act of 1890 was enacted to protect the public from powerful trusts that controlled all aspects of business. What will happen when the vendor controls all aspects of blood bank software? They manufacture, they support, they train, they validate, they set the prices, they prevent the end user from making their own decisions, they prevent true objective evaluation. Every consumer wants the freedom to choose their long distance company, their cable TV company, their software platform. We are consumers yet we are allowing software vendors to control the safety of the product we produce, blood. Allowing vendors to validate not only gives them ULTIMATE control over the software, it could lead to ultimate control of the safety of the blood supply."

ADDENDA Oct. 3, 2003

13. According to Charles Munk, ISBT Validation task force chairman (attribution used with permission), "There are many reasons that prompted ISBT to provide guidelines on validation (PDF) for the international transfusion community. Some of them are listed below:
    • Stakeholder responsibilities are in most occasions not well defined;
    • The validation culture in most organizations was not adopted - most of them see validation as an obligation instead of a benefit which does not necessarily correlate with quality;
    • Validation is applied differently from one organization to another - so it is difficult to compare validation process of different organizations;
    • Maintenance of automated systems (including computerized systems) is still underestimated
    About the question whether the supplier can perform user validation, in terms of responsibility, it may be dangerous to proceed like this. The user is responsible for the use of the system. On the other side, the supplier is responsible for providing a system that fulfills user's requirements. He also has to provide enough information to guarantee both the usability of the system within a specific framework and its limitations. The documentation has to be complete enough to guide the user in the verification of the system implementation in the environment where it will be used. The user validation process should be performed by an entity which has no conflict of interest with the supplier. It could be the user itself as well as a third party. This way to proceed is important for guaranteeing the integrity of the relationship between the user and the supplier. I hope that these considerations are of help in understanding the meaning of validation in terms of responsibility and the utility of having guidelines."

ADDENDA Oct. 5, 2003

14. A quality assurance/regulatory affairs professional in Arizona reports having been involved in software design and validation in FDA-regulated environments for over 20 years, and having served as Director of QA/RA for three of the major donor/transfusion system vendors. This colleague wishes to share the following opinions (verbatim):
    
    "During those years, I had significant involvement with both vendor product design validations and with user installations and validations, and served on the original, pre-regulation AABB/FDA information system committee that helped draft user and vendor responsibilities. Today, I am an independent consultant and have been involved with validations of many types of information systems and instrument software used in life-critical regulated environments, but have not been involved with blood bank/transfusion system validations as consultant. The thoughts that have already been expressed in your forum on the role of either the vendor or an independent consultant in a user validation of a transfusion/donor system have been fairly exhaustive and all should be given consideration. To me, both the vendor and the blood bank/transfusion service (user) have some well-defined roles and responsibilities in the validation process. And when requested, an independent consultant can and does provide a valuable role to both the vendor and the user.
    
    The vendor has the responsibility to:
    • have a well defined and documented software design/development process, including design validation
    • provide the user with the information and/or tools necessary for the user to thoroughly validate the system in their environment, and
    • provide the user (and when applicable, the FDA) with timely information on and corrections for safety related software problems.
    The user has the responsibility to:
    • ensure that the system is thoroughly validated in their own environment, using their configuration, their procedures, and to some extent their personnel
    • report to the vendor (and when applicable, the FDA) in a timely fashion any newly found software problems, and
    • install and validate safety-related software corrections in a timely fashion."
    The Arizona colleague continues by stating his opinion that "Whether or not a user or a vendor needs a consultant to assist in the design or validation process can depend on several factors, including timing, availability of internal resources/expertise, and cost. Whether the user chooses an independent consultant or the vendor (as a consultant) to assist in validation should be based on availability, capabilities, experience, cost and reputation of both. Independent consultants can provide a more objective approach, and often a much broader experience base obtained in the validation of alternate configurations of the same system and in the validation of competitive systems. Also, vendors could be less rigorous and determined in finding problems that weren't found by the vendor during design validation. I would certainly be very skeptical of any vendor that prohibits a user from utilizing an independent consultant in validation efforts. The choice should be that of the user and not the vendor. I do know that one vendor that is currently attempting to prohibit clients from using independent consultants to assist in user validations has in the past used independent consultants or firms to assist in the design and design validations of their own products - I find this very curious."

ADDENDA Oct. 7, 2003

15. A colleague with many many years of experience in blood banking and who works in industry thinks the issue is NOT whether a THIRD party does the validation; but rather that the VENDOR DOES NOT do the validation.
    
    The responding colleague comments: "The validation should be done by the end-user or their appointed third party representative to be fair and impartial with no conflict of interest. I would personally be leary of any vendor that REQUIRED that I allow them to validate their own computer system. The end-user or their third party representative should validate that the system does what the vendor says it will do, what the end-user specified their needs to be, and that the system performs in their unique environment. The VENDOR can and should do installation verification, but not Operation and Process Validation."

Page 1

Submit comments to the e-Network Forum at enetworkforum@cbbsweb.org

Ira A. Shulman, MD
CBBS e-Network Forum Senior Editor & Moderator

W. Tait Stevens, MD
CBBS e-Network Forum Editor & Moderator

Elizabeth M. St. Lezin, MD
CBBS e-Network Forum Associate Editor & Moderator