Building the Software Processes for the Donor Collection 5:Donor Physical Examination and Adverse Reaction Reporting
Donor Physical Examination and Adverse Reactions
Donor physical examination, along with the donor questionnaire, are important both for donor and patient safety. In general:
Is it safe for the donor to donate?
Is it safe for the patient to receive the blood even if it is safe for the donor to donate.
Any donor who does not feel well must not donate. This may be the single most important step in ensuring a safe blood supply.
The donor physical examination includes the vital signs (blood pressure, pulse, temperature, heart rate, and temperature). I have attached a sample set of criteria for review. All are user-definable. Note how the arm examination is also included (looking for scarring, skin lesions, etc.)
For all types of donations, there may be adverse reactions. These must be documented in the record along with the disposition of the donation. Will the donor need an extended deferral if the RBCs in the apheresis run are not returned? This can be built from the reaction documentation. Note the following sample table of reactions.
Donation can be whole blood or apheresis-based. The sex and age for each donation type is specified. At HMC, we did not accept females for platelet or plasma donations, so the starting age is listed as 99 years. Otherwise, in accordance with Qatari law, the starting age for donation is 18. All these parameters are user-definable, and a transfusion medicine physician can override the rules if necessary.
For each and every combination of donations, the deferral interval must be specified. Examples follow. The temporary deferral period is in days:
Previous donation whole blood, current donation whole blood: 56
Previous donor platelets, current donation whole blood: 2
Previous donation whole blood, current donation platelets: 56
Also note how for each possible combination there is an entry for male AND female. Females are restricted to whole blood donation and only RBCs will be made from the collection.
If there is a collection incident and the apheresis procedure is not completed, the interval will be set to 56 days. This will be covered in the post on donor adverse effect reporting.
At the time of registration, the type of donation must be specified. In my last position, this could include whole blood for automated Reveos, whole blood for cryoprecipitate, plasmapheresis, COVID 19 convalescent plasmapheresis, plateletpheresis, concurrent platelet and plasmapheresis, concurrent platelet, plasma, and RBC apheresis, RBC apheresis-one unit, and RBC apheresis-2 units.
There is also a specimen-only donation without actual collection that includes database check, assignment of an ISBT specimen number, donor questionnaire, physical examination, and specimen collection only..
We specified which bag or kit could be used for each type of donation so when it was selected, only that bag type would be accepted by Medinfo
For each of these types we must specify what type of donation is permitted: volunteer, autologous, or directed.
Finally, we must indicate the maximum length of the procedure permitted. This applied to whole blood only and we set this at 15 minutes—this is user definable.
The following are a sample set of parameter settings for the above:
Note how we included contingencies for old bag sets and equipment (that we later discontinued) and for granulocyte collection (which we did not actually perform).
This policy outlines steps taken to minimize the risk of data entry errors and is based on a dualistic approach: review of results by a senior technologist and/or supervisor and various computer safeguards built into the Medinfo Hematos IIG blood bank computer HIIG system. This policy also discusses the verification (here called authorization) and purge processes of HIIG.
Policy:
Review by senior technical, supervisory, or transfusion medical staff:
Designated test procedures require review by a second technologist before authorization.
Complex immunohematology testing and specimens showing aberrant results (e.g. ABO/D discrepancies) are reviewed by the supervisors or designates and ultimately a transfusion medicine physician before authorization.
Computer system HIIG rules:
Privileges:
System restricts which staff can perform specific tests
Patient/donor identity:
System asks end-users to verify patient/donor identity before starting any access to the patient/donor record.
System performs historical database checking and flags any inconsistencies (e.g. historical ABO/D typing differences, etc.)
Testing:
Only selected staff have privileges to authorize or purge.
ABO/D testing algorithms require entry of reactions, not interpretation of results and are compared to a truth table.
Aberrant results require special review before ABO/D typing results can be authorized/purged.
D-controls must be negative to allow D typing results to be authorized for liquid D-typing reagents.
DAT results require appropriate controls to meet truth-table criteria.
Eluates require last wash to be negative before authorization
Blood components:
Selection of RBC or plasma units requires two independent sample determinations within 72 hours of each other.
ABO-incompatible RBC or FFP/FP24 transfusions are not allowed.
Donors with any detectable antibodies are permanently deferred.
Depending on the patient’s antibody history, release of RBC units may require antigen-matched units. Examples:
Mandatory matching (only antigen negative matched units allowed—no antigen positive or antigen-untyped units): Antibodies against H, D, c, K, k, Kpa, Kpb, Jsa, Jsb, Jka, Jkb antigens, anti-PP1Pk
Priority matching (incompatible or untested can be approved by a transfusion medicine physician):Â C,E, e, Fya, Fyb, M, S, s
Antigen matching not required:Â Lea, Leb, N
Least-incompatible crossmatch require special authorization to release
Protocols to force irradiation or other modified components can be setup in HIIG.
Donors:
Donor tests have same criteria as the same test used in patient testing for controls, etc.
Donor demographics are read directly from the Ministry of Interior database—no manual entry (bar code only used).
References:
Workflows for Hematos IIG (1001 through 1005), 2013
Standards for Blood Banks and Transfusion Services, Current Edition, AABB, Bethesda, MD, USA
Guidelines to the Preparation, Use, and Quality Assurance of Blood Components, European Committee (Partial Agreement) on Blood Transfusion (CD-P-TS), Current Edition
Building the Software Processes for the Donor Center 2:
Donor Collection and Screening—Registration and Pre-Donation Parameters
The potential donor enters the collection area. He takes a number and waits to be called. When called, he shows a picture identification card with a unique alphanumeric sequence. This is entered into the donor module software and the system checks the donor deferral database for temporary and/or permanent contraindications. If none are found, a consent form with an ISBT specimen number is generated.
In this post, we will consider:
Registration process in multiple languages
Donor deferral database
Donor consent with generated unique ISBT specimen number
Registration Parameters
Registration:
In the Middle Eastern region, multiple languages are used. Although Arabic may be the main language, not all the registration staff may speak it. English is commonly used as the main work language. The date may be entered as Common Era (Gregorian) and/or Hijri.
An issue is that for native Arabs, the only precise, unambiguous name spelling is in Arabic. English transliterations vary. Example, Muhammad in Arabic is very simple to write, in English it may be rendered as Mohamed, Mohammed, Muhammad, etc. The donor’s name should be recorded exactly as in his native alphabet. How do you register when the staff do not speak or type Arabic?
Fortunately, I have worked with software that is in UNICODE, meaning that the data does not have to be restricted to English or Latin script (I wonder why the hospital information system we had at one institution could be sold in the Middle East and not have this capability!). That means one could perform registration and donor questionnaire tasks in multiple languages, and preferable the native language of the donor. One could even prepare database reports in Arabic.
Medinfo had an elegant solution to the registration process in Qatar. It read the local identity card’s barcode issued by the Ministry of Interior and accessed (read-only) the demographic data on that donor and received back both the English and Arabic name fields:
This would generate the demographic fields in the registration:
The blood bank software would check the national donor deferral database and list any deferrals/contraindications to donation and the next eligibility date. It would also list what type of donations were permitted (e.g. for females, only RBCs could be collected and processed: if a whole blood unit was collected, then the platelets and plasma would NOT be permitted to be processed and were discarded.)
Medinfo used a unique key field, the Medinfo Hematos Donor ID for the database. This was not the same as the national ID card. All records were indexed against this number with strong security.
Donor Deferral Database:
Medinfo had already imported donor data from a previous computer system and added this to its own database. Thus, there was only one database to check. The database listed all previous donations: dates, type, status (complete, aborted). Any contraindications would be prominently shown in RED.
Donor Consent and Assignment of Donor Unit (ISBT Specimen) Number:
If there were no contraindications, Medinfo generated a donor consent in English and Arabic and the unique donor unit number for the current encounter:
Registration Parameters:
Medinfo enforced registration according to the format of the identity card. The donor ID format was built into Medinfo. If the entry deviated from this, it was rejected and registration could not continue:
The registration type would be selected (volunteer, autologous, directed, or paid). In Qatar, paid donations were not permitted:
Next, the donation type had to be selected:
At the time of registration, the type of collection bag (or kit if using Reveos) was automatically set in Medinfo. I will consider this further in the next post of this series to determine eligibility based on the previous donation interval and type.
At each donation site, the allowable types of donations and kits could be set. Based on the donation parameters above, staff could not select the wrong type of bag/kit (e.g. an apheresis kit for a mobile donation).
This is a first is a series of detailed posts of how I collaborated with Medinfo (Nice, France) to build customized donor software for both Saudi National Guard Health Services and Hamad Medical Corporation Doha.
In particular, we were using a non-turnkey software which could be built to order. If we didn’t know what we were currently doing, how could we build something better?
At both sites, we had good manual systems in effect and prepared detailed mapping of the current state. We reviewed our variance reports to see where we needed to bolster the system and improve the critical control points.
We studied the software options and prepared a draft Medinfo future state from which we started to build the system. We did this in small stages so we could test it and adjust our settings as needed—without being charged extra (unlike a general laboratory software I had been working with at the same time, which always charged an arm and a leg).
To do this, I engaged early a team of my most computer-literate staff to work as Super Users. In the Donor Center, this consisted of nurses and technologists.
The flavivirus Zika virus can be transmitted through mosquito bites from Aedes aegypti and Aedes albopticus species. The outbreaks have been associated with severe birth defects, especially CNS (microcephaly). Although it is not clear if it can be definitely transmitted by blood transfusion, major international organizations, UK National Health Service, World Health Organization, and the American Red Cross have instituted temporary deferrals for travelers from those affected areas.
Change Log:
This bulletin reflects recommendations made by the FDA Bulletin dated 1/3/16, FDA issues recommendations to reduce the risk of Zika virus transmission by human cell and tissue.
If so, then they are to be temporarily deferred from blood donation for 28 days upon leaving that area.
A specific question about Zika travel history is now active in the Medinfo Hematos IIG questionnaire.
Clinical Symptoms:
Donors should be asked if they have now or within the past 28 days had any of the following symptoms:
Fever
Rash
Joint Pain
Conjunctivitis (red eyes)
Muscle Pain
Headache
If a donor has any of the above symptoms, they should be deferred for 28 days from blood donation after visiting the Blood Donor Center.
Sexual History:
Blood donors should be deferred for 28 days after the last sexual contact with a man who has been diagnosed with Zika virus or who traveled to or resided in an area with active transmission of Zika virus in the 3 months prior to that instance of sexual contact.
Re-entry of blood donor after deferral:
Defer for 4 weeks after the resolution of symptoms a donor with a history of Zika virus infection.
A deferred donor may be considered eligible after the deferral period has lapsed provided that all donor eligibility criteria are met.
Cellular product and other tissue donors:
Living Donors of Cellular and Tissues:Â Donors should be considered ineligible if they were diagnosed with Zika virus infection, were in an area of active Zika virus transmission, or had sex with a male with either of those risk factors within the past SIX (6) months.
Donors of umbilical cord, placenta, or other gestational tissues should be considered ineligible if they have any of the above risk factors at any point in their pregnancy
Deceased (non-heart beating) donors:Â Donors should be considered ineligible if they were diagnosed with Zika virus infection within the past SIX (6) months
References:
Center for Biologics Evaluation and Research CBER Guidance for Industry Recommendations for Donor Screening, Deferral, and Product Management to Reduce the Risk of Transfusion-Transmission of Zika Virus, February 2016
AABB Association Bulletin #16-03 Zika, Dengue, and Chikungunya Viruses,
Blood Banks Establish Waiting Period For Prospective Donors Returning From Zika-Affected Areas, AABB Newsbrief, 4/2/16
FDA Bulletin 1/3/16, FDA issues recommendations to reduce the risk of Zika virus transmission by human cell and tissue.
After the initial manual setup of the CCP program, the Medinfo process was set up. The following workflow shows the production of CCP from the raw apheresis collection, including division into aliquots based on the total volume. The plasma volumes were kept within the range for riboflavin pathogen inactivation (Mirasol).
The usual safeguards for production were also in effect for CCP. The product could not be labelled without all criteria (donor screening, collection, marker testing) being met. Furthermore, the inter-depot and transfusion service processes still applied. However, all steps were done in quarantine at a location separate from the regular processes. Also, the actual ordering and release of CCP was restricted to the quarantine hospital blood bank site.
Based on the previous software post, I use the antiglobulin test algorithms to construct the antibody screen ABS, namely an INDIRECT antiglobulin test, i.e. incubate reagent red cells with the donor or patient’s plasma and then perform the DAT. At HMC Doha and at NGHA in Riyadh, we mainly used three cell screens (no pooled cells for donors). The reactions could be machine-read (we had the interface) but the interpretation of the specificities found was done manually.
Donor ABS:
We screened all donors for irregular antibodies. I disqualified most donor with non-negative screens from donation (my personal preference). However, for nonspecific antibodies, I might elect to discard the current collection and then reassess the donor’s status at the next encounter. Not everyone would agree with this most restrictive approach but I would not use the platelets or plasma in such situations. I also did not use the donor RBCs, even though they were in SAGM—but I could elect to override this decision in Medinfo if there were a rare blood group (e.g. r’r’).
Example #1 (following) shows a sample donor ABS process:
Patient ABS:
Excluding emergency release, if the patient did not qualify for the electronic (computer) crossmatch, then the AHG crossmatch was required. A three-cell antibody screen including R1R1, R2R2, and rr RBCs was used that usually included cells homozygous for the Kell, Duffy, Kidd, MNS antigens. For any case with a non-negative antibody screen, either donor or patient, an antibody identification was performed.
Note that I did not use any other software to make antibody identifications. I required my technologists to be proficient in identifying basic and intermediate-level testing. The actual antigen makeup of each lot number of antibody screen or identification panel was NOT stored in Medinfo. We scanned the antibody screen and panel workups and could store those in Medinfo.
Example #2 (following) shows a sample patient ABS process:
Patient ABS Fix for Interface Regression Caused by HIS:
Regretfully, with a software update from the hospital information system HIS vendor, a major regression occurred. It would not discard results from Medinfo if more than one antibody result (e.g. anti-E and anti-c) was sent back. We could see the results in Medinfo, but those outside Transfusion Medicine could not see antibody results. The entire interface for antibody identification had to be rewritten so that the HIS would see each result uniquely and thus all results could be sent back to it.
Regression Example:
Anti-Kell sent from Medinfo: one antibody result, HIS would store and show this result.
Anti-E and anti-c sent from Medinfo: No antibody results shown, both results kicked out.
Regression Fix:
Anti-E sent as Method Type1-Antibody 1 and anti-c sent as Method Type 1-Antibody 2: both results displayed in HIS.
Dr. Zeyd Merenkov 