Tag: Processes and Software Building

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

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.

Process Donor Medical Questionnaire

drzeyd

5.2.1 PROCESS:  DONOR QUESTIONNAIRE

Process:

  1. Donor passes donor deferral database screening.
  2. Donor is taken to a private area for the interview.
  3. The donor is positively identified by a designated picture ID and Hematos donor consent form with specimen/encounter number and barcode.
  4. Donor is asked ALL questions by trained Donor Center staff using the Medinfo Hematos IIG questionnaire.
  5. Hematos IIG determines if any contraindications apply.
  6. Donor responses are reviewed by the transfusion medicine physician as indicated in the questionnaire.
  7. Donors without contraindication are sent for donor physical examination.
  8. Donors passing transfusion medicine physician review are sent for donor physicial examination.

References:

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

Policy Donor Medical Questionnaire

drzeyd

Policy Donor Medical Questionnaire

5.2 POLICY:  DONOR MEDICAL QUESTIONNAIRE

Policy:

  1. All policies, processes, and procedures must comply with local, national, 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 software 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.
  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 Specifications, Version 1.5, Hematos IIG, Medinfo, Nice France
  2. Standards for Blood Banks and Transfusion Services, Current Edition, AABB, Bethesda, Maryland, USA

Processes and Software Building 4: Super Users

drzeyd

Super-Users:  Engaging Laboratory Staff in Computer Operations

This is an update of a previous post.

It is critical to engage the technical, medical , and (blood bank) nursing staff in this process,  That is why it is so important to identify a core of computer-literate users to help with the building and testing/validation.

I don’t mean finding staff who can already program or code.  Rather, I mean staff that are astute with knowing their work processes and who had good skills with Microsoft Office and Windows or equivalent.  I did not expect them to understand database structure or use structured query language.  They were chosen for their ability to learn quickly and their meticulousness.

For our blood bank system, I chose computer-literate technical staff to be involved in the build from the very beginning.  They learned how to test each module and to some degree support it.  These became my Super-Users and to this day support the system for many tasks.  These staff served as the system administrators and worked directly with me as the Division Head for Laboratory Information Systems.  They were not full-time and still had their other clinical/technical duties.  They liaised with the software vendors engineers.

Our blood bank system was NOT a turnkey system.  It was custom designed according to our workflows.  There were NO default settings!!  We had to be remember, ‘Be careful what you ask for, you might get it!’  In some countries, approved systems are turnkey and may allow only few changes to the core structure and thus may not be this optimized for the needed workflow;  often only cosmetic changes are permitted.

When we built our first dedicated blood bank computer system, the company would take a module and completely map out the current processes collaboratively with me.  After this, I analyzed the critical control points and started to map out the improved computer processes that would take over.  After that we would build that those processes in the software and test it.  If it failed, we would correct it and test again…and again if necessary.  Fortunately, the blood bank vendor did not charge us when we made mistakes.

Sadly, another vendor (non-blood bank), only gave limited opportunities to make settings.  If wrong, there might be additional charges to make corrections.  This other vendor really pushed the client to accept the default settings regardless whether or not they actually fit.  End-users were selected to make and approve the settings, but they were only minimally trained on how to make the settings.  It was a journey of the end-users being led to the slaughter—and being blamed for their settings when they accepted the vendor’s recommendations—they usually selected the defaults.  There wasn’t enough time for trial and error and correction.

The blood bank system Super Users were an important part of our process.  They were an integral part of the implement team and could propose workflows, changes, etc.—subject to my approval.  They learned the system from the start and developed invaluable skills that allowed them to support the system after the build.  Also, they could serve to validate the system according to the protocols I prepared.  Moreover, I took responsibilities for their activities and they were not left out to hang.

Every hospital blood bank location and the blood donor center had Super-Users.  These included:

  1. Blood Donor Center:
    1. Administrative Clerk for donor registration, consent, ISBT specimen labels, creation of new donors and patients for validation purposes
    1. Apheresis/Donor Nurse for donor questionnaire, donor physical examination, and donor collection
    1. Medical technologist for donor marker testing
    1. Medical technologists for blood component production including Reveos, Mirasol, platelet additive solution, pooling, and leukodepletion
    1. Medical technologist for donor immunohematology testing
    1. Medical technologist for inter-depot transfer of blood components
  2. Hospital Blood Banks and Transfusion Centers:
    1. At least one technologist at each site for inter-depot transfer, component medication (washing, irradiating, aliquoting, reconstituted whole blood), immunohematology testing, component allocation and release

The cost of using these staff?  They were paid overtime and were relieved of other duties when working on Super User duties.  This was much cheaper than hiring outside consultants who may or may not know our system well enough to perform these tasks.

By having a Super User at each site, I in effect had an immediate local contact person for troubleshooting problems who could work with the technical/nursing staff.  We did not rely on the corporate IT department for support and worked directly with the software vendor.  Response time was excellent this way.

The following document is a sample document of the assigned Super User duties during a validation.

Donor Registration Process

drzeyd

5.1.1 PROCESS:  Donor Registration

Process:

  1. Donor presents acceptable picture ID with a unique alphanumeric identifier.
  2. Donors without Qatari ID must be approved by the Coordinator, Donor Recruitment, a donor center physician, or Head, Transfusion Medicine.
  3. Donor ID is scanned into Hematos IIG.
  4. Donor is assigned Hematos IIG Donor ID if not already in the system.
    1. Donors with previous ID will be given a Hematos ID
    1. All donors are registered only using the Hematos ID
  5. Medinfo Hematos IIG software checks donor deferral database
  6. Donor is accepted for medical questionnaire only if he has no contraindications.

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

Donor Recruitment and Campaigns Process

drzeyd

5.0.1 PROCESS:  Donor Recruitment and Campaigns

Process:

  1. Company or organization contacts Coordinator, Donor Recruitment to schedule donation OR:
  2. Coordinator, Donor Recruitment contacts companies or organizations to schedule donations.
  3. The Coordinator, Donor Affairs, is responsible for all recruitment activities:
    1. Serves as initial contact point for organizations and companies desiring to have a donor campaign.
    2. Schedules donor campaigns in advance, arranges for emergency collections as needed.
    3. Assigns donor recruitment staff to visit and inspect prospective donation sites.
    4. Arranges logistics of resources for donor campaigns (personnel, equipment, vehicles, supplies)
    5. Coordinates with HMC Public Relations and the media
    6. Prepares news media to encourage donation
  4. All contacts and schedules are entered into Hematos IIG.
  5. Donor recruitment materials are left at donation site to encourage donation and provide means for donors to schedule their donations during the campaign.
  6. Donor recruitment staff prepare the donation site at time of donation.
  7. Donation processes are conducted in accordance to policies, processes, and procedures for registration, donor questionnaire, physical examination, and collection.
  8. Hematos IIG is accessed by either wireless connection (VPN) or off-line data dump to check donor against donor deferral database.
  9. Blood is stored at suitable temperatures at collection site and in transit back to Donor Center.
  10. Campaign blood components and specimens are received in Donor Center and transferred for further processing and testing.

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