Tag: Processes and Software Building

Detailed discussion of Medinfo processes for all blood bank donor and patient services

Regular and Emergency Mode RBC Antigen Matching

drzeyd

Note:  This is an update of a previous post.

In the previous posts I outlined how Medinfo handled antibody screening and identification.  This post reviews how antigen matching is used based on these results.

There are two modes, regular and emergency.  If the patient has not had at least two ABO/D determinations and/or does not have a recent antibody screen within the past 3 days, then emergency mode must be selected with its own rules.  Otherwise, the regular mode applies.

Regular Mode:

In general, if there is a clinically significant antibody, an RBC unit which has not been matched for the corresponding antigen or has the corresponding antigen cannot be routinely selected.  However there is a hierarchy here also:

  1. Absolutely prohibited release—no one can override the logic (e.g. giving group O to a patient with anti-H)—not even the transfusion medicine physician can override this
  2. Restricted release—only transfusion medicine physician can authorize the release of the incompatible or untested unit (e.g. giving C-positive unit to someone with anti-C)
  3. Least-incompatible for warm autoimmune hemolytic anemia WAIHA:  requires transfusion medicine physician approval
  4. Informational release:  authorized staff may release antigen-incompatible or untested unit but a pop-up menu appears and asks them to accept (e.g. Lewis untested unit in a patient with anti-Lea).
  5. Antigen-specificity matched—the usual mode for patients with antibodies

Examples of Regular Mode rules follow (these are not the complete lists but just provided to show the complexity of the process).


Emergency Mode:

This is much more restricted for selection of ABO/D and other antigen typings.  An example follows:

If low-titer group O whole blood is available, then a specific rule must be added to both regular and emergency mode to allow this to be given to any ABO type except Bombay.

Inter-Depot Transfer, Blood Delivery, Type and Antigen Matching

drzeyd

This is an update of a previous post.

The final components from the component preparation center may be sent to various depots (freestanding location and/or hospital blood banks.  There should be complete traceability for every step (from donor reception, collection, testing, and processing) transport between locations, and finally the exact storage site, which might include which refrigerator/freezer/incubator and even shelf/position number for each component is stored.  The end of that document showed rules for type/antigen matching.

For disaster planning, rapid inventory enumeration by type is very important.  This can be very time-consuming manually.  With our Medinfo Hematos blood bank system, we could quickly get total inventory across the Qatar or by hospital in less than one minute.  We could also quickly find antigen-matched units across the system and reserve it at any one site for another if necessary.

Smart blood bank dispensing refrigerators, as offered by Haemonetics and Angelatoni, may also serve as depots and take the place of a hospital blood bank for some dispensing.  These solutions can also capture vital information about the storage conditions of the components and prevent release if the storage criteria are not met.  They can also interface with blood bank computer systems and use the main system’s logic for the dispensation rules.

Upon receipt at the hospitals from the blood processing center, the forward ABO and D typing must be confirmed.  We used D reagents which detected partial D so we would call such donor units as D-positive.  However, if a patient type reagent insensitive to partial D types is used, it is possible for a unit to be typed as D-negative whereas in the donor center it might be D-positive.  Sometimes, nothing types consistently as D-positive:  all you can say is that with a particular reagent and lot number, there is or isn’t reactivity.

The greatest complexity is for RBCs since potentially so many antigens exist.  Criteria for matching/ignoring certain antigens must be made.  Critically significant antibodies such as the Kell, Duffy, Kidd, and certain Rh (D and c) must be antigen matched.  A robust blood bank computer system can enforce these rules.

For other components, antigen/typing may be less important.  In fact, in most situations, any type of platelets can be given to anyone (except neonates).  Despite the potentially incompatible plasma, there is rarely significant hemolysis.  In fact, if pooling platelets without regard to blood types is done, a platelet transfusion is a common cause of a positive direct antiglobulin test DAT—something that is not clinically significant.  No one died of a positive DAT by itself for this reason.

Specific rules for compatible plasma types are important, but nowadays, low-anti-B-titer group A plasma may be used like universal AB plasma.  The challenge is to be able to perform the ABO titration (specifically anti-B) quickly—titration can be a slow process, even with automated equipment.  A similar situation for low-titer, universal group O whole blood requires both anti-A and anti-B titration (I will return to this topic in a future post).

Process: Donor Collection

drzeyd

Process:  Donor Collection

Zeyd Merenkov, MD, FCAP, FASCP

Independent Consultant in Transfusion Medicine

5.4.1 PROCESS DONOR COLLECTION:

Process:

  1. Donors must pass and complete all previous processes in the donor workflow (registration, questionnaire, and physical examination) before the collection process begins.
  2. The donor is positively identified by a designated picture ID and Hematos donor consent form with specimen/encounter number and barcode.
  3. Donor staff checks and prepares a suitable vein
  4. Donor staff collects/labels specimens and the whole blood or apheresis components AT THE DONOR’S BEDSIDE.
  5. Donor reactions are assessed and treated as they occur.
  6. Donors are observed in a post-donation area and given post-donation instructions before discharge.
  7. All processes are documented in Hematos IIG.
  8. Donor units and specimens are sent to component processing and donor marker testing.
  9. The collection workstation and equipment are cleaned before starting a new donor collection.

References:

  1. HMC 1001 Setting Specification, Version 1.5, Hematos IIG, Medinfo
  2. Standards for Blood Banks and Transfusion Services, Current Edition, AABB, Bethesda, Maryland, USA

Policy: Donor Collection

drzeyd

5.4 POLICY: DONOR COLLECTION

Policy:

  1. All donors will be positively identified with a picture ID and by their Hematos identifiers (donor ID and session registration/specimen number).
  2. All previous processes (registration, donor deferral database check, questionnaire, and physical examination) must pass.
  3. The donor’s arm veins will be inspected for a suitable donation site and prepared by a suitable aseptic technique.
  4. Whole Blood:
    1. Only whole blood units collected within the specified time interval may be used for component processing.
  5. Apheresis:
    1. Apheresis units will be collected at frequencies to keep the total RBC loss below 200 in any 8-week period.
    2. Only apheresis units collected within the specified time interval may be used for component processing.
  6. Donors will be treated for adverse reactions as needed.
  7. All specimens and donor units will be labeled at the donor’s bedside before starting a new donor collection.
  8. Donors will be monitored post-donation for a reasonable interval before discharge.
  9. All processes will be documented in the Hematos blood bank computer system.
  10. All equipment and supplies will be used according to manufacturer’s instructions.
  11. The collection workstation and equipment will be cleaned before starting the next donor.
  12. All policies, processes, and procedures must comply with Qatari, HMC, and applicable accreditation standards (i.e. AABB, CAP, and JCI).

References:

  1. HMC 1001 Setting Specification, Version 1.5, Hematos IIG, Medinfo
  2. Standards for Blood Banks and Transfusion Services, Current Edition, AABB, Bethesda, Maryland, USA, October 2013

Product Delivery in Medinfo 1

drzeyd

This is the start of a series of posts on how Medinfo blood bank software was designed for product delivery in the HMC system in Doha.

The overall process was:

  1. Transfer blood components (all types) from the Blood Donor using the Interdepot Transfer process (see that post for details) to the Hamad General Hospital HGH General Delivery Deposit.
  2. Release components to individual HMC system hospitals and client blood banks from the HGH General Delivery Deposit,.

It was also possible to release blood components directly from the Blood Donor Center to HMC hospital blood banks as a contingency.  Client hospitals outside the HMC system still had to obtain their components from HGH General Delivery Deposit.

Interfaces with Quantitative and Qualitative Results

drzeyd

Processes and Software Building Part 7

This is an update of a previous post.

Blood Bank instruments may perform tests and release test results in a numerical or alphanumeric format or both.  For example, nucleic acid and enzyme immunoassay may release a qualitative result (e.g. positive, reactive, borderline/gray-zone, negative, nonreactive).  Alternatively, the machine may release the signal to cutoff ratio (S/CO) as a numeric result.

Blood bank software may use either kind of result on which to base interpretative rules for acceptability of the donor.  The qualitative result criteria are based on the quantitative SC/O but the equipment automatically interprets this.  The S/CO ratio of 1 is the cut-off point.  Thus a value of 0.99 is negative and the value 1.01 is positive.  But is it really so clear-cut since the difference between the two is so small?  Thus, some people have added the term gray-zone for values close to but below the cutoff.  Could a value of 0.95 be an early infection?

I personally prefer to see the actual cutoff but use the manufacturer’s criteria for interpretation.  As a physician, it is good to review the S/CO on serial exams.  If a borderline or gray-zone result becomes positive, then perhaps the original result indicated early infection.  The question still remains, what is the gray-zone?  0.95 to 0.99, 0.90 to 0.99, etc.  Some accrediting schema have not used gray-zone for interpretation.

With Medinfo’s blood bank software, I could choose either option or both—or at least store the S/CO as a nonreported result for subsequent review.  I could even chose, test by test, in a series between reporting either S/CO or the qualitative result.

Semiquantitative results, e.g. in {0, 1+, 2+, 3+, 4+} are qualitative and could also include mixed field (mf) and hemolyzed (h).  I showed examples of this with ABO/D antigen typing in a previous post—see attachment.

On the contrary, the results from blood production equipment may include parameters such as time of preparation, original volume, final volumes for each component, platelet yield index as an indirect measure of platelet count.  When there is pooling, the final total volume is critical to determine if pathogen-inactivation procedures and platelet additive solution can be used.  This is a much more complicated interface.

Processes and Software Building 6: Interfaces

drzeyd

This is an updated version of a previous post.

Interfaces—General Considerations:

When buying equipment while planning/implementing new laboratory software, I originally had a rule not to purchase anything that the vendor did not have a ready interface.  Even that was not so clear since some vendors had interfaces listed as alpha, beta, and completed.

Could you use an alpha or beta interface?  Was it safe for patient care?  What was the development cycle for new interfaces with your vendor—months, years?

Even if the vendor had a completed interface?  How “complete” was it?  Did it accept all data from the machine?  Did the data stream require reformatting?  Who would write the transformational script?

Even if the vendor could support it, could your local IT organization and the local agent’s IT staff do it?  I had plenty of headaches over this.  The best equipment with the best interface that the local agent could not support was worthless to me.

Some finished interfaces took months to install because of connectivity issues.  What version of the operating system OS was used?  Was it secure?  Did our IT department accept that OS version (e.g. Windows 7) and the provided malware protection?  I have seen malware spread across a network from the interface software installed by the vendor, threatening the entire corporate system. 

Did the solution require middleware?  What were the implications of having middleware and its affect on the main software program, especially at the time of its upgrade or the main software?

I have seen vendors using Windows 2000 for their interface software as late as 2017.  It was difficult for some of them to update to current, more secure versions.  Anyway, our corporate IT department gave them all a deadline to update to the current operating system—they all complied or risked losing all connectivity to the network.

Almost every instrument vendor has told me that they can communicate with my laboratory system.  I guess that is true:  one talks in Russian and the other Sanskrit—they do communicate but is it effective?  Talking is not necessarily useful communication!

I remember one open EIA machine that had a TCP/IP port but it was not functional by the standard protocols.  One had to emulate a serial port to get some rudimentary communication.  The port’s light blinked, however.  I never imagined that someone would put a nonfunctional port as a mere decoration.

On the other hand, I have had excellent experience with another software vendor Medinfo.  Even if the vendor did not have the interface developed, they could build it from scratch in a few weeks.  Paradoxically, it was faster to build these new interfaces than some so-called already interfaces.

I must emphasize:  This is a collaborative team effort between the blood bank information system, software vendor, instrument vendor, and your institution’s IT staff.  There must be excellent cooperation between them for a successful result.

When installing the Medinfo Hematos IIG software, many of our most important interfaces (the Terumo mixed shaker, Trima, Reveos and its predecessor Atreus, Mirasol illuminator) had no developed interfaces when we started.  This was a risk, but actually those interfaces were developed in a few weeks and fully functional.  In fact, we were the first site in the world to have those interfaces working—and without any Middleware.

In general, the blood bank software vendor installed the completed interface and did some low-level testing.  Then, my blood bank computer team did the testing.  The final responsibility for testing and acceptance was with the end-user blood bank team and me as Head of the Laboratory Information Systems.

In general,  I wrote the validation protocol and assigned the tasks to the Medinfo Super Users.  To perform this testing, we still had to register donors and collect and then export the specimens to the donor marker testing laboratory before the actual interface testing could begin.  This was all done in a special test domain separate from the production domain.  The interface did not go live until the validation was completed and accepted and then was moved to the production environment.

I made the validation criteria and reviewed all data as Division Head of Laboratory Information Systems.  Representative screen shots were made.  All data was sent to me.  My final acceptance was required before the interface could be activated.

Automated component processing (Reveos) and component modification are more complicated and will be covered in a future post.

Process: Donor Medical Questionnaire

drzeyd

This is one of a series of posts comparing policies and processes in the blood bank.

PROCESS:  5.2.1 DONOR QUESTIONNAIRE

Process:

  1. The donor is positively identified by a designated picture ID and Medinfo Hematos donor consent form with specimen/encounter number and barcode.
  2. Donor is taken to a private area for the interview.
  3. Donor is asked ALL questions by Donor Center staff using the Hematos IIG questionnaire.
  4. Hematos IIG determines if any contraindications apply.
  5. Questionnaire will be referred to transfusion medicine physician for any questions requiring physician review.
  6. Donors without contraindication are sent for donor physical examination.

References:

  1. HMC 1001 Setting Specification, Version 1.5, Hematos IIG, Medinfo
  2. Standards for Blood Banks and Transfusion Services, Current Edition, AABB, Bethesda, Maryland, USA

Policy: Donor Medical Questionnaire

drzeyd

This is one of a series of posts on blood bank operations, comparing the process and policy documents.

5.2 POLICY:  DONOR MEDICAL QUESTIONNAIRE

Policy:

  1. All policies, processes, and procedures must comply with Qatari, HMC, and applicable accreditation standards (i.e. AABB, CAP, and JCI).
  2. All donors will be positively identified with a picture ID and by their Medinfo Hematos identifiers (donor ID and session registration/specimen number).
  3. Donors will be assessed confidentially in a private area.
  4. Donors will be asked questions based on the latest Uniform Donor Questionnaire with additional localization questions for Qatar using Medinfo Hematos IIG software.
  5. Donor must understand either English or Arabic.
    1. Otherwise, they cannot be accepted for donation.
  6. Donors passing the donor questionnaire will be processed for the donor physical examination.

References:

  1. HMC 1001 Setting Specification, Version 1.5, Hematos IIG, Medinfo
  2. Standards for Blood Banks and Transfusion Services, Latest Edition, AABB, Bethesda, Maryland, USA

Processes and Software Building 5: Processes

drzeyd

This is revision of a previous post.

Building Processes:

This post is mainly on building processes for a non-turnkey system such as the Medinfo Hematos IIG software that I have worked with in several countries, but there will be a few words about turnkey systems for general laboratories.

This has been a collaborative effort between the software vendor’s engineers, my Super Users, and myself.  This pluralistic approach has been most productive.

A turnkey system has pretty much already defined most of the basic processes—those have been specifically approved by a regulatory agency such as US FDA.  There is little customization except formatting screen and reports.  Instrument interfaces are also mainly predefined.  This requires much less thought and planning than a custom-built system designed on the sites actual workflows, but it can be an exercise of putting a round peg in a square hole.  You don’t always get what you want.

In the locations where I collaborated in setting up the Medinfo Hematos IIG program, we did not follow US FDA but mainly the Council of Europe CE standards since this was much more customizable.  Additionally, we could modify and add additional criteria specific to our country and region (e.g. rules for donor qualification for local pathogens).  This has always been my preferred approach.

Start with a frame of reference (CE) and then try to optimize it for our local needs. 

I recommend the Council of Europe CE since it is more flexible and extensible.  Those subject to the US FDA has many fewer approved options in the preparation of blood components (e.g. prohibiting the use of pooled buffy coat platelets, automated blood component production such as Reveos, and use of world-class pathogen-inactivation technologies such as Mirasol.)

If you invested the time to make a detailed workflow across all current processes and tests, much of this can be readily translated into the software processes, but first you must study the flows and determine where you can optimize them.  This requires that you study the options in the new software to see what you can use best.

I always liked Occam’s Razor, i.e. “ntia non sunt multiplicanda praeter necessitatem,”—the simpler the better as long as it meets your needs.  If the manual processes are working well and can be translated into the new system, do so.  If they need changes for optimization, then do so only if necessary.

Most of my career has been spent overseas with staff from many different countries and backgrounds, most of whom were not native in English.  The wording of the processes is very important.  Think of the additional obstacle of working with a complicated software in your non-mother tongue!  Also consider the differences between American English, British English, and international English.  I always made the Super Users read my proposed specifications and then asked them to repeat what I wrote/said.

There were many surprises discovered.  I think of the Aesop’s fable about the mother who gave birth to an ugly baby looking like a monkey.  Still, to the mother her baby was the most beautiful baby and she entered him into a beauty contest.  In other words, to the mother her child is perfect!

It is most important to use the manufacturer’s recommendations to build tests and for the special automated processing and pathogen-inactivation processes.  For example, we had multiple ABO and D typing tests—they did not necessarily agree on what were acceptable results for automated release of results.  The same is true for many other tests.

Example:  One method for Rh(D) typing stated that only results in {0, 2+, 3+, 4+} were acceptable—all other results required manual review and/or additional testing.  Another only accepted results in {0,3,4}.  Thus we had to build separate D typing processes for each methodology.

Another consideration is whether to offer all the processes globally or restricted to one site.  I favor allowing access to all methodologies at all sites—in case of a disaster where tests had to performed at another site.   This means that if you send an order over an interface from the hospital system to the blood bank system, that at the receiving (blood bank) end, you can choose which methodology to use, i.e. it is not a one-to-one mapping but rather a one to many mapping.

If we changed equipment at one site to that used at another site, we didn’t have to modify our software to accommodate this.  Even if you didn’t have the equipment or reagents at one site, you could always build it into the system and not activate the settings until needed.

Finally, the issue of middleware.  Many instruments offer this, but one faces the problem about support and regression errors when you either update the middleware software or the blood bank computer software.  Medinfo itself can serve as the middleware so there is less chance of errors when updating the software.  In fact, I never have used any middleware when using Medinfo.

Instrument interfaces will be a future topic.