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.
In accordance with the College of American Pathologists’ accreditation standards, all report structures (content, formatting) are reviewed at least biannually and upon modification by staff designated by the Chairperson, DLMP, here the Division Head, Transfusion Medicine/Laboratory Information System.
Policy:
Responsibilities:
The Chairperson, DLMP is ultimately responsible for the report formats, electronic and paper (if applicable) across all areas/divisions/sections of the department.
The Chairperson, DLMP delegates the responsibility for this review to the Head, Laboratory Information Systems LIS.
The Head, LIS reviews/approves the final reporting formats after review/acceptance of the formats by the Division and Section Heads for their respective areas.
Content of the reports:
Headers and footers as required, especially for paper reports
Headers will include full patient name and a unique alphanumerical identifier, age, location, sex, date of testing/reporting, location, and ordering physician.
Footers will include contact information for the site performing the testing and for the Chairperson, DLMP.
Body of the report will include:
Test results
Flags
Reference range
Order and result comments
Corrected/amended/appended results will be clearly marked, including any changes from the initial reports.
Documentation of Review:
Screenshots (electronic) or printout (paper formats) will be collated for one example of each test and reviewed by the Division/Section Heads and documented with a signature/stamp for each test result.
Upon acceptance by the Division/Section Head, a cover letter summarizing the acceptance will be signed, stamped, and dated.
The completed documentation will then be submitted to the Head, LIS for final review and approval.
Reference:
GEN.41077, Content/Format Report Review, CAP Checklist, Current Edition
The following is a sample report I prepared during my tenure at HMC Doha:
On the left-hand side of this composite PDF there are embedded attachments, which can be accessed by clicking on each one. In this document, I have shown a sample page from the actual screenshots generated. The data showing is a dummy test patient (no real patient data is exposed).
Note that our design of Medinfo did not include printing copies of reports. The only available reports were the screens. Staff outside Transfusion Medicine viewed the blood bank reports through a separate database viewer. In the example below, the Medinfo screen appears first followed by the EMR Viewer report.
In any case with nonspecific antibodies and for all new patients who will require chronic transfusions, I perform extended Rh (CcEe)/Kell and the three Diamed (now Biorad) profile cards.
It is very easy in Medinfo to write a process for any group of antigen typings as long as you know the manufacturer’s criteria for accepting results. Some cards have controls, others do not. In the latter case, the “control” is a negative reaction in the card or series of cards of the same type.
In Medinfo, one can also look for errors in using the card: In Profile Card 3, i.e. the MNSsFyaFyb card, one must reject the card if no reactions in any well appear: Did the technologist forget to add the cells or reagents? Did he/she use the wrong diluent (i.e. bromelin enzyme) which would destroy the labile antigens?
One can set the acceptable range of reactivity, flag for mixed field, etc. and record these findings in the official record. One can define which reactions you will accept an automatic reading of the card. For the other readings, one can force a manual review and result entry.
Note that Profile Cards 1 and 2 both have an internal control whereas Profile Card 3 (enzyme-labile antigens) does not.
Here are the processes for all three profile cards:
Immediate-spin crossmatch ISXM is an abbreviated compatibility testing that detects most ABO incompatibility. AABB Standards restricts its use to specific situations as indicated in the Policy section below.
Policy:
Applicability:
ISXM may only be used when ALL of the following conditions are met:
Negative antibody screen
No history of antibodies
No ABO/D antigen typing discrepancies
Less than two (2) ABO/D determinations are on-file.
Use the computer/electronic crossmatch whenever its specific criteria are met.
Testing:
ISXM consists of reacting an RBC suspension with patient/serum or plasma, centrifuging, and immediately reading for agglutination or hemolysis. THERE IS NO INCUBATION STEP, NO USE OF ANTIHUMAN GLOBULIN AHG REAGENT.
If any hemolysis or agglutination is detected, the crossmatch is incompatible:
Repeat the ISXM.
Repeat the patient ABO/D AND unit ABO/D typings.
Repeat the antibody screen.
Perform full AHG crossmatch AND AHG/enzyme antibody panels.
Refer the case to senior technical staff or a Transfusion Medicine consultant for further instructions.
Case review will be documented in Medinfo HIIG computer system.
DO NOT RELEASE THE RBCS UNTIL SO INSTRUCTED BY SENIOR STAFF.
References:
Technical Manual, Current Edition, AABB, Bethesda, MD, USA
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
The antiglobulin phase crossmatch is the same indirect antiglobulin test IAT used for antibody screening, only instead of reagent RBCs we use the donor’s RBCs. One question I like to ask my students is to describe the difference between the IAT and the antibody screen. Most don’t realize they are the same thing, the same procedure, i.e. mixing plasma/serum with RBCs and then detecting a reaction using the AHG reagen
In Medinfo, the AHG phase crossmatch will be required unless the criteria for electronic crossmatch have been met (see my previous post on this topic). In emergency mode, one can also do a class II release using immediate-spin to detect ABO incompatibility. Medinfo will check the historical records for previous antibodies.
Notice that the process includes contingencies for room and even lower temperature conditions as well as immediate-spin.
I warn my students that we can make any tube, gel or glass-bead well react if we do not strictly adhere to the manufacturer’s recommendations. The simplest example is to leave the reaction mixture to incubate longer than the time limit for LISS (e.g. 60 minutes).
If the antiglobulin phase crossmatch is positive (i.e. nonnegative reactions), then the unit is rejected or a least-incompatible crossmatch mode is activated. The latter requires the transfusion medicine physician to specifically approve the allocation and release of this component.
Dr. Zeyd Merenkov 