In a 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. This also applies to other laboratory software.
If you don’t know exactly what you are doing, how can you improve it? Regardless whether you currently 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.
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 blood bank 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, I worked at, they had not done this. They built their system based on the processes at the first site to go live, which was a small hospital with less than 10% of the workload. 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? In my opinion, you can’t fully blame the software itself, if you didn’t design your build properly.