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. 

IHE 'Connectathon' 2011: A Preview of Challenges Facing EHR Compatibility

Every year in January, hundreds of engineers gather in Chicago at the Hyatt hotel with their medical devices and/or simulators on their laptops to test interoperability as specified by Integrating the Healthcare Enterprise (IHE) profile definitions. This year was the 12th annual event, and was somewhat larger than last year as there were 95 organizations testing 160 Systems with 350 engineers. It requires seven project managers who oversee more than 50 monitors, including myself, who validate the interoperability tests during the week. 

The week itself is pretty amazing, seeing rows and rows of computers with engineers frantically trying to make things work. The major advantage of participating, from a vendor perspective, is that it provides an opportunity to test a device and/or system against peer systems in a neutral environment. It is amazing that even though these systems are designed to meet rather well defined standards such as DICOM and HL7 and tightly specified profiles in the IHE definition, there are still a lot of details that can cause potential interoperability problems. Again, the good news is that all of this happens in a neutral environment rather than in front of a customer in a clinical environment. 

If one looks at the evolution of these events, it mirrors the transition that takes place in healthcare institutions. We struggled initially to connect medical devices in radiology to a PACS, then worked to facilitate the corresponding workflow over the next few years, followed by making sure images are displayed consistently and persistently, and meet specific modality requirements such as for nuclear medicine and digital mammography. 

Now we are at the point of integrating other departments and specialties and trying to exchange documents between labs, primary care physicians, specialists and healthcare providers using electronic health records. We even have standards for exchanging this information from a patient personal health record. 

As an illustration, I was testing a particular use whereby a patient would carry a flash drive containing his personal healthcare record to a physician, who enters vitals, and other observations and transmits that in the form of a medical summary note to a specialist. The specialist then sends back his observations to the physician, who stores all the information, including new medications and findings in the patient's personal health record. These transactions cross boundaries of five systems from different vendors using a data registry, repository and patient identification system of yet another vendor. 

Amazingly, it all worked, but as with so many standards, the devil is always in the details. To exchange information such as a ED report between a physician and a specialist is not that hard, but to make sure all these systems use the same document templates in exactly the same manner, and even more importantly, use the same vocabulary and codes is going to be a major challenge. It will take an enormous amount of testing and validation on a very detailed level to make sure that all the information is exchanged in the way it is intended. To illustrate the degree of difficulty, imagine exchanging data from one hospital using the ICD-9 coding to encode diagnosis, with another one using ICD-10, and yet another using a local extension. 

With regard to consistent terminology, we are just scratching the surface in radiology right now as we try to organize images on a viewing station from an imported patient CD in the same manner as the new exams, using a different study series and protocol descriptions. 

It was good to see the involvement during the testing of many PACS administrators as monitors for the IHE event. In my opinion this experience will be an invaluable resource as we tackle these interoperability problems. The issues will be very similar, albeit on a much larger scale, as we begin to develop interaction between personal health systems, multiple institutions and local and federal health care entities, all providing directory and patient identification services. 

Another area to watch is Canada as they organize their healthcare management and storage systems on a province-wide (similar to state) basis. I was pleasantly surprised to find that they are already planning to implement some of the IHE documentation and imaging across enterprise profiles as early as this year. There are obviously many disadvantages of a federally organized healthcare system, but no one can deny that the implementation and sharing of images and documents is a major advantage, which can easily be achieved at this level. The same applies for the institutions of the US Veterans Affairs as they have implemented the most comprehensive electronic health record in their 170 hospitals and more than 1,000 clinics and nursing homes. They have documented billions of dollars of savings through the use of this technology. 

Overall, the IHE "Connectathon" provided a good picture of what is coming: an environment whereby healthcare IT standards and profiles provide an excellent framework to integrate multiple systems from many vendors to achieve higher efficiency and better patient care. The complexity of integrating these far exceeds what we have done to date, as we need to go beyond radiology to other specialties and outside institutions. It will be quite a challenge, but by drawing on our experience with integrating imaging and facilitating workflow, we should be able to meet this challenge.