Processes and Software Building 2: Documenting Processes

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