Tag: Quality Assurance

Quality Asssurance in Transfusion Medicine

My Opinion: Separate Transfusion Medicine from the Laboratory and Clinical Departments

drzeyd

This is an update of a previous post.

Transfusion Medicine includes laboratory and non-laboratory functions.  The non-laboratory and purely clinical functions are unique and have no analogy within the general laboratory.  Likewise, from a clinical department perspective, transfusion medicine is not just a clinical service, but also a laboratory and a drug manufacturing center.

The transfusion service/hospital blood bank laboratory is the closest to a laboratory operation, but there is also component modification and complex manual testing, especially for reference immunohematology testing.  The staff must make detailed manual decisions, the errors for which could be life-threatening for the patient.

The blood donor center manufactures a pharmaceutical, i.e. blood components with collection, donor qualification, donor abnormal results review, infectious disease marker testing, component production, and donor immunohematology testing—all subject to Good Manufacturing Practices.  Never forget:  Blood is a drug!!  There is no other part of the clinical services or laboratory that manufactures drugs.

Transfusion Medicine is directly responsible for treatment of critically ill patients.  Therapeutic apheresis is essential for organ and stem-cell transplants, nephrology, neurology, etc.  No other laboratory section is directly responsible for treatment of critically ill patients.  Transfusion Medicine physicians are functioning as intensivists.  There is no hiding in the blood bank from clinical medicine.

It may also be an industrial manufacturing plant to extract various blood derivatives (e.g. factor concentrates, albumin, Rh immune globulin, etc.)  This is pharmaceutical manufacturing on a large-scale basis.  There is medical, technical, and special administrative expertise.

Many functions may operate 24/7. 

The unique blend of clinical skills is unlike anything else in the laboratory.  Thus, those outside the blood bank may not be familiar enough to decide the best course of action for transfusion medicine or for its operations.

The transfusion medicine physician must make acute, life-threatening decisions unlike anyone else in the laboratory 24/7 at all times.  The transfusion medicine physician may be on-call for donor issues and review of complex immunohematology problems to acutely decide which blood component (and phenotype) should be given as well as review all adverse reactions to transfusion.  The blood bank technologist is at the cutting edge of the battle with his testing and interpretations.  No other area of the laboratory is at such risk for injuring or even killing the patient.  There is high stress and burn-out.

I have talked with many blood bankers and many seem to share the exasperation that the laboratory or clinical departments do not understand or appreciate us.  Often, the laboratory looks at blood bank testing like that coming off a hematology or chemistry analyzer—although patients rarely would have severe morbidity or mortality like the blood bank from errors in those analyzers.

No laboratory pathologist has the pressure of the blood bank physician on-call.  It really is 24/7 and requires a broad, clinical background to make the right decisions.  It is very stressful and does not permit a good night’s sleep.

Thus, I make my case to separate us from the laboratory.  We can form our own more effective administrative organization and optimize our own planning.  Regretfully, I have never experienced or worked in such an administrative structure.  I also am a realist that cost-containment nowadays makes it much less likely high administration would permit this change.  This will probably never happen during my career.

Finally, Transfusion Medicine is an essential service.  Blood components are essential drugs.  The operations and staff must be free of political influences.  This is a service for the entire region or country like the fire department, civil defense, etc.  You are playing with fire when you disturb the blood bank.

Knowing Your Technical Staff

drzeyd

As a transfusion medicine physician, I was always being called to make decisions at all times when I was on-call.  This could be for qualifying donors, therapeutic apheresis, or most commonly to analyze complex immunohematology situations and transfusion reactions.

I had to make decisions on data that was presented to me by my staff on the phone.  I had to rely on the technical staff performing the test.  If I made a decision on their findings and their findings were incorrect, I was still responsible for the error as head of the department.

Nowadays with a blood bank computer system, I could remotely access the data as it appeared in the computer.  Still, how could I be sure that it was correct?

Based on my many years of experience, I have learned that I needed to know the capabilities of each staff member and to what extent I could rely on their results.  Not everyone could do complex cases.

I also listened to how they presented the data to me.  If it was disorganized or if they sounded uncertain, that was a red flag that something was wrong and I should be very careful about using the results.  In such cases, I told the staff member to call a senior person to repeat the work.  Of course, I did this in a delicate, face-savings way not to hurt the staff’s feeling.  I usually told them to collect a new specimen and have a second senior person to repeat the workup.

I also had to know the context of the workload at the time of the consultation.  Were there shortages of staff, were the staff stressed out, was there too much work for them to properly perform?  In those situations, I would authorize additional staff to come in and repeat the work.  I was very worried when outside hospital staff used to scream at my staff (usually junior doctors) and upset them.  In the emotional distress, they could make a dangerous mistake.  One of my roles was to serve as a counselor and de-stress my staff.

In summary, if you do not feel your staff can handle the work properly, don’t rely on the output.  Repeat the work, defuse the stress, fix the workload, etc.  As the transfusion medicine physician, it is also your neck on the line.  You are responsible to determine if you can trust the results to make a medical judgment.

User Acceptance Testing

drzeyd

When a new software version was introduced in my system, first the vendor did a preliminary round of testing before submitting it to my Medinfo-Laboratory Information System team for validation.  I then prepared a training session for the Super Users and assigned them validation tasks.  When the validation was completed and accepted by me, then the software was submitted to the Hospital Information System HIS department, which conducted its own final acceptance training.  Following this, transfusion medicine staff were trained before the new software went live.

This is a sample user acceptance training document, which was prepared by Medinfo and myself and submitted to HIS for the upgrade from Version 3.8 to 5.0.  The patient module is shown.

The Medinfo Super Users performed the script while the HIS Quality Team viewed the actual output.  Notice for each Action step there is the Expected Result.

The evaluation for each step was recorded as part of this long and wide spreadsheet:

Super-Users: Engaging Laboratory Staff in Computer Operations

drzeyd

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:

  1. Blood Donor Center:
    1. Administrative Clerk for donor registration, consent, ISBT specimen labels, creation of new donors and patients for validation purposes
    2. Apheresis/Donor Nurse for donor questionnaire, donor physical examination, and donor collection
    3. Medical technologist for donor marker testing
    4. Medical technologists for blood component production including Reveos, Mirasol, platelet additive solution, pooling, and leukodepletion
    5. Medical technologist for donor immunohematology testing
    6. Medical technologist for inter-depot transfer of blood components
  2. Hospital Blood Banks and Transfusion Centers:
    1. 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.

Using the Current State to Build the New Processes:

drzeyd

Processes and Software Building—Part Three

This is an updated version of a previous post.

Using the current state to build a new work flow can be a difficult task and balancing act.  If one changes it too much, it may be difficult for the staff to cope.  If too little, then why bother at all?  Still, we had to take the time to analyze our current system and identify areas  of improvement.  When building a new computer system, we didn’t want to capture our current system with its flaws in concrete.  Buying a new system is costly and it would be very hard to change it again,  This had to be done right.

Also, whether or not you have a pre-existing software may affect your choices.  In my opinion, it is easier to learn something new than to make some changes to a system that everyone has already learned.  Learning is easier than unlearning and relearning.

First, I studied the new system’s capabilities and took note of the features I would like to adopt to improve the current processes.  I did this especially at the critical control points.  I also studied our incident reports:  where had there been nonconformances?  How could I change things for the better, i.e. with increased safety and compliance to international standards?

I did not want to throw out a successful manual system, just to optimize it.  I tried to pick out those manual processes that worked and build those into the new workflows.  What I wanted was a system recognizable and familiar to the staff but with enhancements with the least amount of change to reach our goals.

Although the vendor did some initial testing, this was insufficient to accept the system.  I didn’t want the vendor to just show me some scenarios that they concocted.  I was always suspicious why the vendor chose these examples and not others.  Could it be that the other processes did not work as desired?  I always insisted that I give the vendor representative scenarios and have them show me how the system reacted.

It is daunting task to know what settings to make.  At one of my previous institutions, the administration recognized that they needed additional expertise from someone experienced in the new system.  They hired an outside firm in addition to the software vendor.  Still, even this was not sufficient to make the proper settings and testing.  We had to rely on ourselves!

Ultimately, the Laboratory had to thoroughly test the system,  The only way to do this was to use our own resources.  Only we could test its actual functionality to the proper degree to ensure safety.  Still, where could we get the resources to do this?  Outside consultants were very expensive, especially if they have to live on-site for extended periods.  The only answer was to make use of our internal resources, i.e. our staff.

Serologic Controls

drzeyd

In old days of only polyclonal reagents, QC of reagents took significant time.  This has been simplified and easier since the introduction of monoclonal cocktail reagents.

Controls may be explicit (a specific control provided by the manufacturer) or implicit (implied by at least one negative reaction in the well of a gel card).

In order to properly interpret test results:

  • Always follow manufacturer’s recommendations for performance of test AND use of controls.
  • Use only the manufacturer’s specified control for testing.  For example, do not substitute 6% albumin as the D-control if the manufacturer provides a specific control.
  • Use manufacturer’s criteria for control validity.

Make certain test results meet the criteria for interpretation.  Do not accept negative results for IAT typing if DAT is strongly positive (blocking antibody).

For both manual and automated tests, you can build the control criteria directly into your blood bank computer system’s truth table of results.  This way the system will enforce the criteria and prevent false interpretations:

Example of control for ABO typing:

Overextending Oneself—Two Case Studies in the Blood Bank

drzeyd

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

drzeyd

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:

  1. Order something
  2. Receive specimen
  3. Perform test
  4. 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:

  1. Specimen condition and acceptability criteria
  2. Possible results for each part of the test
  3. Interpretation of each result
  4. Control results
  5. Acceptability criteria
  6. Truth table
  7. 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.

My Opinion: Issues in Transfusion Medicine Software and Component Production

drzeyd

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.