EHR Implementation Update at 6 months

Surprisingly, it has already been 6 months since an enterprise EHR was implemented at the hospital where I work. Things should be going smoothly by now, right? I truly wish I could say that were the case. It may be an understatement to say that the EHR project has hit a few speed bumps. I hear that just a few weeks ago the medical executive committee considered a motion to turn off the EHR for 6 months while it is re-engineered to meet the demands of local practice and function in a more user friendly fashion. That must have been a really scary moment for administrators present at the meeting. I never imagined that a recapitulation of what happened at Cedars Sinai years ago would happen in Yuma. Instead of turning the system off, the decision was made to hire more consultants and IT staff to speed the "optimization" of the system. But I assert that the response of medical staff members was totally predictable.

Optimization is the process whereby the EHR is modified after go-live to correct unanticipated user issues. Above, I mentioned that user outcry was predictable. What did I mean? Adoption of an EHR goes through a well-known life cycle that has been validated by years of experience. First, the institution determines its EHR requirements and (often) produces a RFP (request for proposal) to be submitted to a battery of EHR vendors. Then a multidisciplinary committee sifts through the responses, selects a small group of finalists, makes site visits to hospitals where vendor products have been implemented, performs other due diligence activities and makes a final vendor selection. The next step is contracting for the software license and, often, vendor implementation support. Here, the hospital should take legally binding steps to protect its multimillion dollar investment. Once an agreeable contract is reached, the next steps are to refine local user requirements, perform work-flow analysis, set up governance structures to help manage the EHR, and begin implementation of change management strategies. Then the real fun begins.

Design and build of the software is carried out by local and vendor-provided IT staff based on data collected in previous steps. Testing of the software build in a simulated working environment is essential to verify interface function, safety of the build, stability and performance of IT infrastructure, and generally to make sure that everything works as designed. Everyone who will use the EHR must receive general and specialized training before go-live. Go-live is always a high stress time but really should go smoothly if all the preceding steps were done properly. Finally, optimization is really just part of the maintenance that all IT systems require after they are introduced. So where did the processes at my hospital go wrong?

First, I believe that the selection process was as good as it could have been. The selection that was made was the best that was available at the time. I think that many of those involved in the selection process now feel that we did not get the system or design support that we expected, however. I wasn't privy to the specifications and protections for the hospital built into the contract. Certainly, the investment required in post-implementation support is much greater than the administration expected. I hope the hospital was protected by an appropriate service level agreement.

I am disappointed that more user input specific to our local routines and workflow patterns was not incorporated by the design team. My impression has been that the design team did not do their homework. Governance structure for the EHR is still evolving. Even now, it is not designed to efficiently manage user feedback. The CMIO was almost the last IT staff member hired, a year after other major hires. There was little time to build a sense of team membership/ownership. Everything I have ever read has emphasized the importance of physician involvement from the earliest stages of EHR implementation. I think many of the current problems could have been mitigated had a qualified CMIO participated from the start. I made this point to medical staff leaders and administration members during the selection process; the consequences were predictable; and outcome could have been avoided. Communications have been poorly managed. It is hard to know if or when a help desk ticket has been acted upon and what the outcome is. There is no system of publishing institution wide lessons learned with the EHR. A few notes have been posted in physician's lounges and in mini-pamphlets of "tips and tricks." I would have liked to see ticket request information posted on the private intranet of the hospital. I would also have liked to have lessons learned posted to the intranet along with an index to help find information of concern. Finally, I cannot determine if we selected an unsatisfactory system. It does seem to have many inherent deficiencies but some of these may be design and build related. The next few months of EHR IT department work will see optimization steps that will seriously revisit the previous design and build activity, incorporating our nascent governance input. Hopefully, the future EHR will more closely fulfill the needs for functionality and usability our medical staff members demand.

Clinical Documentation Challenges

One of the most difficult tasks for EHR software is to capture clinical documentation. For many EHR implementers this is one of the last functions to be "turned on." There is a tremendous diversity in the breadth and depth of clinical notes. This is an area where "one size fits all" solutions usually do not apply. An advantage of EHR adoption purportedly has been reduction in transcription costs. This is achieved by clinical documentation software that eliminates the need for dictation and manual transcription. Often this accomplished through use of templates. Check boxes are filled in by the provider and then the narrative text representing the clinical note is generated by computer to provide a traditional-appearing note. Another method is the use of voice recognition software that in real-time converts voice to written text. As usual, I will relate my own experiences and thoughts:

Templates: I work with another surgeon who does mostly one type of operation over and over. He has a very standardized method with few variations. Previously, he dictated an operative report for each case. This task took at least several minutes of his time. That does no account for the time and expense of transcribing his dictations. I was able to create a template that accommodated almost all of his variations. There was one blank that required free text (the name of the anesthesiologist), two drop-down lists, and 5 fields that need to be completed with a typed number for the size of implants used. The surgeon is now able to complete an accurate operative with the template in about a minute. There is no doubt that this is a more efficient way for him to create his operative reports. In my experience templates work well for generally simple clinical documents where there are a limited number of possible variations.

On the other hand, templates do not work so well for me. I think it is hard to capture the nuances that are so important to recognize and report in clinical medicine. The majority of my surgical practice is individually tailored to each patient. The multiple types of conditions that I see and the complexity of co-morbidities make template-based documentation impractical. The types of procedures I perform are numerous and cannot be distilled down to simple templates. I need a tool like to dictation to complete operative reports for the surgeries I perform and the preparation of clinic notes for the outpatients that I evaluate.

Voice to text. My hospital eliminated most of the transcription department when the EHR went live in May. Dictation is still permitted but transcription has been scheduled to be eliminated by January 2013. Transcribed dictations follow a different work-flow than notes entered directly into the EHR because they must be scanned. The hospital administration decided to license voice recognition software for use by clinicians to assist in their documentation. (Recall that our EHR implementation was a "Big Bang" so transition was from paper to all electronic without phased introduction of functions or any pilot projects.) For some clinicians, voice recognition works well, with acceptable accuracy. For me, the accuracy is somewhere less than 85%. Some of the mistakes that are made result in text that at best has a number of embarrassing errors and at worst is nonsensical even to the creator of the note. Optimization of software by "training" is not feasible. It takes too much time and disrupts workflow when attempted on the fly. The output rate for voice to text during a dictation is unpredictable so that it can sometimes be near real-time but at other times as much as a sentence or 3 are printed after a delay, then all at once. Corrections on the fly completely disrupt productivity. Besides, with all the extra work the EHR engenders, I do not have the time nor is it the best use of my training to function as a copyeditor to fix transcriptions. I hesitate to admit that I am now resorting to typing most of my notes. This, I think, is definitely an unintended negative consequence of the EHR adoption. A solution that I favor is to have the hospital hire transcriptionists to review and edit each report. They would have access to the original voice files to help with the editing/correction task. (By the way, I used an earlier version of the voice recognition software the hospital licenses for a year in my private office during 2005-2006. I abandoned the software because of the unacceptable number of errors in my reports. I was actually "happy" to spend $1,000 a month to hire a skilled transcription service whose work I could rely on to be accurate and provide a professional result.)

One advantage of voice recognition software that I am impressed with is its potential to orchestrate navigation functions by voice commands rather through use of a mouse. Macros can be developed to facilitate tasks such as user logon, application launches, and page navigation among others. Programming can be as simple as recording a sequence of mouse clicks or it may require specialized programming training. Watch for increased use of voice controlled functions by users of HIT devices in the near future. Here is an interesting article I just read as I was preparing this post.