Friday, July 1, 2011

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. 

No comments:

Post a Comment