Spending New Year’s Eve supporting a Meditech go-live is not exactly how most people define fun, but it is how many at our hospital spent transitioning from 2011 to 2012. I heard someone state, “Wow, this go-live is just like Y2K; a non-event.”
What most CIOs will tell you is that the main reason Y2K was such a “non-event” is that the amount of work behind the scenes was like a Cecil B. DeMille production — comprising a cast of thousands that put in long hard hours making it a non-event. The same is true for our 6.6 go-live. The cast was not made up of thousands, but definitely hundreds put in countless hours and made it a major success. In the opinion of our Meditech representative, it was a 9 out of 10, and their best to date.
That having been said, it was not without its issues, but we were prepared. To start with, there were countless meetings ensuring everything was just right, most of the tasks were completed, and that contingency plans were in-place. We also had a great command-center model for go-live, having fitted one of our large conference rooms with extra network connectivity, PCs for testing, and telephones for communication. Also, since an army travels on its stomach, we got great support from our nutrition-services department that kept us feed, renewed, and refreshed throughout the event, especially in those wee hours of the morning when coffee and Red Bull were the order of the day.
I was exceedingly proud of how all our hospital staff stepped to the plate cross- organizationally to support the go-live. We truly lived our values and everyone stepped up to make things happen and support each other. There were numerous folks who worked over 12 hours at a stretch and also volunteered to step up and man a night shift. What a team! Some, like me, were up for 36 hours straight or more.
At the same time, I was a bit surprised at the level of expertise of the Meditech staff. Most problems had to be referred to their “development” teams, or level 2 staff, not on site. Also, one other thing I found interesting was that when a problem was brought into command central, our staff jumped on it like a duck on a June bug and ran without hesitation. Often, I got the feeling that the Meditech team just sat there with the “doe caught in the headlight look.” On a more positive note, Meditech was very responsive from the level-2 perspective, especially once the on-site teams left and we were moved to support mode.
Maybe my expectations of the vendor community are too high, but I do think I know a bit about customer service and could not have been prouder of our in-house staff, along with a few of our other vendors. For instance Fuji (PACS), Medhost, and Iatric were all “Johnny on the Spot” and very proactive in ensuring good support. Fuji, especially, checked with us at various points throughout the go-live night to see that things were flowing well.
So you ask, what went well and what could we have done better? Let’s start with printing. Every CIO I have spoken with listed PRINTING, PRINTING, PRINTING as one of their top three issues. We had done a significant amount of testing, but PRINTING was one of our issues too. We had strange things happen, like documents that printed fine in test, ultimately not formatting when live. Also, the font was an issue — in live the font was smaller than in the old Magic reports or screens. This was not a problem on all printers, as a report might show a readable font on one printer but then not on another. The answer from Meditech was these are canned reports and you need to rewrite them in report writer or NPR as a custom if you don’t like the font size. Luckily we have some wiz-bang technicians and they were able to address most of the problems through Windows related changes, rather than rewriting anything.
We also had lots of printing failures. Part of this was user education — that you have to select “local printer,” but also there was printer diagnosis and changes that needed to be made. We did also have lab reports and other items not printing. In the end, while lots of issues were customer related, there was at least one Meditech DTS that was required to resolve printing issues.
While on the topic of printing, we had to manage change and user expectations. Change is never easy, especially when things have been done a certain way for years. We had several trouble tickets from users along the lines of, “My report looks different,” or, “The font is too small.” In many cases, it was not a real problem, just the user adapting or, more importantly, being willing to adapt to a new screen, output, or process. It is human nature that when we migrate from one thing to another, you want the new to work just like the old. How many of you were frustrated when you had to go from Windows 98 to XP or Win2K? Some of you may have even gone to the WIN 98 or XP emulation mode in order to see things as they appeared in the older version. Managing that user experience is critical to the acceptance of 6.x, just like any new system.
Training became another issue. It was quickly clear who missed training altogether or did not try their log-in credentials when they were handed out. We got a plethora of, “How do I do this?” type of calls. On the plus side, we had a great support mechanism in place, with 24×7 super-user and IT response for the first week post-migration. Also, the Meditech PCM team that was onsite was responsive and got to the physicians quickly giving advice, training, or other support. How you train staff and provide support during your go-live (in relation to having super-users, analysts, and trainers readily available) can really drive your user satisfaction and make the transition more successful.
In terms of training, another issue is around the set-up of providers. The MIS Group has moved the training for building provider dictionaries to the Pat Reg Group. The only problem was they did not include that education as part of their training, so our staff and analysts had to work their way through things. Getting consistent guidance (or just poor instructions/communications) especially in how things needed to be configured was also an issue. For instance, we worked with the SCA team to setup providers so they could scan. Our analyst was instructed to add MRN to their application rights (Application Box in Provider Type Config screen), not knowing this is a restricted area and, if that is added, will bar access to all modules not listed. By the way, when blank, it is open access to all modules. Thus, the result was that after making the changes suggested, our providers could no longer be linked to registering a patient or even completing transcriptions, and we had to back the changes out or add all the modules they needed access to. This could have been easily avoided had proper training been provided.
The next challenge was in the NPR report area. As pointed out in my last article, we waited way too long to address converting or rewriting NPR reports. About one month before go-live, we were inundated in NPR reports that “were needed for go-live.” We had requests for more than 350 reports. Our solution was to engage a consulting organization to throw lots of hours into converting the reports. However, that having been said, their first order of business was to validate that the information in the requested report was not available as part of another 6.x report or in workflow. Using them in that manner eliminated over half the reports that required rewriting. Next, we assigned an analyst to work with the user community and truly decide proper prioritization to the remaining work required.
Then the real work could begin. We had several consultants work the high priority reports and assigned a technician (who had a desire to cross train into the Meditech support role) to work with the user community validating the completed reports and working with the consultants to make necessary changes. This provided the consultants some continuity in dealing with us and also kept us from burning valuable consulting hours chasing down users or trying to communicate technical challenges. One of 6.x differences was that just because a report was done in NPR did not mean it could be rewritten in NPR in 6.x. Some had to be redone in report writer and required different consulting resources and, even more critically, some reports had to be spilt into 2 (1 set of data in NPR and 1 in report writer). While the cost of this solution exceeded $40,000 in consulting hours, it did get the most critical reports redone in an expedient manner. It was also a lesson for future initiatives that just because we have staff capable of handing the task does not mean they necessarily will have the bandwidth to complete the task. This must be recognized and addressed as early as possible.
Many of you might also remember that with 6.x we grew to over 70 interfaces. Most transitioned well into the live environment, but we did have some that somehow “changed” from test to live. Having interface programs on standby to deal with these issues allowed for quick resolution to problems. We also moved quickly into the post live development of EMR interfaces. The biggest interface challenge was related to discreet data, especially medication reconciliation and home meds. These are scripts most of the vendors have had little to no experience transferring to 6.x. Also, these fields are apparently hard coded in 6.x and difficult to hook to. We had to move to twice-a-week interface development meetings to keep these going and on track. Also, in discussion with our interface vendor, we found they too are struggling with the 6.x product since much of the interface scripting was initially done in NPR for testing, and now that data might not be accessible via NPR.
Another issue we are working on is that all the existing reports need to be recompiled before available to the user community as menu options. We had to have a lengthy discussion on who owns what and who should be the person doing the compiling. It will vary for each organization and also, at times, department. Another challenge in adding new compiled reports is where did the person who wrote the report pull the data from, and is someone doing a validation of what we want the report to actually deliver in the way of information.
Do not be surprised that your IT staff will not get a break post go-live. There will be lots of little things to handle that can easily overwhelm, especially if the user community comes out with a key item that was forgotten prior to go-live. I would recommend you spend lots of time testing with your referring physicians who get lab/rad reports or other documents faxed, printed, or sent to them in some manner. Also, make sure the referring physicians who might access MAGIC remotely have training and proper access under 6.0.
You will also be doing BAR and HR conversions post go-live, and that will require your analysts to be available for scripting and validating data. Our CFO was personally involved in meetings and working with his staff during this phase. As a matter of fact, I think another one of the reasons for our success was the ownership and backing all our executives provided — both directly and indirectly — in supporting their teams and the project as a whole. It was also seen not as an IT project but as an organizational strategy.
While I could go on and on discussing our go-live and pre go-live experiences, I will leave it with, “things went better than expected” due to the effort of, not myself, but a great team and supportive peers. We still have ESS, CPOE, and Budget Forecasting modules to go-live on in May so I will continue to write monthly columns between now and completion. Next month, I will discuss medication reconciliation, home meds, and downtime procedures as well as changes in how we think about Meditech as both a product and process tool.