Sidebar

The blood bank software of your dreams

October 2001
Suzanne H. Butch, MA, CLDir(NCA)

Back to Cover Story

We expect software to prevent ABO-incompatible blood from being issued and to tell us if a patient’s blood type does not match what was listed previously, as well as perform a number of other tasks. But software should also capture all the steps in processing blood components and add significantly to the blood banker’s ability to prevent errors.

Software should help laboratories meet the requirements of current good manufacturing practices and beyond. It should prevent mistakes or provide a means for detecting them before a unit of blood is issued. Some of these features are now available, such as electronic crossmatch, instrument interfaces, and ISBT 128 capabilities, but no system contains all of the necessary features. So what would the ideal software for the blood bank or transfusion service do?

• Use the error-checking features of ISBT 128 to detect data-entry and labeling errors. Much of today’s software can use ISBT 128, but it fails to use the data-checking features of this symbology, such as reading the data identifiers to ensure that a blood type bar code is not entered for a donor identification number or reading the concatenate features of the symbology to ensure that the correct blood labels have been applied to the bag. Software should know the maximum length of a data stream expected for a field and be able to validate the contents of the input by comparing it to a table of acceptable values.
• Use bar coding from the time an empty bag is labeled until a blood component is transfused or discarded. This must be coupled with the use of an electronic means for identifying patients at specimen collection, generating specimen labels, and identifying patients prior to any treatment, including transfusion.
• Facilitate bar-code reading. For example, when dispensing a blood component, the component bar code should be read first and the information about the unit displayed rather than selecting the unit to be dispensed from a list of units available for a patient.
• Capture all "manufacturing" steps in the blood bank system. When adding a bag or syringe to a blood component, software should document all information about the lot numbers, unit identification, personnel identification, date, time, and weld inspection for that item.
• Allow the information from blood irradiators, apheresis equipment, and centrifuges to be added to the unit record automatically.
• Automatically display a patient’s recent hemoglobin, platelet count, or coagulation test results when components are being reserved for a patient to assist with prospective review.
• Make it easier to generate visual and aural warnings for problems. For example, software should permit the end user to require an acknowledgement of a patient’s special blood component needs each time a component is reserved for that patient, not just when a component is issued.
• Allow the user to determine what combinations of components should get a warning, need a password, or should not be issued to a patient.
• Offer full multi-facility and centralized transfusion service support.
• Provide a report writer that does not require a degree in programming to use. The report writer should ask: How many autologous units were ordered for the patient of Dr. X? One caveat is that for the system to find answers, data must be entered into the system. This task may be more than some blood bankers are willing to undertake, particularly if their systems don’t interface to data repositories.
• Use the real estate on the screen effectively. Applications should be designed to fit the entire screen. Type fonts should be at least 12 points in size. Different fonts should be used to differentiate screen and background information from entered results or related information. Software should allow flexibility in how each person displays tests for result entry and that display setting should remain until it is intentionally reset.
• Reduce the paper used. Software should allow the review of all testing performed in the laboratory during the past days or weekend to be documented online rather than printing it so a signature can be shown to an assessor or investigator.
• Provide an online procedure manual for technical and computer operations. This would require an index containing such categories as "positive antibody screen," "broken bag," or "transfusion reaction," to simplify searches.
• Offer a secondary method for looking up special patient requirements, patient blood types, and transfusion reactions that does not involve printing a list on paper. This information could be stored on a CD, tape, or PC.
• Provide an audit trail for every entry or deletion for routine as well as utility programs. Software should include for all tasks and modules at least four levels of security—view; view and enter; view, enter, and modify; and view, enter, modify, and delete.
• Embody a method to modify, delete, or inactivate data or database parameters. For example, when the disposal method for blood components changes from incinerate to autoclave, the potential for selecting the wrong disposal method could be reduced if all the disposal options containing the method "incinerate" could be inactivated and only the options containing the word "autoclave" could be selected.

Flexibility, however, comes at a cost. The complexity of the system increases and the time to set up and validate the system rises almost exponentially. But if we want computer systems to do a better job of preventing errors, we need software that can be tailored to our needs. The future of the regulatory environment is focused on increased attention to process control. We expect our information systems to document and retrieve all the necessary information about patients and blood units quickly and accurately and in a manner that facilitates our use of the information.

The blood bank software featured on pages 33 through 42 performs some of the aforementioned functions. The information provided is based on vendors’ responses to a questionnaire. Readers should validate vendors’ claims before making a purchase.

Suzanne Butch is chief technologist of the blood bank and transfusion service, University of Michigan Health System, Ann Arbor. She is responsible for validating and implementing blood bank software.