Tuesday, February 1, 2011

Tips from a road warrior (3): Sometimes you have to use a Band-aid

I was about to travel to a conference, waiting for the plane to take off from Dallas when the flight attendant noticed that someone apparently had jammed the latch of the overhead bin about three rows in front of me. It would not close and apparently that is a FAA violation preventing our plane from taking off. Over the next forty minutes, an interesting pattern developed: First a mechanic showed up, and after a few minutes of fiddling with the latch, determined he could not easily fix it. He left and ten minutes later returned with a colleague, who tried for about five minutes. Defeated, they both left. Nothing happened for another ten or so minutes until the first two mechanics returned with their supervisor. 

By this time, we were about 20 minutes late and people were starting to get worried about their connections. He looked at it, tried all of the same things the first two tried and then they all disappeared. Finally, after another five minutes, the first mechanic showed up again with a big role of duct tape. He pushed down the bin cover and put several pieces of tape over it and we were ready to go after a 40-minute delay. I will let the fact that it took several people and more than half an hour to figure out this solution speak for itself. Instead I will use the incident to illustrate the point that sometimes you just need to apply a temporary Band-aid. 

We face the same situation many times in performing a support role as well. Working for a vendor, we sometimes had to perform an emergency software patch to resolve a particular issue. Often we would not know exactly what the reason for the problem was as it was not easily reproducible, especially at the manufacturing site. As a result, we would implement a quick fix or workaround to get the customer back to work. 

I had to make this decision several times as a software project manager for PACS systems. These quick fixes were especially important if the problem had the potential to impact patient care. An example of such a critical error would be the distance measurement on a viewing application giving an incorrect number, or a Left/Right marker might be positioned on the wrong side. While a quick patch might fix the immediate problem, good practice requires a full investigation to find and fix the root cause, preferably with the next major release. If this is not done, you can imagine how the software would look after several of these quick fixes have been applied. Among developers we call this "spaghetti code," which I have seen in several software products, even in medical applications. This can be a serious problem especially if the vendor does not follow standard quality policies and procedures. 

Similarly on the provider side, it might be easy to fix a study so that it appears on a work list for a radiologist by applying a short-cut correction. But one needs to follow up and clean up the code afterwards so that it doesn't happen again. For example making sure that the accession number really matches the order, names are properly identified in a unique manner, and the HIS, RIS and PACS are all in sync with regard to identifiers. All broken links should be mended. If an image identifier is changed, all references to that image, such as presentation states, key images, measurements and structured reports should be updated as well. Identifiers such as UID’s should not just be modified by adding a “1” at the end, which is commonly done, but by being reassigned a true unique identifier. Failure to do so might not be readily visible, but you can bet it will surface when an archive/database needs to be migrated. At migration time, it becomes very obvious how good the support staff has been during the life of the PACS as “orphan” images and unmatched orders surface. I have seen institutions that were migrating the data with an error rate of up to 5 percent of their studies. Similar to the development side, strictly following policies and procedures and cleaning up after a quick Band-aid fixes will definitely increase data integrity of an imaging system back-end. 

In conclusion, sometimes a Band-aid in the form of a piece of duct tape or quick software or database patch is necessary, but it is critical to follow up with a permanent fix, otherwise it could develop into a major problem jeopardizing the integrity of your system. Or in the case of the airline, the same plane full of passengers will be sitting at another airport for 40 minutes while three different mechanics repeat the same routine.