Tuesday, March 1, 2011

Tips from a road warrior (6): Always know how to get back to where you started

The reason that conference organizers often pick nice locations such as Hawaii, Vegas, Athens, or, even on board of a cruise ship, is not only to attract more attendees, but also speakers such as myself who are willing to "sacrifice" their time for a modest speaking fee and travel reimbursement. I have to admit that I occasionally fall for that enticement, which is why I ended up in Athens about two years ago. 

I had taken the bus to the Parthenon from my hotel and after a couple of hours sightseeing, I hailed a taxi to take me back to my hotel to pick up my luggage on the way to the airport to continue my trip. As is common in many countries, taxi drivers often speak only their native language. Not having opted for Greek in high school, I simply told him “Sheraton” hotel, and off we went. After about half an hour of driving, I started getting nervous, as it had only taken 20 minutes on my trip from downtown. I then told the driver the part of town where the hotel was located, but that did not really help him or me. 

After several more minutes of fruitless communication, I was desperate enough to consider calling my spouse back home in the USA to see if she could find in my records the address of the hotel. However, it was unlikely that I would be able to get a hold of anyone due to the time difference, as it was about 3 a.m. in Texas. As my flight departure time approached, I finally recognized the road we were driving and was able to point the driver in the right direction to the hotel. The fact that the hotel had been recently acquired and renamed was apparently a major part of the confusion. Another lesson learned: always know where you came from, and, as a hint, take a business card from the hotel printed in the native language with you. 

When upgrading a system it is also critical to document the departure location and configuration, as it often is required in order to return. One very well run institution in Dallas has as a golden rule that no single upgrade or change is made, unless there is a well-documented “road back”. They have had to use the rule several times. I use it myself as well, as a matter of fact; all of our laptops that we use in our hands-on training have a “roll-back” disk image so that I don't need to worry about students messing up the computer. We simply roll the computer back to the original image at the end of each class, which takes only one simple command. 

I have heard about several other “roll-backs”, for example, at one site a PACS viewing system upgrade was installed over the weekend. Unfortunately, the upgrade was poorly prepared from a user training perspective. On Monday morning, the radiologists had to figure out how to navigate new toolbars and menus and were at a total loss. After two hours of complaints the IT department was forced to reverse the upgrade by noon. In another case, a site had rolled out a Microsoft security upgrade to its Windows browser, which broke the viewing application. The CIO had weighed the risk of installing the upgrade, which was not yet approved by the imaging vendor, against the increasing risk of being infected by a virus that was making use of a newly discovered security gap. However, the upgrade had to be rolled back immediately due to an incompatibility issue. In many cases, the upgrade introduces problems that cause unacceptable patient risks from a clinical perspective. This can happen with any system, even, or maybe especially with systems from the top five vendors. I have seen incorrect Left/Right markers appear on the images with a software upgrade, incorrect measurements resulting from different and incorrect image header attributes for calculation, and patient studies stored on CD’s as separate studies instead of a single one. 

One of the mechanisms to limit the risk of an upgrade is to use it first in a test environment. This will eliminate many of the potential issues, however, based on a recent poll through our OTech newsletter, I learned that the majority of the existing installations do not have a fully functional test system in place, in which case this is not an option. Although I must say that many institutions have learned the need for a test environment and are more frequently specifying them in RFP’s. However, even when tested, often it is hard to predict all possible effects. In addition, one cannot always completely simulate the real environment, especially when it involves upgrading imaging modalities, one could argue that it is not feasible to have another million-dollar device around just for the purpose of testing. 

My lesson learned from this travel experience is that I now trace where I came from so I can get back to my starting point. An analogue lesson learned for health care imaging and IT professionals is that they should always be able to get back to where they started in case any changes and/or upgrades end up taking their systems in the wrong direction.