Meditech 6.0 Diary Part 17 – Addressing Post Go-Live Gripes

So it has been 8 weeks since our go-live. It is always interesting for me to note the things that start to creep up post go-live that could, and should, have been caught during the pre-go-live build. The following is our experience, and will hopefully help you identify processes or items to address in your migration.

To start with, it came as a surprise to our super user community that with the NPR report changes, we also lost the ability to spool file functionality. For those that don’t remember, “Spooling” is basically transferring data or jobs to another, sometimes temporary, working area for another program to work with or execute. With this functionality gone, finance departments are hit hard as reports that used to be processed in the background of a server or other device now get processed on the user’s PC or main server, often taking up valuable memory resources or CPU cycles. In other words, it can really slow down a user’s PC.

While the ability to schedule reports to run without the user at their workstation still exists, there are many reports needed during the day that need to run in a mode where the user has minimized the processing or job window. Since many users have numerous windows open, it is easy to close the one running jobs or accidentally kill the report being run. Perhaps the biggest frustration was that the users were never told this feature, which they were so used to, would no longer be active and, while my analysts were aware of this, even I as the CIO was never informed. Additionally, our staff did nothing in the way of alternatives to provide similar functionality.

The moral of the story is communication is everything!  Had we worked with the user community in advance, they would have been ready and hopefully put in place adaptive processes to deal with the changes. Had I known, we could have worked with consultants or others, and gathered lessons learned from other organizations on how to deal with that change. Some organizations are moving report files to SharePoint and processing them there, and others are using 3^rd party applications. Figuring out how to deal with this before go-live will go a long way to customer satisfaction with 6.x.

Another communication that sets proper expectation is to work with and inform your CFO that they will likely not be able to get out a financial statement for at least 60 days post go-live. The first reason is that your BAR conversion will take at least 2 weeks and possibly 3. Once that is complete, your finance department will likely have at least a week’s worth of data validation to complete. Also, some organizations chose to wait for that process to complete to enter the budget data required for move forward. I will come back to this in a minute, but related to this is that many of the canned Meditech reports in Finance have changed. For instance, in our environment at least, the monthly revenue report no longer differentiates between in-patient and out-patient. While we opened a ticket on this, the response is still that it will need to be sent to their development group which most of you know equates to: don’t expect it with any urgency.

While it was expected for users and dictionary teams to fully test all their access, reports, and other functionality; there were often surprises with access rights, levels, or reports. Canned reports had sometimes changed or data that used to be there seemed to be missing. From the IT part, we waited way too long to address the over 400 reports we were requested to rebuild. In all honesty, we sent out a request for NPR reports about 5 months prior to go-live, but got so busy we just plum forgot to follow up with users. We did not get any response until about a month prior to go-live, and were then inundated with requests. At this point, let me state that many of the requested reports were not needed, as they were now in 6.x workflow or available via other means. It still takes significant time to figure that out and educate the user. To recreate a report averages both our internal staff and consultants over 8 hours each. With 200 actual reports needing recreation that can easily cost you 200 man-days. If you are planning to outsource that, make sure it is in your budget early and that you have contracts in place.

Also a lesson we learned is that you can’t effectively have the report creation consultants working with the user community one-on-one. You really need an IT resource that you can dedicate to facilitate that interaction and keep things moving forward. You need someone who can speak the language of the user and the consultant and often translate needs or wants. That resource can also be very valuable in assisting with the test/validation of reports. Why is that important?  First-off, about 10% of the reports we got back as completed either did not run at all or had significant missing data elements. Secondly, many users don’t understand how to fully validate that the report presented to them works, or was actually what they were looking for.

As I am sure you are tired of hearing me lament about reports, I will only say 2 more things. One is to not forget your regulatory reports due to State, Press Ganey, or other entities, especially ones associated with penalties or other negative impacts. Additionally, I suggest a few months before go-live you sit down with your CFO and look at the canned reports available in both systems, as well as the custom ones you have in Magic. Then have a discussion around, if we were to start fresh, what would we really need in a series of financial or clinical reports? Do we not convert anything, just build those as part of a fresh start?

I talked a bit about the time required for the BAR conversion. The DR conversion takes even longer. During that time, historical data can still be pulled out of Magic but any DR housed data since go-live will likely not be available for reporting or business analytic purposes. Also, the DR migration is in stages with more than one batch load required. If you have a decision support department that is working with their customers, executives, or projects, discuss the impact of DR not being available with them — don’t just leave them hanging. Try to figure out what you can do and how to meet their voracious data requirements in the interim.

In terms of problems, we ran into a unique problem. All of a sudden in the middle of the night, we had servers locking up for no apparent reason. Meditech looked at it and could find no root cause. We noted that memory utilization on one of the servers was over the top, but no root cause for it. This went on for several days and our IT support staff went nuts with hours upon hours of after-hour calls. Then it magically went away. I spoke with some 6.x peers about this and the comment that resonated the most was, “welcome to 6.x” (LOL). An unwelcome greeting indeed …

What did come out of it though was an interesting discussion/debate with the Live CIO user group (more on this later) on how to reboot your Meditech 6.x servers. The official stance from Meditech is that their product does not need server reboots, but that you should follow Microsoft best practice management. Like most hospitals, we have 37 Meditech 6.x servers and another 25 CITRIX servers. The various hospitals CIOs had an interesting communication on how often they reboot or apply MS patches. The answer was anywhere from once a month to once every 6 months, with 1-2 months probably the most prevalent. But what exactly is MS best practice? When you figure it out, will someone please let me know….

That having been said, it is important to note that there is a pretty exact methodology for performing these reboots. We asked for that from Meditech but got a short list of things to do that many of the CIOs agreed was not near detailed enough. One of the CIOs who was live for a while shared a great document of what he found works well. I won’t get into the details here, as it was several pages long, but suffice to say there is a method that really should be followed. If interested, contact me and I will email you the document but use at your own risk — we assume no liability for it.

Ok, so what is this CIO group I keep referring to?  Once live, there is a group of CIOs that meet regularly on a conference call and act as a discussion group to bounce information requests and 6.x related items off each other. It is invitation-only and CIO hosted. Meditech does have a standing invitation to the calls, and we have a valuable exchange with them around problems, practice, and successes. On the call I attend, some the 6.x development team was present and listened to our challenges and needs. While they were not able to help us with some issues, they did note that often items we present lead to fixes or process changes for future installs or clients.

There were several characteristics I noted about that group, but a couple of the most striking benefits are that you realize you are not in it alone, and many of your experiences related to product, training, and support are shared by others (sort of a nice sanity check). Secondly, it’s amazing how willing the group was to help each other and provide suggestions, guidance, or just provide a safe outlet for whining. It never ceases to amaze me, though, that competitor hospitals or CIOs can be on a call or part of a group like this and instead of there being any kind of competitive dialog, it is collaborative, healthy, friendly, and helpful. This group is definitely a user group that adds value and makes me look forward to our meetings.

We went to training on CPOE a couple of weeks ago. Some interesting questions that led to the creation of Meditech tasks were:

• Who is your physician champion or lead?
• Have you contracted with Dr.First for e-prescribing?
• Have you met with your ARRA Team?

I will get into that and other CPOE-related items like physician champions, order sets, and e-prescribing (don’t miss that one) in next month’s article. Enough for now, I hope to add value for you next month.