This is a revision of a previous post, incorporating an updated definition of Transfusion-Associated Cardiac Overload TACO from the National Healthcare Safety Network, Biovigilance Component Hemovigilance Module Surveillance Protocol, Version 2.6.
This is an updated version of a previous post.
Interfaces—General Considerations:
When buying equipment while planning/implementing new laboratory software, I originally had a rule not to purchase anything that the vendor did not have a ready interface. Even that was not so clear since some vendors had interfaces listed as alpha, beta, and completed.
Could you use an alpha or beta interface? Was it safe for patient care? What was the development cycle for new interfaces with your vendor—months, years?
Even if the vendor had a completed interface? How “complete” was it? Did it accept all data from the machine? Did the data stream require reformatting? Who would write the transformational script?
Even if the vendor could support it, could your local IT organization and the local agent’s IT staff do it? I had plenty of headaches over this. The best equipment with the best interface that the local agent could not support was worthless to me.
Some finished interfaces took months to install because of connectivity issues. What version of the operating system OS was used? Was it secure? Did our IT department accept that OS version (e.g. Windows 7) and the provided malware protection? I have seen malware spread across a network from the interface software installed by the vendor, threatening the entire corporate system.
Did the solution require middleware? What were the implications of having middleware and its affect on the main software program, especially at the time of its upgrade or the main software?
I have seen vendors using Windows 2000 for their interface software as late as 2017. It was difficult for some of them to update to current, more secure versions. Anyway, our corporate IT department gave them all a deadline to update to the current operating system—they all complied or risked losing all connectivity to the network.
Almost every instrument vendor has told me that they can communicate with my laboratory system. I guess that is true: one talks in Russian and the other Sanskrit—they do communicate but is it effective? Talking is not necessarily useful communication!
I remember one open EIA machine that had a TCP/IP port but it was not functional by the standard protocols. One had to emulate a serial port to get some rudimentary communication. The port’s light blinked, however. I never imagined that someone would put a nonfunctional port as a mere decoration.
On the other hand, I have had excellent experience with another software vendor Medinfo. Even if the vendor did not have the interface developed, they could build it from scratch in a few weeks. Paradoxically, it was faster to build these new interfaces than some so-called already interfaces.
I must emphasize: This is a collaborative team effort between the blood bank information system, software vendor, instrument vendor, and your institution’s IT staff. There must be excellent cooperation between them for a successful result.
When installing the Medinfo Hematos IIG software, many of our most important interfaces (the Terumo mixed shaker, Trima, Reveos and its predecessor Atreus, Mirasol illuminator) had no developed interfaces when we started. This was a risk, but actually those interfaces were developed in a few weeks and fully functional. In fact, we were the first site in the world to have those interfaces working—and without any Middleware.
In general, the blood bank software vendor installed the completed interface and did some low-level testing. Then, my blood bank computer team did the testing. The final responsibility for testing and acceptance was with the end-user blood bank team and me as Head of the Laboratory Information Systems.
In general, I wrote the validation protocol and assigned the tasks to the Medinfo Super Users. To perform this testing, we still had to register donors and collect and then export the specimens to the donor marker testing laboratory before the actual interface testing could begin. This was all done in a special test domain separate from the production domain. The interface did not go live until the validation was completed and accepted and then was moved to the production environment.
I made the validation criteria and reviewed all data as Division Head of Laboratory Information Systems. Representative screen shots were made. All data was sent to me. My final acceptance was required before the interface could be activated.
Automated component processing (Reveos) and component modification are more complicated and will be covered in a future post.
This is a revised version of a previous post.
I have had many medical students, residents, and fellows rotate through my Transfusion Medicine section. Hardly anyone has any interest in making my discipline his/her career. It is a required rotation or an “easy” rotation during which the trainee may take his vacation. The trainee will cram for the examination and then promptly forget it.
I left practice in the USA in 1990, in what I consider the golden age of laboratory medicine. We had supervisors for each laboratory section. In the blood bank, we had many staff with SBBs or who were SBB students. We were very self-sufficient in handling immunohematology problems except for rare blood types or antibodies to high incidence/prevalence antigens.
When I returned to visit my old laboratory, I sensed a deprofessionalization of the laboratory and blood bank in particular. Blood Bank now is a cost center, not an area of revenue. Why hire experienced blood bankers for most hospitals? Send the antibody workups to the Blood Center. There are limited jobs for transfusion medicine consultants. Minimize testing, don’t do extended antigen typings, etc.
Nowadays, I feel like one of the dinosaurs marching into oblivion like in Walt Disney’s Fantasia film, the section called The Rite of Spring. Who will replace those retiring? Have you ever noted the average age of attendees at the AABB annual convention? I feel young when I go there (and don’t worry about the gray hair!)
I want to attract new doctors and scientists to Transfusion Medicine. I really try, but most have no interest and look on their rotations as a necessary evil.
I have lowered my expectations for most medical trainees in Transfusion Medicine. They don’t like it, they just want to pass it, and move on. What must I impress them with for their future careers? What is essential for them to remember?
I have had both pathology and non-pathology trainees. Surgical and ob/gyn doctors used to spend one month whereas the hematology and pathology residents/fellows spent on average three months. The few interested in the field might do multiple rotations.
I still gave them lectures on a variety of topics, especially how to transfuse blood components, basic ABO/Rh antigens, compatibility testing, and direct antiglobulin testing. They would forget most of this, but I wanted them to remember TURN-AROUND-TIMES:
Examples:
HOW LONG DOES IT TAKE TO PERFORM THE TEST? TO FIND COMPATIBLE BLOOD? TO THAW THE PLASMA? RELEASE AN MTP SHIPMENT? TO PERFORM A TRANSFUSION REACTION WORKUP BEFORE RELEASING MORE BLOOD?
I am not discouraging people from entering the field, but I am a realist to know that few will share my passion for serology or want to take call on difficult immunohematology cases. At least if they understand the pressure the technical staff are in and these turn-around-times this will make both their work as clinicians and mine as transfusion medicine more congenial.
Sometimes, you may not have adequate resources for a project so you will consider hiring an outside consultant. During my career, I have used several outside consultants for projects ranging from installing a new general laboratory computer system to assisting in getting international accreditations.
Regrettably, my experience with software consultants has been mixed. I have used them for general laboratory software installation and settings. Very few have any experience with dedicated blood bank software or setting up hospital blood bank modules. They are often former employees of the software vendor you are using. There is always a potential for conflict of interest.
The software consultant must work for you, NOT for the vendor you are using. He/she must maintain his independence from the vendor and only represent your interests. I have had many problems with this. Here are some of my unpleasant experiences:
Current and Future States:
One set of consultants gave essentially the following current state mapping for almost every test in our menu:
They did not know our current state so they were unable to help us build a proper future state.
Mapping Errors:
The consultants were in charge of exporting results from a previous system into the new one, this included mapping the results into the appropriate test fields. They assumed it would map properly, I insisted on testing a two-week sample of laboratory results and discovered major errors that could adversely affect patient care—it was a major disaster and almost held up implementing a hospital go-live on-time.
Benefits of New Software:
The consultants were obsessed with calculating benefits of the conversion to the new software vendor and making fancy PowerPoint presentations to assure officials that they were gaining benefits. There were many issues to resolve that were critical to the functionality that I felt the time would have been better spent in fixing the software issues than calculating alleged benefits.
The Need for Speed:
There were some consultants without any experience in blood bank who insisted that this had no bearing in making software settings. One bragged to me that he could install a blood bank system in a few days.
Default Settings:
Some outside consultants kept pushing using the default settings. There is no “one size fits all” solution for a large healthcare organization. There is need for customization. I wondered why we needed the consultants to set up default settings which is what the vendor wanted us to do anyway.
Sometimes, you may not have adequate resources for a project so you will consider hiring an outside consultant. During my career, I have used several outside consultants for projects ranging from installing a new general laboratory computer system to assisting in getting international accreditations.
For a complex accreditation process such as AABB, I have used such consultants to audit operations in the donor center including processing and testing, hospital blood banks, and stem cell laboratory. They are high-level technical specialists with highest blood bank qualifications (e.g. SBB(ASCP) or equivalent) and have considerable experience in practice of blood banking and quality systems. They have been AABB Assessors so they can give you a dry-run accreditation assessment.
Depending on the project, you may need one or a group of consultants. I have worked with both individual consultants and groups. A group can complete the tasks quicker but this is not always necessary. Organizations such as AABB have many different consultants with different types of expertise so you can select the most appropriate individuals to form a team for your needs.
These specialists can audit your operations and propose a model and if you want, actually help you to implement the processes. They can help you with the accreditation formalities, especially if you do not have any staff with experience in the process. It all depends how much you can spend.
In the Middle East, to bring in such consultants may mean expensive air fares, hotels, meals, plus the actual costs of doing the consulting. This is a major investment for your organization but it is well worth it to expedite the process. There are local consultants available as well and using them may greatly help with the expenses.
Although it is expensive upfront, it can be cheaper in the long run by establishing the appropriate framework in the first place. You can engage the consultants to actually do much of the work themselves, but it is better for them to offer a train the trainer experience, i.e. engage your own technical staff to learn new skills and then have them cross-train the rest of the staff.
Based on the findings, your local staff can implement the changes. You can then consider rehiring the consultants to verify that the work has been done properly.
I have used both individual consultants and groups through AABB Consulting. My staff and I have learned much from such interactions, and I highly recommend their use when local expertise is not available.
This is one of a series of posts comparing policies and processes in the blood bank.
PROCESS: 5.2.1 DONOR QUESTIONNAIRE
Process:
References:
This is one of a series of posts on blood bank operations, comparing the process and policy documents.
5.2 POLICY: DONOR MEDICAL QUESTIONNAIRE
Policy:
References:
This is revision of a previous post.
Building Processes:
This post is mainly on building processes for a non-turnkey system such as the Medinfo Hematos IIG software that I have worked with in several countries, but there will be a few words about turnkey systems for general laboratories.
This has been a collaborative effort between the software vendor’s engineers, my Super Users, and myself. This pluralistic approach has been most productive.
A turnkey system has pretty much already defined most of the basic processes—those have been specifically approved by a regulatory agency such as US FDA. There is little customization except formatting screen and reports. Instrument interfaces are also mainly predefined. This requires much less thought and planning than a custom-built system designed on the sites actual workflows, but it can be an exercise of putting a round peg in a square hole. You don’t always get what you want.
In the locations where I collaborated in setting up the Medinfo Hematos IIG program, we did not follow US FDA but mainly the Council of Europe CE standards since this was much more customizable. Additionally, we could modify and add additional criteria specific to our country and region (e.g. rules for donor qualification for local pathogens). This has always been my preferred approach.
Start with a frame of reference (CE) and then try to optimize it for our local needs.
I recommend the Council of Europe CE since it is more flexible and extensible. Those subject to the US FDA has many fewer approved options in the preparation of blood components (e.g. prohibiting the use of pooled buffy coat platelets, automated blood component production such as Reveos, and use of world-class pathogen-inactivation technologies such as Mirasol.)
If you invested the time to make a detailed workflow across all current processes and tests, much of this can be readily translated into the software processes, but first you must study the flows and determine where you can optimize them. This requires that you study the options in the new software to see what you can use best.
I always liked Occam’s Razor, i.e. “ntia non sunt multiplicanda praeter necessitatem,”—the simpler the better as long as it meets your needs. If the manual processes are working well and can be translated into the new system, do so. If they need changes for optimization, then do so only if necessary.
Most of my career has been spent overseas with staff from many different countries and backgrounds, most of whom were not native in English. The wording of the processes is very important. Think of the additional obstacle of working with a complicated software in your non-mother tongue! Also consider the differences between American English, British English, and international English. I always made the Super Users read my proposed specifications and then asked them to repeat what I wrote/said.
There were many surprises discovered. I think of the Aesop’s fable about the mother who gave birth to an ugly baby looking like a monkey. Still, to the mother her baby was the most beautiful baby and she entered him into a beauty contest. In other words, to the mother her child is perfect!
It is most important to use the manufacturer’s recommendations to build tests and for the special automated processing and pathogen-inactivation processes. For example, we had multiple ABO and D typing tests—they did not necessarily agree on what were acceptable results for automated release of results. The same is true for many other tests.
Example: One method for Rh(D) typing stated that only results in {0, 2+, 3+, 4+} were acceptable—all other results required manual review and/or additional testing. Another only accepted results in {0,3,4}. Thus we had to build separate D typing processes for each methodology.
Another consideration is whether to offer all the processes globally or restricted to one site. I favor allowing access to all methodologies at all sites—in case of a disaster where tests had to performed at another site. This means that if you send an order over an interface from the hospital system to the blood bank system, that at the receiving (blood bank) end, you can choose which methodology to use, i.e. it is not a one-to-one mapping but rather a one to many mapping.
If we changed equipment at one site to that used at another site, we didn’t have to modify our software to accommodate this. Even if you didn’t have the equipment or reagents at one site, you could always build it into the system and not activate the settings until needed.
Finally, the issue of middleware. Many instruments offer this, but one faces the problem about support and regression errors when you either update the middleware software or the blood bank computer software. Medinfo itself can serve as the middleware so there is less chance of errors when updating the software. In fact, I never have used any middleware when using Medinfo.
Instrument interfaces will be a future topic.
This is part 3 of a medical student lecture I gave at National Guard Health Affairs.
This is the second part of a lecture I gave to medical students at National Guard Health Affairs in Riyadh.
Dr. Zeyd Merenkov 