This is an updated version of a previous post.
Antibody Screening in Medinfo
Category: Donor
Includes registration, questionnaire, physical exam and arm check, collection, marker testing, component separation, donor immunohematology testing
Building Processes in a Blood Bank Computer System
This is updated version of a previous post.
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 or need.
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 these were much more customizable. 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. Also, the USA does not use the full ISBT specification for its labels.
Start with a frame of reference (CE) and then try to optimize it for our local needs. Unfortunately for blood banking, FDA has many fewer approved options than other regions, including in the preparation of blood components, e.g. prohibiting the use of pooled buffy coat platelets, lack of 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 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!
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, then at the receiving (blood bank) end, you would 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 could serve as the middleware so there was less chance of errors when updating the software. In fact, I never used any middleware when using Medinfo.
Plasma Project Considerations for Middle East
This is an update of a previous post.
I have been involved with planning for several plasma fractionation projects in the Middle East.
Many clients expressed the interest in using local plasma to make plasma derivatives (e.g. factor concentrates, intravenous gamma globulin, albumin), feeling that local plasma was safer than using imported plasma. Some of these are in short supply in the world market so the only way to ensure their uninterrupted availability is to consider to manufacture them for local consumption.
Still, the major issue today is that it is difficult for any country in the region to collect enough plasma to make such a project feasible. When I first considered such planning, we were looking for as much as 250,000 raw liters of plasma annually. Since then, there are newer technologies that allow much smaller batches to be cost-effective. Alternatively, one could charge higher prices for using smaller batches from local plasma.
Still, it is likely that plasma must be imported to sustain a plant. There are different regulations for plasma donor qualification country-to-country. Many of these jurisdictions may do less screening and testing than is done for normal blood and apheresis donors. Other countries use their blood donors with the same requirement for both commercial plasma and blood donations.
In this era of emerging infectious diseases, I personally favor using the stringent blood donor criteria—same as routine collections. It is not what we know, but the unknown pathogens that are potentially the most dangerous.
In addition to building a fractionation plant, one must train staff for this highly technical operation. This may require developing a special curriculum to prepare students for these jobs.
To export the plasma to certain regions, one may have to use plasma quarantine. In this protocol, plasma is held or quarantined until the next donation is collected and passes screening. This requires a robust blood bank production software such as Medinfo to track serial donations.
There are other processes to consider: how to develop a transport network to keep plasma frozen at minus 80C viable in a region that reaches very high ambient temperatures.
I would recommend a graded approach to develop such an industry. First I would negotiate a plasma self-sufficiency arrangement. We would collect local plasma in the country and export it to a manufacturing plant in another country and the derivatives would be returned to us. This may require inspection by the accreditation agency of the processing country to allow importation of the raw plasma for manufacture.
Since it is unlikely any one country has enough plasma for manufacture, recruiting neighboring countries to participate in a manufacturing plant is important. Technology for such a plant is complex so establishing a joint venture with one of the plasma industry companies is essential. Some manufacturers are very keen to develop extra capacity since there is a world-wide shortage of plasma fractionation and are even willing to help obtain external plasma sources for such a plant.
Such a plant is an excellent way to develop local talent to run such a plant, including training of local staff to be the industrial engineers in the plasma fractionation process. It would take approximately two years of training to prepare engineers on-site at a plasma fractionation site if they have studied the necessary science and mathematics subjects.
Such a program would take several years of planning and development. Some of the major steps needed include:
- Acquiring software for a blood center with plasma brokering capabilities.
- Passing accreditations such as international AABB and CE for transfusion medicine to allow export of our plasma to the external manufacturing site in the initial plasma self-sufficiency phase
- Identifying extended sources of plasma to feed a manufacturing plant.
- Preparing a curriculum suitable for training as staff for the plant.
- Establishing a joint venture to share technology with a major plasma company to design, build, and operate a plasma fractionation plant.
Super-Users: Engaging Laboratory Staff in Computer Operations
It is critical to engage the technical, medical , and (blood bank) nursing staff in this process, That is why it is so important to identify a core of computer-literate users to help with the building and testing/validation.
I don’t mean finding staff who can already program or code. Rather, I mean staff that are astute with knowing their work processes and who had good skills with Microsoft Office and Windows or equivalent. I did not expect them to understand database structure or use structured query language. They were chosen for their ability to learn quickly and their meticulousness.
For our blood bank system, I chose computer-literate technical staff to be involved in the build from the very beginning. They learned how to test each module and to some degree support it. These became my Super-Users and to this day support the system for many tasks. These staff served as the system administrators and worked directly with me as the Division Head for Laboratory Information Systems. They were not full-time and still had their other clinical/technical duties. They liaised with the software vendors engineers.
Our blood bank system was NOT a turnkey system. It was custom designed according to our workflows. There were NO default settings!! We had to be remember, ‘Be careful what you ask for, you might get it!’ In some countries, approved systems are turnkey and may allow only few changes to the core structure and thus may not be this optimized for the needed workflow; often only cosmetic changes are permitted.
When we built our first dedicated blood bank computer system, the company would take a module and completely map out the current processes collaboratively with me. After this, I analyzed the critical control points and started to map out the improved computer processes that would take over. After that we would build that those processes in the software and test it. If it failed, we would correct it and test again…and again if necessary. Fortunately, the blood bank vendor did not charge us when we made mistakes.
Sadly, another vendor (non-blood bank), only gave limited opportunities to make settings. If wrong, there might be additional charges to make corrections. This other vendor really pushed the client to accept the default settings regardless whether or not they actually fit. End-users were selected to make and approve the settings, but they were only minimally trained on how to make the settings. It was a journey of the end-users being led to the slaughter—and being blamed for their settings when they accepted the vendor’s recommendations—they usually selected the defaults. There wasn’t enough time for trial and error and correction.
The blood bank system Super Users were an important part of our process. They were an integral part of the implement team and could propose workflows, changes, etc.—subject to my approval. They learned the system from the start and developed invaluable skills that allowed them to support the system after the build. Also, they could serve to validate the system according to the protocols I prepared. Moreover, I took responsibilities for their activities and they were not left out to hang.
Every hospital blood bank location and the blood donor center had Super-Users. These included:
- Blood Donor Center:
- Administrative Clerk for donor registration, consent, ISBT specimen labels, creation of new donors and patients for validation purposes
- Apheresis/Donor Nurse for donor questionnaire, donor physical examination, and donor collection
- Medical technologist for donor marker testing
- Medical technologists for blood component production including Reveos, Mirasol, platelet additive solution, pooling, and leukodepletion
- Medical technologist for donor immunohematology testing
- Medical technologist for inter-depot transfer of blood components
- Hospital Blood Banks and Transfusion Centers:
- At least one technologist at each site for inter-depot transfer, component medication (washing, irradiating, aliquoting, reconstituted whole blood), immunohematology testing, component allocation and release
The cost of using these staff? They were paid overtime and were relieved of other duties when working on Super User duties. This was much cheaper than hiring outside consultants who may or may not know our system well enough to perform these tasks.
By having a Super User at each site, I in effect had an immediate local contact person for troubleshooting problems who could work with the technical/nursing staff. We did not rely on the corporate IT department for support and worked directly with the software vendor. Response time was excellent this way.
Overextending Oneself—Two Case Studies in the Blood Bank
One has to learn when enough is enough. There are times when there are staff shortages but the conscientious staff wants to be the Super-Tech and handle all the work, whether or not there are sufficient resources. This is a big gamble, and there may be serious consequences for the over-achiever and for the patient.
Anecdote #1: Chicago Blizzard of 1979 (13-14 January):
When I was in my residency training in Chicago, I was in the blood bank during the blizzard of January, 1979. The following tragedy occurred.
Suse was one of the best blood bank technologists that I have ever known, extremely conscientious and very meticulous—and very fast at doing things. She was a workaholic. Suse’s whole life centered on her job at our academic medical center—so much so that she had an apartment near the hospital complex. In mid-January, a snow storm was predicted with an estimated snowfall of about 5 cm. total. Actually, that night a blizzard developed and around a meter of snow fell with white-out conditions and zero visibility. Preoperative patients had been admitted the night before based on the low snowfall prediction.
The next day was chaos. Essentially only staff who lived near the hospital complex could report to work. Suse came in and saw all the pending preoperative blood requests. She decided to “double-up” and work on two cases at one time. In the rush, she mixed up test tubes and issued ABO-incompatible blood for a surgical case. The surgeon noted the abnormal oozing of blood at the operative site and stopped the transfusion. Hematuria developed, but the patient survived.
Suse was suspended pending investigation. Based on her excellent work record, she was offered to return to work. Unfortunately, she became very depressed and was afraid to return since she feared she would make another mistake. She never worked in the blood bank again.
Anecdote #2: Shortage of Blood at Major Hospital:
1991 in another country, a large hospital complex was suffering a shortage of blood. A large number of donors were called and the available staff were overwhelmed with work. One donor phlebotomist decided to collect whole blood from two different donors simultaneously and in the confusion, mixed up the sample tubes for donor marker testing.
Unfortunately, one of those donors was HBsAg positive, but with the specimen mix-up was marked as negative. The unit of blood was transfused, and the recipient developed fulminant hepatitis B and died.
Analysis:
In both these systems, there were processes in effect not to work on two patient specimens or collect two donors at one time, but the staff took short-cuts.
No one is super-human. Don’t try to cut corners and handle more than one patient at a time. Your intention may be good, but you will be judged by the consequences. No one will care about the extenuating circumstances. You will be blamed. I tell my staff that if they cannot handle the workload, they should contact me as the Division Head, Transfusion Medicine, to triage the cases for them. My role is to bring these events to the higher authorities to get the resources we need to do the work properly and safely.
Processes and Software Building—Part Two
This is a revision of a previous post.
Documenting Processes:
My previous post emphasized how important it is to map the current state across all processes as the first step to optimize current operations and prepare for a new computer system.
One non-blood bank vendor submitted the following as a complete representation of all current processes—across more than 4,000 tests and hundreds of instruments:
- Order something
- Receive specimen
- Perform test
- Report test
This was the same for each of the tests in the different sections of the laboratory—be it blood bank, anatomic pathology, chemistry, hematology, etc. I was flabbergasted! What were we paying for?
As Head of the Laboratory Information Systems, I rejected this. I would have been ashamed to submit this to a client as a sufficient current state. Even more astounding was the fact that that vendor actually mainly used the same four-step flow chart for the tests in their new computer build!!
As painful and time-consuming as it is, one must develop a specific flow for each process. This could include:
- Specimen condition and acceptability criteria
- Possible results for each part of the test
- Interpretation of each result
- Control results
- Acceptability criteria
- Truth table
- Reflex testing triggered by the results
When we built our first dedicated blood bank computer system, the company would take a module and completely map out the current processes collaboratively with me. After this, I analyzed the critical control points and started to map out the improved computer processes that would take over. I did not want to throw out the successful manual system, just to optimize it. After that we would build that those limited processes in the software and test it. If it failed, we would correct it, and the vendor didn’t charge us extra for the corrections. It was a beautiful collaboration.
To illustrate these points, I am showing two process flows from our Medinfo Hematos IIG build: one for the ABO typing (forward and reverse) for donors and the other a complex testing algorithm flow for HCV donor marker testing. These are from previous builds and have been updated subsequently.
ABO Typing: Attachment One
This consisted of six individual tests forward (anti-A, anti-B, anti-A,B), two reverse (A1 cells and B cells) and a control. The acceptable tests for automatic typing were in {0, 2, 3, 4}, other results (mixed field, weak, 1+, hemolysis) required a manual interpretation. There is a truth table for interpretation of all six results together.
Donor HCV Testing: Attachment Two
This is a more complicated flow that includes multiple tests (HCV-antibody EIA, HCV-LIA, and HCV-NAT). Results may trigger reflex testing immediately (abnormal HCV EIA triggers HCV-LIA, abnormal HCV-NAT triggers HCV-LIA, etc.) or repeat testing after six months for indeterminate results.
In each case, every possible result is listed and its interpretation and acceptability criteria.
In summary, it may take considerable time to map out all your processes, but this is time well spent and allows you build your system accurately. There will be few surprises this way.
A Novel Way to Document Therapeutic Phlebotomies in the Blood Bank Computer System
Therapeutic phlebotomies TP, like regular whole blood donation WBD, both require collection of whole blood into a blood bag set. In whole blood donation, we ask two questions during the process:
- Is it safe for the donor to donate?
- Is it safe for the collected unit or its processed components to be given to recipients?
For TP, we only have to consider the first question so the process must ensure the patient/donor’s safety. We do not have to concern ourselves with the use of the collected product—it will be discarded.
Since the donor collection processes of both TP and WBD are similar, why couldn’t we use the blood bank computer software to document the TP procedures? The process is a subset of normal WB donation. On this basis, I make suggestions on using the donor module to document the TP process. It is basically a truncated version of blood donation process in the Medinfo Hematos IIG system:
- Registration
- Donor Safety
- Vital Signs
- Hemoglobin Determination
- Blood Collection Data
- Adverse Effect Reporting
- Discard of Unit
- Documentation of Physician’s Order and Transfusion Medicine Physicians Acceptance
Registration: Positive patient identification can be made through the donor registration process; force selection of an inexpensive bag type (not the Reveos set) for this purpose.
Donor Safety: Perform a modified, shortened donor questionnaire covering the medical history and medications is used. Confirm that the patient has had food and drink before donating. Require a waiting period of 24 hours before the next procedure.
Vital Signs and Weight: Measure weight plus BP, pulse, temperature, and respiratory rate as well as inspect the arm for scarring before procedure. Allow repeat vital signs monitoring after the procedure if requested by the transfusion medicine physician.
Hemoglobin Determination: Allow acceptable Hgb >= 11 g/dl or >33% hematocrit
Blood Collection: Use the same process for the mixer-shakers but the amount collected can range up to 500 ml with amounts <405 ml acceptable for small patients
Adverse Effect Reporting: The complications of TP collection are the same as WBD. Use the same system as for WBD.
Discard of the Unit: Print discard label and quarantine of the ISBT unit number in system (so that it cannot be used for transfusion).
Documentation of Order: Create separate fields for the ordering physician and for the approving transfusion medicine physician. Capture scan of paper orders and incorporate into the TP computer encounter.
Other Considerations: In high-risk cases, e.g. with pre-existing cardiovascular, pulmonary, or cerebrovascular disease, one could consider using a remote monitoring device such as the Umana T1 device to record vital signs, EKG, and oxygen saturation that can continuously record these parameters and trigger user-definable alarms during the process and afterwards if desired. The data can be incorporated into the blood bank computer encounter.
Antibody Titration
My practice across the globe has exposed me different rationales to performing antibody titration. In my American training and practice (and also at international institutions following the American version of AABB accreditation), I only routinely performed titration of anti-D for Rh(D) hemolytic disease of the newborn and anti-A/anti-B for ABO-incompatible stem cell transplants AND ABO-incompatible renal transplants.
I have had heated arguments with some physicians who insisted they wanted titers for other antibodies. The AABB Standards do not require this but leave it to the discretion of the Transfusion Service Medical Director.
In my entire career, I never worked in a blood bank or blood center which had optimal staffing or resources. I focused on what was medically/technically necessary and even then still had shortages. If performing a test does not change the clinical treatment, why perform it unless you are doing a research project!
Titration is a time-consuming, and until recently, a tedious manual task. Recently some of the automated immunohematology analyzers offer a titration program. We used the Ortho Vision Max which could perform both IgG and IgM titers within one hour—walk away!! However, during that time, the titration procedure monopolized the analyzer.
Nowadays, low-anti-B-titer group A universal plasma and low-titer (anti-A and anti-B) group O whole blood may be offered as components. At HMC Qatar, a preliminary study showed about 50% of units could be classified as low-titer (defined as a saline titer <1:128). The amount of titration will require an automated analyzer.
The ABO-incompatible renal transplant program at HMC Qatar was modelled after Sweden’s Karolinska Institute. However the latter site performed manual IgG and IgM titrations using Biorad/Diamed gels.
I did not have sufficient resources to commit staff to manual titration at HMC so I did a comparison study between the Ortho Max and the Biorad manual gel methods. We were able to get good correlation and used the automated method for the transplant.
I still don not perform against performing titrations for antibodies other than anti-D. I always ask, ‘Does the titration correlate with clinical severity?’ Unlike anti-D, antibodies such as anti-Kell and anti-c may be low titer but cause death. Can anyone show me a definitive study that titers are useful except for transplants and Rh(D) hemolytic disease of the fetus/newborn?
Since the method was working well on the Ortho equipment, I next established an interface to Medinfo. The test was performed separately for IgG and IgM antibodies. Medinfo recorded the reactions in all the wells. The last well showing a 1+ reaction was interpreted as the titer (e.g. if 1:64 were the last 1+ reaction, then the titer was 64 in Medinfo).
The Medinfo process is shown below.
My Opinion: Issues in Transfusion Medicine Software and Component Production
I anticipate that there are several innovations coming or in the process of coming to mainstream blood component production and software. Some of these I have already addressed in some of my previous posts:
Pathogen inactivation: We have had this for over a decade. However, with new emerging pathogens, this will become more important so I expect it will be adopted in many centers where it is not currently being used. I expect we will close the loop and pathogen-inactivated RBCs will be available so all components will be treated. Still, the first-generation pathogen-inactivated RBCs may have reduced shelf life compared to regular, untreated units.
Automated component production: Although this is expensive, it does provide excellent GMP production. It is fast and may provide higher yields, especially for platelets. I expect more centers will adopt this technology, especially in combination with pathogen inactivation.
Blood bank computer software: This software must be considered as dynamically changing, and considerable resources are needed to keep in compliance with ever-changing international regulations and the latest epidemiologic data. Production rules can be strictly and mercilessly enforced by a dedicated blood bank computer software. It can also ensure that the final ISBT label is not applied unless all the production rules (registration, collection, processing, and testing) are met. Manual processing is extremely risky nowadays with all the parameters to be monitored.
Patient Blood Management: Current blood bank software does not adequately address the need for prospective review of component orders. I expect that collaboration will occur between laboratory and blood bank software vendors to fill this gap.
Refrigerated platelets: The pendulum swings back to this component which was used over 40 years ago. Refrigerated platelets suspended in additive solution may be effective up to 14 days for hemostasis in the trauma setting. These platelets are activated so standard 20-24C stored platelets may be preferred for prophylactic transfusions.
Low-titer group A universal plasma: This is already available, but its use will increase because of the low numbers of group AB units available and increased demand. This includes its production for COVID convalescent plasma. Your transfusion medical director must decide what “low titer” means. Also you need a robust way of performing anti-B titers, this may require use of an immunohematology analyzer with titration built-in.
Low titer group O whole blood: Use of this product may reduce the need for components in massive transfusion settings but it requires performing anti-A and anti-B titers on large numbers of units. Your transfusion medical director must decide what “low titer” means. Also you need a robust way of performing anti-A and anti-B titers, this may require use of an immunohematology analyzer with titration built-in. Also, you must decide whether to leukodeplete the whole blood units: few whole blood filters are platelet-sparing.
Investigation of Donor Unit Mislabelling
Principle:
All donor unit mislabeling is potentially life-threatening and must be stringently investigated as soon as possible after the discrepancy is detected. Most importantly, if there is one error, there may be possibly ADDITIONAL donor unit errors (e.g. switch of donor tubes or units, etc.). All donor units processed in the same batch must be also quarantined until the discrepancies are resolved.
Definitions:
Responsible blood bank physician: specialist or consultant physician on-call at the time the discrepancy is detected
Policy Details:
The following steps MUST be performed as soon as possible:
- The Component Processing Supervisor or Senior Technologist must be IMMEDIATELY notified of any discrepancy.
- The Blood Bank Supervisor will inform the Division Head, Transfusion Medicine. If the Head is not available, notify the Transfusion Medicine on-call.
- Quarantine ALL donor units collected and processed in the same batch.
- Obtain copies of all testing including photos of the gel/glass bead cards documenting the discrepancy.
- Obtain copies of all worksheets used in donor processing for the affected batch.
- Perform repeat ABO/D typing of ALL DONOR UNITS in the affected batch. Any further discrepancies must be investigated and resolved.
- Identify all staff who were involved in handling the donor unit (phlebotomist, blood bank technicians processing and labelling the unit). Identify those associated directly with the error.
- Submit all documents and photos to the Blood Bank Supervisor or designate.
- Prepare an occurrence/variation OVA report documenting all the data, findings, and interpretations.
- All investigations must be reviewed by the Supervisor, responsible blood bank physician, and one of the senior consultants.
- All such investigations must then be finally reviewed and approved by Head, Transfusion Medicine or his designate. Only when the issue(s) are completely resolved and investigation is approved may the donor unit be properly relabeled and released into available stock. Also, only at that time may the other units in the affected batch be released into available stock!!
- Photograph the correctly relabeled unit and attach it to the other documentation of the incident.
- If the discrepancy cannot be resolved, ALL units in the affected batch must be discarded.
- The implicated staff’s personnel record should be reviewed for previous errors. Appropriate disciplinary action should be taken and documented in the personnel record. If a verbal warning is given, it should still be documented in the written record.
- If there is a systemic cause for the error, appropriate measures should be taken to minimize reoccurrence.
- All actions must be in accordance with the applicable regulations.
Dr. Zeyd Merenkov 