Tag: Medinfo Hematos IIG

Donor, patient, interdepot transfer, interfaces

My Experience with Medinfo Hematos IIG Software for Patients and Donors

drzeyd

HMC Doha 2011-2020:  Set-up of both donor and patient modules including inter-depot transfer:

Donor:

Implemented COVID-19 convalescent plasma CCP production at HMC Doha over two-week period, February-March, 2020 including full integration with software

Donor collection, donor marker testing, donor immunohematology testing, inter-depot transfer between production site and hospitals and hospital-hospital transfers, ISBT labelling and specimen

Collection Interface (read-only) with Qatar Ministry of Interior to obtain both English and Arabic demographic information from donors

Establishing world’s first interfaces (bidirectional as required) with Terumo BCT Atreus and Reveos automated blood processing equipment, Mirasol pathogen-inactivation/platelet additive solution, Terumo Trima Accel donor apheresis machine, Terumo mixer-shaker donor collection device

Patient:

Implemented a CCP quarantine patient blood bank separate from regular hospital blood banks) for thawing and releasing of CCP plasma

Patient module including all compatibility testing, ABO/D typing, extended antigen typings, direct and indirect antiglobulin testing (antibody screens), antibody identifications, eluate, component modifications (thawing, pooling, aliquoting), interfacing of Diamed automated gel testing

Establishing algorithms for emergency release, electronic crossmatching, automated patient specimen titration with Ortho Vision MAX, prophylactic antigen matching, ensuring irradiation of blood components or use of pathogen-inactivation as required, allocation rules by algorithm, required and optional antigen matching in presence of antibodies

Development of bidirectional interface between Medinfo patient module and Cerner Millennium laboratory module (permitting order of transfusion tests and blood component orders in Cerner, transmission to Medinfo patient module for testing and allocation of components, and then sending test results and component status back to Cerner)

Common:

Developing current and future states to develop the workflows to prepare software processes

Validation testing, initial/user acceptance testing, follow-up validations

NGHA Riyadh 2009-2010:  Set up of both donor and patient modules including inter-depot transfer:

Donor:

Collection, marker testing, immunohematology testing, component production, inter-depot transfer between production site and hospitals and hospital-hospital transfers, ISBT labelling and specimens

Patient:

Patient module including all compatibility testing, ABO/D typing, extended antigen typings, direct and indirect antiglobulin testing (antibody screens), antibody identifications, eluate, component modifications (thawing, pooling, aliquoting), interfacing of Diamed automated gel testing

Please refer to my website https://drzeydbloodbank.com for specific posts on Medinfo software process building.  On the right hand side from the bottom TAGS menu, pick Medinfo Hematos IIG to see those articles.

Processes and Software Building 31: HTLV Donor Testing

drzeyd

As I designed in Medinfo, this is a much simpler algorithm than HCV and uses an HTLV-1/HTLV-2 screening test and a confirmatory linear immunoblot assay LIA that can discriminate between type 1 and type 2.  If there is an indeterminate result, a repeat test is ordered after 6 months:

  1. HTLV 1/2 Testing:
    1. HTLV Antibodies positive, then do HTLV-InnoLIA:
      1. HTLV InnoLIA positive for HTLV-1 and/or HTLV-2:  refer to Infectious Disease clinic
      2. HTLV InnoLIA indeterminate or negative, repeat HTLV Ab and HTLV InnoLIA testing after 6 months
    2. Repeat HTLV Testing After 6 Months:
      1. HTLV 1/2 antibodies positive, permanent deferral and do HTLV InnoLIA
      2. HTLV 1/2 antibodies indeterminate,  permanent deferral and do HTLV InnoLIA
      3. HTLV InnoLIA positive for HTLV-1 or HTLV-2: refer to Infectious Disease clinic
      4. HTLV InnoLIA indeterminate, donor permanently deferred.
        1. Issue letter HTLV-Not Confirmed
      5. HTLV 1/2 Ab negative and HTLV InnoLIA negative, reenter donor.

This is translated into the following Medinfo processes:

To Be Continued:

15/8/20

Processes and Software Building 30: Donor HCV Screening Tests

drzeyd

The testing algorithms may trigger additional testing, repeat of current testing at some future date, or permanent deferral.  One of the most complex processes is for HCV testing.  The following criteria are based on US FDA CBER guidelines, but are modified for the availability of test methodologies not licensed in the USA.

For HCV, we use the following testing in all donors:

  1. HCV antibody EIA
  2. HCV NAT
  3. If any of the tests are non-negative, then we do the HCV LIA immunoblot assay. 

HCV LIA is more sensitive than RIBA-3 (now no longer performed in the USA) but is not available in the USA.  This test has been incorporated into the testing algorithm from CBER:

  1. Hepatitis C:
    1. HCV-RNA positive confirmed, regardless of other HCV results:  permanent deferral, refer to Infectious Disease clinic
    2. HCV-RNA borderline:  repeat all HCV testing after 6 months
    3. HCV-InnoLIA positive, regardless of other HCV results:  permanent deferral, refer to Infectious Disease clinic
    4. HCV-InnoLIA indeterminate:  repeat all HCV testing after 6 months
    5. HCV-Ab positive, HCV-RNA negative, do HCV-InnoLIA:
      1. If HCV-InnoLIA positive, permanent deferral, refer to Infectious Disease clinic
      2. If HCV-InnoLIA indeterminate or negative, repeat all HCV testing after 6 months
    6. Repeat Hepatitis C Testing After 6 months:
      1. HCV-RNA or HCV-InnoLIA positive:  permanent deferral, refer to Infectious Disease clinic
      2. HCV-RNA or HCV-InnoLIA borderline:  permanent deferral, HCV infection not confirmed
      3. HCV-Ab positive or borderline without positive HCV-RNA or positive HCV-InnoLIA:  permanent deferral, HCV infection not confirmed
      4. HCV-Ab negative, HCV-RNA negative, HCV-InnoLIA negative:  reenter donor into donor pool

Note that indeterminate HCV results may be carried forward repeatedly by CBER rules but I decided to permanently defer the donor after 2 cycles of indeterminate results.  The donor must wait SIX MONTHS before the next round of testing.  Should he/she return before that time, those results may not be used for determining donor eligibility (unless the results have become clearly positive).

To Be Continued:

10/8/20

Processes and Software Building 29: Donor Marker Testing Overview

drzeyd

Donor marker testing algorithms are very complex and serve multiple objectives:

  1. Is the blood safe for the recipient, i.e. minimize likelihood of disease transmission?
  2. How do we to counsel the affected donor?  Does he need referral for treatment or follow-up?

Often the donor disposition is unclear based on a single encounter and a temporary deferral must be triggered so the current results may be compared to future ones, usually after 8 weeks, 6 months, or one year—depending on the pathogen in question.

Regretfully, the significance of reactions that do not meet the criteria for positivity may be unclear.  It is very difficult to explain to the donor that he has abnormal results and cannot donate but we as physicians do not know what their significance is.

Thus, the testing algorithms may trigger current additional testing, temporary deferral with repeat of testing at some future date, or permanent deferral.

At my previous positions, I started with the AABB/FDA CBER Uniform Donor Questionnaire UDQ and then modified it to include some advanced methodologies not available in the USA.

In the next series of posts I will elaborate on the processes developed for this for each marker.

To Be Continued

9/8/20

Processes and Software Building 28: Donor Questionnaire

drzeyd

Donor Collection 6

I started building this using the Uniform Donor Questionnaire UDQ from the AABB;  however, I modified it to include coverage for Chikungunya, Zika, etc. and to include enhanced processes for malaria based on the Australian Red Cross.

For each screening question, I prepared the exact wording (usually the UDQ’s) and set the deferral to temporary (how many days) or permanent.

Some questions were more open-ended, and the interviewer manually entered a medication, surgical procedure, etc.  The transfusion physician would review this and assign a temporary (specifying the interval) or permanent deferral.

The questionnaire was constantly being updated by changes.  My role was to review different accreditation systems (AABB, CE, etc.) and the World Health Organization’s websites.  I would then prepare an interim policy and pass the specifications for the changes to the Medinfo software engineer and when ready, finally to the Super Users for testing.  If there was an urgent change, the whole process could be completed in less than one day including validation testing.

The following shows examples of the software processes:

  1. Medications
  2. Body fluid exposures
  3. Vaccinations
  4. Malaria
  5. Ebola/Zika

I emphasize that all of these settings are user-definable (at least in jurisdictions that permit all open, non-turnkey software).

Medication Questions:

Vaccinations:


Blood and Body Fluid Exposures:

Malaria Example:  DMAL refers to the malaria antibody test.


Ebola and Zika Examples:

7/8/20

Processes and Software Building 27 Donor Center 5

drzeyd

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.

To Be Continued

5/8/20

Processes and Software Building 26: Donor Collection 4

drzeyd

Deferral Intervals for Each Donation Type

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.

To Be Continued:

3/8/20

Processes and Software Building 25–Donor Collection 3

drzeyd

Donation Type and Bag Parameters

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).

To Be Continued:

1/8/20

Processes and Software Building 24: Data Entry Verification

drzeyd

Principle:

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:

  1. Review by senior technical, supervisory, or transfusion medical staff:
    1. Designated test procedures require review by a second technologist before authorization.
    2. 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.
  2. Computer system HIIG rules:
    1. Privileges:
      1. System restricts which staff can perform specific tests
    2. Patient/donor identity:
      1. System asks end-users to verify patient/donor identity before starting any access to the patient/donor record.
      2. System performs historical database checking and flags any inconsistencies (e.g. historical ABO/D typing differences, etc.)
    3. Testing:
      1. Only selected staff have privileges to authorize or purge.
      2. ABO/D testing algorithms require entry of reactions, not interpretation of results and are compared to a truth table.
        1. Aberrant results require special review before ABO/D typing results can be authorized/purged.
        2. D-controls must be negative to allow D typing results to be authorized for liquid D-typing reagents.
      3. DAT results require appropriate controls to meet truth-table criteria.
      4. Eluates require last wash to be negative before authorization
    4. Blood components:
      1. Selection of RBC or plasma units requires two independent sample determinations within 72 hours of each other.
      2. ABO-incompatible RBC or FFP/FP24 transfusions are not allowed.
      3. Donors with any detectable antibodies are permanently deferred.
      4. Depending on the patient’s antibody history, release of RBC units may require antigen-matched units.  Examples:
        1. 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
        2. Priority matching (incompatible or untested can be approved by a transfusion medicine physician):  C,E, e, Fya, Fyb, M, S, s
        3. Antigen matching not required:  Lea, Leb, N
      5. Least-incompatible crossmatch require special authorization to release
      6. Protocols to force irradiation or other modified components can be setup in HIIG.
    5. Donors:
      1. Donor tests have same criteria as the same test used in patient testing for controls, etc.
      2. Donor demographics are read directly from the Ministry of Interior database—no manual entry (bar code only used).

References:

  1. Workflows for Hematos IIG (1001 through 1005), 2013
  2. Standards for Blood Banks and Transfusion Services, 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

Processes and Software Building 23: Donor Collection 2

drzeyd

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:

  1. Registration process in multiple languages
  2. Donor deferral database
  3. Donor consent with generated unique ISBT specimen number
  4. 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).

To Be Continued:

30/7/20