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
   2. Apheresis/Donor Nurse for donor questionnaire, donor physical examination, and donor collection
   3. Medical technologist for donor marker testing
   4. Medical technologists for blood component production including Reveos, Mirasol, platelet additive solution, pooling, and leukodepletion
   5. Medical technologist for donor immunohematology testing
   6. 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.

To Be Continued:

22/6/20

Processes and Software Building—Part Three

Using the current state to build a new work flow can be a difficult task and balancing act.  If one changes it too much, it may be difficult for the staff to cope.  If too little, then why bother at all?  Still, we had to take the time to analyze our current system and identify areas  of improvement.  When building a new computer system, we didn’t want to capture our current system with its flaws in concrete.  Buying a new system is costly and it would be very hard to change it again,  This had to be done right.

Also, whether or not you have a pre-existing software may affect your choices.  In my opinion, it is easier to learn something new than to make some changes to a system that everyone has already learned.  Learning is easier than unlearning and relearning.

First, I studied the new system’s capabilities and took note of the features I would like to adopt to improve the current processes.  I did this especially at the critical control points.  I also studied our incident reports:  where had there been nonconformances?  How could I change things for the better, i.e. with increased safety and compliance to international standards?

I did not want to throw out a successful manual system, just to optimize it.  I tried to pick out those manual processes that worked and build those into the new workflows.  What I wanted was a system recognizable and familiar to the staff but with enhancements with the least amount of change to reach our goals. Make the least number of changes to meet the objectives!

Although the vendor did some initial testing, this was insufficient to accept the system.  I didn’t want the vendor to just show me some scenarios that they concocted.  I was always suspicious when any vendor chose their own examples and not others.  Could it be that the other processes did not work as desired?  I always insisted that I give the vendor representative scenarios and have them show me how the system reacted. This happened repeatedly with the non-blood bank software vendor so an atmosphere of distrust persisted throughout the general laboratory system (but not the blood bank) build.

It is daunting task to know what settings to make.  At one of my previous institutions, the administration recognized that they needed additional expertise from someone experienced in the new system.  They hired an outside firm in addition to the software vendor.  Still, even this was not sufficient to make the proper settings and testing.  We had to rely on ourselves!

Ultimately, the laboratory had to thoroughly test the system,  The only way to do this was to use our own resources.  Only we could test its actual functionality to the proper degree to ensure safety.  Still, where could we get the resources to do this?  Outside consultants were very expensive, especially if they have to live on-site for extended periods.  The only answer was to make use of our internal resources, i.e. our staff.

To be continued:

21/6/20

My previous post emphasized how important it is to map the current state across all processes as the first step to optimize current operations and prepare for a new computer system.

One non-blood bank (hospital LIS) software vendor submitted the following as a complete representation of all current processes—across more than 4,000 tests and hundreds of instruments:

1. Order something
2. Collect specimen
3. Receive specimen
4. Perform test
5. Report test

This was the same for each of the tests in the different sections of the laboratory—be it blood bank, anatomic pathology, chemistry, hematology, etc.  I was flabbergasted!  What were we paying for?

As Head of the Laboratory Information Systems, I rejected this.  I would have been ashamed to submit this to a client as a sufficient current state.  Even more astounding was the fact that that vendor actually mainly used the same four-step flow chart for the tests in their new computer build!!

As painful and time-consuming as it is, one must develop a specific flow for each process.  This could include:

1. Specimen condition and acceptability criteria
2. Possible results for each part of the test
3. Interpretation of each result
4. Control results
5. Acceptability criteria
6. Truth table
7. Reflex testing triggered by the results

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.  I did not want to throw out the successful manual system, just to optimize it.  After that we would build that those limited processes in the software and test it.  If it failed, we would correct it, and the vendor didn’t charge us extra for the corrections.  It was a beautiful collaboration.

To illustrate these points, I am showing two process flows:  one for the ABO typing (forward and reverse) for donors and the other a complex testing algorithm flow for HCV donor marker testing.  These are from previous builds and have been updated subsequently.

ABO Typing: Attachment One

This consisted of six individual tests forward (anti-A, anti-B, anti-A,B), two reverse (A1 cells and B cells) and a control.  The acceptable tests for automatic typing were in {0, 2, 3, 4}, other results (mixed field, weak, 1+, hemolysis) required a manual interpretation.  There is a truth table for interpretation of all six results together.

Donor HCV Testing:  Attachment Two

This is a more complicated flow that includes multiple tests (HCV-antibody EIA, HCV-LIA, and HCV-NAT).  Results may trigger reflex testing immediately (abnormal HCV EIA triggers HCV-LIA, abnormal HCV-NAT triggers HCV-LIA, etc.) or repeat testing after six months for indeterminate results.

In each case, every possible result is listed and its interpretation and acceptability criteria.

In summary, it may take considerable time to map out all your processes, but this is time well spent and allows you build your system accurately.  There will be few surprises this way.

To Be Continued:

20/6/20

In the next series of posts, I will elaborate on how I built the processes and settings for a blood bank computer system in conjunction with the vendor’s software engineers.

If you don’t know exactly what you are doing, how can you improve it?  Regardless whether you have laboratory software, you still need to optimize processes, determine critical control points, and plan improvements based on that.  A good manual system is the foundation for a good software build.

I was never taught in medical school how to do this.  I learned on-the-job at a time when software was quite rudimentary and mainly to record results.

Staffing:

For our first system, we used medical technologists to make settings for and administrate.  We thought that only those with a technical background in the field could do this.  It was moderately successful.  There was some antagonism between the technologist computer staff and the hospital computer department.  The technologists did not have a background in databases and programming;  the IT staff did not know the laboratory and were frustrated in dealing with the laboratory staff.

Later, to help reconciliate the two when a new hospital system was installed, we tried a different approach.  We found a database professional who was a very good listener.  Although he had no technical background, he could listen and map out the processes.  He was well-liked by the technologists who saw that he just wanted to understand their work and help them.  He was very successful in this endeavor.  I strongly recommend a software engineer as the lead in the project, one who can work with technical and medical staff to map out processes.

Unifying Processes Across Multiple Sites;

If your organization covers multiple sites, it is best to unify your processes as much as possible.  We built our dedicated blood bank system AFTER we had done this so the processes (except for some equipment differences) were the same everywhere.   This allowed us to move work between institutions quickly and makes system administration easy.

At one organization, they built the system based on the processes at the first site to go live, which was a small hospital with less than 10% of the work.  It was not designed for the high-volume sites, and this was major problem as the larger sites were implemented.

Capturing the Current State:

Most importantly, I cannot emphasize enough the need to capture the current state.  Take the time to do this properly and thoroughly.  This will help you whether or not you are building a computer system or just optimizing your manual processes.

At one institution in a non-blood bank system build, the administrative decision was to rush and not wait to complete this task so the actual processes were not captured—I actually rejected the proposed current state but was overruled.  The institution did not unify their processes as much as possible across sites.  The result was a suboptimal system that many/most people do not like:  should you blame the build or the limitations of the underlying software?

To be continued:

19/6/19