Category: Teaching

Teaching medical and technical staff transfusion medicine

Building Processes in a Blood Bank Computer System

drzeyd

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.

Electronic (Computer) Crossmatch

drzeyd

This is a revised version of a previous post.

As much as 90% of the RBC component allocation can be performed without an actual crossmatch test (AHG or immediate-spin) provided that certain criteria are met.

Enforcing these rules, however, can be cumbersome unless one has blood bank software that verifies that each rule is met.  In the Medinfo patient module, the transfusion history database is checked automatically.  If the rules are met, then Medinfo allows the selection (allocation) of RBC units without performing a crossmatch test.  Otherwise, it will check to see if the AHG crossmatch has been done within the past 3 days.  If not, it will prompt for new crossmatch testing with a new specimen.  If the situation is urgent, one can go to Emergency Mode and release components without the crossmatch.

Principle:

In selected patient categories, no classical crossmatch may be required for release of RBC components.  The criteria are specified here as applicable in my build of the Medinfo Hematos IIG computer system HIIG.

Policy:

  1. An electronic crossmatch without antiglobulin or immediate-spin phase testing may be used for the following patient categories:
    1. The current ABO/D type matches the historical ABO/D type.
    2. The ABO/D type (forward and reverse) is clearly defined without any discrepancies.
    3. Two determination of the ABO/D group must be made:
      1. One from a current specimen (within the past 72 hours)
      2. The second by one of the following methods:
        1. Testing a second current specimen
        2. Comparison with previous records of ABO/D typing
        3. Retesting the same specimen
    4. The current antibody screen is negative
    5. There is no history of RBC antibodies or a non-negative antibody screen.
  2. If the criteria in #1 are not met, the AHG crossmatch is required in non-emergency situations.
  3. General computer system safeguards:
    1. The system contains the donor unit number, component name, confirmed ABO/D typing, two unique recipient identifiers, recipient ABO/D, antibody screen typing, and interpretation of compatibility
    2. A method exists to verify correct entry of data before release of blood or blood components.
    3. The system contains logic to alert the user to discrepancies between donor ABO/D group on the unit label and those determined by blood confirmatory tests and to ABO incompatibility between the recipient and donor unit.
  4. HIIG will enforce the above rules.

References:

  1. HIIG Workflow 1004, Patient Testing, Latest Version
  2. Section 5.16, Standards for Blood Banks and Transfusion Services, Current Edition, AABB, Bethesda, MD, USA
  3. FDA Guidance for Industry:  Computer Crossmatch (Computer Analysis of the Compatibility between the Donor’s Cell Type and the Recipient’s Serum or Plasma Type), April, 2011

DAT and Selection of RBC Units for Transfusion

drzeyd

This is an update of a previous post.

Principle:

In 1984 effective with the 13th Edition AABB Standards, the requirements for performing a direct antiglobulin test and autocontrol for compatibility testing were eliminated.  The DAT is very important to detect delayed hemolytic transfusion reactions, certain autoimmune conditions, and drug-related hemolysis.

Since that time, the immediate-spin crossmatch and now the electronic computer paperless crossmatch may be used for most compatibility testing in place of the classic, antiglobulin-phase (indirect antiglobulin test) crossmatch.

If an antiglobulin phase (IAT) crossmatch is performed, an RBC unit with a positive DAT will cause a false-positive reaction.  Since most crossmatching does not include the IAT, it will not be affected by the DAT status of a donor unit.

Policy:

  1. Donor RBC units will NOT be routinely tested for DAT as part of component processing.
  2. The type of compatibility testing selected for a particular patient should be the technically simplest one (no need to do extra work unless so instructed by the transfusion medicine consultant/designate):
  3. Do a full antiglobulin-phase IAT crossmatch if ANY of the following applies:
    1. There are no two independent ABO/D typings on the patient during the current admission.
    2. The ABO/D type of the current admission does not match the historical information.
    3. The patient has a detectable antibody at 37C
    4. The patient has a history of a clinically significant antibody but no current antibody
    5. Whenever the consultant, transfusion medicine/designate requests it.
    6. Whenever the Medinfo HIIG record so indicates (in comment section)
  4. Do the immediate-spin crossmatch if ALL of the following apply:
    1. Only one determination of the ABO/D type
    2. The historical ABO/D type agrees with the current type.
    3. There are no antibodies reacting at 37C AND there is no history of antibodies at 37C.
  5. Use the computer/electronic crossmatch if ALL of the following apply:
    1. There are two determinations of the ABO/D type and they both agree with each other.
    2. The historical ABO/D type agrees with the current type.
    3. There are no antibodies reacting at 37C AND there is no history of antibodies at 37C.
  6. When to do a DAT on a donor unit:
    1. Patient antibody screen is negative but the full AHG crossmatch is incompatible.
    2. Part of a transfusion reaction workup where the AHG crossmatch of donor cells and patient serum is incompatible.
    3. Whenever the consultant, transfusion medicine/designate requests it.
  7. If a donor unit is found with a positive DAT:
    1. Required testing and review:
    2. Test with polyspecific and monospecific IgG and C3d antisera
    3. Perform an acid-elution.
    4. Send the results to the transfusion medicine consultant/designate for review.
    5. The reviewer will enter his review in HIIG in the Donor Consultation Section both as global donor comment and a result-specific comment against the antibody screen result.
    6. Use of the DAT-positive donor unit:
      1. Most of the time you will not know if the donor RBC unit is DAT-positive since we mainly use the electronic crossmatch.  It will be used if all criteria are met.
      2. Otherwise, select another RBC unit for the AHG crossmatch.
      3. The final decision to use the DAT-positive unit will be made by the Transfusion Medicine consultant/designate.

Important:  Don’t do a classic AHG/IAT phase crossmatch unless you have to do it  (see conditions above.)  A donor unit with a DAT is unlikely to be clinically significant and may be transfused safely to the patient in most situations.  Patients receiving electronic-crossmatch and immediate-spin crossmatch are receiving units with positive DAT without incident.

References:

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

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.

Plasma Project Considerations for Middle East

drzeyd

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:

  1. Acquiring software for a blood center with plasma brokering capabilities.
  2. 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
  3. Identifying extended sources of plasma to feed a manufacturing plant.
  4. Preparing a curriculum suitable for training as staff for the plant.
  5. Establishing a joint venture to share technology with a major plasma company to design, build, and operate a plasma fractionation plant.

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.

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: