Author: drzeyd

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:

Evaluation of a Positive Direct Antiglobulin Test

drzeyd

This presentation is from my time at National Guard Health Affairs Riyadh and suggests an algorithm to assess the clinical significance of the reaction. In my opinion, the essence of immunohematology testing is the antiglobulin test so I would spend much time with technical and medical staff, including trainees/fellows (even those not based in transfusion medicine) to make certain they understood how to interpret it.

If it is a neonate and the mother is ABO-incompatible, always test against reagent A1 and B cells.

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:

Blocking Antibodies

drzeyd

This is a revised version of a previous post.

If there is strong antibody binding to an RBC, this may interfere with a typing reagent attaching to the cell and cause a false-negative, i.e. a “blocking” antibody.  Such cells may interfere with the indirect antiglobulin test IAT, i.e. the antibody screen.  The autocontrol and direct antiglobulin test DAT will be strongly positive.

The manufacturer’s instructions for using its reagents should be strictly followed in the presence of a strongly positive DAT.  If there is no reaction with the typing reagent, the result must be indeterminate.

One could try a (relatively) nondestructive elution method such as gentle-heat elution to remove some of the antibody and then retype the cells.  I have found this to be a simple and effective method for my staff to use.  Just remember that despite being “gentle,” there will still be some hemolysis present, but here it is the cells we are trying to save.

Usually, we find this situation in a neonate born of a mother with anti-D.  The baby has a strong DAT but the D typing is negative.  Check the D control carefully:  if it is positive, the result is indeterminate, try another method.  Usually gel/glass bead methods are subject to less interference.  Finally, there is always the classic saline anti-D!

In Medinfo software with a blocking antibody, a nonnegative control will trigger a manual review of the results.  There will be no automatic release.

Here is my process for handling blocking antibodies, which I set up for HMC Doha:

INTERIM POLICY:  ANTIGEN TYPINGS IN PRESENCE OF STRONGLY POSITIVE DIRECT ANTIGLOBULIN TEST (DAT):  RULE OUT BLOCKING ANTIBODY

Principle:

Antigen typing of cells with large amounts of coating antibody (i.e. strongly positive DAT 3-4+) may not always be possible because the bound antibody may block available antigen sites.  This policy is to clarify how to recognize and handle such situations.

Policy:

  1. Always follow the manufacturer’s instructions for the use of the typing reagent.
    1. In particular, note whether a control must be run with the test (e.g. D-control, D-diluent, etc.) or if it is included in the gel or glass bead card.
      1. If a control is required, use exactly what the manufacturer recommends.
      2. DO NOT SUBSTITUTE ANYTHING ELSE AS THE CONTROL!!
  2. Interpret the reactions exactly as the manufacturer indicates.
  3. If the test is invalid because of the control or any other reason, report the antigen typing as indeterminate and send for Transfusion Medicine Physician TMP review.
  4. If the DAT is 3-4+ and the antigen typing shows no reaction (apparent negative), send the case to the Transfusion Medicine Physician for review and final interpretation.  DO NOT ENTER THE RESULT AS NEGATIVE UNLESS THE TMP INSTRUCTS YOU TO DO THIS!!
  5. To rule out a blocking antibody, a special elution to gently remove the coating antibody may be needed so that the RBCs can then be typed (not acid glycine technique—rather use gentle heat elution.)  The Transfusion Medicine Physician will decide whether to do this additional testing.

References:

  1. Standards for Blood Banks and Transfusion Services, Current Edition, AABB, Bethesda, MD, USA
  2. Technical Manual, Current Edition, AABB, Bethesda, MD, USA
  3. Guidelines to the Preparation, Use, and Quality Assurance of Blood Components, European Committee (Partial Agreement) on Blood Transfusion (CD-P-TS), Current Edition

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.