Friday, July 1, 2011

Tips from a Road Warrior (13): Plan Your Retirement

The airlines have a very nice way of retiring their pilots. I once witnessed the last flight of a senior pilot, which was an interesting experience. First of all, they treated it like a celebration, his spouse was included and given a special seat in first or business class, and was given a big bouquet of flowers upon boarding. Second, upon landing the plane gets a "wet" greeting by the airport fire brigade as it taxied through a spray from water hoses, which for passengers is similar to the spray when the plane is being de-iced. The co-pilot told us ahead of time what to expect to keep people from becoming anxious when they saw the fire engines roll up beside the plane. 

When planning the retirement of a healthcare IT system, it also should be treated as a time for celebration, while recognizing the need to alert users to the potential struggles that such a transition involves, especially if the new system comes from a different vendor. Transitioning means in many cases migrating data, in almost all cases a vast retraining effort, and a new support staff. Such change typically triggers apprehension, but when people know what to expect, the anxiety level is reduced. 

In many cases new systems impact productivity as well. People who have implemented an EMR have told me it took them three months to get to the same level of productivity as before implementing the system. Many make the mistake of switching without accommodating the workload, i.e. they expect to be able to treat the same number of patients as they did prior to the switch. Prudent IT managers try to ease the transition by either cutting production in half the first few days or by doubling the amount of support resources. 

Planning for the retirement of a healthcare IT system should actually start when a new one is being purchased. Agreements about support during the retirement process should be negotiated into the contract. There should be clear expectations about the amount of support needed during the retirement process, which will help both the service provider and the user. Frustrations arise on both sides when expectations are not spelled out, for example, service providers can be surprised when they are converted to a month-by-month support agreement, and users can be frustrated to learn that continuing support during the transition phase wasn't included in the budget. 

It is also important to have a disposal plan for the physical hardware. Everyone has probably seen obsolete computers stacked up in a basement closet. A well-known study by a professor from MIT who had his students buy computers from various used sources, found literally thousands of credit card numbers, pharmacy records and other private information on these systems. The US federal HIPAA regulation specifies that old hardware be disposed of in a manner that preserves the privacy and security of the information stored on these systems. In my city, there is a “computer crusher” that takes the hard drives and physically destroys them to prevent any possibility of data recovery later on. 

One should also make sure that a retention policy is defined, i.e. when information and devices should be retired or eliminated, and that retention is possible from a technical perspective. Many systems build in redundancy to make sure information never gets lost, and are not designed to purge information, especially if it is part of a database or archive. Many systems, especially archive systems, delete a record by a flag in a database, which does not erase the actual data on an archive. Consequently, if the information on the old system is migrated to the new, deleted information often reappears. 

In conclusion, one should plan for the retirement for a system when it is being purchased to ensure it can be done gracefully, and one should consider doing it like the airlines do with their pilots, i.e. make it a celebration for the new to come in and let go of the old. 

VHR Lessons Learned for PHR/EHR Implementations

It seems that every time we vacation with our dogs, we end up at a veterinarian as they contract some disease or injury. In any case, we get to know different veterinarians, in this case somewhere in Colorado. We needed a vet and found one using a Veterinarian Health Record (VHR). This recent visit taught some lessons that we might apply as we begin to roll out Personal and Electronic Health Records (PHR/EHR). First of all, I was initially impressed with the nice data entry screen with graphics to identify the information needed; however, I found that it was not as easy and smooth as expected.

In general, when registering a patient, there is an issue with unique identification, i.e. is this person the same patient for which a record already exists in the system? If the system is connected to another patient domain, what is the patient identifier to be used for query? The veterinarian world is relatively easy, as increasingly our pets are getting RFID chips, which are about the size of a grain of rice and implanted under the skin. The purpose of this chip was initially to identify lost pets, but it is also a great tool for medical records identification. Farmers and ranchers have used RFID tags on animal ears for years to identify individual animals among large herds. The DICOM standard extensions for veterinary applications actually have added a special data attribute to include this information with images. 

Unfortunately, there is no US national registry; each manufacturer, distributor, or provider keeps the information. That is why our pets are not "chipped," as we tend to use different providers as we travel with them. 

I don't think it is realistic to expect that human patients would be willing to be “chipped,” however, even if in theory this could happen, it would still require a national registry to prevent duplicates and ensure that each person is uniquely identified. In addition, there are security and privacy concerns that prevent a universal patient ID to be issued and/or used in the US (unlike many other countries), therefore we need to implement rather sophisticated patient registries defined by IHE (Integrating the Healthcare Enterprise) to allow local ID registration that can also be reconciled with multiple ID registries. However, one would suspect that there are no such security and privacy concerns with pets, and therefore hopefully there might come a day when we see a unified pet registry in place. 

Another lesson learned has to do with the data entry for our pet in the electronic record. My guess is that the time it took to enter the information about the primary complaints, and observations, was more than was actually spent with the “patient.” Even though the technician was a very efficient typist, she had to use many different screens and had to do a lot of free text data entry. When I see demos of EHR systems by vendor representatives at tradeshows such as the HIMSS, it appears to go very fast and efficient, however in practice, it is a different story. 

As I watched the data entry for our dog, it occurred to me that it would be really nice to have speech recognition technology or at least templates, macros or other time-saving methods. As a matter of fact, I estimate that this visit took twice as long as with our home veterinarian, who merely scribbles her notes in the patient jacket. Of course, that paper information is not available to other vets, but there is definitely a time trade-off. 

With regard to entering the diagnosis, another issue emerged. While there were no doubt hundreds, if not more, potential diagnoses preprogrammed into the system, the diagnosis for our dog was apparently not foreseen by the system developers. Not that it seemed to me to be an obscure disease, it just did not fit into any of the many available categories. After trying many different searches, the vet gave up; there is apparently no “free text” entry in this particular system. She commented that the system was definitely developed by engineers who had not taken into account the true requirements of healthcare providers. 

I understand the developer’s predicament, especially if we would want to improve our healthcare system for humans, we need to make sure we can categorize diagnoses and therefore measure and potentially influence the efficiency of the healthcare delivery. However, it might not always be possible to define a black-white definition of a given diagnosis that fits an existing code system or text. The danger of course is that by allowing free data entry, physicians may misuse it and not use the standard diagnosis when it is an easy case. However, I would argue that if it is easier to enter the preprogrammed codes than entering additional text, a physician will not misuse the system. 

In conclusion, this experience taught me several lessons with regard to patient identification, ease of use for data entry, and use of preprogrammed templates that I hope that some of the developers of EHR systems will take as valuable input.