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
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. 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 (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 we could perform registration and donor questionnaire tasks in multiple languages, and preferable the native language of the donor. We could even prepare database reports in Arabic.
Medinfo had an elegant solution to the registration process. It read the local identity card issued by the Ministry of Interior and accessed (read-only) the demographic data on that donor. Just by reading the bar code one received both 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.
Donor Deferral Database:
Medinfo imported donor data from a previous 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:
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.
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: