BBDash: An Electron-based tool for analyzing blood product utilization

Abstract

Blood transfusions can be associated with side effects ranging from occasional febrile reactions to extremely rare fatal reactions. Monitoring blood product orders and ensuring appropriate utilization is therefore an important strategy to ensure patient safety. However, data extracted from laboratory information systems can be difficult to interpret. We created BBDash, an Electron-based tool that reads Sunquest reports to create easy-to-interpret graphs related to blood product utilization.

Introduction

Monitoring appropriate utilization of blood products is one of the many important activities performed by clinical transfusion medicine services, and having protocols for reviewing blood product usage is required by accrediting bodies, such as the Association for the Advancement of Blood and Biotherapies.¹ Ensuring appropriate usage of blood products is not just a matter of financial interest to hospital systems, it also represents a major strategy to ensure patient safety. Blood transfusions are not without risks, and can have consequences ranging anywhere from discomfort associated with febrile non-hemolytic reactions to death associated with fatal transfusion reactions.²

Fatal transfusion reactions are the most severe adverse events related to transfusion, though they are quite rare. According to the Food and Drug Administration, out of the approximately 15 million transfusions that occurred in 2019, there were 61 fatality reports that were potentially linked to transfusion.³ Non-fatal transfusion reactions, while not as disastrous, can also result in complications for patients and increase the complexity of their care. One notable example of this is patients who are chronically transfused becoming alloimmunized to red blood cells and platelets. Alloimmunization can result in immune-mediated transfusion reactions and decreased survival of transfused red blood cells or platelets. Finding appropriate products for these patients can take additional time, which may delay important procedures. Transfusing blood products which are quickly destroyed by the patient’s immune system is also not ideal. Alloimmunization significantly complicates caring for patients, and may require a great deal of coordination between transfusion medicine services, clinicians, and blood centers.

While patient safety is the primary reason to not transfuse unnecessary blood products, resource utilization is an additional compelling reason to limit unnecessary transfusions. Although efforts are currently underway to develop artificial blood products, all such components are currently derived from the scarce resource of willing donors. Blood products have a finite supply, and wasting a blood product means that it will be unavailable to another patient who may need it. In addition to the blood products themselves, financial and staffing resources associated with transfusion are an important consideration. For example, one study found that while the cost of an apheresis platelet unit was $592, the total cost of administering the unit including labor costs could be as much as $4436.⁴ In the particular patient population they studied, patients with chronic liver disease undergoing elective procedures, they estimated that the total cost of a platelet transfusion could be as high as $13,117 when considering adverse events and refractoriness.⁴ This represents a significant cost for hospitals, and presents another compelling reason to reduce the number of transfusions that are not clinically indicated.

Stewardship of blood products is a fundamental aspect of blood banking. Currently, a combination of laboratory information systems (LIS) and blood bank utilization softwares are used to perform this necessary service. Some of the most common LIS softwares used in the United States are Epic Beaker, Cerner PathNet, Sunquest/Clinisys, LabDaq, and Orchard Harvest. These can be supplemented by blood bank information systems such as ABO Suite, SafeTrace Tx, and LifeTrak to run additional analytics needed for RBC utilization. Although the need to monitor and assess the appropriateness of blood product usage is clear, not all LISs provide an easy way to perform this task. In particular, the LIS we use at our institution (Sunquest/Clinisys) only provides an unformatted text file with data related to blood product utilization. This made reviewing blood product ordering patterns impractical at a hospital-system level, and only allowed for a subset of transfusions to be reviewed. To facilitate review of blood product usage, we developed BBDash, a cross-platform application that can parse Sunquest transfusion reports and generate easy-to-read graphs of the resultant data. BBDash extracts data directly from Sunquest reports, mitigating the need for additional softwares, and has the potential to be applied to other LIS softwares such as Epic Beaker and Cerner PathNet. This has cost-saving benefits in addition to a reduction in training needed to utilize more complex blood bank information systems.

Technical background

Assessing blood product utilization on our transfusion medicine service is currently done through review of reports generated by our LIS, Sunquest. To retrieve the most relevant transfusion data, two different types of reports need to be generated from the LIS, one containing order information and one containing provider information. These reports are text files that can be up to 500 pages long for each month of data and have partially overlapping information, multiple sections, and an irregular format. These files are not tab delimited, and they cannot be easily parsed and converted into, for example, a spreadsheet. Making meaningful sense of these two reports would require a transfusion medicine specialist to read through two separate files that are hundreds of pages long, and manually match transfusions in one file to providers in the other file. Doing a full review of these data would likely take dozens of hours, and this has historically limited the number of transfusions that could be reviewed for the hospital system.

Our initial approach to this project was fraught with issues. The original application consisted of two components, a Python script to parse the report text files and create a tab delimited file with de-identified transfusion data, and a Django application to which these files could be uploaded to generate graphs. While this approach seemed attractive because the computers in our hospital system have access to Python, getting the Django web application set up locally for users proved difficult because it requires technical expertise on the part of the end user. Alternatively, it would have been possible to deploy this Django application to a cloud server to make a website that was more easily accessible to end users. However, doing so would have required significant resources from the local information technology (IT) department to ensure privacy and security compliance, and we did not believe there would be adequate support for this effort.

The current iteration of our application uses Electron, which is a framework to create cross-platform desktop applications using mainly Javascript. We found that the Electron framework was subjectively less intuitive to work with from a developer perspective and had less available documentation. However, Electron is more convenient from an end-user perspective as it allowed us to create an all-in-one application where users just need to download and install the application, and input some basic data to get set up. Currently, the scope of BBDash includes parsing reports from the LIS, creating graphs to show blood product usage by pretransfusion lab values, and creating graphs to show how providers order blood products.

All data that are entered into BBDash are stored in a SQLite database. Users are able to select a location for the database, which can either be locally on their computer or on a secure network drive. The database stores patient MRNs and detailed information about blood products including date and time of orders, hospital location, and ordering providers. As such, BBDash should only be used on a computer that is encrypted, password protected, and meets hospital security criteria for storing patient data. These data should be deleted if a user plans to de-encrypt their computer because they are leaving their hospital system, would like to use their computer for personal use only, etc.

Extracting data from the LIS reports is a multi-step process. First, users add a provider report or order report file to the program. The data from the various sections of these reports are then extracted using regular expressions. Data that have been read from the report will be added to the database. For subsequent reports that are added, the data that are extracted may result in new database entries or if some data for the transfusion are already in the database, updating existing entries. In order to match transfusions across report types, a unique constraint comprised of four attributes is used: date, donor identification number, order accession, and product type. When a new transfusion has the same values for these attributes as an already existing entry, the existing entry is updated. If a match is not found using these criteria, a new entry will be added to the database.

Procedure

Currently, the code for the Django version of BBDash is available on GitHub (https://github.com/JacobSpectorMD/BBDash), although it is not actively being maintained. The code for the more up-to-date Electron version of the application is also available on GitHub (https://github.com/JacobSpectorMD/ElectronBBDash), and a link to the executable file for the application is included on this page. In order to set up the Electron version of BBDash for Mac or Windows, download and install the application. Then, select a location for the database by going to the Settings tab and clicking Create Database. Before adding blood product reports to BBDash, some basic data should be added for optimal performance. These data include abbreviations for hospital locations and products, along with a list of providers and specialties. BBDash will attempt to automatically incorporate these data from blood product reports that are added, but due to their irregular formatting, this is not always successful. The interface for adding these data is shown in Fig. 1. The specifications for formatting of the input data are described within the application.

Fig. 1.

The interface for adding blood product abbreviations to BBDash. Abbreviations for blood products are entered on the left and existing abbreviations are shown on the right.

To add transfusion data to BBDash, two reports need to be generated from Sunquest and then added to the application. The blood utilization reports contain information about blood product orders, including the time, date, and number of units ordered. The ordering physician reports contains information about the ordering provider and hospital location, and is required in order to associate providers with transfusions they have ordered. Steps to generate these reports in SunQuest are detailed in the supplementary file. To add these reports, navigate to the Transfusion tab of the Data section and drop the files in the dashed box on this page. The reports are automatically processed and the extracted information is added to the database. It is recommended to add all available location reports prior to adding blood utilization reports. When location reports are added, BBDash will scan the file for novel providers, locations, and blood product abbreviations and add these to the database.

Once blood product data have been added, graphs showing summaries of blood product utilization and graphs comparing provider ordering can be generated. To create graphs, navigate to the Graph Section and then click on either the Product Summary Graphs or Provider Comparison Graphs button. Product summary graphs display the transfusions sorted by the value from their respective pretransfusion testing values (Fig. 2). For example, platelet transfusions will be grouped by the patient’s most recent available platelet count prior to the transfusion. The product summary graphs can be filtered by different criteria such as the type of blood product, hospital location, and date. Using filters, particularly the date filter, is recommended as the default behavior of BBDash is to otherwise display all transfusions in the database, which can be a large amount of data. If only a small number of transfusions are graphed, each transfusion is displayed on the graph as a circle. To further investigate specific transfusions, two points on the graph can be clicked and all data for transfusions between these points can be exported.

Fig. 2.

Product summary graphs showing platelet (top) and red blood cell (bottom) transfusions grouped by pretransfusion laboratory values. Hovering over the circles (bottom left) that represent an individual transfusion, brings up additional data including the pretransfusion testing result, specialty of the ordering provider, and hospital location. Clicking on two points of a graph (bottom right) will display additional information about the selected transfusions, and allow their associated data to be saved to a text file.

Provider comparison graphs (Fig. 3) are useful for analyzing the blood product utilization patterns of individual providers. The default display for these graphs sorts providers by the median pretransfusion laboratory value of their orders. Blood product orders for providers can either be shown as a median value and range (Fig. 3, top) or as individual transfusions (Fig. 3, bottom). Clicking on the bar for an individual provider (Fig. 3, bottom) will display additional information for that provider and allows for creating specialty comparison graphs. Specialty comparison graphs show only providers within a single specialty and can facilitate examining ordering patterns for providers in specialties that may have different indications for transfusions. For example, using a specialty comparison graph would make sense to analyze platelet transfusions for neurosurgery providers, where the cut-offs for platelet transfusions are frequently as high as 100,000/μL.

Fig. 3.

Provider comparison graphs for red blood cell transfusions. Providers are sorted by the median value of the pretransfusion laboratory values for the blood products they have ordered. The median value of pretransfusion laboratory values is shown as a horizontal, dashed, gray line. Data can be displayed as a median value and range (top) or as individual transfusions (bottom). Clicking on the bar for an individual provider (bottom right) will bring up additional data and allow for comparison of that provider to other providers in their specialty.

Validation

The format of the files that are derived from our LIS do not have a regular format, which led to many bugs and errors while programming the scripts that parse reports. The locations of different fields in the reports will change, and sometimes fields will collide if the values in these fields are longer than usual. We used regular expressions to read in the data from reports, and it took several iterations of updating the code and checking for accuracy of data that was read into the database. Our last iteration of assessing data accuracy involved manually reviewing 1000 entries in the database. We compared the entries in the database to the original data that were found in the reports from the LIS. Out of the 1000 entries we reviewed, there were five entries which demonstrated a minor issue. The blood products for these five entries were added to the count for other transfusions because they were for the same patient, had the same accession as another transfusion, and occurred on the same day and at the same time. This resulted in, for example, a patient having one entry for two red blood cell units instead of two entries that each had one red blood cell unit. This occurred due to blood product types having different codes in the LIS, for example, codes for red blood cells include “IRL” and “AIRL.” This would not have been expected to result in significant changes in the interpretation of the data, as all other information for the entry, such as the type of blood product and pretransfusion test values, were accurate. The code for BBDash has been updated to resolve this issue, and there are currently no known issues affecting the accuracy of data extraction or graphical output.

We recommend that other institutions who wish to use BBDash perform their own validation to ensure that data in the database are accurate. Our extensive manual review of data with BBDash resolved many bugs, but it is still possible that errors may arise due to unexpected formatting in files or from using different versions of Sunquest. However, BBDash was designed to quickly triage the totality of data for a transfusion medicine service and it is not intended to be a definitive source of data for decision-making. Transfusions of interest should be verified within the electronic health record or LIS to ensure accuracy.

Discussion

BBDash is an application that we created with the narrow scope of assisting with interpretation of blood product utilization reports from the Sunquest LIS. Currently, it can quickly read these reports and displays aggregate product data or shows provider specific data. As an open source application though, the functionality can be extended by developers with knowledge of JavaScript. While up to this point we have only created scripts for reading Sunquest reports, further commonly used LIS and EHR data sources such as Epic and Cerner could be incorporated. Based on the current design, adding additional data sources can be done by modifying the /src/assets/js/sunquest.js file, and would require the file to have a unique pattern in the text recognizable by regular expressions and the development of a function that can read the file. For files that have a regular format (e.g., tab delimited, .csv), this is relatively straightforward and could be done within a few hours for programmers experienced with JavaScript.

Completely new functionality and features can also be added to the application. For example, our current process for tracking HLA-matched and cross-match compatible platelets, corrected count increments, and calculated panel reactive antibody values involves manually tracking data in Excel files. By adding new views and scripts, it would be possible to read reports involved in this process and automate some of this work within BBDash. Although BBDash is focused on blood products, the tool itself or the general approach of using Electron could be applied to other sections of the laboratory. The provider comparison functionality could be repurposed to compare providers and visualize utilization of, as an example, the number of costly tests ordered per in-patient per day. If no tool is available to the laboratory for such purposes, taking advantage of the flexibility of BBDash or using Electron to develop such a feature is an option. One drawback of this flexibility we outline here, however, is the requirement for specialized knowledge of Electron and D3.js to develop new views, and finding developers with this niche experience could prove difficult.

There are several aspects that differentiate BBDash from currently available data visualization tools. Generic data visualization and business intelligence tools such as Tableau or MicroStrategy Dossier could potentially be used to show these transfusion data. However, these tools do not have built in support for parsing Sunquest reports and have less flexibility in how users can interact with visualizations. By default, BBDash uses JavaScript and the extremely versatile D3.js library to create visualizations, which allows for most useful and conceivable functionalities to be added. We have used this flexibility to include features that are of interest specifically to transfusion medicine services, including comparing transfusions between providers, showing individual transfusions, and selecting outlying transfusions. Furthermore, the process to use hospital-provided business intelligence tools can require a long period of back-and-forth discussions with IT partners to develop a suitable dashboard with relevant displays. One benefit of BBDash is that, compared to off-the-shelf solutions, setup is relatively rapid and can be done within a few minutes when the required files are available. Some blood bank information systems, such as WellSky, come with transfusion utilization analytics. BBDash is not meant to replace these blood bank information systems, but was designed as an adjunct for systems where there is no method for visualizing blood product utilization data or where current functionality is lacking.

Future directions

In this article, we have described several aspects of BBDash including the motivation for its development, technical details behind its development, and instructions on using the tool. Two important considerations that we have not addressed here are the willingness of transfusion medicine specialists to adopt BBDash into their workflows and its actual impact on clinical practice. These are critical pieces of information for institutions who wish to implement BBDash or develop a similar application using a comparable framework. Development, deployment, and validation of these tools can be time-consuming and it is important to ensure that investing resources in these efforts is worthwhile. We hope to address these concerns in a subsequent study by soliciting feedback from other institutions, and by comparing blood utilization before and after implementation of BBDash.

Conclusion

Reviewing blood product utilization is an important function of a clinical transfusion medicine service in terms of cost-saving, conserving resources, and patient safety. In order to address issues related to inappropriate blood product administration, it is helpful to review and analyze blood product usage in the hospital system as a whole. However, the format of reports for some LISs are not conducive to such large-scale analyses, and currently reviewing the entirety of these monthly several-hundred-page reports is impractical. We developed BBDash to parse blood product reports from Sunquest and create easy-to-read graphs which should facilitate review of blood product ordering patterns for the entire hospital system. We believe that displaying transfusion data graphically will allow transfusion medicine services to quickly triage and review orders for blood products, which are questionably indicated. Based on these data, interventions can be made to ensure appropriate blood product usage, which could improve patient outcomes, conserve important blood products, and save the hospital money.

Declaration of competing interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Appendix A. Supplementary data

Supplementary material: Instructions for Creating Sunquest Reports